# AGENT-PROMPT-v5-P1-1b — Piece B B-R1 remediation test-plan gate: Miguel's approval

**Date:** 2026-08-06
**Follows:** `docs/AGENT-PROMPT-v5-P1-1b-piece-b-goahead.md` (the piece go-ahead and its standing
test-plan gate), `docs/AGENT-PROMPT-v5-P1-1b-o10-amendment-5.md` (the remediation basis and the
three standing instruments), `docs/p1-1b-status.md` (the B-R1 remediation checklist→test mapping,
recorded in the records commit whose pre-commit base was `b0d7445c5885f4d1b43e6f933403c8200649b18a`,
pushed), `docs/p1-1b-o10-independent-review.md` ("Piece B candidate review — Reject #1"),
`docs/PROJECT-STATE.md`
**Authority:** Miguel. This is the explicit gate decision the go-ahead's standing test-plan gate
requires before any Piece B remediation code. It reopens no decision and changes no baseline: the
five expected completeness baselines remain 119 / 119 / 52 / 221 / **2,787**, the two pinned
`Routine` rows still import verbatim, and the immutable source pin remains
`b91768513fc638381fbde91f0b576b08220a98f6`.

## Decision: **Approved**, with both observations decided in the plan's favor

The B-R1 remediation checklist→test mapping recorded in `docs/p1-1b-status.md` — the Reject #1
disposition table with its 19 Pass rows carried forward as regression requirements, plus B-R1's
correction to items **7** and **20** exactly, mapped to the eight proposed disposable tests
R1a–R1g and the item-20 design-note correction — is **approved as the binding Piece B remediation
test plan**. The root-cause analysis is confirmed as read: PostgreSQL defers only `AFTER`
constraint triggers, the rejected candidate mixed an immediate `AFTER` target-side trigger with an
immediate `BEFORE` provenance-side trigger, and no single-sided adjustment closes both orderings.
The item 5 / item 7 split along the checklist's own boundary is confirmed as the narrowest shape
consistent with amendment 3's "closed by construction, not patched".

### The two reported observations — decided

1. **Observation R-1 — resolved as option (b), both orderings.** The remediation must support
   **both natural statement orderings** of a legitimate value/provenance co-update: item 7 is
   re-implemented as `DEFERRABLE INITIALLY DEFERRED` `AFTER` constraint triggers at the three
   attachment points (`RegistryFieldProvenance` insert/update, `DOCEFL` and `DOCFLG`
   `AFTER UPDATE OF "ItemClass"`), each re-querying **live** state at `COMMIT`, so both orderings
   see the identical final state and an unaccompanied one-sided change still fails closed at
   `COMMIT`. Option (a) is rejected for the reason the mapping itself states: it would silently
   couple Piece C's future O10-D2 `AssignDOCEFLItemClass` command to a fixed statement order and
   reintroduce B-R1's failure mode invisibly on any reordering. Item 5 (company agreement) keeps
   its own dedicated, still-immediate `BEFORE INSERT OR UPDATE` function (proposed
   `RequireCompanyAgreementFn`) on `RegistryFieldProvenance` alone.
2. **Observation R-2 — accepted as a necessary consequence of R-1.** The proof-mechanism shape
   changes to already-Pass items 5/15/16 are approved: 5/15 trace to the new dedicated immediate
   function with unchanged test shape; 16's cross-table sub-case moves from statement-time to
   commit-time rejection (same-row CHECK sub-cases untouched), mirroring the shape item 6's
   deferred cardinality tests already use. The required outcome — rejection — changes in neither
   case; only the point in the transaction at which it is observed changes.

### Confirmed scope notes

The "no provenance row at commit" branch of item 7's redesigned trigger is accepted **only**
because item 6's independent deferred cardinality trigger unconditionally forecloses that state
first; no test may construct a row-less-at-commit transaction to obtain a passing item-7 outcome,
and R1g's direct two-`UPDATE`-only assertion plus the explicit no-reliance statement on the
rejected candidate's delete-update-insert gap are part of the approved plan. The trigger/function
roster growing to a proposed **8 triggers / 4 functions** is approved as **shape**, with the exact
DDL and catalog roster fixed when `Up` is authored during remediation TDD and reported item by
item in the remediation's own evidence map — the same convention Observation 2 established for
items 10/12 and this approval re-confirms. Items 2 and 12's widened roster assertions are part of
the regression plan.

## What is now authorized

Ordered instruction 3 of the go-ahead, on the remediation basis amendment 5 established for piece
candidates: implement the Piece B remediation as a **remediation of candidate `b8fa033…`** under
the amendment-4 reformulated preflight (checks 1–5 re-run fresh and passing; check-6 divergence
logged without reading or adopting post-pin content), TDD first from the pushed approval tip —
applying exactly the approved redesign (the item 5/7 split, the three deferred constraint
triggers, R1a–R1g, the item-20 design-note correction, and the item 2/12 roster widenings) and
**no other content change**; full ordinary, focused, and disposable suites green; build 0
warnings; 0 residual containers; both accepted P1-1a and Piece A migration files byte-identical;
`WaiveDOCFLG` and `RejectTerminalDOCFLGMutationFn` proven byte-identical; the status evidence map
keyed to the 20-item remediation checklist item by item, with measured counts only; commit and
push. Then ordered instruction 4: the fresh independent adversarial review in an independent
session (full depth on B-R1's eight proofs; regression confirmation that every Reject #1 Pass row
still holds on the new diff), verdict recorded. On Accept, stop and report — Piece C still needs
its own go-ahead. On Reject, neutralize per amendment 3, stop, and escalate to Miguel: **this is
the second and final Piece B attempt before escalation.**

## What this approval does not authorize

Starting Piece C or D, or any Scope 1 work. Any content change beyond the approved remediation
diff. Resurrecting any part of the three monolithic rejects or rejected Piece A candidate
`6f86023d…` (Piece B candidate `b8fa033…` is remediated under this approval, never merged as-is).
Relying on, testing through, or documenting the delete-update-insert gap as a supported path. Any
prototype write or post-pin read. Reopening any closed decision or changing any baseline. Any
shared/live database write. Production go-live (O5 remains the only other open item; O5-prep
remains deferred by decision). History rewrite in either repository.

## Records instruction

Record this approval in `docs/p1-1b-status.md` and update `docs/PROJECT-STATE.md` **in the same
commit** (header, changelog; the amendment-5 rule that these records move together is in force),
track this file, push before implementation code — then proceed with instruction 3.