Track the warp-drive-g2b scaffold retirement (plus: control-projection governance sketch)

[flyingrobots]

Rewritten after review. The first version bundled a grounded tracking item with a speculative design proposal and presented both as established. They are now separated, and the design half is explicitly marked as exploration.

Part 1 — Grounded: a committed retirement that nothing tracks

docs/topics/RuntimeConstellation.md contains this row:

Surface	Durable owner	Posture	Boundary
warp-wasm WARP DRIVE scaffold	No durable owner	Retire after aperture conformance exists	"A synthetic query bridge must not masquerade as the filesystem contract"

Nothing in the tracker follows that commitment. The scaffold is crates/warp-wasm/src/lib.rs's experimental_warp_drive_g2b module, behind a Cargo feature of the same name, registering one hardcoded query id (0x5744_4732, ASCII WDG2). A stock build without the feature refuses it with UNSUPPORTED_QUERY; there is a test asserting exactly that.

It is currently WARP DRIVE's only path to Echo-projected file bytes.

Supporting evidence that it is inert rather than evolving: across the 264 commits between WARP DRIVE's pinned Echo seam branch and current main, 154 files changed and none are in crates/echo-wasm-abi/ or crates/warp-wasm/.

This part is a real tracking gap and should stay open.

• Retirement is tracked against a named conformance condition rather than left implicit.
• Once that condition is met: delete the feature and query id, strike the RuntimeConstellation row.
• The retirement condition itself depends on Decide the file-aperture contract boundary and representation #719, which is now a design issue — so this is blocked, not ready.

Part 2 — Exploration only: how control projections should be governed

The following is a proposal I generated while auditing, not an established requirement. It should not be treated as accepted work.

/echo/head.json — the file the scaffold serves — fits none of Echo's existing I/O categories. It is not workspace content governed by echo-file-aperture, and it is not an external-action boundary crossing. It currently has no contract at all: a hardcoded experimental query id, no declared serialization, no selected revision, no reserved namespace, no declared owner.

One reading is that it is a control-plane projection and deserves its own class:

workspace aperture        governed by echo-file-aperture
    /projects/foo/readme.md       identity, basis, intents, receipts

control projection        governed by a query contract
    /.echo/head.json              pure projection at a selected revision
    /.echo/history/...            no basis, no intents, no receipts
    /.echo/status/...             read-only by construction

With a possible namespace-ownership split: WARP DRIVE already reserves /.warp/ for its own mount diagnostics (/.warp/stats, /.warp/runtime), which are the mount's control plane, distinct from Echo's data.

Caveats on the above, stated plainly:

• It generalizes from a single synthetic fixture (/echo/head.json) that exists only to satisfy one WARP DRIVE gate. One data point is thin ground for a namespace doctrine.
• The /.echo/ path convention is invented here, not drawn from any existing Echo decision.
• Whether control projections need governance at all depends on whether more of them are coming, which nobody has established.

Treat Part 2 as a design sketch to accept, modify, or discard — not as scoped work.

Origin

Found auditing the Echo/WARP DRIVE seam at echo c354d53 / warp-drive 63b1f9e.

[coderabbitai]

🔗 Related PRs

#326 - Echo contract hosting roadmap [merged]
#382 - 0024 universal LE binary codec + 0025 sessions design (design-only) [merged]
#389 - warp-wasm: add WARP DRIVE G2b query projection [merged]
#540 - Add Echo-owned file aperture [merged]
#683 - Execute admitted data-only operations in Echo [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!