Agent Brigade 9-step pattern — live receipts

This doc maps each step of the 9-step kitchen-brigade teaching diagram to concrete on-disk evidence that it ran live, not just as designed. Grounding run: the Lenovo prospect assessment executed 2026-07-02 (first-ever full live run of the Assessment Agent Brigade), plus the same-day Lenovo collateral stress run. All paths are relative to ~/Projects/phdata-private/cellar/ unless noted. Verdict per step is one of LIVE (ran and is evidenced), PARTIAL (some real evidence, some gap), or ⚠️ DESIGN-ONLY (described in spec/teaching diagram, not evidenced running). Nothing below is manufactured — where I could not find a claimed artifact, it says NOT FOUND.

Step 1 — Requester brings a need to the STEWARD

Claim: a front-of-house intake conversation between a requester and a steward role produces the need.

Status: PARTIAL. The founder was the requester; there is no distinct front-of-house "steward conversation" artifact — the need entered as free text in the ticket's Order field, not through a structured intake surface.

RECEIPTS:

• tickets/lenovo-assessment-2026-07-02.ticket.md frontmatter: requested_by: founder.
• Work-log 13:25:58 ET: "intake parsed from the Order text as a free-text-brief fallback (intake_parser.md's documented path) — NO canonical CAF intake form exists (prospect, no seller/AE submission). Structured-intake gap explicitly flagged: true."
• The ticket's Order section is the founder's ask, typed once, in prose — no separate "steward interview" artifact upstream of it.

Gap: the steward's front-of-house role (structured need-gathering distinct from the founder directly authoring the ticket order) isn't built. What exists is a documented fallback path, used honestly and flagged as a gap in its own work-log line.

Step 2 — Steward gathers context from the CELLAR and pairs the need to a brigade MENU

Status: LIVE.

RECEIPTS:

• Ticket frontmatter: menu: assessment-agent-brigade/assessment — direct menu pairing.
• Three real cellar sources pulled and recorded as context: entries: companies/lenovo/identity.md, companies/lenovo/jobs/2026-07-02-snapshot.md, companies/lenovo/github/2026-07-02-presence.md.
• Work-log 13:25:58 ET: "cellar-first gather pass ... The 3 scouted cellar artifacts ... recorded as sources[] with status=complete. All 9 named network_routines.md routines ... recorded status=skipped ... NO network calls made this run."
• Full synthesized dossier at assessments/lenovo/context/2026-07-02-dossier-full.md (read in full) — cites every claim back to the 3 cellar sources or flags it as inference; includes an explicit "Open conflicts & ambiguities" section and a per-routine coverage table.
• brigades/assessment-agent-brigade/menu.md — the menu document the pairing resolved against.

Step 3 — Steward writes a TICKET and hangs it on the RAIL

Status: LIVE.

RECEIPTS:

• Master ticket tickets/lenovo-assessment-2026-07-02.ticket.md — full frontmatter (ticket, artifact: assessment, subject: assessments/lenovo, autonomy_mode: hybrid, context: pointers, current_phase) is the ticket-as-scope-pointer object the pattern describes.
• Work-log 13:24:23 ET: "steward: enqueued — Gate A Gate A: 8/8 pass" — lint-checked before hitting the rail.
• 18 micro-tickets under assessments/lenovo/tickets/ as child tickets of the master (parent_ticket: lenovo-assessment-2026-07-02-assessment in each), 9 work items × 2 phases (P3, P4), confirmed by directory listing. Each carries its own scoped context: slice and its own Gate A pass.
• A second, independent rail ticket for the collateral stress run: rail/lenovo-collateral-stress-2026-07-02.ticket.md.

Step 4 — EXPO pulls the ticket (lease), runs Gate A + phase-0 sufficiency judgment

Status: LIVE, with one important honest caveat: the phase-0 sufficiency judgment ran, but the rail's pull/lease mechanics were broken as shipped and had to be worked around live, on the record.

RECEIPTS:

