mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-09-28 18:55:49 +00: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>
sw-block
Private WAL V2 and standalone block-service workspace.
Purpose:
- keep WAL V2 design/prototype work isolated from WAL V1 production code in
weed/storage/blockvol - allow private design notes and experiments to evolve without polluting V1 delivery paths
- keep the future standalone
sw-blockproduct structure clean enough to split into a separate repo later if needed
Suggested layout:
design/: shared V2 design docsprototype/: code prototypes and experiments.private/: private notes, phase development, roadmap, and non-public working material
Repository direction:
- current state:
sw-block/is an isolated workspace insideseaweedfs - likely future state:
sw-blockbecomes a standalone sibling repo/product - design and prototype structure should therefore stay product-oriented and not depend on SeaweedFS-specific paths