Files
seaweedfs/sw-block/design
pingqiuandClaude Opus 4.7 6d8d088273 T4 L1 survey round 3: sw V2 verification of Q1-Q3 + §3.14 AllBlocks hazard + §3.a locked-pairs
Closes QA round-2 feedback loop. Three concerns resolved and one L2-blocker
hazard added.

## Q1-Q3 resolution (sw-verifiable per QA concern; V2 source check)

  Q1 scope completeness: VERIFIED complete. V2 grep shows sync_all_* are
  three test files only — `sync_all_adversarial_test.go`, `sync_all_bug_test.go`,
  `sync_all_protocol_test.go`. Zero production files for sync_all / split_brain /
  takeover / arbiter. These are cross-entity invariants, not distinct types.
  10-entity set stands.

  Q2 ReplicaReceiver scope: VERIFIED per-volume, not per-assignment.
  `v.replRecv = recv` at `blockvol.go:1515` is the only write site; zero
  `replRecv = nil` assignments in codebase. Receiver is constructed-once per
  BlockVol instance. L1 §2.3 wording stands.

  Q3 RebuildSession/Bitmap durability: VERIFIED no sidecar. Grep
  `rebuild_bitmap.go` + `rebuild_session.go` for `os.Open / os.Create /
  WriteFile / ReadFile / persist / sidecar` → empty. Recovery is WAL
  hydration only (`hydrateBitmapFromRecoveredWAL` at `rebuild_session.go:102`).
  L1 §2.10 invariant #3 CORRECTED — earlier draft incorrectly called out a
  "sidecar schema" that doesn't exist.

## QA concern #3 resolution: §3.14 new hazard

  `AllBlocks()` semantic divergence: V3 `walstore.go:565` and
  `smartwal/store.go:367` both call `s.Read(lba)` which reads through the
  dirty map (includes unflushed WAL bytes). V2 `rebuild.go:handleExtentStream`
  uses `readBlockFromExtent` which BYPASSES dirty map (flushed-only).

  Concrete impact: V3 base stream can contain bytes the primary hasn't fsynced.
  If primary crashes pre-fsync, replica's copy is "newer" than primary's
  recovered state. Epoch fencing + WAL-wins bitmap still prevent corruption,
  but the invariant chain is "eventually consistent via epoch churn" instead
  of V2's "base stream never contains unflushed bytes". Different contracts,
  same end state.

  Two L2 options proposed: (a) keep AllBlocks semantics + document non-claim
  in §2.7 bridge; (b) add `LogicalStorage.AllBlocksFlushed()` preserving V2
  invariant. H5 architect-line decision affects which path is safer.

## QA concern #2 resolution: §3.a locked-pairs section (new)

  Documents pre-coupled L2 decisions driven by V3 existing shape:
    H6 Option C → H7b locks automatically (Provider intercepts at LogicalStorage
      layer; Backend.Write stays host-facing, doesn't carry LSN)
    §3.14 + H5 → AllBlocks safety rationale depends on which H5 shape wins

  Per BUG-005 documentation-discipline lesson: record coupled pairs explicitly
  rather than leaving them as "implied". Saves L2 cycles and gives future
  readers visible intent for why Backend.Write excludes LSN.

## QA concern #1 deferred to L2

  Volumes map extension (single-map with role discrimination vs two separate
  primaryHandles + replicaHandles maps) is a legitimate L2 design concern.
  L1 appropriately hedges with "likely needs to grow" (§3.11 Option C); L2
  picks shape. QA's BUG-005-adjacent concern (role-discriminated handle
  callers forgetting to check role) is the right frame for the L2 decision.
  No L1 edit needed; flagged for L2 attention.

## §4 open questions status

  Q1-Q3 ✓ resolved
  Q4 DistGroupCommit residence → effectively answered by §3.11 C
  Q5 protocol-frame wire-compat stance → still architect-line (pairs with H5)

  Blocking L2 start now: only H5 + Q5, both architect-line. QA to draft
  one-page arch memo per round-2 offer.

## Change log

  §5 feedback-round log gains round-3 entry
  §6 change log gains full round-3 detail with V2 line citations

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 23:42:39 -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.