Publish the candidates' answers again, and rebuild how a question reads

[mikaalnaik]

Brings the candidates' questionnaire answers back, rebuilds the card they are read in, and reopens the voter survey.

Two commits, each standing on its own.

1. The answers come back

questionnaireHidden and ANSWERS_WITHHELD are deleted, so rosterSurvey and the candidate-responses read proxy pass answers through again. /issues and /mayor lose their temporary 307s in next.config.ts. The ward pages, /mayor/candidates, the candidate pages and the landing grid return to the questionnaire presentation.

2. The card is rebuilt, because the field is sparser than it assumed

Measured across all 25 wards against the dev server:

respondents	wards
0	2, 3, 5, 6, 16, 18, 20, 21 — 8 of 25
1–2	10 wards
3–4	6 wards
6	ward 13 only

Median ward: 2 respondents over 33 questions. /mayor is the opposite — 14 respondents, ~27 name plates per card. One design was serving both and was built for the dense end.

• Empty wards no longer draw 34 cards reading "No answers to this one yet." They get QuestionnaireOutline — the questions in two columns under their section headings, keeping every id a card carried. ~9,000px becomes ~900px.
• The repeated footer is gone. Ward 1 was printing the same 140-character list of non-respondents at the foot of all 33 cards. The roster above already names and links them. Cards still name respondents who skipped that question, which is per-question and worth saying.
• A question is now a table of candidates — a row each in surname order, answer beside them, so names and answers are both columns you can run down and a candidate sits in the same place on every card. The answer prints in full (outside yes/no these run to ~90 characters, so it wraps rather than being a pill). What a candidate wrote opens in a <details> — no script, works with JS off, card stays a Server Component.
• Only respondents get a row; a line under the question says how much of the ballot that accounts for. Toronto's council races are non-partisan, so the line under a name is the incumbent badge only — "Challenger" under every other name would have been ~200 printings of a word that separates nobody.

Layout notes for review

• Two cards per row from 1166px. Rows inside size against the card via a container query, not the window — at half width a viewport-keyed template would lay out three columns for 1000px inside a 460px card.
• content-start on the card and its nested grids is load-bearing: two-up means both cards stretch to the taller, and grid's align-content defaults to normal → stretch, so opening one answer was sliding the neighbouring card's heading, table and foot apart. The card was flex flex-col before, which is why this never showed.
• Rows animate via ::details-content. interpolate-size is set on the element, not :root, so keyword interpolation doesn't quietly change every other transition in the document. It carries its own prefers-reduced-motion guard because the global rule reaches *, ::before and ::after — not this pseudo-element.

3. The voter survey reopens

