From 50e91d87329f17583665e3c1543ef168cad94dfe Mon Sep 17 00:00:00 2001
From: Nexus Dev <nexus@local>
Date: Fri, 10 Apr 2026 17:40:53 +0000
Subject: [PATCH] fix(nexus): register missing board route roots for prefix
 classifier
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The company-aware router helper (applyCompanyPrefix / Link wrapper in
ui/src/lib/router.tsx) uses BOARD_ROUTE_ROOTS to tell the difference
between "this path is under /:companyPrefix/..." and "this is a raw
company prefix like /NEX." When a path segment isn't in BOARD_ROUTE_
ROOTS or GLOBAL_ROUTE_ROOTS, extractCompanyPrefixFromPath assumes
it's a company prefix and applyCompanyPrefix returns the path
unchanged instead of prepending the current company.

Every board route added in v1.5 (Personal Assistant) and v1.7
(Content Generation, Convert) was wired in App.tsx but never added
here. Sidebar's <SidebarNavItem to="/assistant"> therefore rendered
as /assistant (raw), the router treated "assistant" as a company
prefix, no company matched, and the user landed on the "Company not
found" 404 — this is how the /ASSISTANT/company/settings confusion
from the previous debug session was born: after the Layout
auto-recovery fix the broken link now redirects to /NEX/dashboard
but silently eats the Assistant navigation intent.

Added:
  - assistant     (v1.5 Personal Assistant)
  - content-studio (v1.7 Content Generation)
  - convert        (v1.7 Format Conversion)
  - plugins        (board-scoped PluginPage at /:prefix/plugins/:id)
  - tests          (dev-only /tests/ux/runs RunTranscriptUxLab)
  - settings       (LegacySettingsRedirect at /:prefix/settings, which
                    then redirects to /instance/settings/general)

Also added a block comment above the set explaining the invariant
so future additions to App.tsx's boardRoutes() don't drift out of
sync again. Existing company-routes.test.ts passes unchanged
(2/2 green).

Nothing in the sidebar / nav wiring changed — the Nexus v1.5 and
v1.7 pages were always correctly routed in App.tsx. They were just
unreachable via Link clicks because the prefix classifier lied about
what counted as a board route.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---
 ui/src/lib/company-routes.ts | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/ui/src/lib/company-routes.ts b/ui/src/lib/company-routes.ts
index 48d71ef2..0cd8c3a3 100644
--- a/ui/src/lib/company-routes.ts
+++ b/ui/src/lib/company-routes.ts
@@ -1,3 +1,11 @@
+// [nexus] Every path segment the router treats as a board route (rendered
+// under /:companyPrefix/*) must be listed here, otherwise
+// extractCompanyPrefixFromPath misclassifies it as a company prefix and
+// Link paths fail to get the prefix prepended. When a new board route is
+// added in App.tsx, add it here too. Missing this was the cause of the
+// Assistant link redirecting users to "/ASSISTANT" instead of
+// "/NEX/assistant" — Phase 33 (v1.5) and Phase 40+ (v1.7) introduced
+// routes without updating this set.
 const BOARD_ROUTE_ROOTS = new Set([
   "dashboard",
   "companies",
@@ -16,6 +24,15 @@ const BOARD_ROUTE_ROOTS = new Set([
   "activity",
   "inbox",
   "design-guide",
+  // v1.5 Nexus Personal Assistant
+  "assistant",
+  // v1.7 Content Generation
+  "content-studio",
+  "convert",
+  // Dev / internal tools also under the board scope
+  "plugins",
+  "tests",
+  "settings",
 ]);
 
 const GLOBAL_ROUTE_ROOTS = new Set(["auth", "invite", "board-claim", "cli-auth", "docs", "instance"]);