• Lease: work-log 13:24:34 ET: "rail: lease — worker=pass-runner-lenovo, ttl_min=60".
• Gate A re-checked at every pull, e.g. 13:25:58 ET: "expo: Gate A re-check at pull — Gate A: 8/8 pass" — recurs at every phase transition (c1-c4 and each micro-ticket).
• Phase-0 sufficiency judgment, 13:27:41 ET: "minimum-context bar MET (3 cellar sources status=complete; inbox/ ingest ran but 0 local files) ... Proceeding." This is the Clear/Ambiguous/Thin call — landed dossier records "Confidence posture: thin" explicitly, not silently upgraded to Clear.
• Honest defect, not glossed over: 13:28:01 ET, MACHINERY DEFECT #1 (confirmed empirically): "rail_walk.RailClient._next_workable() only ever selects tickets with status=='queued' or status=='leased'+lease-expired; it has no branch for status=='in-build' ... the documented Step-0→C1→C2→C3→C4 walk cannot happen via pull()/walk() as shipped." Worked around live via rail.release(). A second related defect (MACHINERY DEFECT #2, 13:44:15 ET) hit the C1-approved→C2 transition and was worked around the same way, public APIs only, no source edit.

Step 5 — STATIONS execute, marking up the ticket as they go

Status: LIVE. The generic "stations" concept in this brigade is realized as the phase dispatch chain (step0 → C1 → C2 → C3 → C4), each a distinct station, plus a nested instance of the same fan-out pattern for the P3/P4 per-work-item lens rosters (18 micro-tickets acting as child station runs).

RECEIPTS:

• Dispatch lines for every phase: 13:25:58 ET "...station 'assessment:step0'"; 13:29:35 ET "...'assessment:c1'"; 13:44:58 ET "...'assessment:c2'"; 14:05:36 ET "...'assessment:c3'"; 14:52:19 ET "...'assessment:c4'".
• Self-review checklists per station, all logged with pass counts: C1 7/7, C2 6/6, C3 7/7, C4 5/5 (deterministic gates.lint_cN), distinct from gatekeeper/meta-council judgment.
• Inner-rail fan-out, 14:07:22 ET: "9 work items x 10 per-UC lenses (90 lens-executions) ... combined subagent token spend ~1.1M tokens never touched this PASS's own context window" — genuine subagent isolation, not simulated.
• Each micro-ticket's own work log confirms independent leasing/dispatch/landing, e.g. ...sop-field-service-dispatch-triage-p3.ticket.md: "rail: lease" → "fragment landed" → "ack(advance) -> done".
• Contract artifacts landed at each phase — contract-1 (18.6KB), contract-2 (77.9KB), contract-3 (496KB), contract-4 (342KB) — sizes confirm real content accumulation, not stubs.

Step 6 — CRITIC evaluates and ADVISES (verdict, not a route)

Status: LIVE, with a terminology note: this brigade does not have a station literally named "critic." The advisory-verdict role is split across two mechanisms — the gatekeeper (per-gate, scoped-input judgment, every phase) and the meta-council (C4-only, cross-phase, three independent judges: portfolio_strategist, prioritization_integrity, expectation_steward). Both produce verdicts that inform the exit decision; neither directly routes the ticket.

RECEIPTS:

• brigades/assessment-agent-brigade/2026-07-02-spec.md (~line 372): "Gatekeeper judgment layer (every gate) ... you do NOT re-read the full contracts to gate a decision ... Never approves on the benefit of the doubt when evidence is borderline."
• Gate log embedded in the corrected Build Manifest (build-manifest/2026-07-02T161235-manifest.json, field gate_log), 5 entries, one per phase, each with contract, verdict, approver, notes — e.g. C2: verdict: advance, approver: gatekeeper; C4: verdict: ratify, approver: gatekeeper + meta-council (m-1/m-2/m-3).
• Meta-council advisory (not routing) verdicts, C4 only: 14:36:36 ET m-1 (portfolio_strategist, chair) ratify w/ real finding fixed in place; 14:40:21 ET m-2 (prioritization_integrity, adversarial) ratify w/ RICE-vs-MoSCoW reconciliation finding fixed; 14:40:21-14:52:19 ET m-3 (expectation_steward) VETO, then VETO AGAIN, then RATIFY — full sequence in Bonus receipts below; this is the clearest evidence the advisory verdict is real judgment, not theater.

