Third slice of the conference committee UX. Testimony against a conference asks a different question than testimony against a bill: not whether to pass it, but which version should pass.
Stance
The position enum on testimony gains four values: passNothing, passSomething, passSenateVersion, passHouseVersion. A testimony whose bill carries conferenceId must use one of the four; any other testimony must use the existing three. Validation lives in the runtypes, which is where it lives today (Firestore rules do not check position).
This extends the enum rather than adding a parallel field. It is one domain whose set of values depends on the target, and every consumer has to learn the new labels either way.
Where it lands
- Testimony carries
conferenceId alongside billId, with billId set to the conference's canonical bill so the testimony still appears on the bill page and in testimony search.
- The publish flow branches on
conferenceId the way it branches on ballotQuestionId: the stance step shows the four options, the quick-info and share steps use conference wording, and the mailto subject line maps the four values to readable phrases.
- The conference document gets the four count fields, incremented by the same triggers that maintain bill counts. Bill-level support and oppose counts are untouched because the new values do not map to them.
- Testimony search: the position facet is a string and needs no schema change, but the facet labels and the testimony card need the four labels.
- Notifications and digest emails carry the position and need the four labels.
- The conference page lists testimony grouped by the four stances.
The enum is hard-coded in roughly two dozen non-test files across the bill page, search, publish flow, notifications and backfill scripts. Expect the diff to be wide and mechanical.
Verified when
A testimony published on dev with "pass the Senate version" appears on the conference page under that stance, on the canonical bill page, and in testimony search with the right facet.
Third slice of the conference committee UX. Testimony against a conference asks a different question than testimony against a bill: not whether to pass it, but which version should pass.
Stance
The position enum on testimony gains four values:
passNothing,passSomething,passSenateVersion,passHouseVersion. A testimony whose bill carriesconferenceIdmust use one of the four; any other testimony must use the existing three. Validation lives in the runtypes, which is where it lives today (Firestore rules do not check position).This extends the enum rather than adding a parallel field. It is one domain whose set of values depends on the target, and every consumer has to learn the new labels either way.
Where it lands
conferenceIdalongsidebillId, withbillIdset to the conference's canonical bill so the testimony still appears on the bill page and in testimony search.conferenceIdthe way it branches onballotQuestionId: the stance step shows the four options, the quick-info and share steps use conference wording, and the mailto subject line maps the four values to readable phrases.The enum is hard-coded in roughly two dozen non-test files across the bill page, search, publish flow, notifications and backfill scripts. Expect the diff to be wide and mechanical.
Verified when
A testimony published on dev with "pass the Senate version" appears on the conference page under that stance, on the canonical bill page, and in testimony search with the right facet.