Repository navigation
feat(dashboard): multi-question cards — render every question, submit one answers array #1451
Description
Drew (2026-10-27): "there should be a way to allow multiple questions." A card's question payload can carry several questions (the answer action's payload.answers[] already supports a list — the orchestrator consumes arrays). The dashboard UI must render one control per question on the card and submit them together as a single answer action with the full answers array; partial completion is allowed but the card shows which questions remain unanswered until all are answered (or the card is otherwise resolved). Acceptance: a fixture card with 3 questions renders 3 controls, one submit records one action with 3 answers, and the orchestrator's existing answer handling consumes it unchanged.
Acceptance criteria
- A card whose payload carries several questions renders one control per question.
- One submit records a single answer action carrying the full payload.answers array, consumable unchanged by the orchestrator's existing answer handling.
- Partial completion is allowed and the card shows which questions remain unanswered until all are answered or the card is otherwise resolved; the fixture case (3 questions → 3 controls → one action with 3 answers) passes.
Activity
developing-today commentedon Oct 27, 2026
CODE-532
dezren39 commentedon Oct 27, 2026
Intake review
Fleet monitor intake pass (protocol §5) — this issue was filed today (2026-10-27) from Drew's dashboard/orchestration requests via the orchestration pass and had no
priority/*label (and, where noted, no acceptance-criteria section).Live check: filed within the last hour; no merged PR or commit can have resolved it yet, and it is part of a deliberately filed set — not a duplicate. Cross-checked against the sibling filings from the same pass.
Related: Related: epic #1442; the comment affordance in #1446 is the sibling card affordance.
Notes: The body's acceptance is already precise (fixture card, 3 questions, one action, 3 answers); the appended section formalizes it.
Risks: Risk: partial-answer state must survive re-render — track per-question answered state on the card, not just in the submit payload.
Suggested approach: Suggested approach: render controls from the payload's question list, submit one answers array, leave orchestrator answer handling untouched (it already consumes arrays).
Labels normalized this pass: kind/enhancement, priority/normal, effort/s, status/needs-triage, source/human + meta/enriched.
dezren39 commentedon Oct 27, 2026
Shipped in PR #1470 (merged 2026-10-27T16:54:16Z), deployed to the laptop aggregator and verified live at content level through the tailscale serve address.
What landed: one control per question, a single answers[] submit; answers merge across submits on the card (latest per question wins), answered questions prefill with "✓ answered", and still-open required questions are marked "still needed". Boundary change, recorded on the PR: answers[] submits may be partial — the #1291 required-coverage rejection is retired for answers[] (unknown question ids and out-of-range option values still 400; a bare text answer still cannot bypass a survey). Acceptance fixture: the new suite renders a multi-question card, submits one answer action, and asserts the merged state.