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
  <two sentences>

INVARIANTS
  INV-n: upheld | not affected | VIOLATED — <evidence>

REMOVED PROTECTIONS
  <list, or "none detected">

FINDINGS
  [BLOCKING]     <issue> — <file:line> — <why> — <remedy>
  [NON-BLOCKING] <issue> — <file:line> — <suggestion>

REQUIRED TESTS
  <tests that must exist before merge>

FOUNDATION / LEDGER UPDATES
  <required changes, or "none">

TRUST WALL IMPACT
  <claims affected, or "none">

HUMAN REVIEW REQUIRED: yes | no — <trigger>

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.