mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-09-20 13:30:46 +02:00
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>
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-blockproduct structure clean enough to split into a separate repo later if needed
Suggested layout:
design/: shared V2 design docsprototype/: 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 insideseaweedfs - likely future state:
sw-blockbecomes a standalone sibling repo/product - design and prototype structure should therefore stay product-oriented and not depend on SeaweedFS-specific paths