docs: package phase 17 product claim checkpoint

Freeze the first Phase 17 branch/contract/policy/envelope package, add review and supported-matrix artifacts, and sync the product-completion and claim-evidence ledgers to the new bounded post-Phase-16 checkpoint.

Made-with: Cursor

sw-block/.private/phase/phase-17-checkpoint-review.md

@@ -0,0 +1,183 @@
+# Phase 17 Checkpoint Review
+
+Date: 2026-04-04
+Status: ready for review
+
+## Review Object
+
+Review the current `Phase 17` checkpoint as:
+
+1. `Phase 16` finish-line checkpoint accepted as the bounded runtime stop-line
+2. `17A` delivered as a broader recovery/lifecycle branch map
+3. `17B` delivered as a bounded failover/publication whole-chain contract draft
+4. `17C` delivered as a long-window restart/disturbance policy draft
+5. `17D` delivered as a first launch-envelope draft
+
+This checkpoint should be judged as a bounded product-claim checkpoint, not as a
+broad production-readiness or rollout-approval review.
+
+## What Is In Scope
+
+### Current checkpoint claim
+
+The checkpoint may now claim that, for the bounded chosen path:
+
+1. the broader recovery/lifecycle branches are explicitly enumerated and no
+   longer hidden in implementation-only reasoning
+2. one bounded failover/publication whole-chain statement is explicit and tied
+   to named evidence
+3. long-window restart/disturbance handling is expressed as explicit runtime
+   rule, explicit temporary inconsistency policy, or explicit non-claim
+4. the first launch envelope is finite, with supported scope, exclusions, and
+   launch blockers written down
+
+### Expected judgment
+
+1. the checkpoint is a real product-claim-shaping step, not only wording
+2. claims, non-claims, and blockers are evidence-backed and bounded
+3. the stop-line remains disciplined: nothing here should silently broaden into
+   generic launch approval
+
+## What Is Explicitly Out Of Scope
+
+Do NOT review this checkpoint as claiming:
+
+1. broad generic production readiness
+2. support for every restart/failover/disturbance branch
+3. broad transport/frontend matrix support
+4. `RF>2` product closure
+5. pilot success or soak success as generic production proof
+
+## Primary Files
+
+Checkpoint framing:
+
+1. `sw-block/.private/phase/phase-17.md`
+2. `sw-block/.private/phase/phase-17-checkpoint-review.md`
+3. `sw-block/design/v2-first-launch-supported-matrix.md`
+4. `sw-block/design/v2-product-completion-overview.md`
+5. `sw-block/design/v2-protocol-truths.md`
+6. `sw-block/design/v2-protocol-claim-and-evidence.md`
+
+Primary evidence code/tests:
+
+1. `weed/server/master_block_registry.go`
+2. `weed/server/master_block_registry_test.go`
+3. `weed/server/qa_block_publication_test.go`
+4. `weed/server/qa_block_disturbance_test.go`
+5. `weed/server/qa_block_cp11b3_adversarial_test.go`
+6. `weed/server/volume_server_test.go`
+
+## Accepted Claim Set
+
+1. broader recovery/lifecycle branches on the chosen path are now classified as
+   closed, partially proven, or residual
+2. one bounded failover/publication contract is explicit:
+   after failover completion and winning-primary assignment delivery/applied,
+   lookup/publication must point to the winning primary and agree with registry
+   truth
+3. one bounded disturbance policy table is explicit for startup
+   non-authoritative inventory, repeated restart before convergence, stale rejoin
+   input, repeated failover windows, and degraded sparse heartbeat handling
+4. one first-launch envelope draft is explicit for the bounded chosen path
+
+## Explicit Non-Claims
+
+1. broad whole-surface failover/publication proof
+2. broad restart-window behavior outside the explicit `17C` policy table
+3. broad transport/frontend approval beyond the named bounded envelope
+4. launch approval, pilot approval, or rollout approval
+
+## Residual Gaps
+
+1. stronger whole-surface publication proof across more outward surfaces
+2. broader restart/rejoin/repeated-disturbance closure beyond the current policy
+   table
+3. pilot-pack, preflight, stop-condition, and controlled-rollout artifacts
+4. any broader launch claim that cannot map directly to named accepted evidence
+
+## Evidence Summary
+
+### `17A` branch map
+
+1. branch inventory is derived from `Phase 16` finish-line residuals plus named
+   restart/disturbance/failover tests in `weed/server`
+2. result:
+   - restart same-lineage reconstruction is classified closed on the bounded
+     chosen path
+   - the remaining major branches are classified partially proven rather than
+     silently implied
+
+### `17B` failover/publication contract
+
+1. `TestP11P3_Failover_PublicationSwitches`
+2. `TestP12P1_FailoverPublication_Switch`
+3. `TestP11P3_HeartbeatReconstruction`
+4. failover/promotion tests in `qa_block_cp11b3_adversarial_test.go`
+5. result:
+   - one bounded whole-chain publication statement is supportable
+
+### `17C` disturbance policy
+
+1. `TestStartBlockService_ScanFailureEmitsNonAuthoritativeInventory`
+2. `TestRegistry_UpdateFullHeartbeatWithInventoryAuthority_(NonAuthoritativeEmptyDoesNotDelete|AuthoritativeEmptyStillDeletes)`
+3. `TestP12P1_(Restart_SameLineage|RepeatedFailover_EpochMonotonic|StaleSignal_OldEpochRejected)`
+4. missing-field truth-retention tests in `master_block_registry_test.go`
+5. result:
+   - the main long-window disturbance classes are now policy-shaped rather than
+     only code-shaped
+
+### `17D` launch envelope
+
+1. `Phase 12 P4` bounded floor / rollout-gate package
+2. `CP13-1..9`
+3. `Phase 16` finish-line checkpoint
+4. `Phase 17A-17C` branch/contract/policy package
+5. result:
+   - first supported envelope, exclusions, and launch blockers are finite and
+     named
+
+## Review Questions
+
+### For `sw`
+
+Please check implementation and checkpoint coherence:
+
+1. Is the `Phase 17` package coherent as one bounded product-claim checkpoint?
+2. Are the envelope exclusions and blockers disciplined enough to avoid silent
+   overclaim?
+3. Is any part of the current package still too vague to support review or later
+   global-doc synchronization?
+
+### For `tester`
+
+Please challenge the proof posture:
+
+1. Is the `17B` contract actually supported by the cited tests, or only loosely
+   suggested by them?
+2. Does the `17C` policy table faithfully separate runtime rule from temporary
+   inconsistency window?
+3. Are there any obvious missing outward surfaces that make the current launch
+   envelope too optimistic even in bounded form?
+
+### For `manager`
+
+Please challenge scope and stop-line discipline:
+
+1. Is `Phase 17` the right place to stop this checkpoint package before
+   productionization?
+2. Are the current launch blockers and explicit non-claims sufficient to prevent
+   the package from being misread as launch approval?
+3. Should any current item be moved out of `Phase 17` and into productionization
+   instead?
+
+## Requested Output Shape
+
+Please reply with one of:
+
+1. `ACCEPT`
+2. `ACCEPT WITH MINOR FIXES`
+3. `REJECT`
+
+If not `ACCEPT`, list findings ordered by severity and keep them bounded to this
+checkpoint's actual claim set.

