Commit Graph
13290 Commits
Author SHA1 Message Date
pingqiu 5cf429595f G5-5C mini-plan v0.4.1 → v0.4.2: add §1.E authority-bounded primary recovery invariant
Architect framing 2026-04-27 (sharpening v0.4.1): §1.D ordering-
independence must NOT be misread as "primary may self-discover and
connect to any replica it sees on the network." Tighten with a
second protocol invariant.

Rule (architect verbatim): "Primary recovery loop may retry only peers
that were previously admitted by a master-issued assignment fact for
the current authority lineage."

Layering: master establishes identity once; primary owns retry /
recovery for that admitted peer until master revokes or changes the
assignment.

This is structurally true in V3 today (probe loop reads
ReplicationVolume.peers, which UpdateReplicaSet populates from master
facts) but v0.4.2 promotes it from implementation detail to protocol
invariant so future contributors don't widen the probe surface.

Changes:
- New §1.E with three scenarios:
  (a) first-time replica join — disallowed without master fact
  (b) brief outage + recovery (G5-5C core case) — allowed without
      master re-emit
  (c) epoch / assignment change — probe must stop; in-flight aborts
- Implementation requirement made explicit: ReplicaPeer.Close() must
  abort in-flight probe synchronously.
- Authority alignment surface table: replicaID/epoch/EV → identity;
  AssignmentFact.Peers → only legal probe targets;
  PeerSetGeneration → existing lastAppliedGeneration guard preserved.
- New INV-G5-5C-PRIMARY-RECOVERY-AUTHORITY-BOUNDED in §3.
- New §2 #9 (authority-bounded targets test) and §2 #10 (lineage-
  change-during-probe test).
- §1.A bound-shape Master-interaction row references §1.E.
- §1 Files peer.go row notes Close() must abort in-flight probe.

Standing by for architect single-sign of v0.4.2.
2026-04-27 15:04:13 -07:00
pingqiu aebf668094 G5-5C mini-plan v0.4 → v0.4.1: add §1.D two-feedback-loop ordering-independence invariant
Architect framing 2026-04-27: when a replica goes down or recovers,
both the control-plane identity/health loop and the data-plane
governance loop receive feedback. Protocol must treat them as two
independent loops with no ordering dependency, alignment via durable
identity facts (replicaID/epoch/EV/peer address), and idempotency on
primary-side dispatch absorbing duplicate triggers.

This is a sharpening of v0.4, not a re-bind. Design unchanged:
Option B primary-side probe loop, no master protocol change.

Changes:
- New §1.D: explicit two-loop table, five ordering scenarios all
  ending safe, anti-requirements (master re-emit NOT prerequisite,
  primary recovery NOT blocked on master), idempotency guarantees,
  future RF-health observability noted as different-batch scope.
- New INV-G5-5C-TWO-LOOPS-ORDERING-INDEPENDENT in §3 with test
  pointer (peer_test.go simultaneous-fire test).
- New §2 #8 acceptance criterion: unit test exercising the
  "simultaneous-fire" case (concurrent fact replay + concurrent
  ProbeIfDegraded on same degraded peer; idempotent absorption).

Standing by for architect single-sign of v0.4.1.
2026-04-27 15:01:24 -07:00
pingqiu 4f6e5d3e6a G5-5C mini-plan v0.3 → v0.4: retire Option A, bind Option B per layering correction
Architect re-ruling 2026-04-27: control-plane / data-plane layering.
Master must own identity / topology / address / RF-health; it must NOT
own runtime recovery scheduling. v0.2/v0.3's Option A (master
observation-driven re-emission) forces master into recovery-scheduling
territory and forces PeerSetGeneration to carry two distinct semantics
(authority version + peer-set-view version). That's the wrong shape:
master gets heavier; control-plane heartbeat cadence couples to
data-plane recovery cadence; protocol cleanliness erodes.

Bind Option B (primary-side degraded-peer probe loop) with explicit
constraints. No master protocol change.

Changes:
- §1.A rewritten: Option B bound shape (only-on-degraded, 5s interval,
  per-peer cooldown, in-flight guard, max-concurrent-probes=1, CP4B-2
  lifecycle discipline). Why-A-retired + Why-C-rejected sections.
- §1.B replaced: master protocol explicitly unchanged. v0.3's
  PeerSetRevision proto field, ObservationStore.obsRev counter, and
  UpdateReplicaSet lex-compare upgrade — all three retired.
- §1.C replaced: truth-domain matrix shows zero master-side write;
  one truth domain (primary data-control) writes; all others untouched.
- §1 Files retired master-side rows; replaced with primary-side probe
  loop infrastructure (peer.go probe entry + replication probe loop +
  flags + lifecycle/cooldown/dispatch tests + component test). Total
  ~225 prod + ~310 test, all primary-side. Zero LOC master / proto.
- §2 acceptance criteria rewritten: lifecycle correctness, cooldown +
  in-flight TOCTOU, dispatch branches, hardware GREEN. New criterion
  #7: zero diff under core/host/master/, core/authority/, proto/.
- §3 INVs replaced: drop INV-MASTER-PEER-SET-GEN-REV-MONOTONIC; add
  INV-REPL-PEER-RECOVERY-PROBE-LOOP-001, retain
  INV-REPL-PEER-RECOVERY-NO-RETRIGGER-LOOP, add
  INV-G5-5C-NO-MASTER-PROTOCOL-CHANGE (anti-creep guard).
- §6 risks rewritten around probe loop concerns: lifecycle bugs
  (CP4B-2 lessons), cooldown tuning, in-flight TOCTOU, scope-creep
  prevention via §3 INV + §2 #7 diff inspection.
- §5 forward-carry: trigger source disposition updated to Option B.
- §7 sign table records full ruling history v0.1 → v0.2 → v0.3 → v0.4
  with retire/keep markings; awaiting single-sign of v0.4.

Standing by for architect single-sign of v0.4.
2026-04-27 14:59:30 -07:00
pingqiu 900e4d0cb3 G5-5C mini-plan v0.2 → v0.3: V3 paths + peer-set generation design + truth-domain wording
Architect REVISE ruling on v0.2 — three items, all addressed:

1. V3 paths (was: V2 weed/server + weed/storage/blockvol).
   v0.3 §1 Files table corrected to seaweed_block paths:
   - core/rpc/proto/control.proto (proto field add)
   - core/host/master/services.go (A1 re-emission)
   - core/authority/observation_store.go (obsRev tracking)
   - core/replication/volume.go (lex compare in UpdateReplicaSet)
   - core/host/volume/host.go (applyFact dispatch wiring)
   - core/replication/peer.go (OnReappeared entry point)
   - core/host/volume/apply_fact_test.go + master/services_test.go +
     replication/volume_test.go + replication/component/...
   Header now states Repo: seaweed_block (V3) explicitly.

2. Peer-set generation design (was: missing).
   New §1.B enumerates three options the architect named (master-
   maintained counter / observation revision folded / separate field)
   with concrete V3 mechanics + tradeoff matrix. sw recommends
   Option γ (separate PeerSetRevision field alongside existing
   PeerSetGeneration). Stale-drop hazard cited at
   replication/volume.go:194-209. UpdateReplicaSet stale-replay rule
   becomes lex compare on (generation, revision). Open architect
   choice within γ: per-slot vs per-volume rev (sw proposes per-volume
   max).
   New INV-MASTER-PEER-SET-GEN-REV-MONOTONIC inscribed in §3 with
   test pointers for revision bump + lineage reset + lex-compare
   stale-drop.

3. Truth-domain wording (was: A1 = "read").
   New §1.C corrects: A1 is publication / re-emission of master truth,
   not pure read. Remains authority-safe (no new lineage invented).
   Per-domain matrix replaces v0.2's bullet list.

§2 acceptance criteria #2/#3 updated to reference (PeerSetGeneration,
PeerSetRevision) lex-compare semantics and pin V3 test file paths.
§6 risks add two new entries: obsRev overflow (none) + master-restart
revision reset (mitigation: first-attach bootstrap clears
lastAppliedGeneration/lastAppliedRevision). §7 sign table records
absorbed REVISE items + open single-sign.

Standing by for architect single-sign of v0.3.
2026-04-27 14:48:24 -07:00
pingqiu b6267d8af7 G5-5C mini-plan v0.1 → v0.2: bind trigger source to Option A (A1+A2)
Architect REVISE ruling 2026-04-27: bind trigger source to Option A
with both halves in scope (no split into G5-5B). Reject B and C.
QA review v0.1 flagged: master-side scope must be explicit; pin §5
evidence path.

Changes:
- §1.A: collapse three-option proposal to bound Option A. Make A1
  (master-side observation-driven re-emission) and A2 (primary-side
  recovery dispatch) explicit as two halves of one causal chain.
  Record B/C rejection rationale for future reference.
- §1 Files: revise table with Side column (master/primary). Add
  master-side rows (A1 re-emit logic + ObservationStore freshness
  helper). Total estimate ~360 prod + ~150 test, split master ~90 /
  primary ~120 / tests ~150.
- §2: rewrite criteria #1-#5 around bound Option A (drop per-Option
  deadline language). Split #2/#3 into A1 master-side + A2
  primary-side criteria. Hardware deadline at #5 stays 30s.
