Version. v0.1 Date. 2026-06-25 Author. Claude.ai, under Operator direction. Status. Findings document. Surveys the Companion frontend surfaces for reachability, navigation consistency, and relevance. Organizes problems into clusters with recommended dispositions. Decides nothing; the Operator prioritizes. Not a Step 0 — CRs that follow need live grounding. Grounds on. CC read-only surface audit (2026-06-25): 16 page routes, two nav systems, reachability graph, Companion-panel inspection. Plus a confirming live-panel fidelity check (2026-06-25). This document organizes that audit; it does not re-inspect. Triggered by. Operator observation across seven screenshots: "menu options disappear, Companion panel is essentially useless, All Engagements cannot be reached… review all created pages for relevance and reachability."
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.
CC's exact characterization: a one-way island — System A nav → engagement-navigation works, but engagement-navigation → System A does not.
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 ("menu options disappear, All Engagements cannot be reached"). 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? That needs scoping against the seed's surface principles ("only show what is available," the room model, the Companion-as-environment framing), not a reflexive fix.
Recommended disposition. Scope first (a scoping note), then CR. This is the one cluster where getting the design right matters more than speed. Sub-finding worth deciding early: the post-auth landing choice 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 — a user would start where the global nav exists. Whether to change the landing, or to make engagement-navigation carry a path back, is the core design fork.
Connects to. The in-engagement-commit-affordance scoping note (filed this session, loomworks-record 6eb2095) — that note's gap is partly a symptom of this one: the commit affordance is on a hard-to-reach surface, so making it reachable in-engagement is more urgent than it first appeared.
What. The Companion side-panel (and the full-screen /chat, same ChatView component) is conversation-only. CC verified: 23 classifier intents, none navigational — no navigate/open/select/go-to/switch. So "open engagement," "navigate to engagement 5," "select e005" have no matching capability and are refused or answered unhelpfully. 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 it is 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. Giving the Companion navigation capability is not a copy tweak — it is 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 already in memory (classifier/persona have zero navigation awareness) and connects to the queued "Companion-as-Operator-system-interface" direction. This is a substantial arc, not a small CR.
Recommended disposition. Its own scoping effort, sequenced after or alongside A. Note: if A is solved well (a reachable global nav), B becomes less urgent (the user has a non-Companion path) but no less valuable (the Companion-as-interface vision wants it regardless). A first, B as a distinct deliberate arc.
What. The screenshot showed the panel saying "nothing saved" / "saved" — the 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 "nothing saved" text is an LLM reply, not a hardcoded string. A live check on the current engine (2026-06-25), 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 here so the question is not re-opened.
The "review all created pages for relevance and reachability" request, itemized. Each is 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 their passkey/recovery management by clicking). Disposition: 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. Disposition: relevance call — is saved-filter management still wanted as a standalone page, or has the Cross-cutting UI replaced it? If superseded, remove; if not, link it./chat vs the Companion panel — same ChatView rendered in two places; on desktop the panel is the entry and /chat is reached differently (mobile tab, engagement-navigation). Disposition: design question — is the standalone /chat route still needed, or is it duplication? Interacts with B (if the Companion gains navigation, where does it live)./inbox, /library) versus the engagement-scoped tabs in the in-engagement RightRail. Disposition: consolidation question — are both intended (global triage vs in-context view), or is one redundant? Likely both intended; worth an explicit decision so it's not accidental./admin/grants — orphaned from nav; admin, likely intentional. Disposition: confirm intentional, then leave./auth — dev-only session-mint helper that redirects to /. Disposition: confirm it's excluded from production (relevance flag, not a nav issue)./settings/security link and the /auth production check are small and independent. The relevance calls (/operator/filters, the Inbox/Library and /chat duplication questions) can fold into the A scoping, since they are all "what surfaces exist and how do they relate."This is 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.
DUNIN7 — Done In Seven LLC — Miami, Florida Findings — Companion surface coherence review — v0.1 — 2026-06-25