vibe64 0.1.41 → 0.1.42

package/docs/colleague-usage/ai-accounts.md

@@ -196,13 +196,17 @@ change models or resend the pending words until cleanup and delivery are resolve
 Colleague can explain the error and inspect readiness, but cannot repair the
 host's process service. These recovery steps apply on desktop and mobile.
 
-For regular Z.AI setup, ask Colleague “Is my regular Z.AI connection saved?”
+To check your saved API connections, ask Colleague, for example “Which AI
+connections are saved and ready?” or “Is my regular Z.AI connection saved?”
 The workspace owner can get a fresh, read-only check without opening a project.
-It reports the saved connection, preferred provider, default model and whether
-the account's model policy is recommended-only or unlocked. It never reads out
-the key, key hint or fingerprint. A Personal Coding Plan is a separate connection;
-it does not satisfy this check. If connection storage is unavailable, Colleague
-reports that instead of saying you are disconnected. On desktop and phone,
+It covers every provider saved in **AI Accounts** (Z.AI, a Z.AI Coding Plan,
+OpenAI, OpenCode Zen and any other), and for each one reports whether it is
+ready, why not when it is not, whether it is the preferred provider, its default
+model and whether its model policy is recommended-only or unlocked. It never
+reads out the key, key hint or fingerprint. Claude and Codex sign-ins are not
+saved connections. A Personal Coding Plan is a separate connection from regular
+Z.AI; it does not satisfy a regular Z.AI check. If connection storage is
+unavailable, Colleague reports that instead of saying you are disconnected. On desktop and phone,
 registration, masked **API key** entry and paid-model consent remain your steps
 in **AI Accounts**. If a check fails, reopen AI Accounts and inspect its saved state;
 do not paste a key into chat or reconnect solely because of a failed read.

package/docs/colleague-usage/ai-model-setups.md

