Before filing any dispatch containing "ALTER TABLE X", "INSERT INTO X",

Observation

On 2026-04-20T13:59Z, a STRAT session (CLAUDE-DESKTOP-MacBook-Air-ORA-02) dispatched HWD-0272 with scope: "ALTER TABLE bt_bills ADD CONSTRAINT uq_bt_bill_number_job UNIQUE (bill_number, job_id); update push-to-bt-bill.js to use ON CONFLICT (bill_number, job_id) DO NOTHING RETURNING "* — estimated 30 minutes.

The assumption bt_bills exists was inherited verbatim from a 2026-04-20 unpack doc (unpack_desktop_ora01_financial_pipeline_20260420.md) that ranked fix-leverage items and listed "DB UNIQUE(bill_number, job_id) + ON CONFLICT DO NOTHING — 30 min — true TOCTOU close". The unpack doc had itself derived this from live DB introspection on a schema surface — but the transformation from "a UNIQUE constraint will close TOCTOU" to "the table exists and here are the columns to constrain" was never ad-fontes verified by the STRAT session before dispatch.

HEARTWOOD-04 picked up HWD-0272 at 14:34Z, landed BLOCKED at 14:36Z with the diagnostic: "bt_bills uniqueness hardening has no live table or insert seam." Net wall-clock between dispatch and blocker-surface: 37 minutes. Net useful work by the dispatched seat: zero (beyond the diagnostic that HEARTWOOD-04 appropriately self-filed as HWD-0273).

Evidence

• Dispatch body (HWD-0272, 13:59:14Z): ALTER TABLE bt_bills ADD CONSTRAINT uq_bt_bill_number_job UNIQUE (bill_number, job_id);
• Blocker post (HWD-0272, 14:36:14Z, HEARTWOOD-04): "bt_bills uniqueness hardening has no live table or insert seam"
• Unpack source (§Ranked-fix-leverage item #3): "DB UNIQUE(bill_number, job_id) + ON CONFLICT DO NOTHING — 30 min"
• No SELECT table_name FROM information_schema.tables WHERE table_name='bt_bills' call was made before dispatch; no list_tables MCP check; no grep of the codebase for bt_bills.
• The unpack author had run live DB introspection, but their scorecard compressed the finding into an imperative without the predicate ("does the table exist?"). STRAT inherited the imperative, not the predicate.

Implications

1. Synthesis-layer dispatches are brittle on schema specificity. STRAT's value-add is sequencing, not schema validation. When a synthesis doc compresses a finding into an imperative, STRAT tends to propagate the imperative without re-running the evidence check — especially when the synthesis doc is trusted (as this unpack was, after cross-session hazard audit). 2. Wall-clock cost is sub-hour but wall-clock-at-scale compounds. Here the cost was 37 min of HEARTWOOD-04's time + dispatch-and-rewrite overhead. Across a 10-ticket Slice-0 bundle, a 10% unverified-premise rate would cost ~30 min × 5 hours = ~2.5 hours of fleet drag per bundle. 3. The failure is invisible in agent-audit workflows. The cross-session hazard audit (10-agent synthesis) DID flag vocabulary drift and numbering conflicts, but did NOT flag "this imperative assumes a schema that wasn't verified." Schema-grounding is a different check than consensus/divergence analysis. 4. HEARTWOOD-04's response was correct and doctrine-compliant. They diagnosed the gap, filed BLOCKED with evidence, self-filed HWD-0273 follow-on, and self-claimed. Per ORA-2026-0015 (feed-bracket / self-claim default), this is the exemplar pattern for receiving a dispatch with a bad premise. The failure is in the dispatch, not the reception.

Recommended mitigation

Add a schema-grounding pre-dispatch check to STRAT workflow when any dispatch includes concrete DB artifacts (table names, column names, constraint names, function names):

# Before filing any dispatch containing "ALTER TABLE X", "INSERT INTO X",
# "UNIQUE (a, b)", or "CREATE X", run:

# 1. Table existence check
echo "SELECT table_name FROM information_schema.tables
      WHERE table_schema='public' AND table_name='<X>';" \
  | supabase-psql heartwood

# 2. Column existence check (if named)
echo "SELECT column_name FROM information_schema.columns
      WHERE table_schema='public' AND table_name='<X>'
      AND column_name IN ('<a>','<b>');" \
  | supabase-psql heartwood

# 3. Codebase grep for the name (catches views/functions not in information_schema.tables)
grep -rIE '<X>' /Users/chadbarlow/gh/camber /Users/chadbarlow/gh/heartwood 2>/dev/null | head -5

If any of the three returns empty/mismatched, reformulate the dispatch to include the verification step inside the ticket (as a diagnostic sub-task) rather than assuming the artifact exists.

Stronger pattern: treat every third-party-scorecard-derived dispatch as a two-phase ticket — Phase 1 = verify premise (15 min), Phase 2 = execute (the original estimate). Don't collapse into a single ticket until the premise is locally grounded.

Related doctrines / failures

• ORA-2026-0007 (reassignment cites prior diagnostic): adjacent — the follow-on ticket should link back to the original. Here HWD-0273 does this via PRIOR-DIAGNOSTIC field.
• ORA-2026-0021 (no scope creep on dispatches): adjacent but different — scope creep is adding work; this is assuming work is simpler than it is. Both are "dispatch quality" failures.
• ORA-2026-0032 (identity collision): parent — the entire §0–§13 merge that birthed HWD-0272 was a post-collision reconciliation. Provenance chain: identity collision → merge session → unverified inheritance → blocker surface.
• Future doctrine candidate: "Schema-grounding as a dispatch prerequisite" — if this pattern repeats, elevate from M2 observation to M4 doctrine with mandatory pre-check.