Files
seaweedfs/sw-block/design
pingqiuandClaude Opus 4.7 270615e005 P15 doc cleanup pass 1: G9A placement gate + roadmap entry doc
3 changes for clearer dev roadmap:

1. v3-phase-15-mvp-scope-gates.md — added G9A Placement Controller MVP
   per architect direction 2026-04-26. Sits between G9 lifecycle and
   G10 snapshot. P0 priority. Source rationale: production block
   storage needs V2-like operational ergonomics (operator asks for
   intent → system computes placement → master mints assignment) but
   V3 authority discipline must be preserved (no heartbeat-as-
   authority, no V2 promote/demote). G9A bridges the two:
     - flat-topology RF placement (NO rack/AZ awareness in P15)
     - durable desired topology generation
     - explainable candidate filtering (why selected, why rejected)
     - replacement-on-drain/disk-loss
     - master mints ONLY from desired topology
   Explicit non-scope (defer to G20 / P16): rack-aware, hot rebalance,
   automatic load movement, multi-master HA, V2 promote/demote.
   Updated P0 table, dependency graph §4.5, closure rule §5 #13.

2. v3-dev-roadmap.md (NEW) — 1-page entry point for "where are we,
   what's next." Lists 22 P15 gates with status emoji, current
   batch state, naming decoder, source-of-truth pointers, recently
   closed batches, prediction for after-G5. QA owns; updates at
   every gate-close.

3. v3-phase-development-model.md — added §0 header note clarifying
   this is methodology-only, NOT current state. Points to
   v3-dev-roadmap.md as current-state entry. Methodology sections
   (§1-§6, §8-§14) remain canonical.

Doc layer architecture now:
  Methodology:  v3-phase-development-model.md (stable)
  Roadmap:      v3-dev-roadmap.md (entry point; updated per gate-close)
  Canonical:    v3-phase-15-mvp-scope-gates.md (22 gates + closure)
  Rationale:    v3-product-placement-authority-rationale.md (why G9A)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 20:15:44 -07:00
..

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 rules
  • v2-sync-recovery-protocol.md — sync, keepup, catchup, and rebuild protocol meaning
  • v2-rebuild-mvp-session-protocol.md — rebuild session contract and data/control lanes
  • v2-automata-ownership-map.md — assignment, session, and projection ownership
  • v2-protocol-claim-and-evidence.md — claims and current proof posture
  • v2-validation-matrix.md — Rebuild Ready, Restore Ready, and V2 Ready gates
  • v2-capability-map.md — capability-to-proof-tier mapping
  • v2-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.md
  • v2-protocol-aware-execution.md
  • v2-session-protocol-shape.md
  • v2-two-loop-protocol.md
  • v2-assignment-translation-unification.md
  • v2-reuse-replacement-boundary.md

Validation And Rollout

These define how the active design is validated, staged, or operationalized.

  • v2-validation-matrix.md
  • v2-acceptance-criteria.md
  • v2-product-completion-overview.md
  • v2-first-launch-supported-matrix.md
  • v2-legacy-runtime-exit-criteria.md
  • v2-controlled-rollout-review.md
  • v2-bounded-internal-pilot-pack.md
  • v2-pilot-preflight-checklist.md
  • v2-pilot-stop-conditions.md

Working Reference

These are still useful, but they are not the shortest route to the current truth.

  • v2-open-questions.md
  • v2-phase-development-plan.md
  • v2-execution-muscles-inventory.md
  • v2-scenario-sources-from-v1.md
  • v2_scenarios.md
  • v1-v15-v2-comparison.md
  • v2-algorithm-overview.md
  • v2-algorithm-overview.zh.md
  • v2-detailed-algorithm.zh.md
  • v2-semantic-methodology.zh.md
  • v2-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.md
  • v2-first-migration-task-pack.md
  • v2-second-migration-batch.md
  • v2-second-migration-task-pack.md
  • v2-third-migration-batch.md
  • v2-third-migration-task-pack.md
  • v2-phase14plus-semantic-framework.md
  • v2-pure-runtime-rf1-bootstrap.md
  • v2-volumev2-single-node-mvp.md
  • v2-loop1-surface-draft.md
  • v2-rf2-runtime-bounded-envelope.md
  • v2-rf2-runtime-bounded-envelope-review.md
  • v2-separation-port-layer-audit.md
  • v2_mini_core_design.md
  • wal-replication-v2.md
  • wal-replication-v2-state-machine.md
  • wal-replication-v2-orchestrator.md
  • wal-v2-tiny-prototype.md
  • wal-v1-to-v2-mapping.md
  • v2-dist-fsm.md
  • v1-v15-v2-simulator-goals.md
  • protocol-version-simulation.md

Process

  • protocol-development-process.md
  • agent_dev_process.md

Cleanup Rule

When a document is superseded, prefer:

  1. keeping one canonical file in Core Canon
  2. leaving older reasoning in Migration And Historical Working Set
  3. 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.