Scoping note — Navigation graph (Cluster A: the severed nav)

Version. v0.1 Date. 2026-06-25 Author. Claude.ai (scoping), under Operator direction. Status. Scoping note. Frames the navigation-severance problem, surfaces the one intent-dependent decision, lays out three solutions, recommends one robust across the intent question. Precedes a Change Request. Not a Step 0 — the CR needs live grounding. No build authorized. Grounds on. CC surface audit (2026-06-25) and the Companion surface-coherence findings (loomworks-record investigations, e94d6f3), Cluster A. Seed v0.12 surface principles. This note scopes Cluster A alone; it flags where Cluster D and the in-engagement-commit affordance attach but does not fold them in.

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 that 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.

The problem, precisely

From CC's audit, stated as the structural fact:

• Two navigation systems. System A is the global nav bar (Dashboard, Inbox, Library, Spend, Engagement navigation, Companion trigger, user menu). System B is the per-surface sparse header (engagement-navigation's own header + Companion command bar; the in-engagement "← Back to engagement navigation" link).
• They do not cross-link. System B has no links to Dashboard/Inbox/Library/Spend (grep-confirmed). System A's bar is suppressed on the System B surfaces.
• The landing is on System B. Login → / → redirect to /operator/engagement-navigation. The global nav is hidden there.
• Result: a one-way island. System A → engagement-navigation works (the "Engagement navigation" tab). engagement-navigation → System A does not. A user who never types a URL cannot reach the dashboard family.

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 one decision that determines the fix

The right solution depends on a question the audit cannot answer — it is about intent, not code:

Are the two navigation systems meant to be separate, or is the split accidental?

Three possibilities, each implying a different fix:

1. The two systems are intentional (the sparse in-engagement header is a deliberate focus choice — inside an engagement, don't pull the eye toward global chrome; the engagement-navigation landing is the Companion-as-environment framing — you enter into your engagements, not a dashboard). → Fix is a crossing affordance: a way between the two systems, preserving both.
2. The landing is intentional but the severance is accidental (engagement-navigation-as-home is wanted, but the inability to escape it to the global pages is an oversight). → Fix is a path from System B into System A, keeping the landing.
3. The split is accidental (the two systems are an artifact of phase-by-phase building, never a decision). → Fix is unification: one nav everywhere.

What the seed gives us, and what it doesn't. Seed v0.12 commits to surface principles — "only show what is available," the four-room model, the Companion as the environment the user works inside. The Companion-as-environment framing leans toward the engagement-navigation landing being intentional (you enter into your work, not an admin dashboard). But the seed (as read this session) does not specify the navigation architecture or mandate the two-system split. The intent behind the split 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 at all.

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 the decisive signal: 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 the one robust across all three possibilities.

The three solutions

Solution 1 — Restore the crossing (recommended; robust across the intent question)

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 nav links in the sparse header).

• What the user gets: from anywhere on the nav-less side, a reliable way to reach the dashboard family. The island becomes two-way.
• Why robust: it fixes the thing that is definitely broken (you cannot get back) without betting on whether the two systems should be preserved or unified. If the two systems are intentional (possibility 1), this is exactly right — it adds the missing crossing. If the landing is intentional but the severance accidental (possibility 2), this is exactly right — it restores the path while keeping the landing. Only if the split is fully accidental (possibility 3) is this less than ideal — and even then it is not wrong, just less clean than full unification.
• Cost: low-to-moderate. Frontend nav work; no new pages, no backend. The global nav components already exist (System A) — the work is exposing a path to them from System B.
• Respects "only show what is available": the crossing affordance is always available (the dashboard family always exists), so no disabled-control concern.
• Risk: if the sparse header is a deliberate minimalism, adding a control to it must be done carefully so it does not clutter the focus surface. A single restrained affordance, not the full global bar transplanted.

Solution 2 — Change the landing

Make the post-auth landing a System A page (e.g. /dashboard) with a clear, prominent route into engagement-navigation.

• What the user gets: they start where the global nav exists; the island problem largely dissolves because the default entry is on the connected side.
• When this is right: if, on reflection, the Operator decides the dashboard (cross-engagement overview) is the better home than engagement-navigation — i.e. the landing choice itself was the mistake, not just the severance.
• Cost: low (change the redirect target) — but it is a product decision with real weight: it changes what every user sees first, and it cuts against the Companion-as-environment framing (entering into engagements vs. into a dashboard).
• Risk: reverses an intentional-seeming design (the engagement-navigation landing). Should not be done on convenience grounds alone — only if the Operator affirmatively prefers dashboard-as-home. Note: even with this, the in-engagement pages still need a path back to the global nav (they are also System B), so Solution 2 does not fully replace Solution 1 — it changes the entry but leaves the in-engagement severance.

Solution 3 — Unify the navigation

One navigation system across all surfaces — the global nav (or a single adapted nav) present everywhere, including engagement-navigation and in-engagement.

• What the user gets: total consistency; no two-system confusion; everything reachable from everywhere.
• When this is right: if the two-system split is confirmed accidental (possibility 3) — no deliberate reason for the sparse headers, just phase-by-phase drift.
• Cost: highest of the three. Touches every surface's chrome; must reconcile the in-engagement focus context with a global bar; risks the in-engagement workspace feeling cluttered if the sparse header was a deliberate focus choice.
• Risk: the biggest bet on intent. If the sparse in-engagement header is deliberate, unification destroys it. Should only be chosen if the Operator confirms the split is unwanted.

Recommendation

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 to be resolved first, and it does not foreclose the others: if the Operator later decides the landing should change (Solution 2) or the nav should unify (Solution 3), Solution 1's crossing affordance is compatible with both and is not wasted work.

Sequence the intent decision as a fast gate, not a blocker. Before the CR, the Operator answers one question: is engagement-navigation the intended home, and is the two-system split deliberate? If yes-and-yes → Solution 1 as scoped. If the Operator 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). If the split is unwanted → escalate to Solution 3. The recommended path is Solution 1; the alternatives are there for the Operator to pull toward if the intent points that way.

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.

