Files
seaweedfs/sw-block
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
..

sw-block

Private WAL V2 and standalone block-service workspace.

Purpose:

  • keep WAL V2 design/prototype work isolated from WAL V1 production code in weed/storage/blockvol
  • allow private design notes and experiments to evolve without polluting V1 delivery paths
  • keep the future standalone sw-block product structure clean enough to split into a separate repo later if needed

Suggested layout:

  • design/: shared V2 design docs
  • prototype/: code prototypes and experiments
  • .private/: private notes, phase development, roadmap, and non-public working material

Repository direction:

  • current state: sw-block/ is an isolated workspace inside seaweedfs
  • likely future state: sw-block becomes a standalone sibling repo/product
  • design and prototype structure should therefore stay product-oriented and not depend on SeaweedFS-specific paths