Step 7 — EXPO DECIDES the exit (advance / refire-to-author / reroute-to-spec / reroute-to-steward / kill)

Status: LIVE. The exit decision is a distinct, logged act separate from the critic's verdict.

RECEIPTS:

• compute_exit() semantics documented in spec (~line 464): advance / refire-to-author / escalate / kill, gated on deterministic lint + gatekeeper + (C4 only) meta-council.
• Exit=escalate exercised at the human-mandatory C1 gate: 13:29:35 ET "station assessment:c1: escalate — C1: 7/7 pass; gatekeeper=approve" → "rail: ack(escalate) -> escalated" → "expo: STOP at the C1 human-mandatory gate ... This PASS run ends here."
• Exit=advance exercised repeatedly: C2, C3, C4 all advance on clean gatekeeper approval (13:44:58, 14:05:36, 14:52:19 ET).
• Exit=refire-to-author exercised at C4: 14:40:21 ET, m-3 veto response: "gates.compute_exit's own designed C4 veto path is refire-to-author ... applied that path literally." Two refire rounds consumed against a documented REFIRE_ROUND_BUDGET=2; a third veto would have escalated instead (stated explicitly, not implied).
• The collateral run separately exercised refire-to-author on the objection-sheet kind: round 1 = refire-to-author (claim-level issue), round 2 = advance (rail/lenovo-collateral-stress- 2026-07-02.ticket.md, 19:05:25 ET block).
• reroute-to-spec / reroute-to-steward / kill: NOT FOUND in either run's evidence — real values in compute_exit()'s design, not triggered live on 2026-07-02.

Step 8 — Approved artifacts land in the CELLAR; ticket is closed and filed to its subject

Status: LIVE.

RECEIPTS:

• Master ticket frontmatter: status: done. Work-log 14:52:19 ET: "rail: ack(advance) -> done, filing to assessments/lenovo/tickets/".
• All landed artifacts listed in the ticket's own ## Artifacts section, each a real cellar path (dossier, contract-1 through contract-4, build manifest) — all confirmed present on disk.
• All 18 micro-tickets independently closed and filed: e.g. "micro-ticket ... sop-field-service-dispatch-triage-p3 closed (done) — fragment merged into work_item_readiness_matrix" (repeated per work item, 14:05:36 and 14:52:19 ET blocks).
• Provenance sidecars confirm append-only cellar filing discipline: every artifact has a .meta.json recording landed, produced_by, supersedes.
• Frontend consumer-side check — the loop actually closes. Work-log 14:54:18 ET: "FRONTEND CONSUMER-SIDE CHECK (the loop-closing handoff test) — ran python3 scripts/caf_ingest_assessment.py --from-cellar assessments/lenovo from the frontend repo. Result: EXIT 0, empty stderr, discovered the single non-superseded head manifest ... re-validated (schema + X1-X7) clean ... use_cases=9/9 mapped..." This is a written record of exit code 0, found in the master ticket's own work log — I did not find a separate raw stdout/stderr log file for this invocation, so the exit-0 claim rests on this self-reported work-log line, not an independently-captured shell transcript.

Step 9 — Close-out: completion flows back to the steward/requester

Status: ⚠️ DESIGN-ONLY / NOT FOUND.

RECEIPTS: none found. I searched the master ticket, the brigade spec, and the cellar tree for any notification, message-send, or "close-out" record and found nothing — no iMessage/Discord send log, no "notify requester" work-log line, no founder-facing summary artifact distinct from the ticket itself.

What actually happened instead: the founder learned the run completed by being the one running it / reviewing the ticket and contracts directly (and, per your own briefing, has flagged this gap himself). The C1 human-gate approval (Step 7) required the founder's own real-time judgment mid-run, which is a synchronous human touch, not the close-out notification the diagram depicts at the end of the flow. There is no evidence of a step that pings the requester when a ticket lands done.

