Repository navigation
Primary environments silently discard additional connection routes #286
Description
What: Desktop and served-web primary environments cannot retain extra connection routes, blocking the requirement that every client hold LAN, tailnet and T3 Connect to every server.
Why: Platform ownership of the server's environment ID silently skips registration and learning, removes persisted registrations, and hides route management, while pairing can still report success.
So what: The planner needs to assign the product fix and its design; the LAN exposure task records server reachability separately and does not claim complete client fallback.
Outcome and acceptance
- A desktop's own server and a served web client's primary environment can retain the required connection routes through supported product flows, with visible membership, ordering and active-route status.
- A saved route update to a platform-owned ID either takes effect and survives reconciliation/relaunch, or returns an explicit supported error. Pairing must not report "Backend added" when registration was discarded.
- Authentication remains required and credentials remain scoped to the destination environment; native desktop bootstrap behavior and normal remote environment routing remain covered.
- Prove actual persistence, route preference and fallback in the relevant clients, including web origin/security constraints. Do not weaken mixed-content protection to make an HTTPS page consume HTTP LAN endpoints.
- Any implementation follows the task's exact-head
review/independent-solandreview/independent-groksuccess gates before merge.
Source reproduction and cause
Independently audited source at d2914354e17977f044ed5a1a89803a231ea91e6d; the decisive guards remain in current main bcc4db86b85a841d21f6772c5c91129bcd1d29cc. This is source-path evidence, not a completed GUI reproduction.
apps/web/src/connection/platform.ts:353registers the discovered local server using its descriptor's environment ID.packages/client-runtime/src/connection/onboarding.ts:136uses that same environment ID for another pairing URL; its URL affects the connection ID, not environment identity.packages/client-runtime/src/connection/registry.ts:563returns without registering an ID inplatformEnvironmentIds; at:683platform reconciliation removes an existing saved registration with that ID.registry.ts:899skips learned routes for platform-owned IDs.routes.ts:230also cannot borrow a bearer credential fromPrimaryConnectionTarget. Reordering resolves through a user-entry guard that rejects a platform-owned entry.ConnectionsSettings.tsx:2126excludes primary entries from saved environment rows;CloudEnvironmentConnectList.tsx:205excludes them from relay discovery.ConnectionsSettings.tsx:2722can nevertheless toast "Backend added" after the silently skipped registration.- Opening a LAN pairing URL for a served web environment establishes that origin's cookie-authenticated primary environment. Browser catalogs are origin-local (
apps/web/src/connection/storage.ts:423), so this alone does not preserve a tailnet-origin catalog and T3 Connect fallback.
Normal nonprimary route registration already supports ordered routes and advertised LAN/tailnet learning. Learning does not create the T3 Connect route itself.
Upstream search
Upstream merged multi-route support #15467 and learned routes #15468. The same platform-owned registration exclusion remains on upstream main registry.ts. Bounded source/Issue/PR searches in both repositories found no exact primary-route fix; similar general multi-route work does not resolve the guard.
Non-goals and blockers
No raw encrypted catalog surgery, new server against live userdata, credential weakening or unrelated headless API implementation. Headless cross-machine control has an existing owner in #164; this record does not change that design or assign its scope. Product design/owner assignment and an integrated primary-client proof remain outstanding. The operations task's server exposure changes cannot resolve this state-ownership gap.
Contribution to the Objective
Reliable client connections let the user operate Chromeria's agents across machines during an internet outage, supporting the Promachos working in Chromeria without changing Project Direction.
Requirements and who asked: User's 2026-10-14 decision requires every client, with no own-server exception, to retain LAN first, tailnet second and T3 Connect last for every server.
Deleted: Extra pairing addresses as a workaround for the same environment ID, raw catalog writes, duplicate servers, unsafe mixed-content changes and a competing headless API design.
Bottleneck: The registry's platform-owned environment boundary prevents persistence and route management before network preference can be proved.
Checked myself: Traced environment/connection IDs, registration and reconciliation guards, learning, UI filtering and success reporting; compared the independent audit to current main and upstream records.
Activity
lukemaj commentedon Oct 14, 2026
What: The LAN-first implementation task is advancing the primary-route defect with a concrete design and independent assessment.
Why: Servers are reachable, but platform-owned client state still prevents the required three-route catalog for primary environments.
So what: The task will establish the smallest compatible repair and its proof boundary; the separate deploy owner handles rocky's restart and managed HTTPS activation, and physical client steps remain on #292.
The planner's current instruction is to continue headless client proof and advance #286, without another rocky restart. Current product base is
8f939c24ea898e7600c9c93892cb3ad63ad88686; no product files have been changed by this task. Design/source assessment and headless runtime evidence are independent coverage slices, with no shared machine or repository writes. The implementation and required Sol/Grok exact-head reviews remain unclaimed until a concrete candidate exists.Requirements and who asked: User requires every client, including a desktop's own server and existing served-web clients, to retain LAN then Tailscale then T3 Connect to every server, with unchanged authentication; the planner now asks this task to advance #286 and headless proof.
Deleted: Another rocky restart, an own-server exception, raw encrypted-catalog editing, unsafe mixed-content changes, a competing headless API and new live credentials where an existing read session suffices.
Bottleneck: Primary catalog ownership/authentication and its product route editor, plus a supported way to observe the installed client state; listener and Mac firewall availability are already proved.
Checked myself: Re-fetched #286 and #292, checked current main and its intervening diff, retained exact independent runbook proof and the existing public client/runtime seams. Next deciding evidence is a source-backed design that accounts for primary bootstrap, saved credentials, browser origins and all three clients, assessed independently before implementation.
lukemaj commentedon Oct 14, 2026
What: Current source explicitly treats a primary registration as replacing and deleting saved routes for that environment.
Why: Platform ownership and route ownership are coupled; removing one registration guard would leave reconciliation, persistence, learning and route controls inconsistent.
So what: The task is preparing a faithful public-registry reproduction in an exclusive workspace while the independent design and headless evidence slices finish.
Source checked at
8f939c24ea898e7600c9c93892cb3ad63ad88686: the existingregistry.test.tsprimary-precedence case expects persisted routes to disappear and later relay registration to remain ignored. The resolver separately supports a desktop primary bearer capability and a served-browser same-origin cookie path; the route-learning helper currently accepts only bearer or relay credentials. Those paths need different authentication handling, not a cookie copied to another origin. This is source evidence; no new baseline test execution is yet claimed.Continuation workspace is planned at
/home/luke/dev/toolboxmd/chromeria-worktrees/286-primary-connection-routes, branchfix/286-primary-connection-routes, exact starting base8f939c24ea898e7600c9c93892cb3ad63ad88686. The canonical main checkout and its unrelated untracked files remain untouched. The app-owned worktree handoff will establish the actual binding; no product edits, PR, reviews, merge or deployment exist yet. Product package versions stay unchanged under project policy.The design child is read-only and owns no implementation files. The headless proof child is read-only on shared machines and must not interfere with the separate deploy owner. Their completion state and results remain in app-owned delegation records. Parent acceptance requires inspection of their cited source/live evidence; partial proof cannot stand in for a saved catalog or fallback observation. Recovery starts from #286 and parent #292, then continues with the public registry reproduction, concrete design assessment and only the authorized repair.
lukemaj commentedon Oct 14, 2026
What: Extra routes for primary environments are no longer planned.
Why: The user decided on 2026-10-14 that a desktop needs no backup routes to its own server and served-web primary routing is out of scope.
So what: Close this Issue as not planned; #292 continues with remote-client routes and the approved screen-free fallback simulations.
The source investigation and two faithful failing registry cases established the originally reported behavior, but no product repair is needed for the revised outcome. Only this task's two uncommitted test additions were removed, and the exclusive worktree is clean at
8f939c24ea898e7600c9c93892cb3ad63ad88686. No implementation commit, PR, merge or product deployment exists. The active operational task is still bound to that worktree, so it remains until safe retirement; all investigations and decisions retain their durable app/Issue records.Requirements and who asked: User's 2026-10-14 scope decision removes desktop own-server backup routes and served-web primary routing from #292 acceptance.
Deleted: The #286 repair, its planned primary-state changes and this task's experimental test additions.
Bottleneck: No primary-routing blocker remains in the approved outcome; real remote-client fallback proof now owns the work.
Checked myself: Current user decision, exact owned diff, clean after-state, no product PR/commit, and #292's revised remote-client scope.