design: record the owner walkthrough backlog and its three rulings (session 0)

[guarzo]

A page-by-page walkthrough of every rendered surface, done with the project
owner against production screenshots. docs/design-walkthrough.md carries the
findings as seven self-contained sessions so each is startable from a cold
context. This PR is session 0 — the cross-cutting part the other six depend
on. Sessions 1-6 follow as separate PRs.

Why a new doc rather than more rows in the sweep backlog

The August 5 sweep was eighteen AI reviewers reading code. This was the person
who runs the tool saying what bothers him when he uses it. The doc cross
references both existing records rather than competing with them:

• SYNTHESIS.md item 7 (/payouts cannot answer "was I paid?") is open and
  appears in neither the worked chain nor the deferred list. It fell out of
  tracking. Re-verified against the current tree; filed as session 2.
• SYNTHESIS.md item 6 is already carried forward in SECOND-PASS.md;
  cross referenced, not restated.
• SYNTHESIS.md item 15 already shipped and is explicitly marked do-not-refile.

Three rulings

Recorded in DESIGN.md so a later sweep does not undo the work that follows.

R1 — hit targets. The 28px in-row grade is now scoped by the density
reason rather than by the tag it lands in, so a Disclosure as="row" drawer
takes the 36px standalone grade despite rendering a literal <tr>.

This resolves a contradiction rather than reversing a decision, which is the
part worth checking: e2e/sync.spec.ts:1095 has been pinning the /admin/sync
drawer to the standalone grade all along and passing, and
payouts/[id]/notes-form.tsx:90-95 reasons the same way for a panel field. Only
/admin/accounts read the settled-decisions row as forbidding the exception,
having inherited 28px by structural accident. That row is marked AMENDED
rather than deleted, per that file's own contract.

R2 — rare destructive controls do not hold permanent width in a scanning
table. Records the reveal-on-arm constraint from #112 as a reason to move
such controls, not to progressively disclose them where they currently sit.

R4 — information may not live only in the assistive-tech channel. Two
instances, both the inverse of the usual defect: a working role="status" save
confirmation marked .visually-hidden, and an affordance named in aria-label
and absent from the visible summary. This corrected one of my own findings
during review — the payout notes confirmation was reported as missing and is
actually just invisible, so the fix is to surface it, not to build it.

Copy

Removes the four em dashes from rendered strings. The glyph stays as this app's
null-value marker (error.tsx:239); only prose changed. Drops the /payouts
lede's first sentence, which restated its own table columns, promoting the
second, which routes to /account.

flat-pool-form's note label changed shape, so its 12 e2e/payouts.spec.ts
assertions move with it. That's the bulk of the diff line count.

One deferral, on evidence

The equivalent /account lede is deliberately left to session 3, filed as
3.1b. e2e/account.spec.ts:1583 uses it as the narrow-capped sibling that
proves the manifest opts out of the cap, and finding 3.1 changes what the
correct anchor should be. Deleting it here would mean editing that test twice.

Where to focus review

The settled-design-decisions.md amendment. If R1 is wrong, session 4 builds on
a bad premise, and the whole point of that file is that its rows are not
reopened casually.

Verification

Gate	Result
npm run typecheck	pass
npm run lint	pass
npm run format:check	pass
npm test	1290 passed, 83 files
npm run test:e2e	297 passed
npm run build	pass
scripts/check-node-version.sh	pass

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 57 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: e91baad8-2d3b-4131-bfc6-7ea0aa2347fb

📥 Commits

Reviewing files that changed from the base of the PR and between 7984c14 and 81e36f3.

📒 Files selected for processing (9)

• DESIGN.md
• docs/design-walkthrough.md
• docs/settled-design-decisions.md
• e2e/payouts.spec.ts
• src/app/admin/accounts/page.tsx
• src/app/login/page.tsx
• src/app/payouts/[id]/appraise-form.tsx
• src/app/payouts/[id]/flat-pool-form.tsx
• src/app/payouts/page.tsx

---

_{Comment @coderabbitai help to get the list of available commands.}