vibe64 0.1.47 → 0.1.49

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

@@ -108,6 +108,22 @@ When an assistant cannot start, stops by itself or reports a failure, see [When
 4. Wait for the actual answer and inspect its reported checks. Delivery or a
    working status is not a completed implementation.
 
+A steered message joins the running turn on that turn's own AI connection, so
+the composer can refuse it while the turn runs:
+
+- **Only the owner can steer this turn. You can send a message when it
+  finishes.** The turn runs on the workspace owner's personal plan and you are
+  not the owner (see [Personal-use AI subscriptions](ai-personal-use.md)).
+- **This turn's AI connection is unavailable right now, so you can't steer it.
+  Check AI Accounts, or send your message when the turn finishes.** Vibe64 could
+  not confirm that connection: it may be signed out, or its check failed. This
+  applies to the owner too, and the turn keeps running. When the turn ends,
+  Vibe64 checks the connection again; returning to the browser window also
+  rechecks it. If the hint stays, open AI Accounts and reconnect the account.
+
+Both hints keep your draft and are the same on desktop and phone. Colleague can
+explain them; reconnecting an account remains your step.
+
 On compact screens, reveal chat before using its composer. Failed submissions
 remain visibly failed or pending; inspect the target before retrying an uncertain
 write. Retry reuses the original request identity rather than starting duplicate work.

package/docs/colleague-usage/github-work.md

@@ -13,6 +13,20 @@ pull-request policy. **Update this session (rebase)** reconciles newer saved pro
 work when offered; Save does not silently perform that update for you. A failed or
 uncertain push needs a state check before another request.
 
+While a browser tab shows the project, or an AI turn runs in one of its sessions,
+Vibe64 checks the project's repository every 30 seconds. Newer saved work pushed
+from elsewhere, or committed in a local project folder, turns each affected
+session's tab and header action to **Update this session (rebase)** within about
+half a minute; a Save from another Vibe64 session shows it at once. Nothing is
+checked while no tab shows the project and no AI works in it; it checks again as
+soon as you return. If a check fails, the session's repository status shows the
+error and Vibe64 retries every minute. **Check for updates** in Repository checks
+immediately. These steps apply on desktop and mobile.
+
+Vibe64 reuses your GitHub login for a few minutes across repository operations.
+If you reconnect GitHub and the previous login was revoked, the next operation can
+fail once with a GitHub authentication error; retry it and it uses the new login.
+
 In Auto, **Automatic save after completing a plan** (on by default in the chat
 mode menu) runs this same Save once a plan is completed and its review turn ends.
 Its progress, result and recovery are the ordinary Save's; when it cannot save,

package/docs/colleague-usage/preview-browser-checks.md

@@ -45,9 +45,11 @@ disconnected; it lists every browser command, including `browser storage-state`,
 and the fields of the status, screenshot and eval JSON. Help starts neither
 Preview nor a browser.
 An actual suite still requires the project's installed Playwright version and a
-matching managed runtime. A version error is a test-runtime blocker; interactive
-checks can use the existing managed Preview browser. Report the exact required
-version to the platform operator instead of installing a separate browser.
+matching managed runtime. Every session shares one browser runtime, so a project
+pins `@playwright/test` to exactly that version. On a version error, the coding
+agent pins the project to the version `vibe64-helper playwright readiness`
+reports, runs Workspace setup and checks again; it never installs a separate
+browser. Interactive checks can still use the existing managed Preview browser.
 On a computer without managed browser runtimes, the agent runs the project's own
 Playwright (`npx playwright test`). Interactive Preview checks (screenshot, eval)
 use the project's own Playwright, or else the `playwright` command installed on

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

@@ -67,9 +67,12 @@ work. Public applications and non-web projects do not need preview accounts.
    accounts. Available starters depend on the installation; do not assume an
    absent card exists.
 2. Choose **Use this starter →** on the intended card only when it matches the
-   product you want. Preparation adds it to this session; use the session's
-   **Save** control to keep the work in the project. A failed application reports
-   its error and preserves existing work.
+   product you want. Preparation adds it to this session, whose tab then counts
+   the starter's files as unsaved changes and whose **Save** button turns red;
+   use **Save** to keep the work in the project. Until then, other and new
+   sessions do not have the starter, and archiving this session leaves it out of
+   the project; the **Archive session** dialog warns about this unsaved work. A
+   failed application reports its error and preserves existing work.
 3. You can also describe the app directly in the session's main chat. In an
    empty folder that was never set up, the coding agent first initializes Genesis,
    then proposes a Blueprint and the matching Stack components for your answer.

package/docs/colleague-usage/running-vibe64-on-your-computer.md

@@ -69,7 +69,9 @@ Vibe64 keeps each project's history with Git (2.28 or newer).
 - **Your name on commits.** Commits use the name and email from your own Git
   settings. If Git has none, they are saved with a stand-in name ending in
   “via Vibe64”, and **Health** and the Save result show the two
-  `git config --global` lines to set yours.
+  `git config --global` lines to set yours. Those lines take effect on the
+  next command; a name set some other way (an included file, or one
+  repository's own settings) can take up to 30 seconds to be used.
 - **Signed commits.** If your Git signs every commit (`commit.gpgsign`) and the
   key needs a passphrase, Vibe64 can't type it. Make one signed commit in a
   terminal to unlock the key, then try again. Vibe64 doesn't change the setting.

package/docs/colleague-usage/sessions.md

@@ -2,8 +2,25 @@
 
 Use **New session** (+), or **Create session** when there are no open sessions,
 to open **Start an AI session**. It shows **Runs on your main AI:** and the main
-AI's model; every session runs on that AI setup, with no per-session tool
-choice. Select **Change** to open AI setup instead. Review any branch choice,
+AI's model. A saved setup appears straight away: the dialog does not wait for
+each AI tool's model list or start any AI tool. Without a change the new session
+runs on the main AI and starts with Senior.
+
+To run only this new session on another AI, for example DeepSeek, select
+**Change** beside the main AI. It opens **Custom AI**, the same choice as a
+chat's **Custom** mode, and only then loads the model choices. Choose
+**Orchestrator**, **Model** and **Thinking** and press **Apply**; a loading
+error offers **Retry**, and **Configure more AIs** opens account setup when the
+provider you want is not connected. **Cancel** there keeps the current choice. The
+dialog then shows **This session runs on:** with your choice and says the
+session **Starts in Custom**; the new chat runs on that AI in **Custom** mode,
+and your main AI and other sessions are unchanged. **Use main AI** discards the
+choice, as does closing the dialog. Choosing the main AI's own model keeps the
+main AI. **Change** is offered only to the person who manages the workspace's
+AI; a team member's sessions always start on the owner's main AI.
+
+To change the main AI for every session instead, select **Change main AI for
+all sessions**, which opens AI setup. Review any branch choice,
 then select **Create session** (or
 **Create branch & session**). While **Creating session…** is shown, the dialog
 shows a progress bar and explains that it is copying the project source. It stays open: clicking outside,
@@ -27,8 +44,9 @@ finishes; see [Prepare a session after updating its source](workspace-preparatio
 for failures and retry.
 
 Creation through an action without an explicit AI choice uses the main AI. An
-explicit model choice makes the new chat Custom and is preserved even when it is
-unavailable: fix its account or AI setup before retrying. A team member's new
+explicit model choice, like **Change** in the dialog, makes the new chat Custom
+and is preserved even when it is unavailable: fix its account or AI setup, or
+choose another AI, before retrying. A team member's new
 session still records the owner's main AI; main chat runs on the owner's AI. Colleague
 can read the available choices and explain recovery; it must not claim a failed
 request left no saved lesson without checking that lesson's current state.
@@ -140,6 +158,13 @@ fresh session does not authorize further coding work.
 Select the session, choose **Archive session**, and confirm **Archive session**
 in the dialog. This stops its assistant and terminals, preserves the session and
 removes its active workspace. Desktop and mobile use the same confirmation.
+Archiving does not Save. Work the project does not have yet, such as an added
+starter, stays only in the session archive, and archived sessions cannot restore
+source to the project. When the session has unsaved changes, the dialog says how
+many and its button reads **Archive without saving**; choose **Cancel**, then
+**Save**, to keep them. When Vibe64 has not yet confirmed whether the work is
+saved, the dialog says so. A new session starts from the project's saved source,
+so it does not contain an archived session's unsaved work.
 An OpenCode session can be archived before its main chat has started; an idle
 assistant with no native conversation does not need a main-turn Stop request.
 Its helper conversations and terminals still go through normal cleanup.
@@ -158,9 +183,12 @@ If the last open session cannot be archived, its chat is selected again so you
 can inspect the failure and retry. If another session is already selected, that
 selection stays in place and the failed session becomes available in its tab.
 Colleague can explain these steps and the reported error. When you explicitly
-ask it to archive a named session, it archives it through the same action; the
-same pin, renewal and preparation guards apply, and it reports a failed cleanup
-for retry. Stopping an agent or ending Colleague is never an archive request.
+ask it to archive a named session, it first checks that session's saved-work
+status. If the session has unsaved changes, or their status is unconfirmed, it
+tells you how many, offers **Save**, and archives only after you confirm
+archiving without saving. It archives through the same action; the same pin,
+renewal and preparation guards apply, and it reports a failed cleanup for retry.
+Stopping an agent or ending Colleague is never an archive request.
 
 ## Chat availability
 

package/docs/colleague-usage/starter-apps.md

@@ -28,6 +28,9 @@ The same choices appear on desktop and mobile. Applying a starter imports its
 source and starts **Prepare workspace** at once: it installs dependencies,
 provisions the declared resources (an installation that supplies the database
 does so here) and runs migrations; a failed preparation offers **Retry**.
+The imported files are unsaved session work: the session's tab counts them and
+its **Save** button turns red. Save them to keep the starter in the project;
+archiving the session first leaves it out.
 The coding agent can then follow the first feature request using the existing
 test commands documented in the starter's `docs/colleague-usage/testing.md`.
 

package/docs/colleague-usage/temporary-chat-context.md

@@ -1,7 +1,8 @@
 # Start a temporary chat with recent context
 
 Open **Temporary AI** to create the first chat, or select **New temporary AI task**
-(the plus beside existing temporary chat tabs). Leave
+(the plus beside existing temporary chat tabs). When the session already has
+temporary chats, **Temporary AI** opens them instead and offers no new chat. Leave
 **Include recent chat context** unchecked for an empty conversation, or check it
 and select **Create chat** to copy recent context from Main in this session.
 When Main has no messages yet there is nothing to copy, so the chat opens

package/docs/colleague-usage/temporary-chats.md

@@ -1,8 +1,13 @@
 # Choose the AI for a temporary chat
 
 Open **Temporary AI** from the session toolbar, or from **Session actions** in
-a chat too narrow for it. Select the temporary chat you want to change. Its **Chat mode**
-icon is inside the message box.
+a chat too narrow for it. If the session already has temporary chats, it shows
+them and creates nothing; it starts a new chat only when there are none. Just
+after a session opens, it waits for the saved chats to load before deciding. If
+they cannot be loaded, it shows the error and **Try again** instead of starting
+one. To add another chat, select **New temporary AI task** (the plus beside the
+tabs). Select the temporary chat you want to change. Its **Chat mode** icon is
+inside the message box.
 
 In **New temporary chat**, **Cancel** returns directly to Main when starting the
 first chat. If another temporary or host conversation was selected, it stays
@@ -159,10 +164,17 @@ original settings and files. Anything you typed or attached afterward stays in
 the composer. Accepted files leave the composer; later attachments remain.
 
 If a message shows **Retry**, use that control with the original message.
-It checks whether that exact message reached the selected chat; it does not send
-the work again. A visible message can still be awaiting confirmation. If the
+It checks whether that exact message reached the selected chat. If it did,
+nothing is sent again. If the AI proves it never received the message, Retry
+sends it once with its original settings; while delivery is still unknown,
+nothing is sent. A visible message can still be awaiting confirmation. If the
 connection cannot read the native receipt, keep the chat and retry the check
-after reconnecting. **Stop** remains available for ongoing work. **Close** removes
+after reconnecting. **Cancel** on an unconfirmed message stops ongoing work and
+then checks it: the message is removed, and stays removed after a reload, once
+the AI proves it never received it; a message that did arrive stays in the
+conversation. While delivery remains unknown, Cancel keeps the message and says
+so; try again in a moment. Only Claude can currently prove that a message never
+arrived; with other AIs an unknown delivery stays until it is confirmed. **Stop** remains available for ongoing work. **Close** removes
 the temporary chat only after its native work and attachments are safely cleaned
 up; a failed Close can be retried. If you used more than one AI in this chat,
 Close cleans up each retained native conversation. A retry continues the unfinished