sw-block/design/v2-first-launch-supported-matrix.md

@@ -0,0 +1,123 @@
+# V2 First-Launch Supported Matrix
+
+Date: 2026-04-04
+Status: draft
+Purpose: freeze the first bounded launch envelope from accepted `Phase 12-17`
+evidence, with explicit supported scope, explicit exclusions, and explicit
+launch blockers
+
+## Reading Rule
+
+This document is a bounded support matrix.
+
+It does NOT mean:
+
+1. broad launch approval
+2. generic production readiness
+3. support for every failover/restart/disturbance branch
+4. broad transport/frontend approval outside the named chosen path
+
+It means only:
+
+1. these are the strongest support statements currently justified by accepted
+   evidence
+2. anything outside them is an exclusion, a blocker, or future
+   productionization work
+
+## Supported Matrix
+
+| Dimension | Supported in first draft | Boundary rule | Primary evidence |
+|-----------|--------------------------|---------------|------------------|
+| Replication factor | `RF=2` | bounded chosen path only | `CP13-1..7`, `C-RF2-SYNCALL-CONTRACT` |
+| Durability mode | `sync_all` | bounded chosen path only | `CP13`, `v2-protocol-claim-and-evidence.md` |
+| Control/runtime path | existing master / volume-server heartbeat path | same path as `Phase 10`, `Phase 16`, `Phase 17` checkpoints | `Phase 10`, `Phase 16` finish-line review |
+| Semantic owner | explicit `V2 core` | semantics stay `V2`-owned even when implementation reuses `weed/` and `blockvol` | `Phase 14-16` |
+| Execution backend | `blockvol` via `v2bridge` | reuse implementation; no V1 semantic inheritance | `Phase 09`, `Phase 14-16` |
+| Product surfaces | bounded `iSCSI`, bounded `CSI`, bounded `NVMe` on the chosen path | not a generic transport matrix | `Phase 11`, publication tests, NVMe tests |
+| Restart/failover reading | bounded `17B` + `17C` interpretation | use only the explicit contract and policy table from `Phase 17` | `phase-17.md`, `phase-17-checkpoint-review.md` |
+
+## Supported Statement
+
+The strongest currently supported first-launch statement is:
+
+1. on the bounded chosen `RF=2 sync_all` path, using the existing
+   master/volume-server heartbeat path, explicit `V2`-owned semantics and the
+   accepted `Phase 16-17` contract/policy package provide one finite support
+   envelope for bounded block product use
+2. bounded `iSCSI`, `CSI`, and `NVMe` surfaces are supported only inside that
+   same chosen-path interpretation
+3. failover/publication and disturbance behavior must be read through the
+   explicit `Phase 17` contract/policy package, not through broader inferred
+   product assumptions
+
+## Explicit Exclusions
+
+The following are OUTSIDE the first-launch supported matrix:
+
+1. `RF>2`
+2. durability modes outside the accepted bounded envelope
+3. broad transport/frontend matrix approval beyond bounded `iSCSI` / `CSI` /
+   `NVMe` chosen-path support
+4. broad whole-surface failover/publication proof
+5. broad restart-window behavior outside the explicit `17C` disturbance policy
+   table
+6. generic soak/pilot success as production proof
+7. broad rollout approval
+
+## Launch Blockers
+
+These are still required before this matrix can be read as a real launch
+decision package:
+
+1. a frozen `Phase 17` checkpoint review outcome
+2. a pilot pack with:
+   - preflight checklist
+   - success criteria
+   - stop / rollback conditions
+3. controlled-rollout review artifacts
+4. any additional evidence needed if the product wants claims broader than the
+   current bounded `17B/17C` contract/policy package
+
+## Not Launch-Blocking In This Draft
+
+These are intentionally NOT blockers for the bounded first-draft envelope:
+
+1. lack of `RF>2` support
+2. lack of broad transport/frontend approval
+3. lack of broad launch approval language
+4. lack of generic soak proof inside the phase package itself
+
+## Claim Mapping Rule
+
+Any first-launch support claim must map back to accepted evidence in ALL of the
+following layers:
+
+1. hardening/floor layer
+   - `Phase 12 P4`
+2. contract/workload/mode layer
+   - `CP13-1..9`
+3. runtime truth-closure layer
+   - `Phase 16` finish-line checkpoint
+4. product-claim checkpoint layer
+   - `Phase 17A-17D`
+
+If a claim cannot map cleanly back through those layers:
+
+1. it is not in the first-launch matrix
+2. it belongs in exclusions, blockers, or later productionization work
+
+## Operator Reading Guide
+
+When using this matrix, read it with these constraints:
+
+1. bounded chosen path first, not generic platform promise
+2. explicit exclusions are real product boundaries, not temporary omissions
+3. launch blockers are real blockers, not optional polish
+4. pilot success later may validate this envelope, but cannot redefine it
+
+## Primary References
+
+1. `sw-block/.private/phase/phase-17.md`
+2. `sw-block/.private/phase/phase-17-checkpoint-review.md`
+3. `sw-block/design/v2-product-completion-overview.md`
+4. `sw-block/design/v2-protocol-claim-and-evidence.md`

