Improve workspace navigation and chat interactions - #146
tonyfresher wants to merge 3 commits into
Conversation
|
Some findings that might break existing workspaces (from CLaude): Breaking change for existing workspaces, no shim.Any view still importing focusTab fails to build with "No matching export". I confirmed that. From the code, old built bundles that still serve will throw on click, because the new bridge has no such method. The docs cover this under Migration and the skill version bump triggers an update, but public users' workspaces break until the agent rewrites them. Suggest a one-release shim mapping the old call to navigate with a deprecation entry in moi debug logs. Already compiled, source untouched. The new server keeps serving the old bundle as if nothing happened. Rebuilds are triggered only by source files being newer than the built output, and a moi upgrade changes neither, so moi bundle reports the view as skipped. The view loads and renders normally. But the old bundle carries the old inlined shim, which calls bridge?.focusTab(...), and the host now attaches a bridge without that method. Clicking the button throws "bridge?.focusTab is not a function". The URL doesn't change, the rest of the view keeps working, and the error lands in moi debug logs as a window error for that view. The agent only notices if it reads the journal. The missing-view error, in plain termsBefore this PR, the agent's last step after building was moi tabs focus view:orders. If it got the name wrong, say view:order, the server checked the name against the views on disk and answered with the full menu: Unknown tab "view:order". Valid tabs: overview, agent, scratchpad, view:orders, view:shop The agent could fix the typo from that one error, with no extra command. After this PR the same mistake gets this: ✗ This destination is unavailable in this workspace Nothing tells the agent what the valid addresses are. It has to know to run moi tabs to see the list, which costs another tool call and only happens if the skill text reminds it. Why it changed. The existence check moved from the server to the browser. The server no longer looks at the views on disk before relaying. It forwards the address to the browser, the browser checks it against its own view list, and it reports back a generic message. The old server-side listing simply wasn't wired into the new path. Why it matters. This command runs after every build, so it is the most frequent place for a view-id typo, and an error that names the valid options is the difference between one retry and a stuck loop. Fix options. The cheap one is appending "Run moi tabs to list addresses" to the CLI's failure output. The better one is keeping the old server-side check before relaying, so the error lists the valid moi:/ addresses the way it used to, with the browser check staying as a backstop for a stale view list. |
Summary
Testing