What a CR for this would need (not done here)

Live grounding before the CR:

• The exact System B header components (engagement-navigation's header; the in-engagement LeftRail "← Back to engagement navigation") — where a crossing affordance attaches.
• The System A nav components (the global NavBar, AppShell) — what link/route targets the crossing affordance would use.
• The NAV_HIDDEN_ROUTES logic that suppresses System A on the System B surfaces — whether the crossing is best done by exposing global links in System B, or by adjusting the suppression so a minimal global affordance shows.
• The landing-redirect logic (/ → POST_AUTH_LANDING) — only if Solution 2 is pulled in.
• Frontend test placement for the new affordance, analogous to existing nav tests.

The CR should be drafted in a fresh chat with that grounding.

Where Cluster D and the in-engagement affordance attach (flagged, not folded)

Per the Operator's "Cluster A alone" scope, these are noted, not scoped here:

• In-engagement-commit affordance (scoping note 6eb2095): its gap is partly a symptom of Cluster A — the commit card is on the unreachable dashboard. Solution 1 makes the dashboard reachable, which reduces the urgency of in-engagement commit but does not remove its value (committing in-context is still better than navigating away). Resolve the two consistently: whatever crossing model Solution 1 lands, the in-engagement-commit affordance should fit it.
• /chat vs the Companion panel (Cluster D duplication question): interacts with the nav model — where the Companion lives is a navigation decision. Resolve after Solution 1 sets the nav structure.
• The Cluster D quick fixes (/settings/security link, /auth prod check) are independent of Cluster A and can proceed separately.

What this note does not decide

• The intent question (two systems deliberate? landing intended?) — surfaced as the fast gate; the Operator answers, possibly with a quick spec check.
• Which solution (1, 2, or 3) — default recommended is 1; the gate may pull toward 2 or 3.
• The exact form of the crossing affordance (home control vs. app menu vs. surfaced global links) — a CR design decision, against live components.
• Implementation specifics dependent on live tree-truth (deferred to the CR's Step 0).

DUNIN7 — Done In Seven LLC — Miami, Florida Scoping note — Navigation graph (Cluster A) — v0.1 — 2026-06-25