The panel knew one URL: the one you typed. Navigate three pages into an app and the header still showed the front door, "open in a new tab" still went there, and a reload — which fires by itself whenever a dev server restarts — threw away where you were and started again at `/`. Now the app reports where it is, and a reload composes it back. ── How the panel finds out ── The frame is same-origin for a proxied preview, so `contentWindow.location` is readable. It is PUSHED rather than read, because a dev server is an SPA: a route change is `history.pushState`, which fires no event and never reloads the document. Polling would have to be constant and would still lag. The script the proxy already injects now patches `pushState`/`replaceState`, listens for `popstate`/`hashchange`, and posts the path — with the proxy prefix stripped, since that is plumbing and the panel should not have to know about it to show a URL. Only proxied previews can do this. A cross-origin frame reports nothing, and grafting a remembered path onto someone else's host would be inventing a URL, so `targetUrl` composes only when there is a port. ── Two fields, and the loop that forced them ── `url` is what you pointed the panel at; `current` is where it has got to. The obvious design is one field — a browser has one address bar — and it feeds itself: the stored value IS the iframe's `src`, so recording a route change hands the frame a new `src` for the page it is already showing, which browsers treat as a navigation. Every click would cost a reload. Belt and braces, because one of the two would be enough only until someone changed the other: the fields are separate, AND `PreviewFrame` captures its `src` at mount and ignores later changes. Remount-by-key is still how a reload happens. `ev.source` identifies which frame is talking. `message` is a window-level event and two same-origin previews hear each other; comparing the posting window to this iframe's `contentWindow` is exact, where matching on URL would break the moment two panels pointed at the same port. Writes are debounced 800ms. `useDashboardState.setValue` PATCHes the server on every call and an SPA emits a route change per click; the value is only read at mount, so being a second behind costs nothing. Also: the header shows `localhost:3001/settings` rather than `api/dev-proxy/3001/settings`, and editing starts from that — one is a thing you can retype, the other is not. ── Tests ── The reporter is RUN, not string-matched: `new Function` against a fake window, which also means a syntax error in the injected script fails the suite rather than silently breaking every proxied page. Covers prefix stripping, the app root reporting `/` rather than empty, query and hash surviving, the report on load, pushState, and popstate. Plus the composition helpers, including that an ordinary URL is never composed with a path. ── One stale comment corrected while in there ── The file claimed `allow-same-origin` "is present, and has to be". There is no `sandbox` attribute at all, so nothing was present — and a sandbox with `allow-same-origin` plus `allow-scripts` is worth roughly nothing anyway, since the frame can remove its own sandbox attribute. Now says that. Not verified against a live dev server through the real proxy — that needs the server restarted with this code. tsgo clean, 934 pass / 7 fail unchanged, frontend builds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The documentation, triaged
2026-08-13. A map of what is in here, what it is for, and what should happen to it. Made because there are 42 documents and 13,000 lines, and no way to tell from the filenames which describe the system as it is and which are a record of an afternoon in July.
How much I verified: the classifications below are from filenames, status lines, and greps for things that changed on 2026-08-13. Where I actually read the document or checked the code, it says so. The rest is a starting point for a conversation, not a verdict.
Living — these describe the system and must stay true
| doc | state |
|---|---|
working-on-officer.md |
updated 2026-08-13. Operational guide. |
secret-store.md |
updated 2026-08-13. Built; rotation still open. |
install-variants.md |
new. The branch tree, for discussion. |
http-secure-context-audit.md |
new. What breaks over plain http. |
install-container-testing.md |
new. First container pass and its findings. |
per-user-linux-accounts.md |
partly updated. OFFICER_OS_USERS is gone; check the rest. |
navigation-audit.md |
authoritative on routing. Unverified against tonight's route removals. |
workspace-panels.md + workspace-panel-todo.md |
the panel framework. 1,300 lines combined — likely the biggest cleanup here. |
agent-coordination.md |
the north star for panel work. |
deprovision-os-account.md |
implemented; the 'disabled' stage it may mention was deleted tonight. |
Stale — describe things that changed on 2026-08-13
Each of these references something that no longer exists. Not yet corrected.
sidecar-topology.md— "ecosystem.config.cjs is the source of truth". It is generated now, and holds six processes.sidecar-app-store.md— derives the catalogue fromfull − light. Those files are gone, andcatalogue.test.tswas rewritten.sidecar-bootstrapping.md— "20 PM2 entries, 18 sidecar dirs". Six entries now.mobile-api-keys.md— partly corrected; recheck the origin-checking claims.wallet-key-custody.md—VAULT_STORE_KEYis now the per-purposewalletkey.push-notifications.md— "agreed design, 2026-07-31". Notify is a plugin and unmounted.chat-session-lifetime.md,chat-ui-walkthrough.md— referenceofficer-agent, renamed.
Historical — a record of a moment, and should stay one
Do not rewrite these to match today's code. They document how a decision was reached, and editing them destroys the reasoning. If they mislead, add a dated header pointing forward.
sidecar-audit-2026-07.md(1,377 lines)claude-sidecar-isolation.md— records theofficer-claude→officer-agentrename that preceded tonight'sofficer-agent→officer-claude-codeopen-threads-after-per-user-claude.mdtwo-agent-field-report-2026-08-12.mdapi-method-changes-2026-08-06.md
The opencode cluster — nine documents for one migration
opencode-fork-decision · -parity · -api-2-assessment · -phase0-review · -phase1-report ·
-phase1-review · -serve-migration-plan · -serve-path · -testing-checklist
The migration landed — opencode serve is in the sidecar, verified. So
opencode-serve-migration-plan.md saying "Nothing here is implemented" is false.
This is the clearest consolidation candidate in the whole directory: one document recording what was decided and what shipped, replacing nine that describe stages of getting there. I did not do it because it needs reading all nine, and deleting documents unread is not a thing to do at 4am.
The mobile-dav thread — three documents, one conversation
mobile-dav-provisioning · -feedback · -reply. A correspondence. Almost certainly one document.
Unclassified — I have not looked
design-language-interface · file-sync · jobs-unification · mobile-photo-sync-api ·
nextcloud-replacement · agent-git-identity
The plugin split, which affects most of the above
A core install is six processes. Everything else is a plugin, switched off tonight but present on disk. Most documents here were written when the estate was twenty processes and every one of them was simply "there", so they describe availability that no longer holds.
The useful rewrite is usually one line, not a rewrite: say whether the thing described is core or a plugin, and if a plugin, that it is not mounted on a fresh install.