Gap: an end-of-run notification/close-out channel (e.g., an iMessage/Discord ping when a ticket reaches done or escalated) is not built. This matches your own flag that step 9 is missing/unbuilt.

Summary table

Gaps (known follow-ups):

• Close-out/notification loop (Step 9) — unbuilt, founder-flagged.
• Structured steward front-end intake (Step 1) — currently a free-text Order fallback; no canonical CAF intake form exists for prospect (non-client) assessments.
• Rail pull/lease mechanics for multi-phase tickets (Step 4) — two machinery defects found and worked around live (public-API-only workarounds, no source edits); an upstream code fix is recommended in the ticket's own findings but not yet applied to phdata-ai-wf-plugins.
• reroute-to-spec / reroute-to-steward / kill exits (Step 7) — designed, not yet observed live.

Bonus receipts — governance moments worth showing the org

1. Meta-council double veto (real governance firing, not theater). m-3 (expectation_steward) vetoed the first C4 catalog build twice before ratifying. Veto 1 (14:40:21 ET): dollar ranges rendered with no ROM/floor caveat; Cortex platform presented as settled fact against 0.3 confidence; a hard 400-char truncation asymmetrically stripped uncertainty language from the 6 should_have items only. Fix applied, fresh independent re-verification dispatched (not self-graded). Veto 2 (14:46:49 ET), "narrower, and the process is working as designed": caught a sibling truncation bug in the layman field (140-char cap, deleting the single most important honesty caveat on the warehouse-logistics item) and missing ROM caveats on impl/timeline fields. Final independent re-verification (14:52:19 ET): verdict=ratify, confirmed programmatically (zero schema violations, zero propagation errors catalog↔contract-4). Refire budget was exactly 2, consumed exactly twice — a third veto would have escalated per the ticket's own stated semantics.

2. C1 human-gate approval with delegation provenance. Work-log 13:31:55 ET: "C1 HUMAN GATE — APPROVED by Ray, founder-delegated proxy (delegation: iMessage 2026-07-02 13:00 ET, 'You be the human in the loop judge for me').” The Build Manifest's gate_log records the same: approver: "Ray (founder-delegated proxy)", with binding approval conditions (both mixed-decomposition branches stay open) carried forward as a constraint on P2. This is the one gate in the whole brigade that's human-mandatory in every autonomy mode — the delegation trail from founder → Ray is on the record, not asserted after the fact.

3. Units-bug supersedes chain (schema-valid but wrong → caught by visual check → superseding artifact). 2026-07-02-units-correction-work-note.md: the original manifest (build-manifest/2026-07-02T145219-manifest.json) passed every deterministic gate, X1-X7 cross-check, and the meta-council — and still carried a uniform 1000x unit error ($K rendered as $M), caught only by eyeballing the rendered marketplace ("$40.0M–$130.0M/yr" for a real $40K–$130K/yr figure). Root cause stated plainly: "no existing gate asserts anything about units." Fix: new gate rule X8 (check_x8_units_consistency) so this class "cannot land silently again." The corrected manifest (...T161235-manifest.json) supersedes the original — confirmed via both .meta.json sidecars — and the original is left in place, untouched, per the append-only cellar convention.

4. Collateral run's honesty-gate outcomes (Expectation-Steward and a claim-level refire). Three T2-tier artifacts (outcome-thesis, exec-one-pager, roi-value-snapshot) carry release_note: Expectation-Steward ratified (axis 1/3/5 + A-27/28 residual) and are landed as gated drafts pending founder release (release_status: pending-human-release), not auto-published — confirmed in each file's own frontmatter. I did not find an Expectation-Steward veto on this run specifically (the three T2 kinds ratified on the first pass); what I did find is a separate claim-level veto/refire on the objection-sheet kind (round 1 = refire-to-author, veto_reason_class=claim; round 2 = advance, auto-published as T3) — a real refire cycle, just not the Expectation-Steward axis. Flagging this distinction so it isn't overstated to the org.

Compiled from cellar evidence under assessments/lenovo/ and rail/ as of 2026-07-03. Draft for founder review before any wider circulation.