#694 Render Long Answers Inline Like Every Other Answer Type

[cielbellerose]

Closes #694

Summary

• Long answers now render inline to the right of their question, aligned with every other answer type, instead of dropping into a stacked block below it.

Changes

• components/features/application-answers-list.tsx — removed isFullWidthAnswer and the row-level ternary; every row now uses the single px-4 py-3 sm:grid sm:grid-cols-[minmax(0,12rem)_minmax(0,1fr)] sm:gap-4 class. The long-answer <dd> keeps its max-w-prose text-sm leading-relaxed whitespace-pre-wrap treatment and gains break-words so an unbroken run of text wraps inside the narrower inline column instead of overflowing.
• components/features/application-answers-skeleton.tsx — the third skeleton row now uses the same grid-row shape as the other two (hoisted to a shared ANSWER_ROW_CLASS constant so the three rows can't drift), so the loading skeleton matches the resolved layout and nothing reflows on resolve.
• docs/WORKFLOWS.md — no change needed. The plan called for updating a sentence describing long answers as "full-width as prose," but that sentence was already removed by a prior merged ticket (Show Every Position Question On An Application And Align The Empty Answers Message #688), which replaced it with different wording about listing every live position question. Nothing in the current doc describes the old stacked layout, so there was nothing to update.

Testing plan

• Seed data (npm run prisma:seed), sign in as an applicant, start/continue an application on a position with long-answer questions.
• Paste three paragraphs (separated by blank lines) into one long answer, and a 250-character unbroken string (no spaces) into another; submit the application.
• As a manager/admin, open /manage/applications/[id]: confirm both Profile answers and Position answers show every answer type in one aligned label-value column, with no row dropping below its question.
• Confirm the multi-paragraph answer keeps its blank lines and reads comfortably in the inline column.
• Confirm the unbroken string wraps mid-word and the card has no horizontal scrollbar.
• As the applicant, open /applications/[id] (same component) and confirm the same two sections match.
• Check 375px / 768px / 1280px in both light and dark themes — 768px is the tightest value column (sidebar present), so the paragraph must still be readable there.
• Confirm mobile (< sm, e.g. 375px) is visually unchanged — the grid classes are sm:-prefixed so <dt>/<dd> still stack.
• Hard-reload each route and watch the skeleton → content transition: no row changes shape or height on resolve.
• A question with no answer still shows "No answer"; a long answer stored with multiple values still renders as chips.
• An empty answers list still shows the empty-state message.

Automated checks

• npm run prettier:check
• npm run eslint:check
• npm run tsc:check
• npm run test:unit (386 passed; npm run test requires Postgres, unavailable in this worktree — the one skipped suite, email-delivery-events.test.ts, fails only on DATABASE_URL at import time and is unrelated to this change)

Notes

• No schema, server action, or data-fetch change. AnswerDisplay, AnswerCard, and the applicant-facing stepper are untouched, per the ticket's non-goals.
• No automated test exists for this component (tests are unit/db only per repo convention) — verification is the manual pass above.
• If the 768px column reads too tight in review, the fix per the plan is a responsive label-track width, not reinstating the stacked row (which would change every answer type's layout and is out of scope here).

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
aplio	Ready	Preview	Sep 11, 2026 9:12pm UTC

[cielbellerose]

Code Review — Cycle 1 · needs revision

1 open — 1 🟠 Medium (see inline)

R1-M1 🟠 Medium — docs/WORKFLOWS.md was not updated despite the PR body's claim. Both entries the plan explicitly called out still read "long answers full-width as prose" after this change, which now renders long answers inline like every other type:

• aplio/docs/WORKFLOWS.md

  Line 306 in 03bf65e

  - **Happy path** — `getMyApplications(user.id)` returns the caller's non-deleted applications on published positions, ordered by `submittedAt` (not `updatedAt` — [XC-8](#xc-8-applicant-facing-status-grouping)). The table sorts client-side by position, status or applied date, and collapses to stacked cards below `md`. Each row links to the detail page and carries its primary action and row action. Every status shown is the public one — `reached_out`/`interview_scheduled`/`reviewing` all read as **Applied**.

• aplio/docs/WORKFLOWS.md

  Line 477 in 03bf65e

  - **Failure / edge**

The PR body states this doc needed no change because the "full-width as prose" sentence "was already removed by a prior merged ticket (#688)" — that's not accurate: git blame shows both lines were last touched by #688-era commits (2026-08-28 and 2026-09-04) and both still contain the exact phrase verbatim today. CLAUDE.md requires updating the affected WORKFLOWS.md entry in the same PR as a user-facing flow change; this PR changes the rendering of long answers on both /applications/[id] and /manage/applications/[id] but leaves the doc describing the old stacked/full-width behavior. Fix: update both sentences (e.g. "long answers in a label-value row like every other type") in this PR.

[cielbellerose]

Cockpit note — R1-M1 is a false positive, caused by a stale checkout

R1-M1 should be dismissed. It reports that docs/WORKFLOWS.md lines 306
and 477 "still read long answers full-width as prose verbatim". That text
does not exist on this PR.

Verified against this PR's own head commit (03bf65e7):

$ git show 03bf65e7:docs/WORKFLOWS.md | rg -c -i "full.width as prose"
0

$ git show 03bf65e7:docs/WORKFLOWS.md | sed -n '306p;477p'
- **Happy path** — `getMyApplications(user.id)` returns the caller's non-deleted …
- **Failure / edge**

Zero occurrences, and lines 306/477 hold unrelated content.

Where the phantom came from. That sentence did exist — at commit
1e8bc89, which is what the base repo had checked out. That checkout was 49
commits behind origin/dev, and #688 (merged as PR #701) had already
replaced the wording. So:

"full-width as prose" @ 1e8bc89 (stale local checkout) → 2 matches
"full-width as prose" @ origin/dev and @ PR head       → 0 matches

The implementing agent's claim in the PR body was correct; the review
contradicted it by reading the stale working tree rather than the PR head.

Root cause, worth fixing in the pipeline. The review stage reads the diff
accurately (its description of the code change is right), but evaluates
files not in the diff against whatever the local checkout happens to
contain. Any finding about an untouched file is therefore only as fresh as the
base repo. The same defect produced a stale reference in this ticket's plan,
which is what triggered this whole chain.

The base repo has now been fast-forwarded to origin/dev, so a re-review reads
current content. The durable fix is for plan-agent and review-agent to read
from origin/dev (or work in a fetched worktree, as impl-agent already
does).

No WORKFLOWS.md change is required for this PR. The file no longer
describes long-answer layout at all, so there is nothing stale to correct.

Re-reviewing rather than approving over the top of the verdict — run-build-check,
Analyze, and run-test-check were all still pending when cycle 1 ran, so the
next cycle also gets a complete CI picture.

[cielbellerose]

Code Review — Cycle 2 · approved

0 open — clean