Add Keepable Software as a CCCP thematic strand (#37)

## What

Integrates **Keepable Software** into CCCP in two ways:

1. As an **integral constitutional principle** of the main manifesto
(`README.adoc`); and
2. As an **independent, referenceable thematic strand**
(`docs/strands/keepable-software.adoc`) that adopter projects can cite.

Core idea:

> Software should remain runnable, inspectable, forkable, exportable,
and meaningfully ownable by the person who downloads it.

## Framing (important)

Keepable Software is **one CCCP aspiration among many**, not a
replacement for anything. It sits alongside the language policy,
technical excellence, distributed state, formal verification, community,
and offline-first autonomy. Part of the guarantee lives in the **code**
(what runs locally, what is exportable/forkable) and part in the
**licence** (what the user is legally free to keep, run, inspect, fork).
Good languages and sound engineering remain the foundation; keepability
is a property that foundation should produce. The README now says this
explicitly so the manifesto stays coherent.

Nexia-List appears only as a **brief reference example** of a project
applying this strand — not as the source or sole definition of the
principle.

## Changes

- **`README.adoc`**
- New `== Keepable Software` section (near the Citadel), with the
"download it, keep it, run it, inspect it, fork it" quote.
- `Offline-First as Autonomy` extended with keepable-software bullets +
a cross-reference to the new section.
- New `== CCCP Thematic Strands` catalogue (before `CCCP Certification`)
linking the strand doc.
  - `Political` temperature row now mentions keepable-software design.
- Explicit "one aspiration among many, does not replace the rest"
framing paragraph.
- **`docs/strands/keepable-software.adoc`** — full strand definition
(status, design commitments, web-first-not-web-captive, adoption
criteria, non-goals, Nexia-List reference example, badge text).
- **`.machine_readable/cccp/strands/keepable-software.yml`** —
machine-readable strand metadata.
- **`docs/badges/keepable-software.adoc`** — badge guidance.

## Notes / deviations from the brief

- README strand link uses `link:docs/strands/keepable-software.adoc[…]`
rather than `xref:`, to match the README's existing cross-file
convention (`link:CONTRIBUTING.adoc`, `link:TOPOLOGY.md`) and render
correctly on GitHub. It points at the real file.
- SPDX/copyright headers added to the new `.adoc`/`.yml` files to match
repo convention.
- Nothing was removed; existing CCCP/RSR language around political
autonomy, offline-first, and anti-lock-in is untouched and only
extended.
- No local `asciidoctor` available to render-check; validated structure
manually (section anchors `_keepable_software` /
`_cccp_thematic_strands` resolve, link target exists) and confirmed the
YAML parses.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: hyperpolymath

.machine_readable/cccp/strands/keepable-software.yml

@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: CC-BY-SA-4.0
+# Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
+id: cccp.keepable-software
+name: Keepable Software Strand
+campaign: Campaign for Cooler Coding and Programming
+status: proposed
+summary: >
+  Software should remain runnable, inspectable, forkable, exportable,
+  and meaningfully ownable by the person who downloads it.
+
+principles:
+  - local-first where practical
+  - offline-capable where possible
+  - web-first is acceptable; web-captive is not
+  - meaningful downloadable artefact
+  - inspectable build path
+  - exportable user data
+  - no mandatory remote execution for core experience unless clearly justified
+  - honest declaration of remaining service dependencies
+
+preferred_phrases:
+  - web-first, not web-captive
+  - anti-hostageware
+  - anti-confiscation-by-architecture
+  - download it, keep it, run it, inspect it, fork it
+
+anti_patterns:
+  - hostageware
+  - confiscation-by-architecture
+  - service-only ownership
+  - opaque remote execution as the only runtime
+  - data export as an afterthought
+  - user work trapped behind subscription or platform continuity
+
+adoption_questions:
+  - Can a user keep a meaningful copy?
+  - Can a user run a meaningful version without the original service?
+  - Can a user inspect the code or build process?
+  - Can a user export their data?
+  - Can the project survive a hosting provider, app store, API, or vendor disappearing?
+  - Are remaining external dependencies named honestly?
+
+reference_examples:
+  - name: Nexia-List
+    role: reference adopter
+    claim: local-first browser software with a Rust/WASM client-side core
+    note: >
+      Nexia-List is cited only as an example of the strand, not as the origin
+      or sole definition of the principle.

README.adoc

@@ -47,7 +47,7 @@ CCCP defines *principles and policies* for building software that is:
 | Warm community with graduated trust, cool-headed technical decisions
 
 | *Political*
-| Resistance to monopolistic tooling, anti-corporate lock-in, autonomy through offline-first design
+| Resistance to monopolistic tooling, anti-corporate lock-in, autonomy through offline-first and keepable-software design
 |===
 
 == Core Principles
@@ -65,6 +65,13 @@ Rejecting the npm/node ecosystem's fragility in favor of:
 * Work continues without constant connectivity
 * No cloud-dependent tooling
 * SaltRover for offline repository management
+* Local execution where practical
+* Offline-capable operation where possible
+* Exportable user data
+* No mandatory remote execution for the core experience unless clearly justified
+* Hosted services may enhance the project, but must not become hostage architecture
+
+This principle extends into the <<_keepable_software,Keepable Software>> section below: offline-first is one of the ways CCCP keeps the user's software, data, and work from disappearing behind someone else's switch.
 
 === 3. Distributed State Without Coordination
 
@@ -227,6 +234,28 @@ The *Citadel* is where RSR meets CCCP — the actual implementation pattern that
 * *Collective Defense* — Architecture makes mutual aid easier than isolation
 * *Safe Haven* — Emotionally and technically safe to experiment
 
+== Keepable Software
+
+CCCP treats user ownership as an architectural property, not merely a licence statement.
+
+Software should remain runnable, inspectable, forkable, exportable, and meaningfully ownable by the person who downloads it.
+
+This does not require every project to reject the web, cloud services, sync, accounts, or hosted infrastructure. It requires that those service layers do not become the only place where the user's software, data, or work can exist.
+
+CCCP therefore prefers projects that are web-first without being web-captive, local-first where practical, offline-capable where possible, and honest about remaining external dependencies.
+
+Keepable Software is *one* of CCCP's aspirations, not the whole of it. It sits alongside the language policy, technical excellence, distributed state, formal verification, community, and offline-first autonomy described elsewhere in this manifesto — and it does not replace any of them. It is a better way of doing things rather than a new gate: part of the guarantee lives in the code (what runs locally, what is exportable, what is forkable), and part lives in the licence (what the user is legally free to keep, run, inspect, and fork). Good languages and sound engineering remain the foundation; keepability is one of the properties that foundation should produce.
+
+In short:
+
+[quote]
+____
+Download it. Keep it. Run it. Inspect it. Fork it.
+Do not make the user's own work disappear behind someone else's switch.
+____
+
+Keepable Software is both an integral CCCP principle and a named thematic strand that adopter projects can reference. See <<_cccp_thematic_strands,CCCP Thematic Strands>> for the strand catalogue.
+
 == Relationship to RSR
 
 [source]
@@ -246,6 +275,14 @@ Your Repository (Implementation)
     └── Politically autonomous
 ----
 
+== CCCP Thematic Strands
+
+CCCP principles may be expressed through named thematic strands: focused design commitments that projects can adopt, test, and refine.
+
+Current strands include:
+
+* link:docs/strands/keepable-software.adoc[Keepable Software] — web-first, not web-captive; downloadable, inspectable, forkable, exportable, and meaningfully runnable by the user.
+
 == CCCP Certification
 
 Projects can display CCCP certification when they:

docs/badges/keepable-software.adoc

@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: CC-BY-SA-4.0
+// Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
+= Keepable Software Badge
+
+Projects that adopt the CCCP Keepable Software Strand may use:
+
+----
+CCCP: Keepable Software
+----
+
+Suggested Markdown badge:
+
+----
+[![CCCP: Keepable Software](https://img.shields.io/badge/CCCP-Keepable%20Software-c41e3a)](https://github.com/hyperpolymath/cccp/blob/main/docs/strands/keepable-software.adoc)
+----
+
+Suggested README wording:
+
+----
+This project follows the CCCP Keepable Software strand: web-first where useful, not web-captive by design.
+----

docs/strands/keepable-software.adoc

@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: CC-BY-SA-4.0
+// Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
+= Keepable Software Strand
+:toc:
+:sectnums:
+
+== Status
+
+CCCP thematic strand: proposed / experimental
+
+== Summary
+
+The Keepable Software Strand names a CCCP design commitment:
+
+[quote]
+____
+Software should remain runnable, inspectable, forkable, exportable, and meaningfully ownable by the person who downloads it.
+____
+
+This strand covers projects that are web-accessible but not web-captive.
+
+A Keepable Software project may use a browser interface, optional sync, hosted builds, update services, or companion infrastructure. However, the user's ability to run a meaningful version of the software must not depend entirely on a continuing subscription, remote execution service, central vendor, proprietary runtime, or disappearing platform.
+
+== Core Intention
+
+Keepable Software is not anti-web.
+
+It is anti-hostageware.
+
+It is not anti-cloud.
+
+It is anti-confiscation-by-architecture.
+
+It is not nostalgia for desktop software.
+
+It is a modern design discipline for software that users can keep.
+
+== Design Commitments
+
+A project following this strand should aim to be:
+
+* local-first where practical;
+* offline-capable where possible;
+* downloadable as a meaningful artefact;
+* inspectable by technically competent users;
+* forkable under a recognised software licence;
+* exportable in relation to user data;
+* runnable without mandatory remote execution for the core experience, unless clearly justified;
+* portable across reasonable platform churn;
+* honest about which parts still depend on external services.
+
+== Web-First, Not Web-Captive
+
+A project may be web-first if the browser is the main user interface.
+
+A project becomes web-captive when the browser is only a window onto somebody else's disappearing machine.
+
+A CCCP-aligned web-first project should therefore prefer:
+
+* client-side execution where practical;
+* WebAssembly for real local engines where appropriate;
+* progressive web application patterns;
+* exportable user data;
+* documented build and recovery paths;
+* minimal dependency on platform-specific stores or accounts.
+
+== Adoption Criteria
+
+A project may claim alignment with the Keepable Software Strand when it can answer these questions clearly:
+
+. Can a user keep a meaningful copy?
+. Can a user run a meaningful version without the original service?
+. Can a user inspect the code or build process?
+. Can a user export their data?
+. Can the project survive a hosting provider, app store, API, or vendor disappearing?
+. Are remaining external dependencies named honestly?
+
+== Non-Goals
+
+This strand does not require every project to be fully offline.
+
+It does not require rejecting all servers, clouds, accounts, APIs, or hosted services.
+
+It does not require pretending that maintenance, security updates, and ecosystem dependencies are free.
+
+It only requires that the project does not deliberately make the user helpless when the service layer changes.
+
+== Reference Example: Nexia-List
+
+Nexia-List is a reference example of this strand.
+
+It is local-first in design and web-first in interface. Its primary target is the browser. Its Rust core is intended to compile to WebAssembly so the real engine can run client-side, with no server required for the essential experience.
+
+A desktop shell may exist as an optional external layer, but the browser remains the primary interface.
+
+The relevant CCCP claim is not that Nexia-List avoids the web. The claim is that it aims to be web-first without being web-captive.
+
+== Badge Text
+
+Suggested badge label:
+
+----
+CCCP: Keepable Software
+----
+
+Suggested badge meaning:
+
+----
+web-first, not web-captive
+----
+
+== Short Form
+
+Keepable Software means:
+
+[quote]
+____
+Download it. Keep it. Run it. Inspect it. Fork it.
+Do not make the user's own work disappear behind someone else's switch.
+____