Integrity Audit — Composed E2E Walkthrough (Ryan)¶

Purpose: Confirm the legitimate verified-veteran journey still flows through all four hardened gates (C1, H1, H2, H3) in composition—not just in isolation.

Environment: Prod — https://last1.app, last1.id credentials, WIN (warriors-in-need)

Prerequisite: Run reset (see §0). Start logged out everywhere.

§0 — Reset (operator, before browser)¶

Already run for you (2026-09-09): curryrg@gmail.com — last1.id verification cleared; last1.app coordination wiped (Ω/Λ break-glass + BSL reviews + loops reopened). Beneficiary b33c18d2… / Ryan-Curry-Demo.

To re-run from a prod shell on .104:

# 1) Ω + Λ break-glass (test beneficiary only; requires psql via docker on .104)
source /opt/last1app/.env
docker run --rm --network host postgres:17-alpine psql "$DATABASE_URL" -v ON_ERROR_STOP=1 <<'SQL'
-- replace beneficiary UUID if different
DROP RULE IF EXISTS protect_program_coordination_output_state_events_no_delete ON program_coordination_output_state_events;
DROP RULE IF EXISTS protect_program_coordination_output_state_events_no_update ON program_coordination_output_state_events;
DELETE FROM program_coordination_output_state_events WHERE beneficiary_id IN ('b33c18d2-44e0-4650-b9d9-a5b6d5f59744');
DROP RULE IF EXISTS protect_coordination_ledger_events_no_delete ON coordination_ledger_events;
DROP RULE IF EXISTS protect_coordination_ledger_events_no_update ON coordination_ledger_events;
DELETE FROM coordination_ledger_events WHERE loop_id IN (
  SELECT id FROM coordination_loops WHERE beneficiary_id IN ('b33c18d2-44e0-4650-b9d9-a5b6d5f59744')
);
CREATE OR REPLACE RULE protect_program_coordination_output_state_events_no_delete AS ON DELETE TO program_coordination_output_state_events DO INSTEAD NOTHING;
CREATE OR REPLACE RULE protect_program_coordination_output_state_events_no_update AS ON UPDATE TO program_coordination_output_state_events DO INSTEAD NOTHING;
CREATE OR REPLACE RULE protect_coordination_ledger_events_no_delete AS ON DELETE TO coordination_ledger_events DO INSTEAD NOTHING;
CREATE OR REPLACE RULE protect_coordination_ledger_events_no_update AS ON UPDATE TO coordination_ledger_events DO INSTEAD NOTHING;
SQL

# 2) Mutable tables + BSL + loop reopen (inside last1app container; DATABASE_URL empty skips break-glass)
docker cp /opt/last1app/src/scripts/reset-integrity-e2e-accounts.mjs last1app-app:/app/scripts/reset-integrity-e2e-accounts.mjs
docker exec -e INTEGRITY_E2E_EMAILS=curryrg@gmail.com -e DATABASE_URL= last1app-app node /app/scripts/reset-integrity-e2e-accounts.mjs

# 3) last1.id — unverify curryrg
docker cp /opt/last1.id/repo/scripts/reset-veteran-verification-by-email.ts last1id-app:/app/scripts/
docker exec last1id-app npx tsx /app/scripts/reset-veteran-verification-by-email.ts curryrg@gmail.com

Optional fresh org-invited veteran: invite a new beneficiary or use tony+vetclaims-test@last1.app once a WIN beneficiary row exists for that email.

Accounts (fixture):

Role	Email
WIN org admin	`ryan@last1.enterprises` (or `ryan@warriorsinneed.org`)
Primary veteran (your E2E)	`curryrg@gmail.com`
Second veteran (optional)	`tony+vetclaims-test@last1.app` or `ryan@curry.net`

Program: VetClaims TEST — fbf54f34-5e58-47ea-882b-f693c627b508

§1 — Onboarding + H2 (verification approval integrity)¶

1a. Last1 ID + DD-214 submission¶

Sign in to last1.id as curryrg@gmail.com.
Upload DD-214 (real or test PDF). Confirm review enters pending queue with document attached.

1b. Org approves (H2)¶

Sign in to last1.app org admin as ryan@last1.enterprises.
Open DD-214 verification review queue. Find curryrg@gmail.com pending review.
Negative check (optional): Attempt self-approve as curryrg — must fail (not org queue path).
Approve as org admin (distinct identity from veteran).
Confirm H2 recording: Veteran shows verified badge; provenance indicates org-attested DD-214 path (not VA-confirmed). Audit row exists in last1.id (dd214_review_decided).

1c. WIN beneficiary link¶

Org: /beneficiaries → Ryan-Curry-Demo (or beneficiary for curryrg).
Link member account → curryrg@gmail.com. Confirm strict link (beneficiary user_id matches auth user).
Enroll in VetClaims TEST program if not already enrolled.

Gate passed: veteran_verified=true before program work.

§2 — C1 hard gate (before vs after verified)¶

2a. Before verified (only if you skipped §1 reset)¶

Skip if you just completed verification in §1.

2b. After verified — program actions unlocked¶

Sign in as member curryrg@gmail.com on last1.app.
Open /member or program progress. Confirm veteran setup shows verified (three checks / unlocked).
Negative (mental model): Org admin session cannot act as recipient on outputs (no strict beneficiary link).

Gate passed: Verified veteran reaches output/loop surfaces; org cannot substitute for veteran.

§3 — Outputs via Ω only (H1 + C1)¶

Use program VetClaims TEST outputs (e.g. Claim filed with VA slug claim-filed-with-va).

3a. Veteran submit-first (C1 + H1)¶

As curryrg, on program progress: submit / confirm your output (recipient role).
Confirm success without org impersonation.

3b. Org ladder → two-source close (H1 Ω ledger)¶

As org admin, run org-side steps for same output (mark received → reviewed → confirm, or org-delivered shim UX).
As curryrg, recipient confirm if required by evidence source.
Confirm output reaches two-source closed (or equivalent closed state in UI).

Gate passed: State changes only via Ω path; veteran-bound recipient actions.

Note: If an output scope was already closed in a prior run, pick a different output row in the same program or reset Ω break-glass for test beneficiaries (operator script).

§4 — Question / concern / deny / re-submit (Ω dialogue)¶

On an output not yet closed (or after reset):

Org raises question on an in-flight output.
Veteran responds (member session).
Org deny with re-submittable flag → confirm veteran can re-submit.
Optionally run veteran raise concern path.

Gate passed: Dialogue transitions work; ledger remains append-only (no edit-in-place in UI).

§5 — BSL outcome (H3)¶

5a. Open DRI coordination loop (if none active)¶

Org: open disability rating increase coordination loop for curryrg beneficiary (VetClaims outcome class).
Confirm loop outcome_class = disability_rating_increase.

5b. Veteran uploads own BSL (H3)¶

As curryrg member: upload Benefit Summary Letter on your loop (member route only).
Negative (optional): As org admin, confirm there is no upload affordance for BSL (review/decide only).

5c. Org review → outcome close¶

Org: BSL review queue → open document → approve.
Complete independent/outcome attestation path until loop/outcome reaches VERIFIED (or org-defined terminal success).

Gate passed: Only verified veteran on own loop uploads BSL; org reviews but cannot upload on veteran's behalf.

§6 — Composition success criteria¶

You are done when:

[ ] Verification path completed with org approval (H2), not self-serve bypass
[ ] Unverified gate blocked program work; verified gate opened (C1)
[ ] At least one output closed through Ω-only veteran submit + org ladder (H1)
[ ] Question/deny/re-submit path exercised without dead-ends
[ ] BSL uploaded by veteran, reviewed by org, outcome closes (H3)
[ ] No unexpected 403/500 on happy path; friction noted for follow-up only

If any legitimate step is over-blocked, stop and file the step + error code before Tony's walkthrough.

§7 — Operator verification (optional, after browser)¶

eval "$(ssh ryan@192.168.1.104 \"grep -E '^(SUPABASE_URL|SUPABASE_SERVICE_ROLE_KEY|DATABASE_URL|COORDINATION_DOCUMENT_ENCRYPTION_KEY)=' /opt/last1app/.env | sed 's/^/export /'\")"
cd /opt/last1app/src && npx tsx scripts/h3-wired-prod-verify.ts

All sections should PASS.