observation: UnifiedSidebar 的 nav-order/pin 存储键在 home 上下文解析成「第一个 app」，|| 'home' 兜底实际不可达

越界发现，记录于 #3609 / PR #3630（把 /home 的 Administration 组改由 NavigationRenderer 渲染）期间。按纪律只报不改，单独立单，未认领。

观察类（observation-class）：今天没有用户会碰到，是休眠代码 + 一处不可达兜底。标 finding，不入队，留给 PM 分诊定级。

实测基线：origin/main @ 8d5418e59。

观察

packages/app-shell/src/layout/UnifiedSidebar.tsx：

const activeApp = matchAppBySegment(apps.filter(a => a.active !== false), activeAppName || currentAppName) || activeApps[0];
…
const { applyOrder, handleReorder } = useNavOrder(activeApp?.name || 'home');

useNavOrder(appName) 把顺序存进 objectui-nav-order-${appName}。两点：

|| 'home' 这个兜底不可达（对结果的消费者而言）。 applyOrder/applyPins 的产物只经 processedNavigation 流向 app 分支的 NavigationRenderer。而 app 分支的渲染条件正是 context === 'app' && activeApp —— activeApp 为空时这条分支根本不渲染。所以凡是用到排序结果的时刻，activeApp?.name 必然有值，字面量 'home' 永远不会成为存储键。它读起来像「home 上下文有自己的一套排序」，其实没有。
真要用起来，键是错的。 home 上下文里 activeApp 会解析成 activeApps[0] —— 部署里第一个 app，而不是 home。所以一旦有人给 home 分支接上 enablePinning / enableReorder（PR fix(app-shell): /home 的 Administration 组改由 NavigationRenderer 渲染，9 个系统管理入口恢复可达 (#3609) #3630 特意没有接，理由写在调用点注释里），home 导航就会去吃那个 app 存下的 __root__ 根排序；换个 app 排到第一位，home 侧栏的顺序跟着变。

换句话说：当前是「不可达的兜底」，接通之后是「跨上下文串键」。两种状态都不对，只是前者没有症状。

为什么现在只记录

/home 的导航是内建的固定簇（Home / Documentation + 管理员的 9 项 Administration 组），不是用户可编排的元数据；要不要让它可拖排、可 pin，是独立的产品决定，不属于 #3609「把组展开」的范围。#3630 因此维持现状并把理由写进注释，避免下一个人以为是遗漏而顺手接上。

可能的方向（留给分诊）

若结论是 home 导航不该可排序/可 pin：把 useNavOrder(...) 的调用挪进只有 app 分支才求值的位置，删掉误导性的 || 'home'，让「app 专属」在代码里显形；
若结论是该可排序：存储键必须按上下文取（context === 'app' ? activeApp?.name : 'home'），而不是按 activeApp，否则就是上面第 2 条。

关联

console: /home 的 Administration 组被压平成一条指向 /home 的死链——整簇 9 个系统管理入口在参考 console 上不可达 #3609 / PR fix(app-shell): /home 的 Administration 组改由 NavigationRenderer 渲染，9 个系统管理入口恢复可达 (#3609) #3630 —— 发现现场；该 PR 刻意不接 pin/reorder，注释里已写明本条。

已就关键词（useNavOrder / objectui-nav-order / UnifiedSidebar + storage key / sidebar nav order pin）搜过本仓开放 issue 与 PR，无同源单。

Generated by Claude Code

Findings triage (#4949 discipline) — first grading of this card. Verdict: HOLD. finding retained.

Stale-premise check — re-measured on origin/main (0cf8f0f) from the fetched ref, not the shared worktree. The card was filed against 8d5418e59 and both halves still hold:

packages/app-shell/src/layout/UnifiedSidebar.tsx:201 — const { applyOrder, handleReorder } = useNavOrder(activeApp?.name || 'home'); — present verbatim;
the app-branch render condition context === 'app' && activeApp is at :452, with the same pairing at :370 / :371, so the unreachability argument is intact: every consumer of the ordering result is inside a branch that requires activeApp to be truthy, therefore the 'home' literal can never become a storage key;
enablePinning={!isMobile} sits at :524, inside that same app branch — the home branch still does not wire it, as fix(app-shell): /home 的 Administration 组改由 NavigationRenderer 渲染，9 个系统管理入口恢复可达 (#3609) #3630 intended;
and the reasoning survives in-tree at :638 / :644, where the comment quotes both useNavOrder(activeApp?.name || 'home') and the branch condition. That comment is the reason this card is a finding rather than a trap: the next reader is warned in the file itself.

Why hold rather than promote. The card's two repair directions are not two ways to do one thing — they are the two outcomes of an unmade product decision (should /home navigation be user-reorderable and pinnable at all?), and they point in opposite directions in the same file. Direction 1 deletes the fallback and moves the hook inside the app branch; direction 2 keeps it and makes the key context-derived (context === 'app' ? activeApp?.name : 'home'). Queueing this today would hand a dev a card whose acceptance criteria depend on an answer nobody has given, and the tempting "just delete the dead fallback" reading is the one that quietly forecloses direction 2.

Why not needs-user-decision either. Nothing is broken and nothing is asked of the maintainer yet: today's state is symptom-free dormant code behind an accurate comment. Escalating a question whose answer only matters if someone decides to build the feature would put a null decision in the inbox. The moment that changes is written into the restart conditions.

Why not close as not-planned. The second half is a real latent defect, not cosmetics: in the home context activeApp resolves to activeApps[0] — whichever app happens to sort first in the deployment — so wiring pin/reorder onto the home branch makes home navigation read and write another app's __root__ ordering, and re-ordering the app list silently changes the home sidebar. That is cross-context key bleed with a user-visible symptom, and it is one line of wiring away.

Restart conditions — any one promotes this to pm:queue:

Anyone wires enablePinning / enableReorder onto the home branch — at that instant the dormant bug becomes live, and the storage key must be fixed in the same PR, not after it. This is the condition to watch: it is a one-line change that looks like an obvious omission, which is exactly why fix(app-shell): /home 的 Administration 组改由 NavigationRenderer 渲染，9 个系统管理入口恢复可达 (#3609) #3630 left a comment at :638–:644 instead of a silence.
A ruling that home navigation stays fixed (not user-orderable) — then direction 1 is unambiguous and this promotes as a small cleanup: move useNavOrder(...) where only the app branch evaluates it and drop the misleading || 'home', so "app-only" is visible in the code rather than only in a comment.
A second context gains a sidebar with the same hook shape — the bug generalises beyond home and the ceiling argument for holding disappears.

No domain:* — objectui is a whole-repo seat. Not a transfer: single file in packages/app-shell, no packages/spec face, not cross-repo.

Dedup — this repo and both siblings, open issues and PRs, on useNavOrder, objectui-nav-order, UnifiedSidebar storage key, sidebar nav order / pin. No duplicate; #3609 / PR #3630 is the discovery site and the only related card.