sw-block/design/v2-phase-development-plan.md

@@ -1,6 +1,6 @@
 # V2 Phase Development Plan
 
-Date: 2026-04-02
+Date: 2026-04-04
 Status: active
 Purpose: define the execution-oriented phase plan after the current candidate-path work, with explicit module status and target phase ownership
 
@@ -35,22 +35,26 @@ Use these rules for all later phases:
 
 ## Current Baseline
 
-Current accepted path through `Phase 13`, with `Phase 14` now the immediate next engineering focus:
+Current accepted path now runs through the `Phase 16` finish-line checkpoint:
 
 1. protocol/algo truth set is strong
 2. engine recovery core is strong on the chosen path
 3. control-plane closure is accepted on the chosen path
 4. selected product-surface rebinding is accepted on the chosen path
 5. bounded production hardening is accepted on the chosen path
-6. one bounded accepted path exists for:
-  - `RF=2`
-  - `sync_all`
-  - existing master / volume-server heartbeat path
-  - `blockvol` as execution backend
-7. `Phase 13` has now closed the bounded `WAL V1.5` contract package for the current constrained chosen path:
-  - real-workload package accepted
-  - assignment/publication closure accepted
-  - bounded mode normalization accepted
+6. explicit `V2 core` extraction and adapter/projection rebinding are accepted as
+   bounded engineering structure
+7. one bounded `V2`-native runtime checkpoint is now accepted for:
+   - `RF=2`
+   - `sync_all`
+   - existing master / volume-server heartbeat path
+   - `blockvol` as execution backend
+8. `Phase 13` froze the bounded `WAL V1.5` contract package and `Phase 14-16`
+   carried that package forward into a bounded runtime-owned checkpoint:
+   - real-workload package accepted
+   - assignment/publication closure accepted
+   - bounded mode normalization accepted
+   - bounded heartbeat/restart truth closure accepted
 
 Phase-accounting note:
 
@@ -60,28 +64,32 @@ Phase-accounting note:
 4. `Phase 11` is closed
 5. `Phase 12` is the accepted hardening baseline for the chosen path
 6. `Phase 13` is closed and should be read as one bounded constrained-runtime contract package, not as launch approval
-7. `Phase 14` is now the immediate next engineering focus:
-   - explicit `V2 core` extraction
-   - not more deepening of constrained-`V1` validation by default
+7. `Phase 14` is closed as explicit `V2 core` extraction
+8. `Phase 15` is closed as bounded adapter/projection rebinding
+9. `Phase 16` is closed as a bounded `V2`-native runtime checkpoint, not as broad product/launch proof
+10. the immediate next planning focus is now the productionization program plus the larger post-`Phase 16` gates:
+   - broader recovery/failover/publication statement
+   - launch-envelope freeze
+   - pilot/rollout discipline
 
 Important interpretation rule:
 
 1. the accepted chosen path and claim/evidence set are real
 2. the current `weed/` runtime structure is not automatically the final `V2` structure
-3. until `Phase 14` establishes an explicit `V2 core`, current integrated tests should be read primarily as:
-   - `V1` runtime validation under `V2` constraints
-   - not proof that a completed `V2 runtime` already exists
+3. even after the `Phase 16` finish-line checkpoint, current integrated evidence should still be read as:
+   - one bounded `V2`-owned runtime path on the chosen integration
+   - not broad proof for every recovery/failover/disturbance or launch scenario
 4. future phases must treat:
    - `v2-protocol-claim-and-evidence.md` as current claim authority
    - `v2_mini_core_design.md` as engineering-structure authority
    - `v2-reuse-replacement-boundary.md` as reuse vs replacement authority
 
-This means the next phases should focus mainly on:
+This means the next work should focus mainly on:
 
-1. extracting the long-term `V2 core` structure explicitly
-2. rebinding `weed/` into adapter / projection / backend roles
-3. closing one bounded `V2`-native runtime path before productionization
-4. using `Phase 13` evidence as acceptance input rather than continuing to treat constrained-`V1` validation as the main workstream
+1. keeping accepted `Phase 14-16` closure closed
+2. turning the bounded runtime checkpoint into an explicit launch envelope
+3. deciding broader failover/recovery/publication claims only through named evidence
+4. using `Phase 13-16` evidence as acceptance input rather than reopening micro-seams by default
 
 ## Phase Roadmap
 
@@ -414,6 +422,12 @@ Key files / ownership:
 2. `sw-block/design/v2-phase14plus-semantic-framework.md`
 3. `sw-block/engine/replication/`
 
+Current status:
+
+1. complete as a bounded engineering-structure phase
+2. accepted output is explicit `state / event / command / projection` ownership,
+   not broad live-runtime or launch proof
+
 ### Phase 15: Adapter And Projection Rebinding
 
 Goal:
@@ -463,6 +477,12 @@ Key files / ownership:
 5. `weed/server/master_block_registry.go`
 6. `weed/server/master_block_failover.go`
 
+Current status:
+
+1. complete as bounded adapter/projection rebinding on the chosen path
+2. accepted output is explicit adapter/projection ownership, not broad
+   runtime-closure or launch proof
+
 ### Phase 16: V2-Native Runtime Closure
 
 Goal:
@@ -497,6 +517,19 @@ Key files / ownership:
 2. `weed/server/`
 3. selected `weed/storage/blockvol/v2bridge/*` files
 
+Current status:
+
+1. complete as a bounded runtime checkpoint through the `Phase 16` finish line
+2. accepted checkpoint now covers:
+   - steady-state and bounded restart reconstruction preserve accepted explicit
+     truth on the chosen path
+   - sparse heartbeats do not silently erase already accepted truth
+   - empty full-inventory delete behavior is explicit rather than heuristic
+3. non-claims remain explicit:
+   - not broad recovery-loop closure
+   - not broad failover/publication proof
+   - not launch / rollout readiness
+
 ### Cross-Phase Review Rule For `Phase 14+`
 
 For any new transition, command, or projection rule in `Phase 14+`, require a
@@ -572,25 +605,25 @@ Cross-cutting rules:
 
 | Module area | Current status | Current owner phase | Next target phase | Notes |
 | ----------- | -------------- | ------------------- | ----------------- | ----- |
