v2 build tracker

[FSM1]

The v2 build tracker. Milestone v2.0.0, label v2-build. The blueprint corpus (blueprint/*.md, CONTEXT.md) is normative; blueprint/testing.md law 1 applies to every slice — its suite blocks merges in a named CI job the day it lands.

This tracker is a sub-issue tree, not a checkbox list. Every slice lives under one of the nine children below and its state rolls up automatically. Nothing is tracked in this body.

The tracks

Track	Scope
#989 core	The crates/core codec, crypto suite, frozen KDF edge catalog, envelope and seal, grant section, IPNS records, content sealing
#990 api	The apps/api residual surface — identity auth, pin and name registry, hosted upload, mailbox, in-process republisher
#991 engine: foundation	Seams and conformance kits, the API client and contract suite, the adoption gate and floor law, resolve and publish, the sync core, grants, rotation, facade cold-start
#992 engine: write plane	The frozen content format, op-record rewrap, publishing every op kind, drain failure policy, content upload, vault settings, pin providers, prune
#993 web	crates/wasm bindings and the WASM KAT gate, browser seams, engine worker hosting, tab leadership, the Service Worker byte pipe, the web shell and views
#994 desktop	Hardware gates, the Tauri shell, the desktop seam set, the crates/fuse operation core, the FUSE-T SMB, libfuse3, and WinFsp adapters, mount lifecycle
#995 ci	The main e2e gate and cross-client matrix, the nightly tier, the performance and load harnesses, staging build config
#996 deploy	The staging cutover to the v2 stack, release management at the first v2.0.0 RC, the v2 Grafana dashboards
#719 retro-audit	Cross-cutting simplify and minor-hardening backlog from the retro sweep of shipped v2 PRs — sits on no slice's critical path

Critical path

Core is the critical path. api and the desktop hardware gates can start immediately; parallel tracks are fine wherever each issue's own dependencies allow. The write plane was designed on wayfinder map FSM1/cipher-box-next#813 and decomposed by FSM1/cipher-box-next#825.

Sub-issue parentage and blocked_by dependencies are separate graphs — this tree does not encode blocking order. Each issue carries its own hard dependencies.

Working a slice

implement → /verify → /security-review (plus /crypto-privacy-review when the diff touches crypto) → /simplify → /ship.

[FSM1]

Owed follow-ups filed today, to slot into build order:

• engine: rotateScope owner-revocation eager cascade republishes every descendant scope root with a fresh override seed #749 — rotateScope owner-revocation eager cascade (read-revoke completion; Part of engine: implement rotation primitives, sweep, name wave, and grants #635, dependent on Enforce scope_id-to-gated-record binding in the ChildIndexResolver wiring slice #745 / Decide conflicting scope_id-to-ipns_name resolution in the eager-set walk #746 wiring).
• engine: compose eol_republish sub-EOL seq+1 renewal into the cold-start liveness loop #750 — compose eol_republish sub-EOL seq+1 renewal into the cold-start liveness loop (deferred from feat(engine): wire the liveness re-PUT scheduler into facade cold-start #739; blocked on cold-start identity derivation).
• engine: populate the liveness held-record set from the live resolve path #751 — populate the liveness held-record set from the live resolve path (deferred from feat(engine): wire the liveness re-PUT scheduler into facade cold-start #739; blocked on live-session resolve wiring).

Note: #750 / #751's host — the facade cold-start identity-derivation / live-session resolve wiring — is not a discrete open slice-issue in this tracker (the #628 resolve pipeline is merged; the full facade cold-start assembly is not separately tracked). Flagging so these two get an explicit home before they orphan.