Per architect ruling 2026-04-28 on G6 scope (post-G5-5C close): Bindings absorbed: - G6-T-WALRECYCLE-ESCALATE folded into G6 main acceptance, not a separate sub-batch (architect ruling #1). - §1 AC = single closed-loop covering retention-OK catch-up + recycle-triggered escalation in ONE hardware scenario (architect ruling #1, "现象上是一件事, 不重复跑 sustained"). - §1.A = WAL retention policy options (α config knob / β pin-window / γ replica-watermark-driven). sw recommends α for smallest diff + fastest ratification; β/γ are richer, naturally G6-followup territory if escalation path proves clean first. - §1.H = audit-then-decide on code surface; do NOT pre-declare "zero code". Three possible verdicts: verify-only / minor-patch / engine-evolution-batch (halt condition). §2 acceptance criteria (8 items): - #1 §1.H audit published as commit note before any production code. - #2 §1.A bound + landed. - #3 engine-layer dispatch test pinning RecoveryFailureWALRecycled → RebuildPinned=true → next decide() emits StartRebuild. - #4 hardware retention-OK catch-up GREEN. - #5 hardware recycle-escalation GREEN (rebuild dispatch within deadline OR documented operator-failure-mode if §1 binds rebuild-as-NON-GOAL — architect's product-句 escape clause). - #6 #4 + #5 pass in SAME hardware run (one closed-loop AC). - #7 no regression on G5-5C 6-step suite. - #8 zero diff under master/authority/proto (carries INV-G5-5C-NO-MASTER-PROTOCOL-CHANGE discipline). §3 INVs to inscribe at close (4 always + 1 conditional): - INV-G6-WALRECYCLE-DISPATCHES-REBUILD - INV-G6-CATCHUP-CONVERGES-WITHIN-RETENTION - INV-G6-RETENTION-POLICY-OPERATOR-VISIBLE (only if α) - INV-G6-RETENTION-POLICY-REPLICA-AWARE (only if β/γ) - INV-G6-ENGINE-NO-REBUILD-PINNED-ON-OTHER-FAILURES Forward-carry from G5-5C consumed (§5): - G6-T-WALRECYCLE-ESCALATE — primary scope of this batch. - Evidence: V:\share\g5-test\logs\bcd-20260428T072539Z.log D-section. - QA wait_until_rebuild_dispatched helper held until §1-§6 ratified. §7 sign table awaits architect §1-§6 ratification (especially §1.A α/β/γ pick) before sw runs §1.H audit. Standing by for architect ratification.
V2 Design
This directory currently contains both the active V2 design canon and a large set of working notes, migration packs, and historical comparison material.
Use this README as the navigation layer. If a document is not listed under
Core Canon, treat it as supporting or historical context rather than the
current source of truth.
Core Canon
These are the documents that define the current V2 model and should be read first.
v2-protocol-truths.md— the stable semantic rulesv2-sync-recovery-protocol.md— sync, keepup, catchup, and rebuild protocol meaningv2-rebuild-mvp-session-protocol.md— rebuild session contract and data/control lanesv2-automata-ownership-map.md— assignment, session, and projection ownershipv2-protocol-claim-and-evidence.md— claims and current proof posturev2-validation-matrix.md—Rebuild Ready,Restore Ready, andV2 Readygatesv2-capability-map.md— capability-to-proof-tier mappingv2-proof-and-retest-pyramid.md— proof layering and retest strategy
Implementation Guides
These help maintainers understand how the current model maps into code.
v2-engine-maintainer-tutorial.mdv2-protocol-aware-execution.mdv2-session-protocol-shape.mdv2-two-loop-protocol.mdv2-assignment-translation-unification.mdv2-reuse-replacement-boundary.md
Validation And Rollout
These define how the active design is validated, staged, or operationalized.
v2-validation-matrix.mdv2-acceptance-criteria.mdv2-product-completion-overview.mdv2-first-launch-supported-matrix.mdv2-legacy-runtime-exit-criteria.mdv2-controlled-rollout-review.mdv2-bounded-internal-pilot-pack.mdv2-pilot-preflight-checklist.mdv2-pilot-stop-conditions.md
Working Reference
These are still useful, but they are not the shortest route to the current truth.
v2-open-questions.mdv2-phase-development-plan.mdv2-execution-muscles-inventory.mdv2-scenario-sources-from-v1.mdv2_scenarios.mdv1-v15-v2-comparison.mdv2-algorithm-overview.mdv2-algorithm-overview.zh.mdv2-detailed-algorithm.zh.mdv2-semantic-methodology.zh.mdv2-protocol-closure-map.zh.md
Migration And Historical Working Set
These files are mostly valuable for reconstruction of design history, migration intent, or earlier prototype shapes. They should usually not be the first docs opened during current development.
v2-first-migration-batch.mdv2-first-migration-task-pack.mdv2-second-migration-batch.mdv2-second-migration-task-pack.mdv2-third-migration-batch.mdv2-third-migration-task-pack.mdv2-phase14plus-semantic-framework.mdv2-pure-runtime-rf1-bootstrap.mdv2-volumev2-single-node-mvp.mdv2-loop1-surface-draft.mdv2-rf2-runtime-bounded-envelope.mdv2-rf2-runtime-bounded-envelope-review.mdv2-separation-port-layer-audit.mdv2_mini_core_design.mdwal-replication-v2.mdwal-replication-v2-state-machine.mdwal-replication-v2-orchestrator.mdwal-v2-tiny-prototype.mdwal-v1-to-v2-mapping.mdv2-dist-fsm.mdv1-v15-v2-simulator-goals.mdprotocol-version-simulation.md
Process
protocol-development-process.mdagent_dev_process.md
Cleanup Rule
When a document is superseded, prefer:
- keeping one canonical file in
Core Canon - leaving older reasoning in
Migration And Historical Working Set - avoiding duplicate "read first" lists across many files
Future cleanup should physically move or archive files only after their inbound references are reviewed.
Execution Note
- active development tracking lives under
../.private/phase/ - current phase contract and slice packages live there rather than in this directory
The original project-level copies under learn/projects/sw-block/design/
remain as shared references for now.