@@ -127,8 +127,14 @@ Models.
 provider's own, for example **Main AI: DeepSeek, via Claude Code**. **Use as
 main AI** on another card moves Senior, Junior, Router and Quick helper to that
 provider in the tool it is connected through (see
-[AI onboarding](ai-onboarding.md#redo-with-an-existing-setup)). The crown and
-**Recommended** ribbon stay on Claude's card; they never mean "in use".
+[AI onboarding](ai-onboarding.md#redo-with-an-existing-setup)).
+
+After you save a different tool or model for Senior or Junior, here or with
+**Use as main AI**, an unfinished goal (except one on a Custom model) is
+cancelled the next time it would continue; its chat says so, and you start the
+goal again on the new main AI (see [Goals and model
+changes](coding-agent-goals.md)). A thinking-level-only change does not. The crown and **Recommended** ribbon stay on Claude's card; they
+never mean "in use".
 
 ## Colleague's model
 

package/docs/colleague-usage/coding-agent-failures.md

@@ -14,8 +14,8 @@ mode** and choose another connected **Orchestrator**, or choose **Custom** and a
 permitted model. A pending automatic continuation or review does not prevent
 this change: Vibe64 cancels its old scheduling and waits for routing-helper
 cleanup before switching. During an active turn, the new settings are saved for
-the next turn. An unfinished goal keeps its orchestrator; another orchestrator
-is saved for after that goal finishes. A reported cleanup failure keeps
+the next turn. After a different main AI is saved in AI setup, an unfinished
+goal is cancelled the next time it would continue; see [Goals and model changes](coding-agent-goals.md). A reported cleanup failure keeps
 the previous selection; retry after restoring the execution service.
 The session's files and saved conversation remain. Switching does not resend
 the session's already-delivered opening briefing through project setup. A first

package/docs/colleague-usage/coding-agent-goals.md

@@ -29,19 +29,28 @@ during a pending delivery may require cancelling that request and sending it aga
 These steps apply on desktop and mobile. Account sign-in and credential entry
 remain your actions; Colleague can explain the recovery and offer supported help.
 
-An unfinished goal stays with its current tool. Open **Chat mode** while
-it is running or paused and choose **Senior**, **Junior**, or **Custom**. A model
-or direct-mode change within the same tool applies to the next turn,
-including automatic goal continuations. The current turn keeps its settings;
-the goal keeps its objective, budget and progress. You do not need **Pause goal**,
-**Cancel goal** or a reload to save settings.
-Choosing **Auto**, a model in another tool, or moving the main AI to another tool
-in AI setup applies after the goal finishes; it does not transfer or cancel the
-current goal. Ordinary messages still use the current goal’s tool and the AI setup
-saved when it started. If a message is rejected before sending, its delivery check
-also uses the current goal’s tool. These steps apply
-on desktop and mobile, including goals created by the assistant. Colleague can
-explain or offer a supported change and needs your request before performing it.
+Open **Chat mode** while a goal is running or paused and choose **Senior**,
+**Junior**, or **Custom**. A model or direct-mode change within the same tool
+applies to the next turn, including automatic goal continuations. The current
+turn keeps its settings; the goal keeps its objective, budget and progress. You
+do not need **Pause goal**, **Cancel goal** or a reload to save settings.
+Choosing **Auto** or a Custom model in another tool in **Chat mode** applies after
+the goal finishes.
+
+When the workspace owner saves a different tool or model for **Senior** or
+**Junior** in **AI setup** (or **Model setups**), an unfinished goal started on
+the previous main AI is cancelled the next time it would continue, as **Cancel
+goal** would: when its current turn ends, when you choose **Resume goal**, or
+after a server restart. This includes goals in projects that were not open when
+the setup changed. The chat shows **Goal cancelled because the main AI changed in
+AI setup**; the conversation, files and work done so far are kept. To continue,
+choose **Goal** → **Set goal** again; it runs on the new main AI. A goal on a
+**Custom** model is not cancelled, and neither a thinking-level-only change, a
+Router or helper change, nor the first AI setup cancels goals. If the goal cannot
+be cancelled (for example its AI is unreachable), the failure is recorded in the
+operational log; choose **Goal** → **Cancel goal**. These steps apply on desktop
+and mobile. Colleague can explain this and change the AI setup on your request;
+it warns first that unfinished goals will be cancelled.
 
 When changing a Codex model provider during a goal, the current turn finishes
 before the same conversation continues with the new provider. If that change
@@ -139,8 +148,10 @@ explicit confirmation.
 A copied development workspace never inherits permission to run its parent's
 goals. Restart continuation applies to supported Main native goals; temporary
 logical and scoped conversations do not expose native goal controls or receipts.
-Colleague can explain these controls and offer the supported action, but needs
-your request before changing a goal.
+Colleague can read a session's current goal (its objective and whether it is
+active, paused, blocked or complete) and explain these controls. It cannot set,
+pause, resume or cancel a goal itself: it tells you which **Goal** control to
+use and can draft an objective for **Set goal**.
 
 A paused Claude goal stays paused while you send ordinary messages in the same
 chat, including after reloading or restarting the application. The objective

package/docs/colleague-usage/coding-agents.md

@@ -157,10 +157,22 @@ Open **Chat mode** at any point to choose **Auto**, **Senior**, **Junior**, or
 **Custom** → **Apply**. Senior and Junior come from the AI setup and always run
 in the main AI's tool. Saving settings does not stop the
 current turn. The next turn uses the new settings; see [Goals and model
-changes](coding-agent-goals.md) for automatic continuations and an unfinished
-goal's retained tool. If saving fails, the control reports the error;
-retry after resolving it. Colleague can explain or perform a supported selection
-change when you explicitly ask.
+changes](coding-agent-goals.md) for automatic continuations and goals. If saving
+fails, the control reports the error; retry after resolving it. Colleague can
+explain or perform a supported selection change when you explicitly ask.
+
+A message sent while a turn is still running joins that turn, with that turn's
+mode and model. This includes a Claude turn whose reply is ready while a
+background task (for example a long test run) still runs: the status reads
+**Reply ready · background task still running…**. If you changed **Chat mode**
+(or chose another Custom model) since that turn started, Vibe64 does not send the
+message into it: it names the mode or model the running turn still uses, and
+the message stays in chat with **Retry**. Choose **Stop** (this also stops the
+background task) or wait for the turn to finish, then choose **Retry** to send it
+as a new request on your current Chat mode. During a goal, the goal's own mode
+governs its turns (see [Goals and model changes](coding-agent-goals.md)). This
+applies on desktop and mobile; Colleague can explain the notice, and you choose
+Stop and Retry.
 
 To change the model for an active Update merge repair, open **Chat mode** in
 that repair's composer, then **Choose model**. In **Custom AI**, choose a

package/docs/colleague-usage/colleague-watches.md

@@ -15,10 +15,11 @@ finishes” for a completion watch instead. Watching starts only on your request
 checks your current project access and does not stop or resend the coding work.
 
 Colleague can also watch more than conversations, wherever your Vibe64 offers
-it, for example a project's deployment on a hosted Vibe64: ask “Tell me when my
-app is live” or “Tell me if anything changes in that deployment”. Ask Colleague
-what it can watch here; it lists what this installation offers. An app that is
-already live is reported at once. Every reading checks your current access to
+it, for example a project's releases from its **Publish** page: ask “Tell me
+when my release is live”, “Tell me if the release fails” or “Tell me if anything
+changes in that release”. Ask Colleague what it can watch here; it lists what
+this installation offers. A release or app that is already live is reported at
+once. Every reading checks your current access to
 that project; a watch only reports and never deploys, restarts or changes
 anything.
 

package/docs/colleague-usage/project-messages.md

@@ -104,3 +104,26 @@ hosts without that facility do not advertise it.
 If the destination has a pinned source session, that is its server-selected
 session for messages without `--session`, even while someone browses another tab. Unpinning restores ordinary
 selection. Pinning does not change message permissions or acknowledgement rules.
+
+## View another project's Preview
+
+A coding assistant can open another project's running Preview, for example to
+review an app built in a sibling project. Ask it to look, for example: “Check
+the shell in mercbot's Preview.” It uses:
+
+```sh
+vibe64-helper session project-preview mercbot
+```
+
+The command prints that project's current Preview address, which the assistant
+opens in its managed browser. Add `--session <id>` to choose a session other
+than the selected one. Access follows the same rule as messages: you must be
+able to use that project, and it must be open with an active session.
+
+The address can change when that Preview restarts, for example after new
+packages are installed. The assistant runs the command again instead of reusing
+an old address. The command never starts the other project's Preview. If the
+project is closed, has no active session, or its Preview is not running after a
+short wait (about ten seconds), the command stops with a clear message; open the
+project or start its Preview, then ask again. Signing in to that app uses its
+own accounts, as for any visitor.

package/docs/colleague-usage/publishing.md

@@ -123,6 +123,13 @@ confirmation. Only your **Publish** press publishes. Colleague never sees a
 token, key, passphrase or file path, and cannot add accounts, unlock keys,
 accept a licence or confirm.
 
+After you press **Publish**, ask Colleague “Tell me when the release is live”
+or “Tell me if it fails”. It watches the project's latest release (not dry
+runs) and reports once every target is live, or when the release fails, reaches
+only some targets or stops before finishing; “Tell me if anything changes”
+reports each change. A watch only reports: it never publishes, retries or
+confirms. Manage it from **Watches and assignments** in Colleague.
+
 How publishing works underneath:
 
 Package registries Vibe64 releases to: