TRACK H, PRODUCTION DEPLOY OF THE LAST LOGIN FIX. Evidence, 28 July 2026. APPROVAL, recorded verbatim as the guardrails require: "Track H login fix deploy to production: approved, record this approval in the ledger. Ship it exactly as described, baseline plus the Track H change only, both nodes, build routes re proven dark, authenticated leg in the sweep." Joseph, 28 July 2026. BUILT the way the guardrails require, NOT from repository HEAD. A clean worktree at the pre build baseline 462eb81 with only the Track U and Track H files overlaid, cmd/api/main.go hand resolved for the platform gate and the operator MFA wiring, and AppShell.tsx taken from the BASELINE so the Phase 1 capture navigation link cannot ride along again. API sha256 8f24414531e80a9ab5297fa693323b07f87b2e46b0a1cbbb8097f3f760dc82a9 Proven by grepping the BINARY, not the source: requirement-drafts 0 occurrences opportunities/tracked 0 occurrences scope/items 0 occurrences SELECT auth_touch_last_login($1, $2) PRESENT Tests green in the production tree: auth, security, config. DEPLOYED to BOTH nodes, identical sha 8f24414531e80a9a on each, healthz 200 on each. Previous binaries kept as mm-api.bak.pre-trackh on both. PRODUCTION POSITIVE CONTROL, one real login through the public HTTPS URL: A dedicated probe account was provisioned for this rather than using a real person's credentials: trackh.probe@missionmatch.test, viewer, NO tools, created through the same path provision-org uses and retired afterwards. before last_login = NULL wall clock 2026-07-28 16:36:07 CDT login HTTP 200 session leg GET /api/auth/session -> 200 after last_login = 2026-07-28 16:36:08.000522-05 The stamp is correct to the second against the wall clock. The mechanism now works in production, not only in history. BUILD ROUTES RE PROVEN DARK, both legs, sampled four times so both pool members answer: UNAUTHENTICATED POST requirement-drafts approve 404 404 404 404 POST opportunities tracked scope 404 404 404 404 POST opportunities/tracked 405 405 405 405 (pre build shape) AUTHENTICATED, with a real session, which the previous sweep did NOT have and which is why it missed a 500 behind the session gate: POST requirement-drafts approve 404 404 404 404 POST opportunities tracked scope 404 404 404 404 GET opportunities/tracked 404 404 404 404 Session proven real: GET /api/auth/session 200 200 200 200. GET /api/candidates and /api/requirements answered 404 for the probe, which is CORRECT: a viewer with no tool grants is refused by RequireAnyTool with 404, fail closed working as designed. ZERO 5xx SWEEP: 96 requests across 16 paths, each path hit on BOTH the unauthenticated and the authenticated leg, three times each. 0 fives. PROBE RETIRED: status disabled, sessions revoked, account NOT deleted, per the rule that accounts are never deleted. It remains visible in the audit trail with its last_login intact, which is the honest outcome. RESTORE SCRIPT HARDENED so the drill's discovery lives in the script rather than in anyone's memory: It now ENSURES every required extension before loading, driven by a named REQUIRED_EXTENSIONS list so a future dependency is handled before it costs an outage rather than after. It ASSERTS the critical tables afterwards: candidates and opportunity_records must be PRESENT, NON EMPTY, and RECONCILED. Any one of the three failing fails the drill, because that is exactly what a silently failed restore looks like. POSITIVE CONTROL ON THE NEW ASSERTION: the vector extension was dropped and the drill REFUSED to proceed, naming the exact superuser command a real recovery must run. Restoring the extension made it pass again. THE RESTORE TIME IS A BASELINE THAT WILL GROW WITH THE DATA. Today it is 8 to 10 seconds for a 16 MB decrypted dump of the 95 MB database. The script now prints that caveat on every run and records the size beside the time, so the number is compared against the previous phase close and never read in isolation.