[tonyfresher]

Pinned workspace chats stay visible while switching tabs, and the selector shows the chat name with pin/unpin controls. Views keep one permanent ID and tab from the initial sketch through the compiled applet, preserving their chat history. CLI view creation opens the new view before returning in both handoff and pinned in-place modes.

moi views create --source-session <session-id> --requirements "Build a weather view"

{"viewId":"abc123","mode":"handoff","sessionId":"child-session-id"}

A handoff starts the build in a child chat. A pinned in-place build continues in the current chat while opening the new view. Navigation failure returns the created IDs with a warning, so the agent can link to the existing view.

Overview history is grouped by day and excludes view chats. The workspace skill covers provisional title/icon updates, focused checks, bundling, and the final view link.

Review these boundaries closely:

• Startup saves the child chat before sending. Failed or uncertain submissions preserve recoverable state and never automatically replay the request; navigation failure also preserves successful creation.
• Collab selections inherit CLI handoffs until a browser tab makes its own choice, including an explicit empty chat; the workspace pin remains shared.
• Fork provenance and the copied-history cutoff are saved once. A failed initial history read leaves the child usable with its full transcript visible.

See the lifecycle notes for ownership, completion, and failure behavior.

Verification: earlier branch checks passed bun test (2,001 passed, 4 skipped) and browser checks of docked/popup chat headers and pin toggling. The navigation fix passed 9 focused tests (bun test server/test/view-create-cli.test.ts server/test/navigation-cli.test.ts server/test/skills-template.test.ts), bun run typecheck, and lint/formatting hooks.

[molefrog]

Looked through the PR, gonna test it locally now and report.

Things to do in the future PRs once this one is merged:

• Unify files in the DATA_DIR. Moi manages multiple .json files globally for things like pinned chats, models, etc. Might make sense to come up with one unified format or use sqlite. Would also make sense to store state per workspace, e.g. DATA_DIR/workspaces/{id}/state.json <- pinned, archived chats, models and so on
• session_id is injected for every chat message, might need to consider injecting it only when agent wants to build a new.

[molefrog]

Things I suggest fixing here. In the pending view chat, this context is attached to every message:

View build request — follow the pending view steps in the moi-workspace skill.
View id: <id> (already assigned)
Available view icons: …
Set the provisional title and icon with: moi views set <id> --title "<title>" --icon <icon-id>
Keep the user's current tab open. Link to moi:/views/<id> when the build is done.
Current session id: <session>. Use this as --source-session for moi views create.
This chat belongs to views/<id>; the active tab may be different.

my suggestions:

1. provide exact commands agent must run, since all ids are known already
2. split into two parts: view build intent block + current chat context (id etc.)
   3.provide first block only in the first message of the chat (no need to carry it in every follow up message)

sometrhing like

Build a new view from this message.
- The view id is `k3x9fa` and is already assigned. Write the view source to `.moi/views/k3x9fa.tsx`.
- Before building, set a provisional title and icon:
  `moi views set k3x9fa --title "<sentence case title>" --icon <icon>`
- When done, do not navigate. End your message with `[Open the view](moi:/views/k3x9fa)`.
- Available icons: chart, table, user, …

Context of this chat:
- This chat is attached to the pending view `k3x9fa`.
- If the user asks for a separate, additional view, do not build it here.
- Start a separate view in its own chat, so each view keeps its own chat and history:
  `moi views create --source-session 7d1c… --requirements "<complete requirements>"`
- Never use `moi views create` for `k3x9fa`.

[molefrog]

looks good! listed things to address next.
the only required thing is the context prompt rephrasing

[molefrog]

Also, I think this one is important. Chat context breaks when chat is pinned:

Start a new view from the New view tab, submit a request such as "a weather dashboard", and let its chat start building. While it is still running, go to Overview and pin a different, unrelated chat. Open the building view's tab again, where the pinned chat is now shown, and send any message such as "what are you working on?". The view's tab spinner now follows the pinned chat instead of the chat that is actually building, and stops as soon as the pinned chat replies. The pinned chat also receives that view's build instructions and may start editing the same view file as the original builder. If the view had failed before you sent the message, it now shows as waiting instead of failed.

[molefrog]

This PR will probably fix #108

UPD: tested it and it should work fine!
However, I would test additional edge cases such as:

1. Start new view, start building
2. Start another view and let it build (in parallel with 1.)
3. Go to overview and ask to add a widget => might call moi bundle => all pending views will be finalized