Conference committee UX

[fastfadingviolets]

Bespoke experience for bills that are in a committee of conference: the ad-hoc group of three House and three Senate members appointed to reconcile the two chambers' versions of a bill. In the months after the formal session ends these are the only bills still moving, and MAPLE currently treats them like any other bill.

What we want

• A page per conference showing who is on it (with a map), the status, and links to both versions of the bill and to its hearings.
• Sensemaking from news organisations that explains how the House and Senate versions differ, alongside a machine diff of the two texts.
• Testimony against the conference with a four-way stance instead of support/oppose/neutral: pass nothing, pass something, pass the Senate version, pass the House version.
• Later, and out of scope for now: LLM synthesis of that testimony that MAPLE could package for the conferees.

Design decisions

• A conference is its own document (generalCourts/{court}/conferences/{id}), not a flag on a bill. Everything above is a property of the pair of bills, not of either one. Ballot questions are the precedent: a sibling collection with its own counts, testimony carrying an optional target id, and the publish flow branching on it.
• Conferences are authored in YAML and synced by a script, as ballot questions are. There are only a handful per session, so no history parser for the first cut.
• Each of the two bills carries a conferenceId pointer written by the sync script. Search needs it because the search record is a pure function of the bill document; the publish flow and the bill page need it to avoid a second query per page load. The scraper writes with merge and only rebuilds the fields it names, so the pointer survives rescrapes the same way summary, topics and city already do.
• The testimony position enum is extended with the four new values and validated against the target, rather than adding a parallel field.

What the data already gives us

Verified against the public API for S3141 / H5630 in the 194th court:

• Conferees are named in the bill history: Committee of conference appointed (Friedman-Cronin-Tarr) and Committee of conference appointed - (Michlewitz-Kilcoyne-Kane), in concurrence.
• The pairing is in the history too: Text of H5618, published as H5630 on the Senate bill, See S3141 on the House bill.
• Conference hearings arrive with an empty agenda and no committee code, and their descriptions do not follow a fixed format ("Data Privacy Conference Committee Meeting", "Protect Act -- Conference Committee Meeting"). They are linked by hand in the YAML.

Upstream context (codeforboston/maple)

• Add inConferenceCommittee Flag to Bills codeforboston/maple#2247 adds an inConferenceCommittee boolean derived from the last history action. It is one-sided (only the chamber that passed first carries the action) and we do not depend on it.
• Add Conference Committee Members to Testimony CCs codeforboston/maple#2211 asks for conferees in the testimony CC list.
• Bill <-> Hearing Sync Broken for Conference Committee Hearings codeforboston/maple#2246 reports the broken bill/hearing link for conference hearings.

Slices

Each slice is one PR, verified end to end on dev before the next begins. The sub-issues carry the detail.

1. Conference data, YAML sync and the bill pointer
2. Conference page
3. Four-way testimony
4. Diff and authored sensemaking

Slices 3 and 4 depend on 2 but not on each other.