Expose Congress.gov measure details in voting records

[capituwuistgoonsquad]

Summary

• add forward-only migration 0037_congress_gov_measure_read_surface.sql with a versioned get_canonical_voting_records_v3 RPC
• preserve v2 person resolution, official/legacy coverage, filtering, ambiguity-safe deduplication, ordering, and pagination while attaching bounded exact Congress.gov measure links
• render validated bill/amendment labels, titles, purposes, observation dates, and official Congress.gov links in the live Voting Record tab
• advance scraper schema preflight to migration 0037 and document the completed GovTrack-retirement observation plus this presentation gate

Data and security boundary

• one result remains one vote even when a roll call links to multiple measures
• legacy state/historical rows always receive an empty measure array
• only active, verified, exact-link Congress.gov facts from the approved source/catalog/endpoint contract are exposed
• title and purpose display lengths and measures per vote are bounded
• source_records, legislative_roll_calls, legislative_measures, and link tables remain private to browser roles
• no raw JSON, private metadata, payload hashes, scraper writers, source requests, API keys, or legacy vote rows are added or changed
• the client falls back only from a missing v3 RPC to v2 during rollout; other v3 errors still fail closed

Production evidence

The first scheduled run after PR #109, run 32090695651, confirmed zero legacy GovTrack profile attempts/failures while the official House, Senate, and Congress.gov paths remained healthy. The previously observed Congress.gov contract remains 18 detail calls, 18 measures, 43 exact links, and 40 linked roll calls.

Validation

• python3 -m unittest discover -s tests -q — 371 tests passed
• python3 -m compileall -q .
• npm run typecheck
• npm run lint
• ALLOW_MOCK_BUILD=true npm run build — static export succeeded
• git diff --check

Required post-merge rollout

1. Manually apply migrations/0037_congress_gov_measure_read_surface.sql to Supabase before the next scheduled scraper. Do not replay earlier migrations.
2. Confirm migration marker 0037 and browser execute access to v3 while all four private tables remain unreadable to anon and authenticated.
3. Compare v3 and v2 base vote rows across pagination/filter boundaries and validate exact measure arrays on representative House and Senate profiles.

Until step 1 is complete, the frontend remains available through the narrow v2 rollout fallback, but scraper schema preflight intentionally blocks the next ETL run so schema drift cannot silently persist.

Greptile Summary

This change adds a versioned voting-record response that decorates official vote rows with bounded Congress.gov measure details and displays them in the Voting Record tab. The client preserves the existing v2 fallback while the new database migration is unavailable.

The executed client harness disproved the tested failure hypotheses: v3 measure decoration did not alter vote-row pagination, legacy vote rows remained undecorated, malformed and duplicate measures were discarded, and unsafe URLs were not rendered. Focused migration, UI, schema-preflight, TypeScript, lint, and production fixture-build checks also completed successfully.

T-Rex validation blocked

Live Supabase validation was blocked by missing approved remote SUPABASE_URL and SUPABASE_KEY credentials and a representative profile UUID. As a result, deployed v3/v2 result equivalence, browser-role access controls, and live House/Senate rendering could not be exercised.

Confidence Score: 5/5

No actionable defects were found in the exercised migration, client normalization, fallback, UI build, and schema-preflight behavior.

There are no final findings. The focused runtime harness exercised the changed v3/v2 client boundary, pagination, legacy-row isolation, measure validation, and URL sanitization, while focused contract tests and frontend checks passed.

Files Needing Attention: No files require changes from this review. migrations/0037_congress_gov_measure_read_surface.sql and the live Supabase deployment should receive the planned post-deployment v3/v2 and browser-role verification once approved credentials are available.

T-Rex Logs

What T-Rex did

• Ran the v3 voting-record client contract harness against the real TypeScript client module with mocked Supabase RPC responses; in the unavailable-v3 flow, it fell back to v2 with two undecorated rows, and in the available-v3 flow it retained two paginated vote rows, accepted 98 valid measures, discarded malformed and duplicate values, cleared legacy measures, and converted an unsafe URL to null.
• Executed the focused migration, UI, and schema-preflight suite; 16 checks passed.
• Ran frontend TypeScript and ESLint checks and completed the optimized Next.js fixture build; the fixture build did not issue remote Supabase requests.
• Validation was blocked by missing credentials; approved remote SUPABASE_URL and SUPABASE_KEY, plus a representative profile UUID, were unavailable, so the live v3 RPC could not be compared with v2 and browser-role ACLs or representative remote rendering could not be tested.
• Collected a set of runtime and test artifacts to support review, including the v3-voting-record runtime harness, before/after v3 availability RPC flow logs, focused migration/UI/schema-preflight test output, frontend checks, and the optimized fixture build output.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "Expose Congress.gov measure details" | Re-trigger Greptile}