CIP-001–013: read/write distributed storage program

README.md

@@ -136,8 +136,9 @@ lifecycle. See the unit header for GPU/role customization via `systemctl --user
 ```
 .
 ├── docs/
-│   └── c0mpute-v1.md                  # v1 PRD (source of truth)
-├── dips/                              # design proposals
+│   ├── c0mpute-v1.md                  # v1 PRD (source of truth)
+│   └── prds/                          # CIPs — per-phase PRDs (see prds/README.md)
+├── dips/                              # design proposals (the "why")
 ├── node/
 │   └── crates/                        # all Rust source — host + transcode workload
 │       ├── c0mpute-cli/                 # produces `c0mpute`

dips/0012-no-storage-network.md

@@ -1,17 +1,30 @@
 ---
 dip: 0012
 title: "c0mpute is compute-only; we don't run a storage network"
-status: Accepted
+status: Superseded
 authors:
   - anthony@profullstack.com
 created: 2026-05-03
-updated: 2026-05-03
+updated: 2026-08-29
 discussion:
 implementation:
 supersedes:
-superseded-by:
+superseded-by: DIP-0012 (0012-storage-plugin.md)
 ---
 
+> **Superseded.** This is draft v1 of DIP-0012 and no longer describes the
+> project's position. It was withdrawn in favour of
+> [`0012-storage-plugin.md`](0012-storage-plugin.md), whose motivation table
+> records this draft and why it was dropped — the file simply never had its
+> status updated, leaving two `Accepted` DIP-0012s on disk asserting opposite
+> things.
+>
+> **c0mpute hosts files.** See the storage-plugin DIP for the current design,
+> and [`docs/prds/`](../docs/prds/README.md) (CIP-001 onward) for the delivery
+> plan. The cost analysis below is still worth reading: the five structural
+> overheads it identifies are real, and CIP-001 and CIP-005 are largely
+> answers to them.
+
 ## Summary
 
 c0mpute is a **compute marketplace**, not a storage network. Customers

dips/0012-storage-plugin.md

@@ -258,6 +258,21 @@ egress as the differentiator. **No claim of "cheaper than R2."**
 
 ## Out of scope
 
-- Filesystem-style mutable objects. Content-addressed, immutable.
+- ~~Filesystem-style mutable objects. Content-addressed, immutable.~~
+  **Amended 2026-08-29:** c0mpute ships a read/write POSIX mount. See
+  [CIP-007](../docs/prds/007-c0mputefs-filesystem.md). The immutability
+  property is preserved where it matters — blocks, manifests, and snapshot
+  nodes are still content-addressed and immutable. Mutability is confined to
+  advancing one signed 32-byte root pointer per volume
+  ([CIP-004](../docs/prds/004-metadata-durability.md)); the filesystem is a
+  naming layer above that, not a change to the storage layer.
 - Permanent / Arweave-style storage.
 - IPFS interop — could add later as a read-only adapter.
+
+## Delivery plan
+
+Phases 1–5 above are elaborated as CIPs in
+[`docs/prds/`](../docs/prds/README.md). CIP-001 supersedes the pricing figures
+in this DIP: tiered pricing at $0.0035/GB-month for RS 10/14 `standard`, based
+on an expansion-factor advantage over Storj rather than on the $0.008 estimated
+here.

dips/README.md

@@ -5,6 +5,13 @@ crosses a project-policy line, or is hard to undo once shipped. DIPs are
 where we record the *why* behind durable decisions so future contributors
 don't have to reverse-engineer them from git history.
 
+> **DIP or CIP?** A DIP records *why we decided something*. A
+> [CIP](../docs/prds/README.md) — c0mpute Improvement Protocol, in
+> `docs/prds/` — is a PRD for a shippable phase: scope, API surface,
+> acceptance criteria, estimate. A CIP implements a DIP and cites it. If a CIP
+> finds its governing DIP is wrong, the fix is a new DIP, not a CIP that
+> quietly contradicts one. Numbering is independent between the two.
+
 If a change is small, local, and obvious from the diff — just open a PR. DIPs
 are for the things you'd want to read about a year from now.
 
@@ -105,7 +112,8 @@ superseded-by: <DIP-NNNN if this gets replaced>
 | 0009 | Mojo for GPU/kernel-shaped compute (when applicable)             | Accepted   |
 | 0010 | Operator-run seed nodes for libp2p Kad-DHT bootstrap             | Accepted   |
 | 0011 | No central backend; libp2p + CoinPay are source of truth         | Accepted   |
-| 0012 | c0mpute is compute-only; storage is BYOS                         | Accepted   |
+| 0012 | c0mpute hosts files: Reed-Solomon 10/14, compute-locality value   | Accepted   |
+| 0012 | ~~c0mpute is compute-only; storage is BYOS~~ (draft v1)           | Superseded by `0012-storage-plugin.md` |
 | 0013 | Position: GPU batch-compute marketplace; 5–8× cheaper niche      | Accepted   |
 | 0014 | Public /status page + status-aggregator service                  | Accepted   |
 | 0015 | Hosting vertical: censorship-resistant static sites              | Draft      |

docs/prds/000-template.md

@@ -0,0 +1,62 @@
+---
+cip: 000
+title: "Short imperative title — what ships"
+status: Draft
+authors:
+  - you@example.com
+created: 2026-08-29
+updated: 2026-08-29
+implements: DIP-NNNN
+depends-on:
+blocks:
+implementation:
+estimate:
+---
+
+## Summary
+
+One paragraph. What is being built, and what can a user do at the end of it
+that they couldn't before? A reviewer should be able to read this and decide
+whether to keep reading.
+
+## Goals
+
+Bulleted, concrete, testable. "Fast" is not a goal; "p99 read latency under
+400 ms for a 4 MiB block" is.
+
+## Non-goals
+
+What this phase deliberately leaves undone, especially things a reader will
+otherwise assume are included. Point at the CIP that covers each one.
+
+## Design
+
+The actual proposal. Be specific enough that someone else could build it:
+
+- New API surface (routes, CLI flags, config keys, on-disk formats)
+- Data structures and wire formats
+- Failure modes and what happens in each
+- Which crates change, and roughly how
+
+## Acceptance criteria
+
+A numbered checklist a reviewer can actually run. Each item is a command, a
+test, or an observable behaviour — not a feeling.
+
+1. `cargo test -p c0mpute-store` passes with N new tests covering X.
+2. …
+
+## Risks
+
+What could make this take twice as long, or ship broken. Include the mitigation
+for each, or say plainly that there isn't one yet.
+
+## Estimate
+
+A range, with the assumption behind it (one engineer? two? familiar with the
+codebase?). Break it down if the phase has distinct chunks.
+
+## Open questions
+
+Things intentionally unresolved. These should shrink to zero before status
+moves to Approved.