DUNIN7 · Loomworks · Scoping Note
Plain-language summary
When a user logs in, they land on the engagement-navigation page. That page — and the in-engagement pages — have no link to Dashboard, Inbox, Library, or Spend. Those four pages can only be reached by typing their URLs. So from the default landing, half the application is undiscoverable. The Operator experienced this directly: tried to reach those pages, couldn't, read it as "menu options disappear, All Engagements cannot be reached."
This note scopes the fix. There is one design question that must be answered first, because the right fix depends on it: are the two navigation systems intended to be separate, or is the split accidental? The note surfaces that question, then shows one solution is robust either way — restore a path from the nav-less side back to the global nav, without necessarily changing the landing or collapsing the two systems. That is the recommended default. The two alternatives (change the landing; unify the nav) are laid out with the trade-offs that would make one of them right instead.
/ → redirect to /operator/engagement-navigation. The global nav is hidden there.This strands shipped work. The CR-2026-121 held-commit card lives on /dashboard — a System A page, unreachable from the landing. The feature is built, tested, recorded, and a normal user cannot navigate to it.
The right solution depends on a question the audit cannot answer — it is about intent, not code:
The gate
Are the two navigation systems meant to be separate, or is the split accidental?
What the seed gives us, and what it doesn't. Seed v0.12 commits to surface principles — "only show what is available," the four rooms, the Companion as the environment the user works inside. The Companion-as-environment framing leans toward the engagement-navigation landing being intentional. But the seed (as read this session) does not specify the navigation architecture or mandate the two-system split. That intent likely lives in the architecture specification v0.4 or a design standing note — or, given phase-by-phase building, may never have been an explicit decision.
The evidence that resolves it enough to act. The Operator — who designed the landing — tried to reach the dashboard family and experienced the failure as a bug. That is decisive: the landing can be intentional while the inability to escape it is accidental. Those are not in tension. A deliberate "you land in your engagements" choice does not imply "and you can never get to your library." So whatever the intent behind the landing, the one-way severance is almost certainly not intended — the person who built it reads it as broken. This is why the recommended solution is robust across all three possibilities.
Give System B a persistent path into System A, without changing the landing or collapsing the two systems. Concretely: a stable affordance on engagement-navigation and the in-engagement header that reaches Dashboard/Inbox/Library/Spend (a "home"/global-nav control, an app menu, or surfacing the global links in the sparse header).
Make the post-auth landing a System A page (e.g. /dashboard) with a clear, prominent route into engagement-navigation.
One navigation system across all surfaces — the global nav (or a single adapted nav) present everywhere, including engagement-navigation and in-engagement.
Solution 1 as default — gate the intent decision, don't block on it
Solution 1 — restore the crossing — as the default, because it is the only one robust across the intent question. It fixes the definitely-broken thing (the one-way severance) without requiring the intent question resolved first, and it does not foreclose the others: if the Operator later changes the landing (Solution 2) or unifies the nav (Solution 3), Solution 1's crossing affordance is compatible with both and not wasted.
Sequence the intent decision as a fast gate. Before the CR, the Operator answers: is engagement-navigation the intended home, and is the two-system split deliberate? Yes-and-yes → Solution 1 as scoped. Prefers dashboard-as-home → add Solution 2's landing change on top of Solution 1 (the in-engagement severance still needs Solution 1's crossing regardless). Split unwanted → escalate to Solution 3.
Why not wait to confirm intent first: the design record may not have decided this (phase-by-phase building often sets a landing without documenting why), so a spec search could come back empty and stall the fix. Solution 1 is correct whether or not the intent is documented, because it repairs the severance the Operator already experiences as broken.
NavBar, AppShell) — what link/route targets the crossing would use.NAV_HIDDEN_ROUTES logic suppressing System A on System B surfaces — whether to expose global links in System B, or adjust suppression so a minimal global affordance shows./ → POST_AUTH_LANDING) — only if Solution 2 is pulled in.The CR should be drafted in a fresh chat with that grounding.
6eb2095): its gap is partly a symptom of Cluster A — the commit card is on the unreachable dashboard. Solution 1 makes the dashboard reachable, reducing the urgency of in-engagement commit but not its value (committing in-context is still better than navigating away). Resolve consistently: whatever crossing model Solution 1 lands, the in-engagement affordance should fit it./chat vs the Companion panel (Cluster D duplication): interacts with the nav model — where the Companion lives is a navigation decision. Resolve after Solution 1 sets the structure./settings/security link, /auth prod check): independent of Cluster A; can proceed separately.