- §2 verifier note: file paths + test names pinned at code-start
  (acceptable for v0.2 per QA review).
- §5: pin G5-5 seed evidence to actual artifact path
  V:\share\g5-test\logs\artifacts-20260427T092858Z\primary-fail.log
  (no future task — fact-pointer).
- §7: trigger-source binding row marked done (architect REVISE);
  single-sign of v0.2 still pending.
- Header: v0.1 → v0.2 status note updated.

Standing by for architect single-sign of v0.2.
No code starts until single-sign.
2026-04-27 14:38:04 -07:00
pingqiu d6a2fb92d6 G5-5 close handoff: roadmap update + G5-5C mini-plan v0.1 kickoff
Per architect single-sign of G5-5 §close (`seaweedfs@c78116fd2`):

(a) v3-dev-roadmap.md
- §3: G5 line note now mentions G5-5 closed at L3 + G5-5C carry-forward
- §4: G5-5 row → CLOSED (link to seaweedfs@c78116fd2); G5-5C row added
  as next active gate with bound pass criterion
- §7: G5-5 close commit appended to recently-closed table
  (seaweed_block@5c4718f + seaweedfs@c78116fd2, L3 reached, #4 carry)

(b) v3-phase-15-g5-5c-mini-plan.md (new) v0.1 kickoff
- §1 scope: peer recovery trigger after replica restart; reuse T4d-4
  primitives (architect binding); no engine logic change
- §1.A: three trigger source options (A master observation, B periodic
  probe, C transport reconnect) with tradeoffs; sw recommends A; final
  pick deferred to architect ratification
- §2: 6 acceptance criteria, hardware step is exactly G5-5 #4
  (verify_restart_catchup → GREEN with no harness changes)
- §3: 2 new INVs proposed (REPL-PEER-RECOVERY-TRIGGER-001 +
  -NO-RETRIGGER-LOOP) + 2 deferred ledger pointers from G5-5 close
- §4: G-1 N/A (new build, no V2 PORT)
- §5: forward-carries from G5-5 §close all addressed
- §6: 5 risks tabled
- §7: sign table awaiting architect §1-§6 ratification including
  trigger source pick

Standing by for architect ratification of trigger source binding.
No code starts until §1-§6 signed.
2026-04-27 02:41:52 -07:00
pingqiu c78116fd2f G5-5 §close doc-fix #2: drop stale 'blocked' sign-table rows
Architect's round-15 hygiene callout: §7 sign table still had
three pre-code 'blocked' rows after the real close-state rows
landed in the prior doc-fix commit. Pure leftover from before
the close-state update overwrote earlier rows but didn't delete
the trailing pre-code rows.

Removed:
  - 'Code start (script + Go helper) ... blocked on ratification'
  - 'm01 hardware verification run ... blocked'
  - '§close append + close sign ... blocked'

Sign table now ends cleanly at the §close architect single-sign
pending row. Ready for sign.
2026-04-27 02:33:34 -07:00
pingqiu 12fcdb41f8 G5-5 §close doc-fix: forward-carry text + sign-table state + ledger update + header
Architect ratification round 14: substance approved, but doc-fix
required before single-sign. Four hygiene fixes:

1. §5 forward-carry consumed: was 'both paths consumed; neither
   carries forward'. Now correctly states process-restart path
   FAILED on m01 hardware and carries to G5-5C (matches §close
   substance and architect ruling 2026-04-27).

2. §7 sign table: stale pre-code rows replaced with actual close
   state (ratification , code  landed at seaweed_block@2745cf4
   et seq, m01 verification  rounds 1-14, §close submitted ,
   architect single-sign  pending).

3. §3 'Invariants whose ledger row updates at G5-5 close' had
   placeholder 'Last verified → 2026-04-DD' text. Now reflects
   actual ledger updates landed in this same commit. Ledger
   updated: 5 INV-BIN-WIRING-* rows now show Last verified=
   2026-04-27 (G5-5 §close — Tier 2 m01 cross-node hardware
   Integration backstop: seaweed_block@5c4718f rounds 1-14).
   T4 invariants (INV-REPL-CATCHUP-FROMLSN-IS-REPLICA-FLUSHED-
   PLUS-1, INV-REPL-LSN-ORDER-FANOUT-001) deferred to G5-5C
   close (single Integration row update covering #2 + #4
   together, since #4's verify lands at G5-5C).

4. Header: DRAFT v0.3 → §close submitted, awaiting single-sign.

5. Bottom 'Next actions' table: stale pre-code routing rows
   replaced with post-§close routing (architect single-sign,
   sw roadmap update + G5-5C mini-plan, QA optional clean run).

No substance change. Pure doc hygiene. After this commit
architect can single-sign per v3-batch-process.md §5 + §8C.2.
2026-04-27 02:31:04 -07:00
pingqiu 54feecb31d G5-5 §close: 3 of 4 verify steps GREEN on m01 hardware; #4 carry → G5-5C
§close summary per v3-batch-process.md §12 template:

  Done:
    - #1 verify_cluster_ready
    - #2 verify_byte_equal — live iSCSI replicated write, byte-equal
      verified via storage-aware m01verify (LBA[0]=0xab on cross-host
      hardware)
    - #3 verify_network_catchup — iptables disconnect+heal, replica
      converges to LBA[1]=0xcd byte-equal in 8s via engine-driven
      catch-up
    - 14 bugs surfaced+fixed across 14 m01 self-iteration rounds
    - 5 INV-BIN-WIRING-* invariants in v3-invariant-ledger.md from
      G5-4 still load-bearing; G5-5 hardware run is Integration backstop

  Not done:
    - #4 verify_restart_catchup — kill replica + write while down +
      restart: replica's LBA[2]=0xef does NOT converge in 30s. Per
      architect ruling 2 (round 13): real recovery-path finding,
      surface as G5-5C carry-forward.
    - #5 verify_race_stress + #6 verify_full_suite — gated on #4 fix
      or test sequencing rework.

  Product level reached: L3 (Replicated IO) per v3-architecture.md §13.
  Falls short of full L4 (Failure/recovery under IO) — process-restart
  recovery is the gap, scoped as G5-5C.

  Next gate that makes it usable: G5-5C Peer Recovery Trigger After
  Replica Restart — fix engine-driven catch-up re-trigger when a
  degraded peer becomes reachable again. After G5-5C: re-run #4 #5 #6
  in this same harness; full L4 reached.

Forward-carries to G5-5C (architect-bound 2026-04-27):
  - Reuse existing engine-driven recovery primitives (T4d-4); no
    ad-hoc re-ship from replication layer.
  - Define trigger source first: observation reappearance, periodic
    probe loop, or stream/transport reconnect signal.
  - Pass criterion: exactly the failed hardware case from G5-5 #4.
  - Seed evidence: seaweed_block@5c4718f primary-fail.log shows the
    gate-degraded + stale-barrier-ack pattern.

Forward-carries to opportunistic future hardening:
  - Unit test for EnsureStorage→assignment-arrives→first-Open
    Identity-latch path (would have caught round-10/11 bug pre-m01).
  - Generalize start_cluster() pre-flight stale-state cleanup pattern
    for future hardware harnesses.

Forward-carries to G5-6:
  - G5-DECISION-001 (Path A vs Path B) — engine-state serializability
    pinned in T4d still holds; G5-5 doesn't change posture.

Pending: architect single-sign on §close per v3-batch-process.md §5
+ §8C.2.

Refs: 24 commits in seaweed_block@phase-15 spanning rounds 1-14
(documented in §close.evidence.commits table).
2026-04-27 02:23:24 -07:00
pingqiu 774cee5bf4 G5-5 mini-plan v0.3: §2 acceptance criteria rewritten (architect REVISE round 51-followup)
Architect's v0.2 review caught that §1 absorbed the 3 binding revisions
but §2 (the close contract per v3-batch-process.md §2) stayed stale:
  - §2 #2 still said "byte-equal on replica's walstore extent"
  - §2 had old #4 (race stress) instead of new #4 (process restart)
  - §2 #3 didn't name /status/recovery as the R/H source

v0.3 rewrites §2 to match §1, with explicit verifier names:

  #1 verify_cluster_ready
  #2 verify_byte_equal — m01verify Go helper using walstore.OpenReadOnly
     + storage.LogicalStorage.Read(lba) + SHA-256 (NO raw extent peek)
  #3 verify_network_catchup — iptables disconnect + polls
     /status/recovery?volume=v1 for R/H; asserts RecoveryDecision="catch_up"
  #4 verify_restart_catchup — SIGTERM replica + restart same binary +
     same --durable-root; polls /status/recovery same as #3
  #5 verify_race_stress — 10x -race on G5-4.5 integration test
  #6 verify_full_suite — go test ./... clean from m01
  #7 v3-dev-roadmap.md updated at gate-close per v3-batch-process.md §8

§1 file map and §5 forward-carry table already match v0.3 numbering
(grep confirmed no stale references). Implementation scope unchanged
from v0.2 (~310 prod LOC + ~30 unit tests).

v3-batch-process.md §2 single-source-of-truth discipline preserved:
§2 acceptance criteria IS the close contract; §1 scope description
stays in sync but is not load-bearing for close evidence.
2026-04-26 21:09:17 -07:00
pingqiu e0261bfd84 G5-5 mini-plan v0.2: architect REVISE-BEFORE-CODE responses
Addresses 3 architect revision requirements (round 51):

REVISION 1 — process restart distinct from network disconnect:
  Split G5-4 #4 forward-carry into TWO scenarios:
    §2 #3 network disconnect (iptables) — proves live TCP interrupt
          + recovery without process restart
    §2 #4 replica process stop/restart — proves durable reopen +
          master resubscribe + recovery reconstruction
  G5-4 #4 is now FULLY consumed (was: only network proxy in v0.1).

REVISION 2 — storage-aware byte verifier:
  Replace raw walstore .extent peek with storage-abstraction Read(lba):
    helper opens replica's walstore via core/storage/walstore (or
    equivalent OpenReadOnly path), invokes Read(lba) per LBA in the
    range, SHA-256 vs primary's known payload. Raw extent peek
    REJECTED — walstore on-disk includes WAL frames + checkpoints
    + sparse regions + potentially-stale-but-valid blocks; only
    Read(lba) returns the authoritative current value.
  Risk added: if walstore.OpenReadOnly is missing, sw adds it as
  part of this batch (small scope expansion contained in
  core/storage/walstore; read-only opener for verification only,
  NOT a substrate semantic change).

REVISION 3 — named R/H observation source:
  /status?volume=v1 returns frontend.Projection (no R/S/H). G5-5
  adds /status/recovery?volume=v1 returning engine.ReplicaProjection
  (Mode, R, S, H, RecoveryDecision); gated by new --status-recovery
  daemon flag (default off; production binaries don't enable).
  Loopback-only via existing isLoopbackRemote guard. ~30 prod LOC
  + ~30 unit tests. Engine/adapter logic unchanged — surfaces
  already-computed projection through HTTP.

Updated §1 file map, §1.4 truth-domain check, §5 forward-carry
table, §6 risks (3 new rows), §close template unchanged.

Re-submitted for architect §1-§6 ratification. After ratify, sw
codes per §1 file map; estimate ~310 prod LOC + ~30 unit tests.
2026-04-26 21:06:46 -07:00
pingqiu 4045f8c8aa G5-5 mini-plan v0.1 — first trial of compressed v3-batch-process.md
Single doc per v3-batch-process.md §2: scope + acceptance + invariants
+ forward-carry + risks + sign table; §close appended at batch close
(no separate kickoff / closure / G-1 docs).

Scope: m01 hardware first-light, promoting G5-4's L1 (binary
composition) result to L3 (Replicated IO) per v3-architecture.md §13:
  1. iterate-m01-replicated-write.sh orchestration script
  2. Real iSCSI write byte-equal primary→replica on hardware
  3. iptables disconnect + engine-driven catch-up (within retention)
  4. 10x -race stress on G5-4.5 integration test (m01 has CGO/gcc)

Architecture touchpoints (v3-architecture.md):
  §6.1 Write Path, §6.3 Replication Path, §7 Recovery

Explicit non-claims: rebuild path, NVMe target, durability modes,
failover, backend-layer failure injection — all defer to follow-up
batches per §1.

Forward-carry consumed (G5-4 §close criteria 3+4+6).

G-1 N/A (V3-native verification batch, no V2 muscle PORT).

Per v3-batch-process.md §15: per-agent action list at end.
2026-04-26 21:02:24 -07:00
pingqiu 087343dd14 v3-batch-process §14: clarify architect/sw/QA are AI agents; user routes between them 2026-04-26 20:58:47 -07:00
pingqiu 34dfbb66ef v3-batch-process §15: per-agent action list at end of every response (cut user's routing load) 2026-04-26 20:57:51 -07:00
pingqiuandClaude Opus 4.7 0965a36b16 v3-batch-process §12-§13 + v3-architecture.md (architect first-order)
Architect additions to v3-batch-process.md:
  §12 Architect review checklist — system-level drift check (4 questions:
      scope truth, V2/new-build decision, engine/adapter impact,
      product usability level). Close-sign template enforces honest
      "Done / Not done / Product level reached / Next gate" statement.
  §13 Failure modes process must prevent — 5 observed waste sources:
      V2 porting drift, engine/adapter change without reason, function
      close = happy path only, product unusable despite green tests,
      missing architecture component (catches like binary wiring +
      G9A placement gap).
  §14 (renumbered from §12) — ownership table unchanged.

v3-architecture.md (NEW first-order doc, architect-authored):
  369 lines, 15 sections covering component map, truth domains,
  control-plane + data-plane flows, recovery architecture, failure
  model, operator interface, P15 gate alignment, product completion
  ladder, open architecture decisions, change discipline.

  Bridges the gap surfaced in conversation: WHAT (gates) + behavior
  contracts + anti-patterns existed; HOW the system fits together
  was missing. v3-architecture.md is now peer of mvp-scope-gates.md
  + block-behavior-contract-index.md as first-order references.

  v3-batch-process §8 control-doc table updated to include
  v3-architecture.md as architect-owned, "component/responsibility/
  flow changes" trigger.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 20:55:07 -07:00
pingqiuandClaude Opus 4.7 a8b0999c45 v3-batch-process §12: ownership table
Codifies who owns each step based on what actually worked in T4 + G5:

  - Gate scope: architect
  - Batch sketch (mini-plan §1-§6): sw
  - G-1 V2 read (when V2 PORT): sw
  - Mini-plan ratification: architect signs + QA reviews
  - Code + unit tests: sw
  - Component scenarios + m01 verification: QA
  - Ledger inscription (PR-atomic): sw
  - §close append: sw drafts + QA verifies
  - Close sign: architect single-sign

Why sw plans (not architect):
  - Knows code feasibility + framework state
  - Self-commits to deliverable scope (fewer revision cycles)
  - Architect ratifies SCOPE but doesn't need implementation detail
    (caught 2 binding clarifications at G5-4 v0.2→v0.3 — that's the
    right level of architect involvement)

Why QA reviews (doesn't plan):
  - Independent third party (not scope or implementation advocate)
  - Catches discipline gaps sw + architect miss
  - Owns m01 hardware + component scenarios

Edge cases:
  - Process changes (this doc): QA proposes; architect signs
  - Hotfix-class (§6.3): sw self-authors + self-merges; QA spot-reviews;
    architect ratifies if invariant-affecting

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 20:31:51 -07:00
pingqiuandClaude Opus 4.7 d0cbe66702 v3-batch-process.md (NEW): compressed batch governance
Codifies the lessons from T4 + G5-4 retrospective:

KEEP — earned its keep on T4:
  - G-1 V2 PORT read (saved 5 hidden invariants on T4b-4, probe non-
    mutation pin on T4c-2, 3 placement decisions on T4d-3)
  - Mini-plan acceptance criteria (single source of truth for close)
  - Invariant ledger discipline ("claim without test = wish")
  - m01 -race verification (caught 2 engine bugs at T4d-4 part C)
  - Architect single-sign at close (caught 4 stale refs at G5-4 close)

DROP — overhead without payoff:
  - Separate kickoff PROPOSAL doc (mini-plan §1-§6 = same thing)
  - Separate G-1 doc (inline §4 of mini-plan)
  - Separate closure report doc (§close section of mini-plan)
  - Separate forward-carry checklist (§5 of next-batch mini-plan)
  - Separate QA scenario catalogue (write tests directly when ready)
  - Multi-version doc churn (v0.1→v0.5)
  - Cross-doc invariant restatement (ledger is sole source)
  - Mixed T-track + G-N naming for same gate

Compressed sign cycles: was 4-5 architect signs per batch; now 2
(scope ratify + close sign).

Per-batch artifact count: was 5+ (kickoff + mini-plan + G-1 +
closure + checklist + scenario catalogue); now 1 (mini-plan with
§close appended).

Decision rules codified:
  §6.1 G-1 yes/no (V2 PORT yes; V3-native no)
  §6.2 T-track vs G-N naming (architect picks at kickoff)
  §6.3 When to skip mini-plan (1-line hotfix-class)

§8 names the 6 first-order control docs to keep current
(v3-dev-roadmap, v3-phase-15-mvp-scope-gates, v3-invariant-ledger,
v3-block-behavior-contract-index, v3-product-placement-authority-
rationale, v2-v3-contract-bridge-catalogue).

§9 first trial: G5-5 m01 hardware first-light.

§11 honesty principle: documentation that catches bugs is
discipline; documentation that doesn't is ceremony. Drop ceremony,
keep discipline.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 20:30:11 -07:00
pingqiu 0667f8edbf v3-dev-roadmap: link v3-block-behavior-contract-index as first-order architect ref 2026-04-26 20:21:40 -07:00
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
pingqiuandClaude Opus 4.7 daafc8e25b G5-4 mini-plan v0.5: architect close-sign + doc-lock
Architect ratification round 51 verbatim:
"APPROVED — G5-4 close. Binary T4 replication wiring is complete at
commit seaweed_block@c820e17; criteria 1/2/5/6/7 satisfied; criteria
3/4 explicitly relocated to G5-5 hardware first-light; --data-addr
correction accepted; 5 INV-BIN-WIRING-* rows ACTIVE. Close claim is
wiring-ready, not byte-movement-ready."

4 doc-lock corrections applied:

1. Header status v0.2 → v0.5 CLOSED + close-sign metadata
2. §1.2 + §1.5: --ctrl-addr → --data-addr correction inscribed
   - executor dials peer.DataAddr (core/transport/executor.go:303)
   - listener MUST bind the address master mints into
     AssignmentFact.peers[*].DataAddr
   - --ctrl-addr reserved for future control-plane split; verified
     no current binder + no NVMe/iSCSI/status conflict
3. §4 #3 + #4: marked RELOCATED to G5-5 with rationale (in-process
   subprocess can't drive real iSCSI/NVMe write without kernel
   client; G5-5 m01 has the kernel tooling)
4. §4 #6: marked DONE (m01 -race ×10 PASS in 13.2s; was pending
   in v0.4); §4 #1/#2/#5/#7 marked DONE with evidence pointers

Final state:
  - 5 of 7 acceptance criteria satisfied (1, 2, 5, 6, 7)
  - 2 criteria (3, 4) RELOCATED to G5-5 hardware first-light
  - 5 INV-BIN-WIRING-* rows ACTIVE in v3-invariant-ledger.md
  - Code: seaweed_block@c820e17 (binary wiring + integration test)
  - Ledger: seaweedfs@36ba7b44e (5 invariant rows)

Close claim: wiring-ready, NOT byte-movement-ready (per architect).
G5-5 m01 first-light certifies byte-movement.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 20:07:08 -07:00
pingqiu 36ba7b44e1 G5-4: 5 INV-BIN-WIRING-* invariants inscribed in ledger
PR-atomic with seaweed_block@c820e17 per architect binding round 50
(mini-plan v0.4 §4 #7): ledger inscription required at G5-4 close.

  - INV-BIN-WIRING-ROLE-FROM-ASSIGNMENT
  - INV-BIN-WIRING-PEER-SET-FROM-ASSIGNMENT-FACT
  - INV-BIN-WIRING-LISTENER-LIFECYCLE-LIFO
  - INV-BIN-WIRING-ASSIGNMENT-DRIVES-MEMBERPRESENT
  - INV-BIN-WIRING-SESSIONID-VIA-ADAPTER

All 5 are ACTIVE with test pointers to
cmd/blockvolume/g5_4_l2_replication_test.go (subprocess integration)
+ source-side checks in cmd/blockvolume/main.go and core/host/volume.

Last verified 2026-04-26 (G5-4 close).
2026-04-26 17:03:52 -07:00
pingqiuandClaude Opus 4.7 3892ab29ce G5-4 mini-plan v0.4: G-1 ceremony DROPPED; sw cleared to code
User question surfaced the overhead-vs-value of G-1 for V3-native
batches. Honest assessment:

G-1 ceremony EARNED its keep on T4 V2-PORT batches:
  - T4b-4 G-1 caught 5 hidden invariants pre-code
  - T4c-2 G-1 caught probe non-mutation discipline pin
  - T4d-3 G-1 caught 3 placement decisions

G-1 ceremony does NOT earn its keep for G5-4:
  - V3-native binary integration (not V2 muscle PORT)
  - Mini-plan v0.3 already has scope + 7 acceptance criteria + 5
    inscribed invariants + file map
  - Architect's 2 binding questions (round 50) are small design
    questions answerable in PR description, not separate ratified doc

v0.4 changes:
  §7.1 #1 — G-1 deliverable struck through; replaced with PR-
    description requirements for the 2 architect bindings
  §3 #5 predicate — G-1 dropped; sw cleared to start G5-4.1
  §8 sign table — code-start row "▶️ unblocked" (was " pending")
  G5-4 close requirements unchanged: 7 acceptance criteria + 5
    invariants in ledger + PR cites resolution of 2 architect bindings
    + architect single-sign per §8C.2

Process lesson: don't auto-port T4 governance template to every batch;
ask "does this step earn its keep" each time. Future V2-PORT batches
still get G-1 ceremony. Future V3-native batches: mini-plan + PR
review + G-2/G-3 gates is sufficient.

Sw next: code G5-4.1 → G5-4.2 → G5-4.3 → G5-4.4 → G5-4.5 in order.
PR description must cite resolution of 2 architect round-50 bindings.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 16:39:31 -07:00
pingqiuandClaude Opus 4.7 a68d94679c G5-4 mini-plan v0.3: architect round-50 RATIFY with 2 bindings
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>
2026-04-26 16:28:08 -07:00
pingqiu c46c52e1aa G5-4 mini-plan v0.2: QA round 1 review responses
Addresses QA's 3 notes + 1 clarification ask:

Note 1 (role inference):
  §1.3 rewritten — fact.ReplicaID is master-minted (proto verified
  at control.proto:128-148 + mint site at services.go:198-205).
  Binary reads `fact.ReplicaID == self.ReplicaID` directly. No
  lex-smallest fallback (master always names exactly one bound
  replica per volume per line). Removes the binary-side authority
  inference that violated the master-authority rule.

Note 2 (acceptance circular):
  §4 #2 verifier reframed to G5-4.5 in-process test. m01 hardware
  verification belongs to G5-5; G5-4 closes on the in-process pin.

Note 3 (G5-DECISION-001 contradiction):
  §5 rewritten — G5-4 ships Path B runtime AND keeps Path A
  serializability seam open. T4d-4 part B's RoundTripJSON test
  already pins serializability; G5-4 preserves it. G5-6 architect
  ratification can promote to Path A by adding persistence on top
  of the existing struct, with no engine-state-shape change.

Clarification ask (sessionID minting):
  §6 added INV-BIN-WIRING-SESSIONID-VIA-ADAPTER. Adapter mints
  unique sessionIDs via process-wide atomic counter at
  adapter.go:70; binary inherits for free as long as it dispatches
  via the adapter (never via framework shortcuts that hardcode
  sessionID=1, which is the known T4c §I + QA G5-1 round 1 SKIP
  gap). Pinning this invariant keeps the gap test-side.

Re-submitted for QA re-review per parent kickoff §7 governance loop.
2026-04-26 16:20:37 -07:00
pingqiu c6b2685890 G5-4 mini-plan v0.1: binary T4 replication wiring
Mirror cmd/blockvolume to T4d-4 part B's WithEngineDrivenRecovery()
framework binding. Single batch (~250 prod + ~150 tests), 5 ordered
subtasks. Design decisions (a-d per kickoff §3 G5-4 row):

  (a) Role inference: assignment-driven, no new CLI flag
  (b) Peer discovery: AssignmentFact.Peers per T4a-5 P-refined
  (c) Listener lifecycle: --ctrl-addr reuse + LIFO Stop in host.Close()
  (d) Engine instantiation: one engine per volume, single --volume-id

Pre-merge gates require G-1 V3-native PORT read of cluster.go:357-369
+ V2 lesson check on weed/storage/blockvol/blockvol.go before code.

4 new invariants to inscribe at close (INV-BIN-WIRING-*).

Submitted for QA + architect ratification per parent kickoff §7
governance loop. No code until ratify.
2026-04-26 16:08:35 -07:00
pingqiuandClaude Opus 4.7 bf77e2b57a G5 kickoff v0.3: architect round-49 RATIFY WITH DOC FIXES
Architect sign by pingqiu 2026-04-26:
"6-batch shape 批准; G5-4 governance loop 批准 (kickoff → mini-plan
→ G-1 → code); ordering 批准 (G5-1/2/3 可并行; G5-4 blocking G5-5;
G5-6 closure last); G5-DECISION-001 timing 放在 G5-6 close 最合适."

5 doc fixes applied:
  1. §4 #1 "5 G5 batches" → "6 G5 batches" with explicit batch list
  2. §6 forward-carry table — G5-DECISION-001 → G5-6 + m01 → G5-5
  3. §8 "5-batch shape" struck through with v0.3 ratify note
  4. handoff doc title + §0 context renamed G5-4 → G5-5 for m01;
     added v0.3 architect-round-49 note explaining renumber
  5. §7 status relaxed from "No G5 code begins until ratified" to
     "No G5-4 code begins until G5-4 mini-plan/G-1 ratifies" +
     explicit cleared-to-start list

Sw + QA clearances effective immediately:
  - QA cleared: G5-1 scenario authoring (component-scope, no
    binary wiring needed)
  - QA cleared: G5-2 primary-only smoke
  - sw cleared: G5-3 metrics/backpressure assessment
  - sw cleared: G5-4 mini-plan + G-1 V2-native PORT read
    (T4d-4 part B component framework as PORT source)

Held until further governance:
  - G5-4 binary-wiring CODE (waits for G5-4 mini-plan + G-1 ratify)
  - G5-5 m01 hardware first-light (depends on G5-4)
  - G5-6 G5-DECISION-001 architect resolution (at close)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 15:40:38 -07:00
pingqiuandClaude Opus 4.7 ead22edcd5 G5: surface binary T4-wiring as new G5-4 batch (was implicit; now explicit)
Hand-off doc v0.3 + G5 kickoff v0.2: m01+M02 bring-up smoke surfaced
that cmd/blockvolume binary lacks T4 replication wiring entirely.
Sw-confirmed root cause:
  - --t1-readiness HealthyPathExecutor is primary-only by design
  - volume.Config.ReplicationVolume slot exists (host.go:73) with godoc
    "T4a-5 production wiring sets this" — but T4a-5 only added the
    field; the wiring NEVER landed
  - T4d-4 part B wired WithEngineDrivenRecovery() for component test
    framework (cluster.go:357-369), NOT for the binary
  - Result: V3 components compose end-to-end (proven by T4d HARD GATE
    #3); the production binary still constructs a primary-only data
    plane

Sw confirmed this is real implementation work (150-300 LOC + design),
not a 50-LOC quick patch. Four design decisions needed:
  1. Role inference (assignment vs CLI flag vs topology)
  2. Peer discovery (from AssignmentFact.Peers)
  3. Listener lifecycle (--data-addr reuse + Stop)
  4. Engine instantiation (one engine per volume)

G5 kickoff revised to v0.2:
  - 5 batches → 6 batches (binary wiring promoted to G5-4)
  - G5-1/2/3 are NOT blocked by G5-4 (component framework already
    binds T4d-4 part B; QA scenarios + walstore cadence at
    component/primary-only scope can run in parallel)
  - G5-4 binary wiring: needs full governance loop (kickoff →
    architect ratify → mini-plan → architect ratify → G-1 → code).
    G-1 source: T4d-4 part B component framework as V3-native PORT
  - G5-5 m01 hardware first-light DEPENDS on G5-4 (script can't
    drive replica scenarios until binary supports replicas)
  - G5-6 G5-DECISION-001 resolution at G5 close (was G5-5 in v0.1)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 11:38:31 -07:00
pingqiuandClaude Opus 4.7 fbcfe89e24 G5-4 bring-up hand-off v0.2 — RESOLVED via local debug
Root cause for "volume not ready" gate: missing
--expected-slots-per-volume 2 flag on blockmaster.

Default is 3; QA's 2-node topology had 2 slots; controller
silently rejected observation snapshot (cmd/blockmaster/main.go:39).

Fix verified locally on Windows (single-node, no m01/M02 needed):
  - Add --expected-slots-per-volume 2 to blockmaster command
  - Primary reaches Healthy=true with epoch=1
  - assignment-received fires; durable storage opens; status
    endpoint serves {"Healthy":true}

Lesson learned (process improvement): for V3-internal bring-up
debug, try single-node local reproduction FIRST. The cluster
bring-up gate is V3 logic, not network topology. Reproduces in
seconds locally with full source-code access; m01/M02 only needed
for cross-node-specific scenarios (real network conditions,
iptables, multi-host wire).

Secondary finding: replica r2 sees primary r1's assignment but
records "supersede, not applying to adapter" because T1
HealthyPathExecutor only handles primary case. For G5-4 replica
bring-up, sw needs to wire T4a-T4d ReplicationVolume + ReplicaPeer
+ ReplicaListener stack (not just --t1-readiness flag). This is
the actual next gap for G5-4.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 10:41:02 -07:00
pingqiu e21c686939 G5-4 m01+M02 bring-up — sw answer: --expected-slots-per-volume flag
Root cause: cmd/blockmaster/main.go hardcoded ExpectedSlotsPerVolume=3.
QA's 2-slot topology silently failed validateVolumeTopology in the
controller, so no assignments were minted, no master-log lines,
and volumes timed out at durable open.

Fix landed in seaweed_block@f5de7c5: --expected-slots-per-volume
CLI flag, default 3, set 2 for the 2-node smoke.

QA next: rebuild blockmaster, pass --expected-slots-per-volume 2
in §3.4 of the handoff command sequence; rest unchanged.
2026-04-26 10:37:20 -07:00
pingqiuandClaude Opus 4.7 2d9c2be9f3 G5-4 m01+M02 cluster bring-up — hand-off to sw
Records QA's cross-node smoke attempt 2026-04-26: infrastructure
fully verified READY (m01+M02 reachability, SMB share for binary
distribution, master cross-node listen, network OK), but cluster
bring-up blocked at V3-internal gate.

Symptom: blockvolume on both nodes connects to master but logs
"durable open: frontend: volume not ready" — never reaches steady
state, status endpoint never binds, master log shows no heartbeat
or assignment-mint events.

Hand-off contents:
  - §1 specific questions for sw (5 gaps to fill)
  - §2 infrastructure verified READY (no action needed)
  - §3 copy-pasteable commands sw can run/debug
    (build → topology → master → primary → replica → cleanup)
  - §4 QA's hypothesis on the gap (assignment-from-master flow)
  - §5 debug suggestions for sw (log levels, integration test
    references)
  - §6 G5-4 script skeleton current state
  - §7 QA's next steps once sw answers

Working dirs reproducible:
  - Binaries: /mnt/smb/work/share/g5-binaries/{blockmaster,blockvolume}
  - Run state: /tmp/g5sm/ on both nodes
  - Logs: /tmp/g5sm/logs/{master,primary,replica}.log

Blocks: G5-4 implementation work (script scenario bodies, hardware
first-light scenarios). Does NOT block QA scenario authoring at
component scope (Cluster framework already covers that).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 10:32:10 -07:00
pingqiuandClaude Opus 4.7 ce78fea36f G5 kickoff §7a: m01 + M02 infrastructure verification (QA pre-ratify)
Per QA infra-check round 2026-04-26, surfaces real readiness gaps
before architect ratifies G5-4 schedule:

m01 (192.168.1.181 — primary node):
   32-day uptime; sudo password-less; 16 cores; 19 GiB RAM
   177 GiB free disk; Go 1.26.2 installed
   iptables / netns / multi-process tools all available
   T2 m01 NVMe script template available as pattern reference

M02 (192.168.1.184 — replica node):
   Reachable from m01 (0.92ms); same kernel; 178 GiB free disk
   Go NOT installed — must scp binaries from m01

Implication for G5-4:
  Build binaries on m01, scp to M02. Same cross-node binary pattern
  T2 already uses for its iSCSI target deployment. G5-4 skeleton at
  seaweed_block/scripts/iterate-m01-replicated-write.sh implements
  this build-then-scp flow.

No infrastructure blockers. Architecture ready as soon as G5 mini-plan
ratifies scenario list.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 09:38:57 -07:00
pingqiuandClaude Opus 4.7 a792ed67e5 G5 kickoff PROPOSAL v0.1 (post-T4 close)
QA-authored proposal opening G5 collective close planning.
Inherits 5 forward-carries from T4d closure §I as G5 scope:
  - m01 hardware first-light for replicated write path
  - Multi-replica concurrent live + recovery scenarios
  - G5-DECISION-001 resolution (Path A persist vs Path B rebuild)
  - walstore flusher cadence verification + tuning policy
  - Minimal metrics/backpressure assessment

5-batch shape proposed:
  - G5-1 multi-replica scenarios (component) — QA + sw framework
  - G5-2 walstore cadence verification — sw + architect
  - G5-3 metrics/backpressure assessment — sw + architect
  - G5-4 m01 hardware L3 first-light — QA + sw
  - G5-5 G5-DECISION-001 resolution + closure report — architect + sw + QA

QA recommendations:
  - G5-DECISION-001: Path B (rebuild from probe after restart) for
    MVP scope. T4d-4 part B already structurally enables (ReplicaState
    JSON-clean per TestG5Decision001_*); production restarts rare;
    Path A's persistence work substantial. Backwards-compatible
    upgrade later if production usage proves Path B insufficient.
  - G5-5 timing at close (after G5-1/2/3/4 evidence informs decision)
  - §2.2 explicit non-claims to prevent G5 scope creep:
    * CARRY-T4D-LANE-CONTEXT-001 → post-G5 hardening backlog
    * --durable-walsize CLI flag → post-G5
    * Snapshot-based catch-up → post-G5
    * Wire protocol versioning → post-G5
    * Auth/encryption/mTLS → post-G5

Status: ⏸ DRAFT — awaiting architect ratification on §2 scope +
§3 batch shape + §4 acceptance bar + §5 G5-DECISION-001 path.

No G5 code work begins until ratified.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 00:26:15 -07:00
pingqiuandClaude Opus 4.7 75d18e676f T4d batch close: catalogue invariant upgrades + checklist v0.3
Catalogue §3.3 — 12 T4d invariants flipped from ⏭ to ✓ PORTED with
specific commit hashes; 4 round-47/48 invariants newly inscribed:

Pre-existing flipped to ✓ PORTED:
  - INV-REPL-NO-PER-LBA-DATA-REGRESSION → bd2de99 + 01f4ab9
  - INV-REPL-RECOVERY-STALE-ENTRY-SKIP-PER-LBA → bd2de99
  - INV-REPL-RECOVERY-COVERAGE-ADVANCES-ON-SKIP → bd2de99
  - INV-REPL-LIVE-LANE-STALE-FAILS-LOUD → bd2de99
  - INV-REPL-RECOVERY-COVERAGE-RESTART-SAFE → bd2de99
  - INV-REPL-LANE-DERIVED-FROM-HANDLER-CONTEXT → 01f4ab9 + 44c60dd
    (with named carry CARRY-T4D-LANE-CONTEXT-001 to post-G5)
  - INV-REPL-TRANSPORT-STORAGE-CONTRACT-ONLY → 44c60dd + 1edeb36
  - INV-REPL-CATCHUP-FROMLSN-IS-REPLICA-FLUSHED-PLUS-1 → 44c60dd
  - INV-REPL-CATCHUP-FROMLSN-FROM-ENGINE-STATE-NOT-PROBE → 44c60dd

Newly inscribed (round-47 + round-48 architect additions):
  - INV-REPL-CATCHUP-EXHAUSTION-ESCALATES-TO-REBUILD → 812d3fa + e642ae8
  - INV-REPL-REBUILD-FAILURE-TERMINAL → 812d3fa
  - INV-REPL-FAILED-SESSION-KIND-DRIVES-ESCALATION (part C bug #1) → e642ae8
  - INV-REPL-REBUILD-ESCALATION-STICKY-UNTIL-TERMINAL (part C bug #2) → e642ae8

Forward-carry checklist v0.3:
  - All per-batch focus rows resolved
  - m01 -race verified across all T4d batches including T2A NVMe race fix
  - Status transitions from "active gating" to "G5-baseline"

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 00:24:23 -07:00
pingqiuandClaude Opus 4.7 2ee12b2c14 T4d batch close artifact + mini-plan v0.5 (architect-accepted)
Two artifacts landing together to close T4 batch series:

1. v3-phase-15-t4d-closure-report.md (NEW)
   QA single-sign artifact for T4d batch close per §8C.2; architect
   T-end three-sign per §8C.1 (T4d IS final T4 batch — confirmed at
   round-48 review). Round-48 + round-49 corrections incorporated:
   - Part C commit hash bound to e642ae8 throughout
   - CARRY-T4D-LANE-CONTEXT-001 bind point = post-G5 hardening
     backlog (not T4e — consistent with "T-end at this close")
   - §H Finding #1 reworded — walstore HAS background flusher
     (walstore.go:189-190); QA's earlier "caller-driven" was wrong
   - §H Finding #3 RESOLVED at a0be6d5 (T2A NVMe race fixed +
     m01 -race ×50 PASS)
   - 16 invariants pinned (added 2 named for part C bug fixes:
     INV-REPL-FAILED-SESSION-KIND-DRIVES-ESCALATION +
     INV-REPL-REBUILD-ESCALATION-STICKY-UNTIL-TERMINAL)
   - 22/22 packages green under -race on m01 (post-a0be6d5)

2. v3-phase-15-t4d-mini-plan.md (NEW — was uncommitted across
   v0.1 → v0.5 evolution)
   Final v0.5 incorporates: architect Path B fold; round-47
   rebuild path engine-driven HARD GATE expansion; G5-DECISION-001
   named decision record; 4-batch shape ratified; T4d-3 G-1 binding.

Active forward-carries (post-G5 hardening backlog):
  - CARRY-T4D-LANE-CONTEXT-001 — replace TargetLSN==1 caller shim
    with true handler/session-context lane signal
  - G5-DECISION-001 — engine recovery state behavior across
    primary restart (Path A persist vs Path B rebuild-from-probe)

G5 collective close items (NOT post-G5):
  - m01 hardware first-light for replicated write path
  - Multi-replica concurrent live + recovery scenarios
  - walstore flusher cadence verification + tuning policy
  - Minimal metrics/backpressure assessment
  - G5-DECISION-001 architect resolution

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 00:21:20 -07:00
pingqiuandClaude Opus 4.7 80036404ce T4d planning + G-1 doc landing (architect Path B + Issue 2(a) ratification)
Lands four T4d planning artifacts together:

1. v3-phase-15-t4d-3-g1-v2-read.md (NEW)
   T4d-3 G-1 V2 read v0.2, QA-signed in conversation 2026-04-25.
   Per architect Issue 2(a) ratification: G-1 docs land first;
   implementation references the committed hash. Future T4d-3
   commits should reference this commit's sha via:
     Refs G-1 sign: <this-commit-sha>

2. v3-phase-15-t4d-forward-carry-checklist.md (NEW)
   v0.2 — 19 active T4a/T4b/T4c invariants with risk grades and
   per-batch focus rows. T4d-3 close gate inscribed
   (CARRY-T4D-LANE-CONTEXT-001 option A or B); pre/with-T4d-3
   doc fixes recorded.

3. v3-phase-15-t4d-qa-scenario-catalogue.md (NEW)
   v0.1 — 9 QA component-scope scenarios mirroring T4c QA
   Stage-1 discipline. 10 framework primitives surfaced for
   sw's batch PRs.

4. v2-v3-contract-bridge-catalogue.md (UPDATED)
   §3.3 inscriptions for T4d-locked invariants:
     - INV-REPL-NO-PER-LBA-DATA-REGRESSION (round-43)
     - INV-REPL-RECOVERY-STALE-ENTRY-SKIP-PER-LBA (round-43)
     - INV-REPL-RECOVERY-COVERAGE-ADVANCES-ON-SKIP (round-44)
     - INV-REPL-LIVE-LANE-STALE-FAILS-LOUD (round-44)
     - INV-REPL-RECOVERY-COVERAGE-RESTART-SAFE (Option C)
     - INV-REPL-LANE-DERIVED-FROM-HANDLER-CONTEXT (Q2 + round-46)
     - INV-REPL-TRANSPORT-STORAGE-CONTRACT-ONLY (Q1+Q3 + T4d-1
       strengthening)
     - INV-REPL-CATCHUP-FROMLSN-IS-REPLICA-FLUSHED-PLUS-1
       (T4d-3 G-1 §5)
     - INV-REPL-CATCHUP-FROMLSN-FROM-ENGINE-STATE-NOT-PROBE
       (T4d-3 G-1 §5)
     - CARRY-T4D-LANE-CONTEXT-001 (named carry, T4e/post-G5)
   INV-REPL-CATCHUP-WITHIN-RETENTION-001 status updated:
   T4c downgrade → T4d-2+T4d-3 un-pin path.

Process rule inscribed (architect 2026-04-25):
G-1 sign docs land in seaweedfs FIRST; sw implementation in
seaweed_block references the committed G-1 hash via
"Refs G-1 sign: <sha>" per mini-plan §7.1 procedural binding.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-25 22:26:21 -07:00
pingqiuandClaude Opus 4.7 7b9b353293 T4d kickoff: v0.3 architect-ratified
Architect sign by pingqiu 2026-04-25:
"T4d v0.2 scope accepted as one batch series; Option C for appliedLSN
source; BlockStore walHead hotfix may land pre-T4d; substrate defense-
in-depth included where practical; 4-batch order approved; T4d-3 G-1
required; T4d-2 no G-1; T-end three-sign at T4d close if T4d remains
final T4 batch."

All open architect-decision points (§2 scope, §2.5 Option/hotfix/
substrate, §3 batch shape, §4 acceptance bar) resolved. §6 open
issues all closed. §8 inscribes the verbatim ratification record.

Sw clearances effective immediately:
  - Land BlockStore walHead one-liner as pre-T4d hotfix (single PR with
    un-skipped regression test)
  - Produce T4d mini-plan (4-batch shape per §3)
  - Produce T4d-3 G-1 V2 read on wal_shipper.go runCatchUpTo
  - T4d-2 spec is round-43/44 architect text (no G-1 needed)

T-end horizon: §8C.1 T-end three-sign lands at T4d close IF T4d
remains final T4 batch (per architect's criterion #10 wording tweak).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-25 15:46:13 -07:00
pingqiuandClaude Opus 4.7 c910464a9a T4c batch close artifact: closure report (architect-accepted)
QA single-sign artifact for T4c batch close per §8C.2; architect
acceptance of §B scope deltas signed 2026-04-25 by pingqiu.

Scope deltas accepted:
  - T4c closes as mid-T4 batch under §8C.2, not T4 T-end
  - L2/L3 mini-plan bar narrowed to muscle-level L2 + component evidence
  - L3 m01 first-light deferred to T4d / G5 final close
  - Substring "WAL recycled" matching accepted as TEMPORARY, replacement
    bound to T4d (preferred) or G5 final sign (latest)
  - INV-REPL-CATCHUP-WITHIN-RETENTION-001 downgraded to T4d blocker
    (catch-up sender hardcodes ScanLBAs(1); replica's R+1 not threaded)

Doc-hygiene fixes per PM round-2 review (this commit):
  - Drop INV-REPL-CATCHUP-DONE-MARKER-EMITTED (non-existent: V2 marker
    collapsed into barrier-as-terminator per catchup_sender.go:48,187)
  - §B/#2 + #5 reword "green at HEAD" to acknowledge architect Windows
    cleanup-only repro failures (tracked as next-batch carry)
  - Active formal-INV count 8 -> 6

Forward-carries to T4d (BLOCKERS):
  - R+1 catch-up threading (StartCatchUp signature + adapter wire)
  - Full engine→adapter→executor recovery wiring
  - Structured RecoveryFailureKind replacing substring sentinel
  - LastSentMonotonic_AcrossRetries cross-call form scenario
  - Windows TempDir cleanup race investigation

Forward-carry to G5 final close:
  - m01 hardware first-light for replicated write path

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-25 11:49:24 -07:00
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
pingqiuandClaude Opus 4.7 de2767cd3c T4 L1 survey round 2: sw pre-scan output + H6 narrowing + H7 + §3.13
Fulfills §5 step 1 pre-scan gate with concrete V3 source evidence and
propagates findings to §3 observations.

## Pre-scan output (§5 step 1)

5-row checklist table against V3 source:
  - SetReplicaAddrs / ReplicaAddrs / replica fields: NONE in
    `core/frontend/` or `core/storage/` (grep-clean)
  - Sync/Write remote-ack semantics: NONE; all returns pure-local
    (`types.go:50-78`, `logical_storage.go:57-70`)
  - LogicalStorage.Write LSN: pure-local; distributed durability
    is explicit non-contract (`logical_storage.go:45`)
  - Ship/Replicate/Quorum/Barrier/Durability identifiers: none in
    code; comments only
  - Replication stubs: NONE; but three fully-implemented replica-
    side primitives on LogicalStorage: ApplyEntry / AdvanceFrontier
    / AllBlocks, with impls in walstore.go + smartwal/store.go

Net: frontend/durable layer clean; LogicalStorage layer already
committed to a specific replica-side shape. L2 must ALIGN with
that shape, not override it.

## §3 updates driven by pre-scan

§3.11 (H6) narrowed with V3 existing-shape evidence:
  - Option A unlikely (no supporting V3 shape; StorageBackend is
    replication-unaware)
  - Option B effectively ruled out (ApplyEntry/AdvanceFrontier sit
    BELOW Backend on LogicalStorage; a ReplicatedBackend wrapper
    would either reach past its wrapped contents or duplicate the
    storage-layer contract)
  - Option C leading (matches V3 existing Provider-owns-lifecycle
    shape; generalizes BUG-005 lesson)

§3.12 (H7) new — LSN surface-up gap:
  - `Backend.Write → (int, error)` discards LSN
  - `LogicalStorage.Write → (lsn, error)` returns it
  - Primary-side shipper needs per-write LSN
  - H7a (extend Backend sig) unlikely; H7b (Provider intercepts
    at LogicalStorage layer) natural fit with H6 Option C; H7c
    (side-channel NextLSN+Boundaries delta) rejected as racy
  - H7 resolution coupled to H6 — joint L2 LOCK

§3.13 new — replica-side bypasses Backend entirely:
  - Structural finding already locked by V3 shape, NOT an L2 choice
  - Primary-side traffic: session → handler → Backend → LogicalStorage
  - Replica-side traffic: network frame → ReplicaReceiver →
    LogicalStorage.ApplyEntry (bypasses Backend)
  - Explicit so L2 builds on it rather than fighting

## Feedback-round log + change log

§5 feedback log gains round 2 entry; §6 change log gains full
round-2 detail with line-level citations.

No sign event; this is iterative informal feedback per §8C.8
lightweight cadence. L1 stays DRAFT until bundled T4 T-start
three-sign with L2 + L3.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 23:21:35 -07:00
pingqiuandClaude Opus 4.7 b4adf76aa0 T4 L1 survey: drop invented L1-sign gate; keep only T-start three-sign
§8C.8 specifies exactly one three-sign per T-boundary — at T-start,
covering the bundled L1+L2+L3 package. I had proposed a separate
L1 three-sign in §5 that isn't in the rule. Architect correctly
pushed back.

§5 rewritten as lightweight cadence:
1. sw V3 pre-scan (~5 min, inline reply, prerequisite to L2 not a
   sign gate) — same grep checklist retained, same BUG-005 rationale
2. sw + QA iterate on L2 (catalogue §3 filled) informally
3. sw + QA draft L3 (T4 port plan sketch)
4. T4 T-start three-sign on bundled L1+L2+L3 (only governance event)

Informal feedback-round log hook added so architect/PM inputs are
tracked without per-round sign ceremony.

Change log updated.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 22:59:01 -07:00
pingqiuandClaude Opus 4.7 d2588f5b77 T4 L1 survey: architect feedback round 1 (F1/F2/F3 + H5/H6 + sw pre-scan gate)
All 5 feedback items accepted; no subsetting.

F1 — RebuildBitmap split into standalone §2.10 entity (10 total,
was 9). Rationale: bitmap has independent on-disk schema (~84 LOC
rebuild_bitmap.go) + independent conflict-resolution invariant
(WAL-wins-over-base). Collapsing into §2.6 RebuildSession at L1
would lose granularity for L2 — bitmap and session may have
different PRESERVE/REBUILD verdicts. §2.6 now explicitly
cross-references §2.10.

F2 — ShipperGroup §2.2 gains "External deps" row: N = RF comes
from master assignment via BlockVol.SetReplicaAddrs, not from
shipper-internal decision. Cross-entity contract (master assignment
↔ ShipperGroup size ↔ ReplicaReceiver expected-connection-count
↔ DistGroupCommit quorum arithmetic) made explicit so L2 split
can't silently drift sync_quorum.

F3 — ReplicaBarrier §2.4 scope rewritten from "per-request
ephemeral" to "per-request call-closure, BUT queue-state shared
per-volume via cond.Wait". Prior wording risked 1:1-porting into
a V3 stateless function, losing multi-watcher cond.Broadcast
semantics.

H5 added to §3 observations — cross-node epoch consistency
observation window for sync_quorum. V2 implicit via ack frame
carrying epoch; V3 L2 must pick "ack frame carries epoch" vs
"primary maintains per-replica epoch cache" before locking.
Different choices → different failover + rebuild-trigger semantics.

H6 added to §3 observations — write-path vs replication-path
concurrency residence. Three L2 options documented:
  A) StorageBackend.Write triggers shipper (violates T3a layering)
  B) ReplicatedBackend wraps StorageBackend+shipper (clean; +1 entity)
  C) Replication inside DurableProvider (extends BUG-005 lesson)
L1 makes no recommendation; L2 LOCKS the decision before L3.

§5 restructured into 5 gated steps; step 1 is a mandatory sw V3
pre-scan of core/frontend/durable/ + core/frontend/*.go for
pre-baked replication-adjacent assumptions. Rationale cited per
architect: BUG-005 latent drift came from implicit V3 convention;
L1 must surface any such convention before L2 verdicts lock.
Concrete grep checklist included so the scan is 5 min, not open-ended.

§2 header + §4 open question #1 updated for 10-entity count.
Scope block references rebuild_bitmap.go explicitly.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 22:41:18 -07:00
pingqiuandClaude Opus 4.7 38cb25702f T4 kick-off: L1 V2 replication entity survey (pre-sketch review)
First artifact for T4 (Gate G5 Replicated Write Path) under the §8C.8
top-down port discipline added post-T3 retrospective. This is L1 only
— raw V2 entity enumeration with scope / lifecycle / concurrency /
cross-session / authority / protocol / invariants attributes. No V3
bridge verdicts proposed yet; L2 follows only after L1 review closes.

9 entities identified across replication surface:
- WALShipper (per-replica fan-out)
- ShipperGroup (per-volume aggregator)
- ReplicaReceiver (per-volume replica-side listener)
- ReplicaBarrier FSM (per-barrier ephemeral)
- DistGroupCommit closure (per-write-op, mode-aware)
- RebuildSession (volatile, non-crash-durable)
- RebuildServer (per-primary listener)
- RebuildTransportServer / Client (per-session base lane)

9 L1-level observations flagged as L2 hazards: epoch fencing
pervasiveness, contiguous-LSN cross-cutting invariant, two-lane
rebuild bitmap integration, mode-dependent durability, volatility
of rebuild session (vs BUG-005 Provider cache lesson), explicit
reconnect protocol, three-phase barrier, ioMu.RLock nesting,
shipper-group double watermark.

5 open questions raised for sw / architect / PM review before L1
sign: scope completeness (sync_all_reconnect, split-brain arbiter?),
scope accuracy (ReplicaReceiver per-volume vs per-assignment),
RebuildSession volatility confirmation, DistGroupCommit V3 residence
opinion, protocol-frame wire-compat stance.

Status: DRAFT — open for sw review; L2 + L3 work blocked on L1 sign
per §8C.8 discipline.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 22:30:57 -07:00
pingqiuandClaude Opus 4.7 88dcd49d67 sw-block/design: T3 mini-plan + audit + sketch docs (pre-close docs)
Predecessor docs for the T3 batch, retained here for audit trail.
The closure report (`v3-phase-15-t3-closure-report.md`), contract
bridge catalogue, and BUG-005/006 artifacts already landed in
commits `4127e5136` + `6e196885e`; this commit fills the docs
those closure artifacts reference back to.

Landed:
  v3-phase-15-t3-port-plan-sketch.md    T3 umbrella sketch (rev-2.1, three-signed)
  v3-phase-15-t3-port-audit.md          T3.0 port audit + Addendum A (QA-signed)
  v3-phase-15-t3a-mini-plan.md          T3a scope + sign-off (CLOSED 0e1595c)
  v3-phase-15-t3b-mini-plan.md          T3b scope + sign-off (CLOSED 72d0d40)
  v3-phase-15-t3c-mini-plan.md          T3c scope + sign-off (CLOSED 829c6a9)

Total 1,346 lines of doc; no code impact.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 22:19:03 -07:00
pingqiuandClaude Opus 4.7 6e196885e4 T3 closure: reconcile §8C.3 trigger narrative + C5 pin strength
Two document-truthfulness mismatches flagged by architect review:

§B Governance transition (closure report): previously claimed "no
§8C.3 triggers fired during T3"; §H Phase 3's own BUG-005 description
matches trigger #1 (unknown-unknown architectural bug, V2/V3 shape-
level mismatch). Corrected to say trigger #1 fired once (BUG-005)
and was handled per §8C.3, with log entry, architect+PM notification,
catalogue §2.3 drift-event row, and porting-discipline citation.

C5-NVME-SESSION-STATE-CLEANUP-ON-CLOSE (contract bridge catalogue
§2.2.14): previously stated "PASSES today" / "pinned explicitly".
Closure §H Phase 4 correctly narrows landed tests to "smoke +
goroutine-leak guard" with Target.ctrls/AER/KATO-stored-ms
introspection not exercised. Catalogue row now matches that
strength: "pin strength today: smoke + goroutine-leak guard only;
full state-release introspection NOT exercised; queued as
follow-up".

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 22:14:08 -07:00
pingqiuandClaude Opus 4.7 4127e5136c T3 closure: finalize sign-ready state + BUG-006/007 + catalogue retrofill
Closure report (v3-phase-15-t3-closure-report.md):
- §E rewritten as FINAL A–F m01 verification table with per-impl
  status + G4 pass criterion = smartwal (production default) full
  A–F green; walstore non-default fallback with Matrix D failure
  tracked via BUG-007
- §E sign table: QA re-sign 2026-04-22 with evidence basis
  (seaweed_block@313dd52 + BUG-005 fix 42b045a); prior RETRACTED
  row superseded
- §D INV-DURABLE-001: conditional "Path B pending" wording
  removed; scoped to smartwal; canonical row name stands
- §B non-claims: stale _TBD_ perf wording replaced with
  first-light scope statement; new non-claim "G4 pass =
  smartwal only; walstore deferred via BUG-007" added
- §G.3 finalized: FINAL resolution with smartwal A–F PASS;
  walstore deferred
- §H Phase 2 narrative updated to match final matrix outcome
  (Matrix E smartwal-only; walstore E skipped pending BUG-007)
- §H Phase 4: T3-DEF-6 test wording downgraded from
  "pins cleanup contract" to "smoke + goroutine-leak guard"
  per PM feedback (no test-only introspection of Target.ctrls/
  AER/KATO internals; follow-up deferred)
- §H Phase 5: BUG-007 filed and scoped; non-blocking basis
  spelled out

Contract Bridge Catalogue (v2-v3-contract-bridge-catalogue.md):
- §2.2.14 C1-NVME-SESSION-KATO reclassified PRESERVE-partial
  → VIOLATED with BUG-006 anchor + m01 Matrix D evidence
- §2.2.14 C5-NVME-SESSION-STATE-CLEANUP-ON-CLOSE added
  (T3-DEF-6 retrofit, pinned by QA L1 addendum)
- §2.3 drift-event audit table expanded with BUG-006, BUG-007,
  T3-DEF-5, T3-DEF-6

BUG-006 (006_nvme_kato_timer_not_enforced.md):
- Unified contract ID to catalogue name
  C1-NVME-SESSION-KATO-STORED-NOT-ENFORCED (was drifting as
  C3-NVME-KATO-ENFORCEMENT, PM Low catch)
- §7 reframed as "existing row reclassified VIOLATED"
  rather than "add new row"

BUG-007 (007_walstore_umount_remount_data_loss.md): filed as
pre-existing walstore-specific durability bug surfaced by
Matrix D re-verify; explicitly non-blocking for T3 since
smartwal is production default.

BUG-005 (005_backend_close_cross_session.md): committed for
HEAD-reproducibility (referenced by closure §H Phase 3).

Inventory (bugs/inventory/nvme-test-coverage-deferred.md):
T3-DEF-5/6/7 struck through with per-row resolution pointers;
zero open T3-scope inventory rows remaining.

Evidence artifacts committed in seaweed_block@313dd52
(scripts/iterate-m01-nvme.sh Matrix F robustness +
t3_qa_session_cleanup_addendum_test.go).

Awaiting architect + PM three-sign.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 22:08:30 -07:00
pingqiuandClaude Opus 4.7 953fdb7564 doc: P14 S8 final bounded close — evidence matrix + P15 handoff
Adds the six S8 closure deliverables consolidating S4-S7 evidence,
classifying V2 scenarios, and mapping residual product gaps onto
canonical P15 tracks (per v3-phase-15-product-plan.md §4).

New docs:
- v3-phase-14-s8-assignment.md — S8 execution contract.
- v3-phase-14-s8-final-bounded-close.md — bounded P14 target,
  accepted topology, reject conditions.
- v3-phase-14-s8-evidence-matrix.md — 16 claims × {L0, L1, L2, L3,
  Status, Residual}. 15 PROVEN, 1 PARTIAL (Claim 15 fence
  quantitative bound, P14 internal follow-up). Rounds 2-3 architect
  corrections: Claim 10 / 12 L2 narrowed; Claim 6 refresh gap closed
  by the new L1 test (see companion commit in seaweed_block).
- v3-phase-14-s8-v2-scenario-classification.md — every V2 scenario
  mapped to RUNNABLE-P14 / BLOCKED-FRONTEND / BLOCKED-OPS /
  BLOCKED-HA / BLOCKED-PERF / PORT-MECHANISM; scenario YAMLs kept
  as L3 shape, not executed evidence.
- v3-phase-14-s8-p15-handoff.md — 11 rows (10 canonical P15 tracks
  + 1 P14 internal follow-up anchored to Claim 15 PARTIAL); §4
  integrity check split by row class.
- v3-phase-14-s8-closure.md — final P14 closure statement matching
  the close doc §10 wording; explicit non-goals; all 9 P15 tracks
  named with canonical numbering.

No claim of CSI / frontend / migration / security / performance /
production readiness. Every product gap is handed off with a
concrete first-proof gate.

Companion: seaweed_block commit adds the IntentRefreshEndpoint L1
route test that closes Claim 6.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-20 01:44:11 -07:00
pingqiuandClaude Opus 4.6 247d9f6fa6 doc: V3 observability — structured logging, tracing, metrics, debug zip, alerts
Covers 6 areas based on CockroachDB/Ceph/etcd/Longhorn research:

1. Structured logging: zap + JSON + channel model (OPS/STORAGE/REPL/ISCSI/AUDIT/HEALTH)
2. Distributed tracing: OpenTelemetry spans across write/rebuild/failover paths
3. Metrics: 40+ must-have Prometheus metrics with histogram latency buckets
4. Debug tools: debug zip (logs+pprof+state), log merge, live tail
5. Audit logging: every admin mutation with actor/target/operation/result
6. Alert design: 3 tiers (page/ticket/log), anti-patterns to avoid

Identifies existing gaps: no I/O latency histogram, no rebuild duration
metric, no audit trail, no structured logging, no distributed tracing.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-13 02:32:30 -07:00
pingqiuandClaude Opus 4.6 9437bd0b95 doc: V3 development process — branch strategy, CI/CD, review, release
Covers full engineering process based on SeaweedFS upstream audit:
- Branch strategy: feature/sw-block with checkpoint branches for perf baselines
- Commit conventions: type: description format
- Code review checklist with anti-pattern checks
- Testing standards: 5 levels, 1600+ tests, 4 hardware acceptance scenarios
- CI/CD pipeline: unit→component→hardware gates
- Release process: checklist, artifacts, versioning
- Issue/PR templates with anti-pattern classification
- Agent collaboration model (architect/sw/tester/manager roles)
- Code quality: golangci-lint config, race detection
- Upstream contribution path for SeaweedFS merger

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-13 01:58:19 -07:00
pingqiuandClaude Opus 4.6 f11a5829d7 doc: update operations design — add existing V1 UI foundation, code map
Added section 8: existing UI/admin infrastructure from V1:
- iSCSI admin HTTP server (admin.go: /status, /assign, /rebuild, /snapshot)
- Grafana dashboard JSON (block-overview.json, already built)
- Master UI HTML (master.html, add Block Volumes tab)
- Volume server UI HTML (volume.html, add Block section)
- Prometheus metrics (already integrated)

Added section 10: existing vs new code map showing most backend
exists — work is wiring to user-facing interfaces.

Updated Phase 1 to include Master UI tab (+200 lines HTML/JS).
Updated Phase 5 with two options (lightweight extend vs full SPA).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-13 01:44:47 -07:00
pingqiuandClaude Opus 4.6 3ba622d9e0 doc: V3 operations design — user-friendly setup, shell commands, REST API
Covers three personas (developer/operator/platform engineer) with:
- One-command setup: weed server -block (10 seconds to first volume)
- Shell commands: block.list, block.status, block.health, block.create, etc.
- REST API: /block/volumes CRUD, /block/health
- Observability: Prometheus metrics, alerting rules, Grafana dashboard
- Actionable error messages (every error tells you what to do next)
- Dry-run by default for all destructive operations

Competitive comparison: 10s setup vs Ceph 30min, 13.5x write IOPS,
single binary for object + block storage.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-13 00:36:32 -07:00