Commit Graph
5 Commits
Author SHA1 Message Date
pingqiu 4a876a9cd2 G6 §close + 5 INVs inscribed in ledger + roadmap closure
m01 single-run GREEN at 71 s on seaweed_block@96c51b4 — both §2 #4
(retention-OK catch-up) AND §2 #5 (sustained-write recycle →
rebuild dispatch + 5000-LBA byte-equal) in one closed-loop run per
architect §2 #6 binding.

Logs: V:\share\g5-test\logs\g6-20260428T100217Z.log
Scenarios: V:\share\g5-test\scenarios-g6.sh + scenarios\g6-d.sh

Mini-plan §close:
- §close.summary: 8-row table of bindings + commits + hardware
  + regression status, all GREEN.
- §close.evidence: software-pin (3 commits, 10 tests / 14 cases
  PASS); hardware-pin (5 acceptance rows, all GREEN; single 71 s run).
- §close.deltas: 2 entries documenting (a) physical-recycle NOT
  required for §2 #5 (engine recovery decision branch is
  load-bearing) and (b) harness discipline finding from QA.
- §close.findings: 2 findings — (1) data-vs-state convergence
  harness discipline → new INV; (2) §1.H audit verdict was
  correct + resolved in-batch.
- §close.forward-carries: G5-2/G5-6 (durability mode), G5-3
  (peer-state surface), future replica-aware retention (β/γ),
  G7 (rebuild path semantics).

5 INVs inscribed in v3-invariant-ledger.md:
- INV-G6-WALRECYCLE-DISPATCHES-REBUILD
- INV-G6-CATCHUP-CONVERGES-WITHIN-RETENTION
- INV-G6-RETENTION-POLICY-OPERATOR-VISIBLE
- INV-G6-ENGINE-NO-REBUILD-PINNED-ON-OTHER-FAILURES
- INV-G6-HARNESS-DATA-AND-STATE-CONVERGENCE (NEW from §close.findings #1)

INV-G6-RETENTION-POLICY-REPLICA-AWARE NOT inscribed — reserved for
future β/γ replica-aware retention batch (architect §1.A α
ratification 2026-04-29).

Roadmap §3 G6 line: ⏳ next → ✅ closed 2026-04-28 (retention-aware
recovery; α config knob + escalation pin).
Roadmap §7: G6 row added to recently-closed table.
Roadmap §8 backlog: G6-T-WALRECYCLE-ESCALATE → "Closed backlog
tickets" section with verdict (a) + resolution narrative.

Awaiting architect single-sign on this §close.
2026-04-28 11:03:26 -07:00
pingqiu 1207fc5444 Roadmap §8: queue G6-T-WALRECYCLE-ESCALATE backlog ticket from G5-5C QA scenario D
Per architect ruling 2026-04-28 + sw §close.appendix: D's WALRecycled
boundary finding is G6 territory, not a G5-5C reopener. Adding the
backlog ticket here so it doesn't get lost between G5-5C close and
G6 kickoff.

Ticket text + evidence pointer + cross-references all preserved
from the §close.appendix; this is the dev-roadmap-side mirror so
the ticket surfaces when planning G6 scope.

Standing by for architect final §close single-sign on G5-5C.
2026-04-28 00:40:40 -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 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