feat(account): collapse the character manifest to one status chip per row

[guarzo]

Pull request

What changed and why

PR #162 merged six manifest columns into four to fix horizontal crowding at 10+
characters. It fixed that and made the original complaint worse: the STATUS cell
stacked three .status-line rows and the name cell gained a location line, so a
row that was one line tall became three. At ten characters the manifest went from
~10 lines of vertical space to ~30 — on a page whose stated problem was crowding.

The three lines almost always read ok / ok / on. The page was spending its
scarcest resource on saying nothing was wrong.

The rule: a row shows detail only when the member can act on it.

• src/core/account-health.ts exports classifyCharacter, a three-way
  attention / stalled / ok taxonomy built from the needsAttention and
  isStalled predicates that were already there and stay private.
  computeAccountHealth now calls it too, so the row rendering and the
  account-level verdict cannot drift into two taxonomies. One exported classifier
  rather than two exported booleans, so callers cannot invent a fourth
  combination. No new imports — src/core/ purity is preserved.

• The STATUS cell collapses to one chip for ok and stalled rows, and
  expands to detail lines only for attention. This is static, not a
  disclosure: no click, no client component, the manifest stays a server
  component. A stalled character keeps its own chip — sync disabled,
  sync failed — and is never shown a green ok it hasn't earned.

• formatLocation stops printing the system name twice. EVE dock names
  already contain their system (an NPC station is <celestial> - <name> where
  the celestial begins with the system name, and players name structures after
  the hole they live in), so ${system} — ${dock} rendered
  Jita — Jita IV - Moon 4 - Caldari Navy Assembly Plant. Taking the dock's last
  - segment gives Jita — Caldari Navy Assembly Plant. The system stays
  because a J-code is the operationally useful half.

• last seen leaves the visible string and moves to a .visually-hidden
  span, since the existing .dim treatment already carries "true, but not now"
  visually. This is the one place here where sighted users get less text than
  screen-reader users, and it is deliberate.

Net effect: roughly three lines per character down to two.

The one-line layout was measured and rejected

The design proposed putting name and location on one line, and gated it on
measurement because the name column sets the manifest's width — spending
horizontal budget in exactly the column #162 was compressing. The gate resolved
against it. At the 320px narrowest supported viewport, a flex row forced 413px of
horizontal scroll against a 286px-wide scroll region, versus ~146px stacked:
close to a full extra screen of blind scrolling to reach the STATUS and ACTIONS
columns a member came for. .char-line is therefore a stacked grid, and
e2e/account.spec.ts pins the measurement that forced the call so a future
change cannot reintroduce the flex row without re-checking it.

Accessibility

The collapsed row must not fix a sighted-density problem by taking information
away from screen-reader users, which would invert the work in #137, #150, #159
and #162.

• A collapsed chip never overstates health — ok is shown only for the ok
  state.
• The chip's accessible name carries all three facts (token, standings, map), so
  a screen-reader user hears what a sighted user read across three lines. This is
  how map: off stays reachable while the chip reads ok.
• aria-describedby stays gated on hasContactRemedy, now deliberately a
  different predicate from the expand rule rather than accidentally the same one.
• The <caption> is updated; it described a STATUS column that always showed
  three states, which is now false for most rows.

What CI cannot check

Nothing beyond CI for the logic. The layout decision rests on a measurement CI
now runs as a test rather than on a screenshot:

e2e/account.spec.ts — maxScrollLeft at 320px viewport
  flex row (rejected):  413px forced scroll
  stacked (shipped):   ~146px
  scroll region width:  286px
  gate threshold:       250px

That test asserts the location actually rendered on the row it measures and
floors maxScrollLeft above zero, so a broken seed fails loudly instead of
passing under the ceiling.

Deploy notes

None. No schema change, no migration, no new secret, no fly.toml change.

Flags

• map: off renders a plain ok chip. This is the one place the design
  shows a green chip over a false-ish fact, and it is deliberate: there is
  nothing a member can do about map membership from this page, and
  src/core/account-health.ts:27-35 already excludes it from the account verdict
  because wanderer_acl_observation is a delete-and-replace snapshot — "off the
  ACL legitimately" and "job never ran" are the same absent row. A chip reporting
  it as a fault would raise an alarm it cannot substantiate for every member with
  an off-map alt. The fact stays readable in the chip's accessible name.

• A player structure with an internal - (e.g. "Home - Refinery") loses
  its first segment. Accepted cost of a rule with no special cases.

• Two deferred Minors, both judged non-blocking. (1) The — not managed /
  not yet run copy is duplicated between standingsSummary and
  contact-state.tsx; it can only drift for two cases that never render
  ContactState on a collapsed row. (2) .char-line duplicates .stack
  exactly and no selector references it — kept because the comment above it is
  the only committed home for the measurement that forced the fallback, written
  for whoever retries the flex row.

• Out of scope, unchanged: the admin members drawer's layout. It renders
  CharacterLocation too, so the location text change reaches it — intended,
  since the redundancy was the same there.

[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: 20 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: d20c452c-6459-4b0f-ab43-a53601b071a7

📥 Commits

Reviewing files that changed from the base of the PR and between e9ff584 and 18ba3e5.

📒 Files selected for processing (11)

• e2e/account.spec.ts
• e2e/geometry.ts
• e2e/location.spec.ts
• src/app/_components/character-location.tsx
• src/app/account/contact-state.tsx
• src/app/account/page.tsx
• src/app/globals.css
• src/core/account-health.ts
• src/core/location.ts
• tests/account-health.test.ts
• tests/location-format.test.ts

---

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