# AGENT-PROMPT-v5-P1-1b — Piece D go-ahead: integration gate — cumulative catalog equivalence and Scope 1 readiness **Date:** 2026-08-06 **Follows:** `docs/AGENT-PROMPT-v5-P1-1b-o10-amendment-3.md` (Piece D content, pre-authorized), `docs/AGENT-PROMPT-v5-P1-1b-o10-amendment-5.md` (checklist discipline, proof-pattern annex, test-plan gate), `docs/AGENT-PROMPT-v5-P1-1b-piece-c-goahead.md` (format and sequencing precedent), `docs/p1-1b-o10-independent-review.md` ("Piece C candidate review — Accept", `ce983b2c…`), `docs/p1-1b-status.md`, `docs/PROJECT-STATE.md` **Authority:** Miguel. Piece C has a recorded independent **Accept** — candidate `ce983b2cb1397f53ec5dbe47d5b568cb025288ec`, verdict **0 Critical, 0 High, 0 Medium, 0 Low**, recorded in `docs/p1-1b-o10-independent-review.md` ("Piece C candidate review — Accept") — so per amendment 3 this document is **Piece D's own go-ahead**: its content was pre-authorized by amendment 3; this starts it. It reopens no decision. The five baselines remain 119 / 119 / 52 / 221 / **2,787**; the two `Routine` rows still import verbatim; the pin remains `b91768513fc638381fbde91f0b576b08220a98f6`. **Accepted implementations, from the live records:** Piece A `f6f297b…` (accepted P1-1a plus Piece A), Piece B `7059809…` — the B-R1 remediation of rejected candidate `b8fa033…`, reviewed and accepted at `256da9c…` — and Piece C `ce983b2…`, reviewed and accepted at the commit recording that verdict. Monolithic rejects `b324a3e…`, `57f0f023…`, and `7ea6c0f…`, and piece candidates `6f86023d…` (Piece A Reject #1) and `b8fa033…` (Piece B Reject #1), remain **neutralized evidence only** — never resurrected, never cherry-picked, not even in part. The accepted implementations are Piece A `f6f297b…`, Piece B `7059809…`, and Piece C `ce983b2…` alone. ## What this go-ahead authorizes, and what it does not Piece C's Accept authorizes Piece D to seek its own go-ahead; it does not itself authorize Piece D's start. **This document is that go-ahead — Piece D may now start under amendment 3.** **Scope 1 remains unauthorized until Piece D independently Accepts.** No decision is reopened by this document. ## Scope, restated from amendment 3 — an integration gate, not a migration/content piece Piece D adds **no new migration content**. It is verification that Pieces A + B + C together — run cumulatively on top of the accepted P1-1a catalog — are byte-exact-invertible and complete. It performs: - **No production, shared, or live database write** of any kind. - **No importer execution** and no import of any kind. - **No Scope 1 work.** Scope 1 restart is gated on Piece D's own Accept, not performed by Piece D. Piece D's mapping, and its later implementation once approved, may **add or strengthen** integration tests, test harness/helper code, and the two required records files (`docs/p1-1b-status.md`, `docs/PROJECT-STATE.md`) — and only where the approved test-plan mapping later requires it. **No implementation of any kind precedes Miguel's explicit approval of the mapping.** **Additive base:** the accepted P1-1a catalog plus accepted Piece A (`f6f297b…`) plus accepted Piece B (`7059809…`) plus accepted Piece C (`ce983b2…`), run cumulatively in one combined migration sequence for the purposes of the proofs below. Piece D must not touch any accepted P1-1a/Piece A/Piece B/Piece C object; it observes and proves against them. ## The Piece D consolidated checklist — exhaustive, per amendment 5 The implementer's evidence map and the reviewer's disposition key to this list and to nothing else. A standing requirement found missing from it is a stop-and-report, never silently satisfied or skipped. 1. **Preflight and exact allowed surface.** The amendment-4 reformulated preflight checks 1–5 pass fresh and read-only (fresh cell-by-cell 49/49 roster measurement, per the review-correction precedent); check 6 records the live tip and any post-pin commits by hash and subject only, with no post-pin content read or adopted. The exact allowed surface for this piece is: no new migration content; test/harness/helper code and the two records files only. All six accepted P1-1a/Piece A/Piece B/Piece C migration files remain byte-identical (blob-ID assertion, not `diff --stat` silence) throughout — before, during, and after Piece D's own work. Minimal-surface discipline: an apparent need to alter, drop, re-own, or replace any accepted object is a stop-and-report, never a judgment call. 2. **R2 cumulative `pg_catalog` snapshot over the complete relevant surface.** A recorded snapshot covering: schemas/tables/columns (types, defaults, generated flags, nullability), owners, ACLs, roles/memberships/attributes, constraints with names and exact definitions and deferrability, indexes with exact definitions, triggers and their timing/deferral/enabled state, and functions/procedures with owner, ACL, security-definer status, `search_path`, identity arguments, return type, language, and exact `pg_get_functiondef` text — plus the EF migrations-history table where relevant. The snapshot must be semantically complete, deterministically normalized, and compared **as sets/records**, never as lossy counts. 3. **Combined cumulative Up→Down→Up proof, one disposable PostgreSQL 17 run.** Over P1-1a plus accepted Pieces A + B + C together, in a single disposable run, prove three distinct snapshots/phases without ambiguity: - **Phase 1 — first `Up`:** the cumulative catalog snapshot immediately after the combined `Up` sequence completes. - **Phase 2 — post-`Down`:** the catalog snapshot after the combined `Down` sequence. This must equal the **accepted P1-1a catalog exactly** — not the pre-`Down` A+B+C tip, and not a partial or approximate match. - **Phase 3 — second `Up`:** the catalog snapshot after re-applying the combined `Up` sequence from the post-`Down` state. This must equal **Phase 1 exactly**. 4. **R7 end-to-end.** All four accepted `ImportEvidenceRow` UNIQUE constraints remain unchanged by exact `pg_get_constraintdef` text, with the relevant `pg_indexes` definitions also unchanged, across first `Up`, post-`Down` accepted-P1-1a baseline, and second `Up` as applicable to each constraint's origin. 5. **The five baselines, one single end-to-end disposable run.** 119 / 119 / 52 / 221 / 2,787, plus both `Routine` rows imported verbatim, measured in one combined disposable-database run — **not stitched together from separate tests or separate runs.** Population/scope assertions are required alongside the counts so that a matching count cannot be vacuous or a sampled subset. No live import of any kind. 6. **Unknown `ItemClass` fails closed end to end, both imported and native rows.** Coverage spans DOCEFL and DOCFLG and the command/validator/schema surfaces where each applies. Honest SQL `NULL`/absent governed historical rows remain allowed and are measured (per the five baselines above), never coerced to a non-null placeholder. 7. **Full verification envelope.** Focused integration tests; the full disposable suite; focused registry tests; the ordinary suite; a clean rebuilding build at 0 warnings/0 errors; `git diff --check` clean; exact changed-path/claim equality (the diff matches what the status record claims, item for item); and 0 residual containers. Every claim equals a measured assertion — no stale binaries are trusted as evidence. 8. **New mandatory invariant — the roster/direct-DML trust-boundary probe, prompted by the Piece C independent-review non-binding observation.** This item does not require, and must not claim, that `RejectTerminalDOCFLGMutationFn` independently enforces a capability boundary against owner/superuser principals — the recorded Piece C owner-level probe already demonstrated a caller-set `sibyla.docflg_evidence_append_id` bypasses the trigger at owner level. The tested invariant is narrower and does not depend on that known-false outcome: - Build a complete, measured roster — after the combined first `Up` and again after the second `Up` — of every role/principal able to perform direct `INSERT`/`UPDATE`/`DELETE`/`TRUNCATE` on `DOCFLG` through ownership, superuser status, direct table grants, direct column grants, inherited membership, or any other effective route. - Classify the roster into two disjoint classes: owner/superuser control-plane principals, and application/executor/importer roles. - Assert fail-closed that **zero** application/executor/importer principals — i.e., every principal outside the owner/superuser control-plane class — can reach raw direct `DOCFLG` DML under the accepted P1-1a + Piece A + Piece B + Piece C catalog. - Separately, rerun an owner-level (or equivalent control-plane) adversarial probe that reproduces and explicitly asserts the known trust-boundary limitation: a caller-set `sibyla.docflg_evidence_append_id` can bypass `RejectTerminalDOCFLGMutationFn` at owner level to make the forbidden raw mutation without the command's audit/provenance. This probe is evidence explaining *why* the zero-reachable-application-writer roster is security-relevant — it is not expected to pass as a denied mutation, and it is not a claim that the trigger independently enforces a capability boundary at owner/superuser level. - Any unexpected non-owner/non-superuser writer, grant, or inheritance discovered during the roster build is a fail-closed stop-and-report, never adapted around silently: it requires Miguel's explicit contract/authority decision, because Piece D cannot remediate it by altering migration/DDL content — Piece D has no migration content. - The test-plan mapping must specify the exact catalog queries, the exact role expansion/inheritance semantics used to compute reachability, the expected roster (by class), and the exact assertions for both the zero-application-writer proof and the owner-level probe. A future intended importer role with direct DML is not silently accepted into the control-plane class merely because it is "intended" — it reopens this boundary for an explicit decision before Scope 1. ## Ordered execution 1. **Governed records acceptance.** Track this go-ahead and record its acceptance in `docs/p1-1b-status.md` and `docs/PROJECT-STATE.md` in the same records commit, pushed before any test-plan work begins. **This document only authors the go-ahead; it does not perform that records step.** 2. **Test-plan gate.** Map each of the eight checklist items above to exact proposed test method(s) and/or verification commands, labelled **New**, **Strengthened**, or **Existing regression**, and by surface. Adversarially assess feasibility and report any ambiguities or contract collisions as observations with a proposed resolution — exactly as Pieces A, B, and C did; never resolve them silently. Commit and push the mapping records, then **stop for Miguel's explicit approval.** No code, test, helper, migration, container, or database run precedes that approval. 3. **Only after approval,** implement TDD-first integration test/harness changes from the pushed approval tip. No migration content of any kind. 4. **Fresh independent integration-focused review**, explicit Accept/Reject verdict recorded. **Only Accept authorizes Scope 1 to seek/restart** at its own preflight and confirm-pin-or-re-pin checkpoint. **Reject stops** — Piece D does not self-authorize remediation unless the governing amendment explicitly permits it and the required mapping/approval gate is followed exactly as for Pieces A, B, and C. ## What this go-ahead does not authorize Any Piece D migration or DDL product change. Any importer or import execution. Any Scope 1 restart. Any shared or live database write. Any prototype write or post-pin content adoption. Any change to a baseline or a decision. O5 work of any kind. Production go-live (O5 remains the only other open item). History rewrite in either repository. Resurrection, cherry-picking, or reuse in any part of `b324a3e…`, `57f0f023…`, `7ea6c0f…`, `6f86023d…`, or `b8fa033…`. Implementation of any kind — test, harness, helper, or records content beyond this go-ahead's own governed-acceptance step — before Miguel's explicit approval of the checklist→test mapping. ## Report This document is authorization and gate specification only. It stops, by design, at the test-plan gate defined above and before any code. No test has been run and no evidence exists yet under this go-ahead; none is claimed here. The report expected once the ordered execution above proceeds is: the governed-acceptance commit hash; the checklist→test mapping recorded and Miguel's explicit approval; the implementation evidence map keyed item by item to the eight checklist items above; the independent integration-focused review verdict in full; build/test/ container evidence; confirmation that `PROJECT-STATE.md`, `p1-1b-status.md`, and the review record are mutually consistent; and, only on Accept, the statement that Scope 1 is ready to seek its own restart at preflight and the confirm-pin-or-re-pin checkpoint against pin `b917685…`.