-| `sw-block/engine/replication` core FSM/orchestrator/driver | Strong long-term `V2 core` asset | `Phase 09` accepted, `Phase 13` active constraints | `Phase 14` | Main next work is explicit `state / event / command / projection` extraction, not reopening accepted semantics. |
-| Engine executor real I/O boundary (`CatchUpIO` / `RebuildIO`) | Strong on chosen path | `Phase 09` accepted | `Phase 14/16` | Keep the boundary stable; later work is to connect it to explicit `V2 core` ownership and runtime closure. |
-| `weed/storage/blockvol/v2bridge/control.go` | Strong boundary adapter on chosen path | `Phase 08/09/10` accepted | `Phase 15` | Remains a bridge between `V2` truth and runtime execution; should not accumulate new semantic authority casually. |
-| `weed/storage/blockvol/v2bridge/reader.go` | Strong backend-facing adapter | `Phase 09` accepted | `Phase 15/16` | Mostly stable; later work is explicit boundary ownership and runtime proof, not new protocol semantics. |
-| `weed/storage/blockvol/v2bridge/pinner.go` | Strong backend-facing adapter | `Phase 09` accepted | `Phase 15/16` | Retention safety is proven on the chosen path; later work is keeping it under explicit `V2` control boundaries. |
-| `weed/storage/blockvol/v2bridge/executor.go` WAL scan | Strong backend-facing adapter | `Phase 09` accepted | `Phase 15/16` | Real execution path is closed on the chosen path; later work is core-driven runtime integration. |
-| `v2bridge` `TransferFullBase` | Strong on chosen path | `Phase 09 P1` accepted | `Phase 16` | Execution closure is accepted; do not reopen casually unless core-driven runtime closure exposes a real contradiction. |
-| `v2bridge` `TransferSnapshot` | Strong on chosen path | `Phase 09 P2` accepted | `Phase 16` | Execution closure is accepted; later work is bounded runtime closure rather than first-implementation discovery. |
-| `v2bridge` `TruncateWAL` | Strong on chosen path | `Phase 09 P3` accepted | `Phase 16` | Narrow contract is accepted; later work is preserving that contract under explicit runtime ownership. |
-| `weed/server/volume_server_block.go` V2 assignment intake | Adapter-boundary reality with accepted chosen-path closure | `Phase 10 P4` accepted, `Phase 13` contradiction pressure | `Phase 15` | This is where assignment/readiness/publication closure must become explicit adapter behavior rather than mixed service semantics. |
-| `weed/server/block_recovery.go` live runtime ownership | V2-owned runtime truth on chosen path | `Phase 09/10` accepted | `Phase 15/16` | Serialized ownership is accepted; later work is making it cooperate with explicit `V2 core` and projection boundaries. |
-| `weed/server/master_block_registry.go` / failover / handlers | Mixed projection/truth reality | `Phase 10-12` accepted surfaces | `Phase 15` | Should converge toward projection store + operator-visible truth surfaces rather than mixed business-logic/state storage. |
-| `blockvol` WAL/flusher/checkpoint runtime | Reuse reality | Existing production code | `Phase 16` | Reuse implementation; do not let `V1` replication semantics redefine `V2` truth. |
-| `blockvol` rebuild transport/server reality | Reuse with redesign boundary | Existing production code | `Phase 16` | Bounded chosen-path integration is accepted; later work is runtime closure under `V2` authority. |
-| local server identity (`localServerID`) | Strong chosen-path rule with narrowed semantics | `Phase 10 P1` accepted, `Phase 13` constraints | `Phase 15` | Stable identity must remain distinct from transport address shape and explicit in later adapter/projection work. |
-| Snapshot product path | Strong on chosen path | `Phase 11` accepted | `Phase 16` | Product-visible snapshot workflow is accepted on the chosen path; later work is preserving it under `V2`-native runtime closure. |
-| `CSI` integration | Strong on chosen path | `Phase 11` accepted | `Phase 16` | Bounded controller/node lifecycle rebinding is accepted; later work is runtime preservation, not first rebinding. |
-| `NVMe` / `iSCSI` front-ends | Strong on chosen path | `Phase 11` accepted | `Phase 16` | Publication/address truth rebinding is accepted; later work is proving the `V2`-driven runtime path beneath them. |
-| Testrunner / infra / metrics | Strong support layer | existing | `Phase 13-16` | Reuse to validate contract closure, adapter contradictions, runtime closure, and later productization gates. |
+| `sw-block/engine/replication` core FSM/orchestrator/driver | Strong long-term `V2 core` asset | `Phase 14` accepted, `Phase 16` runtime checkpoint accepted | Productionization / broader failover gate | Main next work is not new core extraction; it is using the accepted core as authority when deciding broader post-`Phase 16` claims. |
+| Engine executor real I/O boundary (`CatchUpIO` / `RebuildIO`) | Strong on chosen path | `Phase 09` accepted, `Phase 16` integrated on bounded path | Productionization / broader recovery-loop gate | Keep the boundary stable; later work is broader runtime/failover evidence, not first implementation. |
+| `weed/storage/blockvol/v2bridge/control.go` | Strong boundary adapter on chosen path | `Phase 15` accepted, `Phase 16` checkpoint accepted | Productionization | Remains a bridge between `V2` truth and runtime execution; should not accumulate new semantic authority casually. |
+| `weed/storage/blockvol/v2bridge/reader.go` | Strong backend-facing adapter | `Phase 09` accepted, `Phase 16` bounded runtime checkpoint accepted | Productionization / broader disturbance hardening | Mostly stable; later work is evidence under wider disturbance classes, not new protocol semantics. |
+| `weed/storage/blockvol/v2bridge/pinner.go` | Strong backend-facing adapter | `Phase 09` accepted, `Phase 16` bounded runtime checkpoint accepted | Productionization / broader disturbance hardening | Retention safety is proven on the chosen path; later work is long-window hardening rather than ownership redesign. |
+| `weed/storage/blockvol/v2bridge/executor.go` WAL scan | Strong backend-facing adapter | `Phase 09` accepted, `Phase 16` bounded runtime checkpoint accepted | Productionization / broader recovery-loop gate | Real execution path is closed on the chosen path; later work is broader runtime evidence. |
+| `v2bridge` `TransferFullBase` | Strong on chosen path | `Phase 09 P1` accepted, `Phase 16` bounded runtime checkpoint accepted | Productionization / broader recovery-loop gate | Execution closure is accepted; do not reopen casually unless broader runtime evidence exposes a real contradiction. |
+| `v2bridge` `TransferSnapshot` | Strong on chosen path | `Phase 09 P2` accepted, `Phase 16` bounded runtime checkpoint accepted | Productionization / launch-envelope gate | Execution closure is accepted; later work is first supported-envelope accounting. |
+| `v2bridge` `TruncateWAL` | Strong on chosen path | `Phase 09 P3` accepted, `Phase 16` bounded runtime checkpoint accepted | Productionization / broader recovery-loop gate | Narrow contract is accepted; later work is preserving that contract under broader disturbance evidence. |
+| `weed/server/volume_server_block.go` V2 assignment intake | Adapter-boundary reality with accepted chosen-path closure | `Phase 15` accepted, `Phase 16` finish-line checkpoint accepted | Productionization / broader failover gate | This boundary is now explicit on the chosen path; next work is wider gate evidence, not another rebinding phase. |
+| `weed/server/block_recovery.go` live runtime ownership | V2-owned runtime truth on chosen path | `Phase 16` finish-line checkpoint accepted | Productionization / broader recovery-loop gate | Serialized ownership is accepted on the bounded path; later work is proving more of the surrounding loop without widening claims casually. |
+| `weed/server/master_block_registry.go` / failover / handlers | Bounded projection/truth closure accepted on chosen path | `Phase 15` accepted, `Phase 16` finish-line checkpoint accepted | Productionization / broader failover/publication gate | Heartbeat/restart truth-closure seams are closed on the bounded path; remaining work is broader gate evidence and launch scoping. |
+| `blockvol` WAL/flusher/checkpoint runtime | Reuse reality | Existing production code, bounded path accepted through `Phase 16` | Productionization / broader disturbance hardening | Reuse implementation; do not let `V1` replication semantics redefine `V2` truth. |
+| `blockvol` rebuild transport/server reality | Reuse with redesign boundary | Existing production code, bounded path accepted through `Phase 16` | Productionization / broader recovery-loop gate | Bounded chosen-path integration is accepted; later work is wider disturbance/failover evidence under `V2` authority. |
+| local server identity (`localServerID`) | Strong chosen-path rule with narrowed semantics | `Phase 10 P1` accepted, carried through `Phase 16` | Productionization / launch-envelope gate | Stable identity must remain distinct from transport address shape; next work is supported-envelope/accounting, not semantic redesign. |
+| Snapshot product path | Strong on chosen path | `Phase 11` accepted, preserved through `Phase 16` | Productionization / launch-envelope gate | Product-visible snapshot workflow is accepted on the chosen path; next work is first supported envelope and exclusions. |
+| `CSI` integration | Strong on chosen path | `Phase 11` accepted, preserved through `Phase 16` | Productionization / launch-envelope gate | Bounded controller/node lifecycle rebinding is accepted; next work is supported-matrix/accounting rather than first rebinding. |
+| `NVMe` / `iSCSI` front-ends | Strong on chosen path | `Phase 11` accepted, preserved through `Phase 16` | Productionization / launch-envelope gate | Publication/address truth rebinding is accepted; next work is envelope freeze and broader incident-driven hardening. |
+| Testrunner / infra / metrics | Strong support layer | existing, used through `Phase 13-16` checkpointing | Productionization | Reuse to validate launch-envelope gates, pilot packs, incident buckets, and broader hardening claims. |
 
 
 ## Completion-State Targets
