DUNIN7 · Loomworks · Findings
Plain-language summary
The Companion frontend has sixteen pages built across many phases, each in its own change request. Each works on its own. But nobody had checked whether they form a coherent, navigable whole — and they do not. The root problem: when a user logs in, they land on a page (engagement-navigation) that has no link to half the application. Dashboard, Inbox, Library, and Spend can only be reached by typing their URLs. A normal user who never edits the address bar cannot discover them.
This compounds with work shipped this session: the held-commit card built in CR-2026-121 lives on the Dashboard — one of the pages a user can't navigate to from where they land. The feature is built and correct, but a user can't reach it.
The Operator's observation decomposes into four distinct problems of different sizes: a severed navigation graph (the root, structural), a Companion side-panel that can't navigate and is hidden where it would help most (a capability gap), a stale-content artifact that turned out to be already fixed (no action), and a set of orphaned or duplicated pages needing a relevance call (a mix of quick fixes and design questions). This document lays out all four so the Operator can decide what to fix, what to remove, and in what order.
Sixteen page routes, split across two navigation systems that do not cross-link.
System A — the global navigation bar (Dashboard, Inbox, Library, Spend, Engagement navigation, Companion trigger, user menu). Appears on: dashboard, inbox, library, spend, settings, settings/security, chat, claim, admin/grants, create-engagement, filters.
System B — per-surface sparse headers, no global nav. Appears on: engagement-navigation (its own header + Companion command bar) and the in-engagement workspace (a single "← Back to engagement navigation" link). These are the two surfaces a user spends the most time on — and they have no path to System A.
The entry point lands on System B. Login → / → redirect to /operator/engagement-navigation, which is on the nav-less side. From there a user can reach individual engagements, create-engagement, and the full-screen chat — but not Dashboard, Inbox, Library, or Spend. The global nav only appears once a user is already on a System A page, which they can only reach by typing a URL.
What. Two nav systems that don't cross-link, and the post-auth landing is on the side that can't reach the other. Dashboard/Inbox/Library/Spend are URL-only from default entry.
Why it matters most. This is the structural root of the Operator's entire observation. It also strands this session's own work: the CR-2026-121 held-commit card is on /dashboard, unreachable from the landing. A user who logs in and stays on the default side experiences perhaps half the application as nonexistent.
Why it is not a quick patch. The two nav systems may be intentional — the sparse in-engagement header is plausibly a deliberate focus choice (when you are inside an engagement, you should not be visually pulled toward global chrome). Bolting the global nav onto every surface could violate that intent. The real question is a design one: should there be two systems, and if two, how does a user cross between them — a persistent affordance, a home/escape control, a unified nav, or something else? Scope against the seed's surface principles, not a reflexive fix.
Recommended disposition. Scope first (a scoping note), then CR. The one cluster where getting the design right matters more than speed. Sub-finding to decide early: the post-auth landing itself. If the landing were a System A page (e.g. dashboard) with a clear route into engagement-navigation, the island would be far less severe. Whether to change the landing, or give engagement-navigation a path back, is the core design fork.
Connects to. The in-engagement-commit-affordance scoping note (filed this session, 6eb2095) — that gap is partly a symptom of this one: the commit affordance is on a hard-to-reach surface.
What. The Companion side-panel (and full-screen /chat, same ChatView) is conversation-only. CC verified: 23 classifier intents, none navigational. So "open engagement," "navigate to engagement 5," "select e005" have no matching capability and are refused. Compounding it, the panel is suppressed on exactly the two surfaces (engagement-navigation, in-engagement) where navigation help would matter most.
Why it matters. This is the Operator's "Companion panel is essentially useless" — and the cruel irony of cluster A: the user can't navigate by nav (severed graph) and can't navigate by asking the Companion (no nav intents). Both paths to the dashboard family are closed. The panel that should be the escape hatch refuses to be one.
Why it is large. Navigation capability is not a copy tweak — new intents (navigate/select/open), a routing layer from intent to UI action, and a decision about how a conversational agent drives a frontend. CC notes this matches two open follow-ons in memory (classifier/persona have zero navigation awareness) and connects to the queued "Companion-as-Operator-system-interface" direction. A substantial arc, not a small CR.
Recommended disposition. Its own scoping effort, sequenced after A. If A is solved well, B becomes less urgent (the user has a non-Companion path) but no less valuable (the Companion-as-interface vision wants it regardless).
What. The screenshot showed the panel saying "nothing saved" / "saved" — old pre-CR-2026-122 fidelity language.
Disposition: closed, no action. Confirmed resolved. The panel uses operator_converse — the exact surface CR-2026-122 fixed. The text is an LLM reply, not a hardcoded string. A live check on the current engine, led toward the defect, returned corrected language: "still waiting on your okay… a draft — not in the record yet… say the word and I'll save it." The screenshot's content was captured before CR-2026-122 landed — stale, not a surface the fix missed. Recorded so the question is not re-opened.
The "review all created pages for relevance and reachability" request, itemized. Each flagged, not judged — the Operator decides keep / fix / remove.
/settings/security — no inbound link found; expected to be linked from /settings but isn't. Likely a real small bug (a user can't reach passkey/recovery management by clicking). Probably a quick fix (add the link), pending confirmation it's not linked elsewhere./operator/filters — orphaned, no inbound links; may be superseded by the engagement-navigation Cross-cutting filter UI. Relevance call — standalone page still wanted, or replaced? If superseded, remove; if not, link it./chat vs the Companion panel — same ChatView in two places. Design question — is the standalone route still needed, or duplication? Interacts with B./inbox, /library) vs the engagement-scoped tabs in the in-engagement RightRail. Consolidation question — both intended (global triage vs in-context), or one redundant? Likely both intended; worth an explicit decision./admin/grants — orphaned from nav; admin, likely intentional. Confirm intentional, then leave./auth — dev-only session-mint helper. Confirm excluded from production (relevance flag, not a nav issue).Suggested order — Operator decides
/settings/security link and /auth production check are small and independent. The relevance calls can fold into the A scoping, since they are all "what surfaces exist and how do they relate."Worth recording as a methodology observation. Every change request this session was vertical — one feature, built deep, tested, recorded. The work was sound. But coherence is a horizontal property — whether the surfaces reach each other, share navigation, and form a navigable whole — and no vertical CR was positioned to see it. The severed nav graph existed across many phases without being caught, because each phase was correct in isolation. The Operator's "review all created pages" instinct caught what feature-by-feature work structurally could not. A periodic horizontal survey — does the whole still cohere — is a discipline worth keeping, distinct from per-feature work.