v2 gates: the approved design needs gate content the system does not record anywhere

[pseudoseed]

Scoping finding for the gates unit of #37, before a spec gets written against data that does not exist.

What the design needs

codev/research/v2-mockups/02-gate.png (extracted as 02-gate.html, matched to its UX Pilot source at 0.863 token overlap) shows, per gate:

• the question, pulled out and quoted: "Delete the legacy refunds_legacy table, or keep it for audit purposes?"
• WHAT HAPPENS NEXT — one card per choice, describing what the builder will actually do: "migrates audit_log.refund_ref to refunds_v2, drops refunds_legacy, runs full checkout test suite, opens PR"
• the last terminal output that led to the question, with its warnings
• held-for duration, machine, workspace, spawning architect, worktree, branch, commits this run

That second item is the design's whole point: it tells you what each choice will cause before you make it. A gate queue without it is a list of names.

What the system actually records

blockedGate is derived by detectBlockedGate (overview.ts:367-374) and is just the gate name — spec, plan, pr, verify-approval.

A real status.yaml:

gates:
 pr:
 status: pending
 requested_at: '2026-08-12T09:11:25.150Z'

Name, status, timestamps. No question. No choices. No consequences. None of it exists in structured form anywhere — it lives only as prose in the builder's terminal and in the afx send message it writes to its architect.

Why this is filed rather than specified around

Spec 83 recorded FR-3 as unsatisfiable after measuring the wire, and the measurement was right even though my conclusion was wrong. The same discipline applies here and the answer is not in doubt: the gate view cannot be built against the current contract. Writing a client spec first would produce a screen that renders four gate names.

The shape that worked for the tree was server contract first (spec 52), then client (spec 83). Gates should follow it.

Options for the server half

A. Structured gate requests in porch. A builder requesting a gate records question, options with consequences, and a terminal excerpt. Complete, and it is a porch protocol change — every protocol's gate-request step has to emit it.

B. Reuse the message the builder already sends. Every gate today produces an afx send architect message containing exactly this content in prose, and the mailbox is already persisted in global.db. Far lighter; gives prose rather than structured choices, so WHAT HAPPENS NEXT stays two blocks of text instead of two labelled options.

C. Terminal scrape. Rejected. Fragile, and the consequences cards cannot come from anywhere.

B is worth costing seriously before committing to A — it may deliver most of the design for a fraction of the change, and A can follow if the prose proves too loose.

Not blocked on

The queue half of the design — builder, workspace, held-for, longest-wait marker, RULING ON #1 OF 3 — is buildable today from blockedGate plus blockedSince, neither of which is on the v2 wire yet but both of which exist server-side. That is a smaller first step than the full gate view.

[pseudoseed]

Architect ruling: option A (porch records structured gate requests)

Two paths were on the table:

A. Extend porch so a gate request carries structured content — question, choices, consequences — alongside the gate name.

B. Reuse the afx send architect gate message. Every gate today already produces one containing this content in prose, and the mailbox is persisted in global.db, so no porch change is needed.

Decision: A.

B is cheaper and I recommended it first. It does not survive contact with the design. The
approved gate card renders fields — a question, a choice set, a consequence per choice. The
mailbox holds prose. Turning prose back into fields means parsing free text an agent wrote,
which fails the first time a builder phrases a gate differently. The card would render a name
and a paragraph.

That is the same failure mode as #112: something that passes every test while missing the
thing the design was for. Not repeating it here.

Scope this implies

• status.yaml grows a structured gate-request block. It is written by porch only — the
  hand-edit prohibition is unchanged.
• The v2 node payload carries it through to blockedGate, which today is a bare name.
• The skeleton's protocol definitions gain the vocabulary, so adopters get it too.
• The afx send gate message stays as-is. It is the human notification; it is not the record.

This needs a spec before code — it changes a persisted format and ships to adopters. Spec
first, then a builder.