# AGENT-PROMPT-v5-P1-1a-review — Independent review and sign-off

**Date:** 2026-08-05
**Follows:** `docs/AGENT-PROMPT-v5-P1-1.md`, `docs/AGENT-PROMPT-v5-P1-1a-d2.md`,
`docs/AGENT-PROMPT-v5-P1-1a-d2-amendment-1.md`, `docs/AGENT-PROMPT-v5-P1-1a-d2-closure.md`
**Authority:** Miguel. This prompt assigns the independent review that P1-1a acceptance has been
waiting on since the closure commit. It authorizes verification and a written verdict. It does
**not** authorize code changes, record rewrites, P1-1b work, or anything on the "may not do" lists
of the prompts above.

## Who you are, and who you are not

You are a fresh session. You are **not** the agent that implemented `e2f4c2a`, `719407c`, or
`74d8635`, and you must not have their conversation context. Your job is to try to find reasons
the P1-1a set should **not** be accepted, and to sign off only if you fail. Read
`docs/PROJECT-STATE.md` first and obey its state discipline: that file wins over every other
document; report contradictions, never resolve them silently.

A remote pre-review already exists (`docs/p1-1a-remote-review-report.md`, if committed, or as
provided by Miguel). It reviewed code and records but **could not run anything**. Do not treat its
conclusions as evidence; re-derive them. Its advisory findings A1–A5 are questions for you to
confirm or dismiss, and A2 (filename-uniqueness case sensitivity vs the pinned prototype's §15
semantics) requires an answer from the pin, which you have and it did not.

## Scope under review

The P1-1a set on `feature/p1-0d-follow-up`:

1. `e2f4c2a` — deliverable 1, the migration train (schema, governed commands, identity-stability
   verifier, disposable suite).
2. `719407c` — deliverable 2, the validation service (sixteen checks, snapshot source, tests).
3. `74d8635` — the closure records (O6 closed, O7 registered, four corrections).

Read before judging: `docs/p1-1a-status.md`, `docs/p1-1a-d2-status.md`, the three prompts this
one follows, `docs/p1-0-signoff.md` (the record pattern you will imitate), and the cited seed and
mapping drafts as needed.

## Step 1 — repository state

Verify and record: branch in sync with origin (local = upstream = remote SHA, divergence 0/0);
working tree clean; `74d8635` single-parent with no merge/rebase/force-push anywhere in the
P1-1a range; both feat commit bodies readable with `git log --format=%B` (note `e2f4c2a`'s
recorded literal-`\n` defect — it stays; `719407c` and `74d8635` must be clean); the closure
commit touches exactly `docs/p1-1a-status.md`, `docs/PROJECT-STATE.md`, `docs/project-todo.md`,
`docs/p1-1a-d2-status.md`.

**The topology deviation is known and disclosed:** the closure prompt ordered one commit; the
implementation was already pushed as `719407c` by prior instruction, so the closure became a
records-only second commit. Verify the disclosure exists in both status files, then either accept
it as a recorded deviation in your sign-off or object with reasons. Do not "fix" it.

## Step 2 — reproduce the verification, independently

Run, in this order, and record actual numbers (any regression → stop, report, **no sign-off**):

1. `dotnet build GOTT.Sibyla.slnx` — expected 0 warnings, 0 errors.
2. `dotnet test tests\Sibyla.Tests\Sibyla.Tests.csproj` — expected 629 passed, 0 failed,
   0 skipped (P11aDatabase excluded by default).
3. The focused registry suite (filter on the registry validation tests) — expected 28 passed.
4. `scripts\run-p11a-disposable-tests.ps1` — expected 10 passed against disposable PostgreSQL 17.
5. `docker ps -a --filter name=sibyla-p11a-` — expected 0 residual containers.
6. `git diff --check` — clean; confirm the run left the working tree unchanged.

## Step 3 — deliverable 1, structural

Confirm by reading (not rewriting): the single regeneratable migration and its Up-Down-Up test
with the `P11aCode_`-prefixed decoy surviving Down; the forged-GUC test (`sibyla.actor` /
`sibyla.authorities` grant nothing; allocation fails); receipt-gated purge (only a durable
`StorageDeletionReceipt` marks `Purged`; failed/ambiguous attempts retained); sequence allocation
by `INSERT … ON CONFLICT DO NOTHING RETURNING` with no runtime `setval`. Confirm no shared or
persistent database is touched anywhere in the suite.

## Step 4 — deliverable 2, deep

For each of the sixteen checks in `docs/p1-1a-d2-status.md`'s table, open the cited source and
confirm it says what the citation claims — including the pinned `SKILL.md` sections (blob
`72f17dcfa85c78a1c4825355697fe2092379f407`) and `Scripts/build_workbook.py::build_lookup_tables`
/ `Scripts/entity_utils.py::is_synthetic_fiscalno` at pin `9359c67c…`, read-only. Then confirm in
`RegistryValidationService.cs` / `PostgresRegistryValidationSnapshotSource.cs`:

- `Source <> 'BNK'` scoping on exactly three checks (filename, DOCTYP coverage, DOCTYP
  placement) and nowhere else;
- the global two-directional pair↔LGCode bijection, and the absence of the prohibited
  one-EntryCode/one-code check;
- warnings exactly for synthetic FiscalNo, CaptureQuality, orphan (input retained); failures for
  everything else including the exact 45-row DOCEFL manifest with fourteen required fields;
- the FX triplet `(Period, From, To=EUR)`;
- authorization: single unambiguous `sub`→`NameIdentifier` subject, byte-exact comparisons,
  active `UserProfile` → active `Membership` → active `CompanyRegistry`, and every fail-closed
  path (unauthenticated, ambiguous subject, unavailable source → all data checks failed);
- the "Resolved source differences" section records every deviation from a source rather than
  silently deciding it, and takes no decision reserved to Miguel (`CaptureQuality` stays open
  as O7).

Disposition A1–A5 from the remote pre-review: for A2, determine from the pin whether §15's
filename uniqueness is byte-exact or case-insensitive and state whether the Ordinal
implementation matches; record the other four as confirmed-advisory or dismissed.

## Step 5 — the verdict record

Write `docs/p1-1a-signoff.md` in the pattern of `docs/p1-0-signoff.md`:

- header: date, reviewer identity, the three SHAs, the pin;
- the reproduced verification numbers from Step 2, as measured, not copied;
- findings: blocking (if any), advisory, dismissed — each with file/line or record citation;
- disposition of the topology deviation and of A1–A5, including the A2 answer;
- verdict: **Accepted** / **Accepted with notes** / **Rejected (reasons)**;
- the explicit limitation sentence: *this sign-off accepts P1-1a as implemented and does not
  authorize P1-1b imports, shared- or persistent-database migration, production deployment
  (O5 open), or the O7 decision.*

If accepted: update `docs/PROJECT-STATE.md` per its own rules — P1-1a phase row to accepted,
changelog row dated with the sign-off, open items unchanged (O5, O7) — and commit prompt +
sign-off + state update as one `docs:` commit with a clean multi-line body, pushed. If rejected:
commit only the sign-off with its findings; change nothing else; stop and report.

## What you may not do

No `src/`, `tests/`, `migrations/` or schema changes — findings are reported, not fixed. No
prototype writes; the clone stays read-only at the pin. No P1-0 draft edits. No live data, no
shared database, no deployment, no merge to `main`, no history rewrite. If any instruction here
conflicts with `docs/PROJECT-STATE.md`, stop and report the conflict.