mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-07-30 20:13:23 +00:00
5cf429595f73699111a3a860f7f901145381fe1c
13290
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
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.
|
||
|
|
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. |
||
|
|
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. |
||
|
|
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.
|
||
|
|
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. |
||
|
|
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. |
||
|
|
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. |
||
|
|
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. |
||
|
|
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).
|
||
|
|
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. |
||
|
|
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. |
||
|
|
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. |
||
|
|
087343dd14 | v3-batch-process §14: clarify architect/sw/QA are AI agents; user routes between them | ||
|
|
34dfbb66ef | v3-batch-process §15: per-agent action list at end of every response (cut user's routing load) | ||
|
|
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>
|
||
|
|
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>
|
||
|
|
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>
|
||
|
|
0667f8edbf | v3-dev-roadmap: link v3-block-behavior-contract-index as first-order architect ref | ||
|
|
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>
|
||
|
|
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>
|
||
|
|
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). |
||
|
|
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>
|
||
|
|
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> |
||
|
|
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. |
||
|
|
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. |
||
|
|
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> |
||
|
|
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>
|
||
|
|
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>
|
||
|
|
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. |
||
|
|
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>
|
||
|
|
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> |
||
|
|
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>
|
||
|
|
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>
|
||
|
|
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>
|
||
|
|
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>
|
||
|
|
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>
|
||
|
|
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>
|
||
|
|
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> |
||
|
|
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>
|
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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>
|
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |