# Prompt — Change Review Review a proposed code change against the Foundation. Produce **PASS**, **CONDITIONAL PASS** or **FAIL**. --- ## Inputs - The proposed change (diff or PR) - `foundation/foundation.yaml` — constraints and invariants - `intransic/internal/evidence-ledger.yaml` — claim status - `AGENTS.md` — conventions --- ## Instructions You are reviewing a change to a backend handling health-related personal data. Be specific and evidence-based. Do not approve on the basis that a change "looks reasonable". ### Step 1 — Understand the change Summarise what it does in two sentences. Identify every file touched and every endpoint, entity or configuration key affected. **If it touches a file listed under `change_constraints.changes_requiring_review`, say so immediately.** ### Step 2 — Invariant check For each invariant in `foundation.domain.invariants`, state: **not affected** / **upheld** / **VIOLATED**. Quote the specific lines for anything other than "not affected". Pay particular attention to: - **INV-1** — does this let anyone read data that is not theirs? - **INV-2** — does identity come from anywhere other than the validated principal? - **INV-6** — does this add a secret to a tracked file? ### Step 3 — Prohibited states Check each entry in `foundation.domain.prohibited_states`. Any hit is an automatic **FAIL**. ### Step 4 — Boundary violations - Does a controller now contain business logic or data access? - Does a service reach outside its component boundary? - Does anything read `Request.Headers` for identity outside a Development gate? - Does an integration bypass the established resilience pattern? ### Step 5 — Removed protections ⚠️ **Scan the diff for deletions, not just additions.** Explicitly list any removed: - `[Authorize]` or `[Authorize(Roles=...)]` - `[EnableRateLimiting]` - `IsDevelopment()` gate - validation or scope check - identity-resolution call replaced with a direct header read For each removal, require an explicit justification in the change description. **An unexplained removal of a protection is a FAIL.** > This step exists because a merge on 2026-07-25 silently deleted `[Authorize]`, a caller-scoping helper and three rate-limit attributes while adding unrelated feature code, reopening a fixed vulnerability. Deletions hide in diffs dominated by additions. ### Step 6 — Security, privacy, reliability implications - **Security:** new surface? changed authn/authz? new outbound data flow? new dependency? - **Privacy:** new personal/health field? → must be added to `data.classifications[].fields` (`F-10`) or it will show up as an unexplained `pii_coverage` warning next run. New processor? → must be added to `privacy.processors` with a stated `basis` (`F-11`). Changed retention/consent? **Does it log anything that might contain personal data?** (redaction is not systematically in place) - **Reliability:** new failure mode? external call without a timeout? non-idempotent operation on a retried path? ### Step 7 — Test requirements - Does an existing test cover the changed behaviour? - **If the change touches authentication, authorisation, identity resolution or rate limiting, a test asserting the security property is MANDATORY.** Its absence is a **FAIL**, not a suggestion. - Does the change alter behaviour asserted by a currently-failing test? Where the suite carries a standing failure count, check whether a "pre-existing" failure is in fact caused by this change. ### Step 8 — Documentation and Foundation updates - Does this change a constraint, invariant, boundary, interface or data classification? → **Foundation must be updated.** - Does it change the status of a ledger claim? → **ledger must be updated.** - Does it invalidate an existing claim? → downgrade it; do not leave it stale. - Does it make an existing document wrong? → record in the contradiction register. ### Step 9 — Trust Wall impact - Does it strengthen evidence for a withheld claim? (e.g. closing `AUTH-006` unblocks `AUTH-003`) - Does it weaken evidence for a published claim? → the claim must be **downgraded or removed before merge**. - Does it require regenerating `trust/claims.json`? --- ## Output format ``` VERDICT: PASS | CONDITIONAL PASS | FAIL SUMMARY INVARIANTS INV-n: upheld | not affected | VIOLATED — REMOVED PROTECTIONS FINDINGS [BLOCKING] — — — [NON-BLOCKING] — — REQUIRED TESTS FOUNDATION / LEDGER UPDATES TRUST WALL IMPACT HUMAN REVIEW REQUIRED: yes | no — ``` **Verdict rules** - **FAIL** — any invariant violated, prohibited state introduced, protection removed without justification, or a mandatory security test missing. - **CONDITIONAL PASS** — no violations, but Foundation/ledger/test updates are required before merge. List them precisely. - **PASS** — no violations and no outstanding updates. Do not soften a verdict because a change is small, urgent, or authored by someone senior. State findings plainly and let a human decide.