One line off the registry entry, which is how surveyClosed was designed to be undone. surveyHref is the single rule all five invitations ask, so they return together: the landing card (between the mayoral read and the whole-field one, as that page's own comment describes), its closing CTA, the bands on /mayor and /issues, and the SurveyCta on all 25 ward pages.

⚠️ The submissions endpoint is live again, not just the links. POST /api/elections/survey stops returning 404 and starts recording real responses. I did not test-submit, since that would write an actual survey response — worth a deliberate check of the write path before this ships.

4. Two unrelated fixes

A truncated rule on /when-is-the-election

Carried here rather than split out, since it touches one file nothing else on this branch goes near.

The line closing the three-way ways-to-vote grid stopped about two thirds across. It is the border-t of the proxy-voting paragraph beneath, which carried max-w-[62ch] on the same element — a max-width bounds the box the border is drawn on. The gutters and the rule move to a wrapper; the measure stays on the paragraph.

It showed there and not elsewhere because that rule closes a full-bleed grid between two full-width ones. Three other spots pair a border with a max-w (AlignmentResults.tsx:203, SurveyClient.tsx:779, ElectionLanding.tsx:372) and are left alone — each is a short rule above a footnote, where matching the note's measure is a plausible choice.

The names panel on /issues overflowed sideways

A segment's panel lists everyone who gave that answer, capped at max-h-[14rem] and scrolling past it — but the names were in CSS columns, and multi-column inside a height-capped box fragments sideways rather than growing down, opening extra columns past the panel's right edge. The overflow ran horizontally while the scrolling ran vertically, so those names were unreachable. It's a grid now, which fills rows downward.

Column count is keyed to the panel rather than the window: these cards are two-up on a wide screen, so the panel is ~460px there while sm:columns-3 was firing off a 640px viewport.

Worth a reviewer's eye: container-type: inline-size carries contain: layout, which makes the figure a stacking context where plain position: relative was not. The panel's z-20 had lifted it clear of the page; scoped to its own figure, the card below — later in the tree, and exactly what the panel opens over — would have painted on top. The figure now takes z-30 while a panel is open, and only while open.

5. /issues presentation

Three separate commits, each revertible on its own.

Three cards to a row from 1280. Charts only — roll calls are tables whose answer column already runs to ninety characters. Not from 1166, because the scroll rail arrives at 1200 and takes 268px with it, so splitting three ways there would drop a card from ~510px straight to 283px. Measured cost: the option wordings are full sentences (median 71 chars, max 108), so a legend row goes from two lines to three or four. Taller cards, a third fewer rows, much the same total height.

The split is drawn as a pie. New OptionPie beside OptionBar in the charts package — same props, same hues, same hover wiring, so the legend and names panel are untouched. Slices are separated by a 2px stroke in the page background rather than a border; a 100% option is drawn as a <circle>, since a full-turn arc has identical endpoints and renders as nothing. Geometry verified numerically (starts at 12 o'clock, contiguous boundaries, closes the circle, large-arc flag correct at the half turn).

⚠️ This reverses an earlier decision. The figure was a donut once and was deliberately replaced by the band. That argument still holds: the page's work is comparing splits across 33 cards, which is aligned lengths on bars versus angles across separate circles — and 26 of the 33 questions are the ordered yes / yes-with-conditions / no scale (they already use the diverging ramp for exactly that reason), with five more having two options, where a pie is two slices. The reasoning is recorded in both files rather than argued away, and OptionBar is still exported with the same props, so reverting is an import and a figure element.

The survey CTA moved up beside the title, in addition to the closing band. Same SurveyCta as the landing page, at its default "beside a heading" width rather than the landing's 560px band override. The page now shows that block twice — there's a fair argument the top one should replace the closing band rather than join it.

6. A candidate's own page reads as a candidate, not as a field of one

The card in sections 2 and 5 was designed against a ward. A profile page runs the same card over a roster of one, and three things it does for a field are wrong for a person.

A follow-up was printing under the bio. ward_commitment_target is a textarea authored directly beneath the choice question it follows up on, so writtenQuestions swept it in with the bio and every profile printed "If you selected "Ward commitment," state one numerical target and a deadline" under the candidate's biography — a prompt with no question attached, reading as a stray instruction to the candidate.

The CMS has no field marking a follow-up, so position is the only signal available: followUpQuestions takes, for each choice question, the textarea authored beneath it in the same step. Those leave the prose and travel on the answer, printing under the question that asked them with the prompt above the text — several of these answers are bare numbers ("12000") and mean nothing without it. Kept apart from explanation, which is reasoning nobody asked for.

Against live data: writtenQuestions now yields bio alone, and 26 answers carry a follow-up under performance_metric.

Faces on the questionnaire rows. The ward cards, the mayoral field and a candidate's own hero all print a portrait; the rows — the one list where a reader hunts for a single person among thirty — printed names alone. They now carry the plate, built from the roster the component is already handed, so no caller changed.

CandidatePortrait is that plate, extracted rather than copied a third time. The copies had drifted in the one way that matters: the sizes hint, which decides how large a file the browser fetches. It is now derived from the size.

We hold a photograph for 44 of Toronto's 388 registrants, so most rows are a monogram rather than a face. That is deliberate — a plate appearing only where there is a photo leaves names starting in two different places down one column, which reads as a fault in the page rather than a fact about the ballot. Measured: /mayor renders 256 photos against 192 monograms.

The disclosure is gone from profile pages. <details> earns its place on a page with a field in it — a ward's four respondents write a paragraph each, and thirty-three cards of paragraphs is the page the table replaced. A profile has one row per card and no split to read down, so the writing is the whole of what a card says and the control's only remaining use is hiding it.

printWriting prints it outright: no details, no summary, no icon. The icon's trailing 1rem column goes with it, which is what puts the answer against the card's right edge instead of a rem short of it, and the answer badge stops spanning a column that no longer exists when the row stacks on a narrow screen. The two grid templates are now named constants shared by the column heads and the rows beneath them, so they cannot disagree.

page	<details>	icons	grid
candidates/darrell-brown	0	0	2-column
wards/25	16	32	3-column
mayor	322	644	3-column
issues	0	0	n/a (bands)

Deliberately not done

• /issues gets no portraits. Its names come from the responses rather than the ballot and carry no image, so the map is empty and the page is untouched — the same reasoning as its existing notes={false}.
• The resident survey results page (AlignmentResults) takes its roster over a JSON API route at runtime; portraits there would mean changing that payload. It renders unchanged.
• MayoralCard and CouncilCandidate were refactored onto CandidatePortrait but do not render on any route I could reach — the ward pages use the questionnaire grid now, and CouncilCandidate is school-board-only. The markup is identical apart from the initials gaining aria-hidden (the name is always printed beside them), but that pair is unverified in a browser.

Verification

npx tsc --noEmit and npm run lint clean on every commit (4 pre-existing warnings elsewhere). Against the dev server: all 25 wards plus /, /survey, /issues, /mayor, /mayor/candidates and a candidate page return 200. Ward 5 (empty) shows the outline, ward 1 has no repeated footer, ward 17 shows the incumbent label on the 23 questions Shelley Carroll answered, /issues is unchanged.

npm run build fails at /tracker, which prerenders against localhost:3000/api/dashboard/.... Verified pre-existing on a clean tree — unrelated to this branch.

Not verified visually. No browser was available in any session on this branch, so every layout decision here is reasoned from the CSS and measured from rendered markup rather than seen. The container-query breakpoints, the answer-block tint, the icon alignment, the 220ms reveal, the 28px portrait in a compact row and the printed card's right edge all deserve a real look — /toronto/vote/2026/wards/17 is the richest page for the card, and /toronto/vote/2026/candidates/darrell-brown for section 6 (he is one of the ten respondents we hold a photograph for).

🤖 Generated with Claude Code

[greptile-apps]

This review was skipped because it would exceed your organization's monthly flex usage limit. Raise the limit in billing settings or wait until the next billing period resets limits.