Commit Graph
5 Commits
Author SHA1 Message Date
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