@@ -615,40 +648,50 @@ Use these rough targets to judge whether a phase is moving the product meaningfu
 
 If the goal is to maximize product completion efficiently, the recommended order is now:
 
-1. keep `Phase 09-12` accepted closures closed and do not reopen them casually
-2. keep `Phase 13` closed as the bounded `WAL V1.5` contract package
-3. move next to `Phase 14` core extraction:
-   - explicit `state / event / command / projection`
-   - minimal `ApplyEvent() -> Decide() -> EmitCommands()` path
-4. then `Phase 15` adapter/projection rebinding:
-   - assignment
-   - readiness
-   - publication
-   - diagnostics
-5. then `Phase 16` bounded `V2`-native runtime closure
-6. only then move to the productionization program:
-   - freeze launch envelope
-   - run limited internal pilot
-   - harden from incidents
-   - review controlled rollout
+1. keep `Phase 09-16` accepted closures closed and do not reopen them casually
+2. treat the `Phase 16` finish-line checkpoint as the bounded runtime stop-line,
+   not as a reason to continue indefinite micro-slicing
+3. move next to the productionization program:
+   - `P0` launch-envelope freeze
+   - `P1` limited internal pilot pack
+   - `P2` incident-driven hardening loop
+   - `P3` controlled rollout review
+4. only reopen runtime logic if broader failover/recovery/publication evidence
+   exposes a real contradiction
+5. keep larger post-`Phase 16` gates explicit:
+   - broader recovery-loop closure
+   - broader failover/publication statement
+   - long-window restart/disturbance hardening
 
 The most important near-term engineering weight should now go to:
 
-1. making `sw-block/engine/replication` the explicit long-term `V2 core`
-2. keeping `weed/` changes bounded to adapter / projection / backend roles unless they are explicitly promoted into `V2`-owned authority
-3. using `CP13-1..9` as acceptance input for new `V2 core` work rather than as a reason to keep extending constrained-`V1` validation
+1. freezing the first supported launch envelope from accepted `Phase 12-16`
+   evidence
+2. deciding what broader failover/recovery/publication claims are actually
+   supportable before widening product scope
+3. keeping `weed/` changes bounded unless a real contradiction requires broader
+   runtime work
 
 ## Short Summary
 
-The V2 line now has accepted execution, control, product-surface, and hardening closure on one bounded chosen path.
+The V2 line now has an accepted bounded path through:
 
-The next development plan should not jump directly from `Phase 12` to productionization.
-It should move through four bounded engineering phases first:
+1. execution closure
+2. control-plane closure
+3. product-surface rebinding
+4. bounded hardening
+5. constrained-runtime contract freeze
+6. explicit `V2 core` extraction
+7. adapter/projection rebinding
+8. bounded `Phase 16` runtime closure
 
-1. `Phase 13`: freeze the current `WAL V1.5` constrained-runtime contract package
-2. `Phase 14`: extract the explicit `V2 core`
-3. `Phase 15`: rebind `weed/` as adapter/projection reality
-4. `Phase 16`: close one bounded `V2`-native runtime path
+The roadmap should now stop treating `Phase 14-16` as future work.
+Their bounded checkpoint is complete.
 
-Only after that should the roadmap move into bounded launch-envelope freeze, internal pilot, incident-driven hardening, and controlled rollout review.
+From here the practical plan is:
+
+1. freeze the first supported launch envelope
+2. decide the larger post-`Phase 16` failover/recovery/publication claim boundary
+3. run a limited internal pilot
+4. harden from incidents without silently widening scope
 

sw-block/design/v2-product-completion-overview.md

@@ -45,9 +45,9 @@ It already has:
 2. accepted engine execution closure on the chosen path
 3. accepted control-plane and product-surface rebinding on the chosen path
 4. accepted hardening evidence for the bounded chosen path
-5. an active `Phase 16` runtime-closure program that is moving live ownership
-   from host-local orchestration toward explicit core-driven command / event /
-   projection seams
+5. an accepted `Phase 16` finish-line runtime checkpoint
+6. an active `Phase 17` product-claim package that now makes broader branch,
+   contract, policy, and launch-envelope boundaries explicit
 
 The most important current distinction is:
 
@@ -67,14 +67,14 @@ These levels are rough engineering estimates, not exact percentages.
 | Engine recovery core | Strong | Sender/session/orchestrator/driver/executor are substantially implemented and remain the semantic center. |
 | Weed bridge integration | Strong | Reader / pinner / control / executor are real and tested on the chosen path. |
 | Integrated candidate path | Strong on chosen path | Backend, control-plane, and selected product surfaces are accepted on one bounded chosen path. |
