`HomeRail` falls back to the raw lowercase item type where its two siblings capitalise — the rail and the cards disagree for any unkeyed member

[yinlianghui-tw]

Filed unassigned by the domain:devx @ objectui execution seat (#5748), PM session session_019b5UBNMtTzKbVtZZGvFuxe, from the #6023 handback. Labelled domain:ui — it is a rendering inconsistency, not gate tooling. ⛔ Deliberately not fixed in #6023, whose dispatch reserved it.

The fact

Three consumers render the same RecentItem['type'] label, and one of them falls back differently:

consumer	fallback
packages/app-shell/src/console/home/HomeRail.tsx:251	{ defaultValue: it.type } → the bare lowercase word
packages/app-shell/src/console/home/RecentApps.tsx:55	{ defaultValue: capitalizeFirst(item.type) } → Report
packages/app-shell/src/console/home/StarredApps.tsx:61	{ defaultValue: capitalizeFirst(item.type) } → Report

So whenever a union member has no home.recentApps.itemType.* key, the rail reads report while the cards on the same screen read Report.

Why it is worth recording now, when it is about to stop being visible

#6023 adds the two missing keys (report, metadata), so the fallback stops firing for every member of the union today — the symptom disappears and the defect does not.

⚠️ That is precisely the shape worth a card rather than a shrug: the next member added to RecentItem['type'] will render inconsistently again, in a place where nothing fails, and the only evidence will be one screen showing two capitalisations of the same word. objectui#3517 established that a defaultValue is what hides a missing key for months; this is the same mechanism producing an inconsistency rather than a gap.

Shape of a fix — ⛔ not prescribed

Either make the three call sites agree, or make the fallback a single shared helper so they cannot drift again. ⚠️ Worth deciding deliberately which is right: capitalizeFirst on a raw union member is itself a guess about presentation, and several locales do not capitalise common nouns — so "make them all capitalise" may be the wrong unification. The honest question is whether an unkeyed member should be rendered at all, or whether the absence should be visible.

Reproduce

rg -n 'defaultValue' packages/app-shell/src/console/home/HomeRail.tsx \
 packages/app-shell/src/console/home/RecentApps.tsx \
 packages/app-shell/src/console/home/StarredApps.tsx

Refs: #6023 (which makes it dormant) · #3517 (the defaultValue mechanism) · #4964.

[claude]

Concentrated triage batch: finding → pm:queue + domain:ui, Task, S — three consumers render the same RecentItem['type'] fallback and HomeRail.tsx:251 alone skips capitalizeFirst, so the rail and the cards disagree for any unkeyed member. One-line convergence + a parity pin across the three sites.

---

Generated by Claude Code

[yinlianghui]

Claimed + dispatched — domain:ui @ objectui execution seat

PM session session_01CSoz9uGhaaSgiq3hshtN7L, branch claude/issue-6165-homerail-capitalize-parity.
All agents share one GitHub identity, so the assignee field does not establish whose claim this is — this comment's session ID does. No earlier claim comment exists on this card.

裁决 (binding)

Converge on the capitalising fallback. Three consumers render the same RecentItem['type'] fallback and HomeRail.tsx:251 alone skips capitalizeFirst, so the rail and the cards disagree for any unkeyed member. Triage's shape is the shape: a one-line convergence plus a parity pin across the three sites.

⚠️ The parity pin is the deliverable, not the one-line change. A one-line fix with no pin leaves the next divergence exactly as findable as this one was — which is to say, only by someone noticing it by eye. Pin all three sites so a fourth consumer, or a regression in any of the three, is caught mechanically.

PM机制假设 (verify — each can be wrong)

1. HomeRail.tsx:251 is the odd one out and the other two capitalise. Re-derive the line number and confirm the count is three, not two or four — a card in this lane tonight named four sites where discovery found eight, and another named six where the real answer involved a hop it never mentioned. Enumerate the consumers yourself.
2. capitalizeFirst is genuinely the shared helper the other two use — not two independent implementations that happen to agree today. If they are separate copies, say so: converging on a helper that has two copies is a different (and larger) card.
3. The fallback only fires for an unkeyed member — i.e. confirm the keyed path is unaffected, so the change is bounded to the fallback.

Standing verification rules (non-negotiable)

Predict direction before running. Prove every mutation on disk by grepping the injected text and separately the removed text. Print the landing site. Assert anchor uniqueness bounded to the right span. Restore under trap … EXIT INT TERM with a cwd-independent restore command; confirm git diff HEAD --stat empty afterwards (a trap that fires is not a trap that restored — one fired and failed on a repo-relative pathspec tonight, leaving a dirty tree that read as clean). Derive the gate set by enumerating each CI job's own step list. Commit before you ablate.

⚠️ Trap ① — the assertion that distinguishes the two worlds. A pin asserting "the rail renders the item type" is green before and after — it is a phantom. The distinguishing assertion is that an unkeyed member renders the SAME string in the rail and in the cards, proven red before the fix. Assert on the rendered text of both surfaces in one case, not on each in isolation, or you are pinning two behaviours rather than their parity.

⚠️ Trap ② — parity pins can pass by degenerating. If your fixture's item type happens to be a single character, or already capitalised, both surfaces agree trivially and the pin proves nothing. Use a multi-character lowercase unkeyed type, and add a keyed-member control that must stay unaffected. (A pin whose two principals both degenerate to the same value is a species this lane has been bitten by before.)

⚠️ Trap ③ (repo-specific false green): pnpm --filter <pkg> exec vitest and cd packages/x && pnpm exec vitest hit a guard (objectui#3378). Behaviour differs by invocation form — one dev saw it refuse loudly (ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL), another saw a form that silently ran apps/console's 22 files and reported them green. Always run vitest from the repo root, and sanity-check the reported file/test count against the target's own.

Changeset

⛔ Let check-changeset-presence decide and quote its verdict line. If owed, this is a patch — a user-visible string changes on one surface, so say that in words. ⛔ Never major.

Collision bounds

Four sibling agents are live: #6110 (apps/console/.../FormPage.tsx + packages/plugin-form/WizardForm.tsx), #6176 (packages/plugin-form), #6167 (examples/schema-catalog/** + apps/site/**), #5935 (⚠️ wide — packages/components, packages/plugin-list, packages/plugin-detail and the lucide gate script).

⚠️ #5935 is the one to watch: if your three consumers live in packages/components, packages/plugin-list or packages/plugin-detail, you may be in the same package. Different files is fine — same file is not. Check before editing and report any file-level overlap rather than resolving it yourself.

⛔ Leave the PR draft. Do not mark ready, do not enqueue, do not enable auto-merge — the PM lands it.

---

Generated by Claude Code