mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-11-06 12:07:51 +01:00
pingqiuandClaude Opus 4.7
a68d94679c
Architect ratification 2026-04-26: "Role inference, in-process acceptance, G5-DECISION-001 seam, and sessionID discipline are architecturally correct. G-1 must clarify replica readiness semantics and confirm ctrl-addr reuse or introduce repl-addr before code." 2 binding clarifications baked into v0.3: #1 — §4 #2 acceptance criterion split by role: - Primary: Healthy=true per existing frontend/write-ready projection - Replica: replication-ready / listener-bound + ApplyEntry byte-equal verified — MUST NOT report Healthy=true if existing field implies frontend-primary-write-ready - If existing status field is too coarse, G5-4.5 uses precise assertion names (assertReplicaReplicationReady, assertPrimaryFrontendReady) instead of unified assertHealthy #2 — §4 #7 acceptance criterion strengthened: - Catalogue inscription ALONE insufficient at G5-4 close - 5 INV-BIN-WIRING-* invariants MUST land in v3-invariant-ledger.md - Per v3-quality-system.md §6 "an invariant without a test is a wish" - Ledger updated as PR atomic with code (not after-the-fact) §7.1 G-1 deliverable extended (G-1-blocking subitems): - Replica readiness semantics — what existing volume.Status / ProjectionView field expresses replication-ready (vs Healthy)? G-1 either proposes new field OR specifies precise assertion names - --ctrl-addr reuse confirmation — verify NO conflict with NVMe/iSCSI control-plane traffic on same port. If conflict, G-1 introduces --repl-addr flag (small scope expansion, contained in this batch) §3 #4 predicate flipped to ✅ DONE (architect round 50). §8 sign table updated with explicit ledger requirement at close. Architect-pre-baked: ratification stays valid; no further mini-plan revisions needed before G-1. Sw next: produce G-1 V3-native PORT read deliverable per §7.1 (includes the 2 binding subitems). Code stays blocked until architect ratifies G-1. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.