-| Runtime ownership inside live server loop | Strong on bounded path, still widening | `Phase 16A-16I` now give one substantial core-command-driven runtime path, but broad recovery-loop closure is not yet claimed. |
+| Runtime ownership inside live server loop | Strong on bounded checkpoint | `Phase 16` finish-line closed the bounded runtime checkpoint; broader lifecycle closure is now handled as explicit `Phase 17` product-claim work. |
 | Production-grade data transfer | Strong on chosen path | `TransferFullBase` and `TransferSnapshot` execution closure are accepted on the chosen path; later work is hardening. |
 | Truncation / replica-ahead execution | Strong on chosen path | `TruncateWAL` narrow chosen-path closure is accepted; later work is hardening/planning improvement. |
 | End-to-end control-plane closure | Strong on chosen path | `Phase 10` accepted bounded end-to-end control-path closure on the chosen path. |
 | Product surfaces (`CSI`, `NVMe`, `iSCSI`, snapshot productization) | Strong on chosen path | `Phase 11` accepted bounded product-surface rebinding on the chosen path. |
 | Production hardening / ops | Strong on bounded path, not full launch proof | `Phase 12` closed the bounded hardening bar, but not the whole first-launch envelope. |
 | Multi-replica catch-up runtime ownership | Strong on bounded startup/execution path | `16F-16I` made command/event/pending/aggregation/startup ownership replica-scoped enough for the bounded primary multi-replica path. |
-| Broad failover / publication / launch envelope | Partial | Main remaining product gap: prove wider runtime closure and freeze a supported launch envelope. |
+| Broad failover / publication / launch envelope | Structured but still bounded | `Phase 17` now defines a branch map, bounded failover/publication contract, disturbance policy table, and first-launch envelope draft, but not broad launch approval. |
 
 ## Reuse Strategy
 
@@ -156,41 +156,49 @@ For the chosen `RF=2 sync_all` path, the project can already claim:
 The biggest remaining product-completion gaps are no longer "invent the first
 working path". They are closure and launch-envelope gaps:
 
-1. broader recovery-loop closure
-   - current `Phase 16` evidence is strong on one bounded runtime path, but not
-     yet a claim that all recovery lifecycle branches are core-owned end to end
+1. broader recovery-loop closure beyond the current `17A` branch map
+   - branches are now classified explicitly, but most remain only partially
+     proven rather than broadly closed
 2. broader failover / publication closure
-   - product-facing truth under failover, replay, and disturbance still needs a
-     stronger whole-chain statement, not only local runtime proofs
-3. restart / disturbance preservation
-   - accepted behavior must remain correct under restart, rejoin, repeated
-     failover, and address churn without reopening semantic ambiguity
-4. long-run / soak / performance floor
-   - accepted behavior must remain stable under longer operation with explicit
-     floor numbers and bounded rollout gates
-5. launch-envelope freeze
-   - the first supported launch matrix, exclusions, operator expectations, and
-     stop conditions must be written down explicitly
+   - `17B` now defines one bounded whole-chain statement, but not yet a broad
+     whole-surface publication proof
+3. restart / disturbance preservation outside the current `17C` policy table
+   - current long-window behavior is now policy-shaped, but not yet a broad
+     production hardening statement
+4. pilot / rollout package
+   - the first launch envelope is now drafted, but pilot pack, preflight, stop
+     conditions, and rollout review artifacts are still missing
+5. long-run / soak / performance extension beyond the bounded floor
+   - `Phase 12 P4` remains the bounded floor; broader confidence still belongs to
+     later productionization
 
 ## Recommended Completion Roadmap
 
-### Stage 1: Finish `Phase 16` runtime closure cleanly
+### Stage 1: Review And Freeze The `Phase 17` Checkpoint
 
 Target:
 
-1. close the next bounded `Phase 16` runtime gap with explicit bounds and
-   package one clear reviewable runtime checkpoint
+1. package the current `Phase 17` branch/contract/policy/envelope work into one
+   clear reviewable product-claim checkpoint
+
+Status:
+
+1. in progress
 
 Main output:
 
-1. one accepted bounded `V2`-native runtime path that is explicit about what is
-   core-owned, what is adapter-owned, and what is still only compatibility
-2. one short list of residual recovery-loop gaps after `16I`
+1. one `Phase 17` checkpoint review artifact
+2. one first-launch supported-matrix artifact
+3. one bounded statement of:
+   - branch map
+   - failover/publication contract
+   - disturbance policy
+   - launch envelope
 
 Why it matters:
 
-This is now the main semantic engineering blocker between a strong bounded path
-and a launchable product statement.
+This is now the main boundary-setting blocker between a strong bounded path and a
+bounded launch decision package.
 
 ### Stage 2: Freeze the first supported launch envelope
 
@@ -201,12 +209,13 @@ Target:
 
 Status:
 
-1. not yet frozen
+1. first draft frozen inside `Phase 17`
+2. not yet accepted as a launch decision package
 
 Main work:
 
-1. define the supported environment / replication / durability matrix
-2. define explicit exclusions that remain outside the first launch claim
+1. accept or refine the bounded supported matrix
+2. accept or refine explicit exclusions outside the first launch claim
 3. bind product-facing surfaces to the named supported envelope
 4. define preflight, success, and stop conditions
 
@@ -261,33 +270,33 @@ The most important gates from here are:
 If the goal is to maximize product completion efficiently:
 
 1. do not reopen accepted execution, control-plane, or product-surface semantics casually
-2. treat the remaining `Phase 16` work as runtime-closure work, not as another
-   round of broad redesign
-3. finish the next bounded recovery-loop gaps before claiming more product scope
-4. then freeze the first supported launch envelope
-5. then run a limited internal pilot
-6. then widen only through explicit incident review and rollout-gate review
+2. treat `Phase 16` as closed at its finish-line checkpoint
+3. use `Phase 17` to keep branch/contract/policy/envelope claims explicit and
+   bounded
+4. then run a limited internal pilot
+5. then widen only through explicit incident review and rollout-gate review
 
 In short:
 
-1. runtime closure first
-2. launch-envelope freeze second
+1. runtime checkpoint first
+2. product-claim / launch-envelope freeze second
 3. bounded productionization third
 
 ## Short Summary
 
 The V2 line is already beyond "algorithm only".
 It has an accepted bounded chosen path through backend, control-plane, selected
-product surfaces, bounded hardening, and substantial `Phase 16` runtime closure.
+product surfaces, bounded hardening, an accepted `Phase 16` runtime checkpoint,
+and an active `Phase 17` product-claim package.
 
 The main remaining work is not "build the first real thing".
 It is:
 
-1. finish broader recovery-loop and failover/publication closure strongly enough
-   for a product statement
-2. freeze the first supported launch envelope from accepted evidence
-3. run a limited internal pilot with explicit stop conditions
-4. harden from incidents without silently broadening scope
+1. finish review/freeze of the bounded `Phase 17` branch/contract/policy/envelope
+   package
+2. run a limited internal pilot with explicit stop conditions
+3. harden from incidents without silently broadening scope
+4. only broaden claims when new evidence supports them
 
 That is the practical path from the current bounded runtime-complete candidate
 to a bounded first-launch block product.

sw-block/design/v2-protocol-claim-and-evidence.md

@@ -57,7 +57,7 @@ This is the bounded envelope currently allowed for active V2 claims:
 | Durability mode | `sync_all` | `v2-protocol-closure-map.zh.md`, `Phase 13` |
 | Control path | current master / volume-server heartbeat path | `v2-protocol-closure-map.zh.md` |
 | Execution backend | `blockvol` | `v2-protocol-closure-map.zh.md`, `v2-reuse-replacement-boundary.md` |
-| Frontend in active validation | iSCSI | `Phase 11`, `CP13-8` |
+| Frontend/product surfaces in bounded support envelope | iSCSI, CSI, NVMe on the chosen path | `Phase 11`, `Phase 17` |
 | Real-workload checkpoint | `CP13-8` | `Phase 13` |
 
 Current explicit exclusions:
@@ -109,6 +109,8 @@ These are the claims that may currently be made without overreach.
 | `C-CONSTRAINED-V1-RUNTIME` | current integrated checks are evaluating `V1` runtime behavior under `V2` constraints rather than validating a completed `V2 runtime` | current chosen path only, until explicit `V2 core` extraction | `v2_mini_core_design.md`, `Phase 13` docs | allowed |
 | `C-MODE-NORMALIZATION` | one bounded mode-policy / normalization package is closed on the current constrained chosen path | bounded chosen path only; does not imply pure `V2 core` extraction or broad product policy | `CP13-9` docs/tests | allowed |
 | `C-PHASE16-RUNTIME-CHECKPOINT` | the bounded heartbeat/master/API runtime path now preserves accepted explicit truth across the delivered `16M-16W` restart/disturbance seams | bounded chosen path only; excludes broad recovery-loop, broad failover/publication, and launch claims | `sw-block/.private/phase/phase-16-finish-review.md`, `phase-16.md`, focused `weed/server` tests | allowed |
+| `C-PHASE17-PRODUCT-CHECKPOINT` | the current broader recovery-branch map, bounded failover/publication contract, bounded disturbance policy table, and first-launch envelope draft are explicit for the chosen path | bounded chosen path only; excludes broad production readiness, broad transport/frontend approval, and broad whole-surface failover/publication proof | `sw-block/.private/phase/phase-17.md`, `sw-block/.private/phase/phase-17-checkpoint-review.md` | allowed |
+| `C-FIRST-LAUNCH-ENVELOPE-DRAFT` | one bounded first-launch supported matrix is frozen as a draft with explicit exclusions and launch blockers | bounded chosen path only; not a launch decision, pilot approval, or rollout approval | `sw-block/design/v2-first-launch-supported-matrix.md` | allowed |
 | `C-LAUNCH-APPROVAL` | broad product launch readiness | outside current phase | future | not allowed |
 
 ## Evidence Map
@@ -126,6 +128,9 @@ These are the claims that may currently be made without overreach.
 | Assignment/publication closure | assignment does not imply readiness/publication and corrected wiring refreshes replication truth explicitly | `CP13-8A` code/tests/debug evidence | tester investigation, bug docs |
 | Mode normalization | one bounded mode set is explicit and surface-consistent on the constrained current path | `CP13-9` contract/doc/tests | tester validation report |
 | Runtime truth closure under restart/disturbance | accepted explicit truth survives the delivered bounded `Phase 16` heartbeat/restart seams through `16W` | `phase-16-finish-review.md`, `phase-16.md`, focused restart/heartbeat tests in `weed/server` | `v2-product-completion-overview.md`, `v2-protocol-truths.md` |
+| Failover/publication bounded contract | one bounded whole-chain statement is explicit for publication ownership/address coherence after failover completion and winning assignment delivery | `phase-17.md`, `phase-17-checkpoint-review.md`, publication/disturbance tests in `weed/server` | `v2-first-launch-supported-matrix.md` |
+| Disturbance policy table | startup/restart/rejoin/repeated-failover/degraded-sparsity behavior is explicit as runtime rule, temporary inconsistency policy, or non-claim | `phase-17.md`, `phase-17-checkpoint-review.md`, restart/disturbance tests in `weed/server` | `v2-product-completion-overview.md` |
+| First-launch supported matrix | one bounded launch envelope draft is explicit with supported scope, exclusions, and launch blockers | `v2-first-launch-supported-matrix.md` | `phase-17-checkpoint-review.md`, `Phase 12 P4`, `CP13`, `Phase 16` |
 
 ## Invalidated Or Narrowed Evidence