vibe64 0.1.33 → 0.1.34

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

@@ -20,6 +20,31 @@ The existing source and Git history are retained. If preparation fails, read the
 reported step and use the offered retry after addressing its cause. Do not apply
 a starter over an existing repository to repair it.
 
+### Preview accounts for an imported application
+
+If the application has login-protected pages, the coding agent should initiate
+preview-access setup during import. It asks which **existing development
+accounts** represent an administrator and other roles you need to inspect, and
+which should be the default. Supply an email, login or user ID, not a password.
+The agent should reuse answers you already gave and wait for your choices.
+Choosing a name such as “admin” does not grant that account administrator rights.
+
+The coding agent can implement the application's Preview identity adapter after
+you accept that work. To configure named accounts, open **Dashboard > App access**
+and use **Managed app access > Add identity**. Enter **Name**, **App identifier**
+and **Application value**, choose **Make default** if needed, then **Save**.
+On mobile, use **Show project** to reach Dashboard. Colleague can explain these
+fields and, when asked, save the supported identity settings; application code
+work belongs to the coding agent.
+
+Once the adapter is ready, choose the configured name from Preview's application
+identity menu and verify the expected access. Saving the list alone does not
+prove the account exists or authentication works. A missing or disabled account
+needs a corrected existing account selection; import does not create users,
+change roles or reset passwords. If you postpone this setup, the agent should
+leave authenticated preview access explicitly pending and continue other setup
+work. Public applications and non-web projects do not need preview accounts.
+
 ## New project
 
 1. Open the project and create or select its coding session. At **What would you
@@ -42,8 +67,10 @@ use **Show project** to see setup and **Show chat** to follow the conversation.
 ## Colleague assistance
 
 Ask “What does this setup screen need?” for an explanation. Colleague can read
-onboarding state, discuss the product, create an authorized first session, and
-send an explicitly requested inspection or setup to that session's coding agent.
+onboarding state without preparing a large coding request, discuss the product,
+create an authorized first session, and send an explicitly requested inspection
+or setup to that session's coding agent. After you request the task or accept its
+offer, Colleague retrieves that exact setup request before sending it.
 It can follow the conversation and report the observed result. It does not inspect
 the repository itself. An explanation or offer starts no coding work; a direct
 request or accepted offer authorizes the specified task. Missing project access,

package/docs/colleague-usage/session-terminal.md

@@ -0,0 +1,42 @@
+# Open the coding agent's terminal
+
+This continues [Create and switch sessions](sessions.md).
+
+Open **Dashboard → AI Terminal**, then select **Start Codex**, **Start Claude
+Code** or **Start OpenCode**, depending on the session's agent. The terminal
+continues that session's native conversation. **Close terminal** stops its
+interactive terminal; starting it again resumes the saved conversation.
+
+Claude opens a new interactive process for the current saved conversation. Finish
+or stop an active chat turn before selecting **Start Claude Code**. The idle chat
+process stops first, and chat is unavailable while the terminal is open. Use
+**Close terminal** to return to chat. With a saved Claude connection the
+terminal opens the conversation directly, without Claude's first-run setup,
+folder-trust question or bypass-permissions warning.
+It asks you to sign in only when the connection is missing or has expired.
+Complete sign-in yourself; Colleague can explain it but cannot sign in for you.
+
+Click inside the terminal before typing or pasting. Text and Enter are delivered
+in the order you entered them, even while the server checks terminal access.
+If an input error appears, inspect the terminal before entering the command again;
+the error does not mean that earlier input was discarded or rolled back.
+Colleague can explain the error, but terminal commands remain your interaction.
+
+A resumed Codex terminal keeps the shared server's saved permissions. Codex may
+still show its own OpenAI sign-in screen when Main chat uses an external model:
+its terminal checks the shared server's account before opening the conversation.
+An external model connection alone does not satisfy that native sign-in. Complete
+the offered account sign-in yourself, or close the terminal and continue in Main
+chat. Colleague can explain the steps, but cannot complete your sign-in.
+
+## Leave a terminal on mobile
+
+AI Terminal fills small screens. Use **Exit full screen** in its header to
+restore the page and its **Dashboard section** selector. This keeps the terminal
+running. Use **Full screen** to enlarge it again. **Close terminal** stops that
+terminal; it is a separate control.
+
+The same full-screen controls appear on other non-collapsible terminal views.
+Task output with a **Collapse** control keeps that existing way back. Colleague
+can explain these controls or open another view through its navigation action;
+leaving a view does not authorize stopping its work.

package/docs/colleague-usage/sessions.md

@@ -3,11 +3,26 @@
 Use **New session** (+), or **Create session** when there are no open sessions,
 to open **Start an AI session**. Choose an available orchestrator, review any
 branch choice, then select **Create session** (or **Create branch & session**).
-While **Creating session…** is shown, the dialog stays open: clicking outside,
+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,
 pressing Escape, Close and Cancel cannot dismiss it. On success it closes and
 opens the new session. If creation fails, review the error and retry or dismiss
 the dialog. This works the same way on desktop and mobile.
 
+For a project with connected projects, the dialog closes once the session's own
+source is ready. The session then shows **Preparing workspace…** while Vibe64
+prepares the connected projects together, naming those still in progress (for
+example **Preparing connected projects: jskit-ai, genesis (1 of 3 ready)**),
+followed by the project's setup steps. The assistant can start when preparation
+finishes; see [Prepare a session after updating its source](workspace-preparation.md)
+for failures and retry.
+
+Creation through an action without an explicit AI choice uses the first available
+workflow from the same picker. An explicit choice is preserved even when it is
+unavailable: fix its account or Model routing settings before retrying. 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.
+
 The new session appears in the session list after its source checkout is ready.
 Refreshing during creation does not report that checkout as missing. If a
 **session needs attention** notice remains after creation, use **Check again**;
@@ -15,6 +30,11 @@ if the checkout is still missing, use **Copy recovery details** and ask your
 administrator to restore the original work from a verified backup. Colleague
 can explain the notice, but cannot restore missing source through session creation.
 
+If creation reports **This session source already exists**, existing commits,
+staged changes and files have been preserved. Reopen that session if it is listed;
+otherwise keep the source and ask your administrator to inspect the recovery
+details. Repeating creation does not reset or replace the checkout.
+
 Colleague can explain the choices or create a session through its session
 creation action when you explicitly ask it to do so.
 
@@ -42,23 +62,41 @@ the smallest panes keep secondary actions in **Session actions**. Update uses a
 vertical line through a circle, distinct from the branching pull-request icon.
 Hover or focus a control to read its action label.
 
+During a session **Save** or **Update**, you can still open existing temporary
+chats, read their saved history and keep a plain text draft. The draft's save
+state appears in that chat. Sending or changing assistant work waits for the
+repository operation to finish. If an Update response is lost, use the saved
+Update status and recovery controls before requesting another Update; a reload
+does not establish that the first one failed.
+
 Colleague can explain the tabs and open an accessible session through its
 navigation action when you explicitly ask it to do so.
 
-## Working and Learning session navigation: integration prerequisite
+## Reconnect a chat
+
+If the conversation shows **Conversation subscription failed.**, choose
+**Reload chat** to reconnect to the same session. This reads its saved history
+and restores updates without sending your draft or repeating an earlier request.
+Standalone Vibe64 supports this through the local editor for its selected project;
+it does not require a hosted workspace login. Keep using the editor's localhost
+address. If the error persists, report the project, session and exact error.
+On phones, open the chat pane to find the same control. Colleague can explain
+recovery and open the session; the person selects **Reload chat**.
+
+## Working and Learning session navigation
 
 The prepared mode filter uses the same session tabs and chat panel for Working
 and Learning sessions. Older sessions without a purpose remain Working. Hiding
 a session from navigation preserves its running work, mounted conversation and
 draft; it does not stop or archive anything. A selected session of the other
-purpose is hidden without opening a different session automatically. The host
-must attach the actual mode control and remembered selection before this is a
-complete visible feature. The filter does not create a lesson, authorize an
+purpose is hidden without opening a different session automatically. The yellow
+**L** plate in the app header switches the filter (see
+[Choosing lessons and Learning conversations](learning-mode-ui.md)). The filter does not create a lesson, authorize an
 attempt or turn an ordinary session into a teacher. Desktop and mobile use the
 same navigation contract. Colleague can explain the mode; changing it does not
 authorize starting or ending a lesson.
 
-When the host connects Working and Learning to these tabs, each mode remembers
+Each mode remembers
 its own selected conversation. A Working conversation that finishes opening
 while you view Learning stays with its original project and does not replace the
 lesson you are viewing. Switching modes preserves hidden conversations and
@@ -71,8 +109,8 @@ must not remain available. If a conflicting-conversation error appears, retain
 your work and ask the owner to inspect it. Colleague can explain these states;
 it cannot grant access or repair saved identities. Ordinary **New session** and
 **Archive session** are Working operations, not ways to start or end a lesson.
-These rules apply on desktop and mobile; this prerequisite alone does not add
-the visible mode control or complete lesson delivery.
+These rules apply on desktop and mobile. Start, resume and end lessons through
+Learning → **Courses** and Colleague instead.
 
 ## Keep the fresh session's link after renewal
 
@@ -92,49 +130,35 @@ 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.
+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.
+Archiving also cancels pending Main and temporary-chat routing, waits for its
+owned helpers to stop, then closes native work through the normal cleanup path.
+You do not need to send the pending request or change AI accounts to close it.
+If routing cleanup takes longer than 30 seconds, the session stays available
+with a retryable cleanup error; choose **Archive session** again. A new request
+arriving during cancellation can also require another Close attempt. Pinning,
+renewal and active workspace preparation still prevent archival.
+Archiving uses the session's saved assistant even after a server restart; it
+does not require connecting a different assistant just to stop that session.
 If history preservation fails, the operation reports the error and keeps the
 workspace for retry. Resolve the reported problem, then retry **Archive session**.
+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; the existing session
 permissions and confirmation still apply.
 
-## Open the coding agent's terminal
-
-Open **Dashboard → AI Terminal**, then select **Start Codex**, **Start Claude
-Code** or **Start OpenCode**, depending on the session's agent. The terminal
-continues that session's native conversation. **Close terminal** stops its
-interactive terminal; starting it again resumes the saved conversation.
-
-Claude opens a new interactive process for the current saved conversation. Finish
-or stop an active chat turn before selecting **Start Claude Code**. The idle chat
-process stops first, and chat is unavailable while the terminal is open. Use
-**Close terminal** to return to chat. Even with a saved Claude connection, its
-interactive terminal may request first-use setup or sign-in. Complete the native
-steps yourself; Colleague can explain them but cannot sign in for you.
-
-Click inside the terminal before typing or pasting. Text and Enter are delivered
-in the order you entered them, even while the server checks terminal access.
-If an input error appears, inspect the terminal before entering the command again;
-the error does not mean that earlier input was discarded or rolled back.
-Colleague can explain the error, but terminal commands remain your interaction.
-
-A resumed Codex terminal keeps the shared server's saved permissions. Codex may
-still show its own OpenAI sign-in screen when Main chat uses an external model:
-its terminal checks the shared server's account before opening the conversation.
-An external model connection alone does not satisfy that native sign-in. Complete
-the offered account sign-in yourself, or close the terminal and continue in Main
-chat. Colleague can explain the steps, but cannot complete your sign-in.
-
-## Leave a terminal on mobile
-
-AI Terminal fills small screens. Use **Exit full screen** in its header to
-restore the page and its **Dashboard section** selector. This keeps the terminal
-running. Use **Full screen** to enlarge it again. **Close terminal** stops that
-terminal; it is a separate control.
-
-The same full-screen controls appear on other non-collapsible terminal views.
-Task output with a **Collapse** control keeps that existing way back. Colleague
-can explain these controls or open another view through its navigation action;
-leaving a view does not authorize stopping its work.
+## Chat availability
+
+The chat checks which modes you can use and shows the effective assistant,
+shared-backup label or an actionable connection message. These lightweight
+checks do not start a model or download its repeated execution plan. Opening
+**Chat mode** still shows the available choices; access is checked again when
+work is sent. Colleague can explain an unavailable mode, but cannot grant access.
+
+To open the coding agent's own terminal, or leave it on a phone, see [Open the coding agent's terminal](session-terminal.md).
 
 ## Leave a dashboard tool
 
@@ -169,17 +193,31 @@ explicit Refresh and checks for changes made outside Vibe64 remain available.
 Opening a session also checks your AI access. Sending waits for that result;
 the pending check does not itself mean the connection is unavailable. A confirmed
 unavailable connection or access error is shown after the check returns.
-
+If chat stays on gray loading rows while the application Preview still works,
+use **Reconnect** or **Retry connection** when shown, then reload the browser tab
+if it remains stuck. Report the selected session and any failed chat/access
+request status when asking for help; do not share cookies or tokens. Colleague can identify the
+selected session and explain recovery, but cannot read the browser console.
+
+**Sending to assistant…** covers delivery of your message. With Claude,
+**Assistant is working…** replaces it as soon as Claude starts the turn, before
+its first reply arrives; the composer is not left without a status in between.
 **Assistant is working…** means the turn is active. Its animated dots require
 the provider to report a live reasoning phase. Tool use and waiting between
 provider events can keep the turn active without animating those dots. Reasoning
 summaries may arrive late in a response; absent dots alone do not prove a stall.
 Reduced-motion preferences also disable the animation.
 
+With Claude, **Reply ready · background task still running…** (Main) means
+Claude has posted its answer, but a command it started in the background is
+still running. The answer above is complete and readable. The turn stays active
+until that command finishes or times out, and Claude may then add a short
+follow-up reply after the answer; earlier replies stay visible. Temporary chat
+shows the same text. Press **Stop** if you do not need the background command.
+
 Colleague can explain these states. It should verify current session activity
 through its available read operations before claiming that work has stopped.
 
-
 ## Lessons that do not need a practice workspace
 
 A lesson without practical workspace steps can retain its own conversation and
@@ -194,7 +232,39 @@ but cannot continue running as the archived conversation. Colleague can explain
 the reported error; it cannot grant another learner's access or silently replace
 the saved lesson with newer content.
 
-This session foundation adds no lesson-launch control. Lesson selection and
-Main teaching must be connected through the existing learning flow before this
-can be used from the interface; the ordinary **New session** control still creates
-a working session with source.
+Start such a lesson from Learning → **Courses** (see
+[Choosing lessons and Learning conversations](learning-mode-ui.md)); the ordinary
+**New session** control still creates a working session with source.
+
+## Pin a source session
+
+Select the source session, then choose **Pin session as project source** beside
+Save. Its pin icon becomes filled. One session per project can be pinned.
+Pinning and unpinning work while the assistant is busy or reconnecting; they do
+not require an AI connection. Archive or renewal already in progress still blocks pinning.
+You can still browse and work in other session tabs; the server-selected source
+link stays on the pinned session. Cross-project requests addressed to the
+server-selected session also keep that destination. Pinning does not Save,
+publish, freeze file contents, or deploy.
+
+The pinned session cannot be archived or renewed, and the project cannot close
+or be closed by idle cleanup. Closing your browser does not remove the pin.
+The pin survives server restarts. To change it, return to the pinned session and
+choose **Unpin session**; tab selection then controls the source link again.
+Other sessions show a disabled pin with **Unpin the project's pinned session first**.
+Desktop and mobile use the same pin button beside Save. Learning sessions have
+no source pin. Separate project pins do not affect each other.
+
+Colleague can explain the pin or, on your explicit request, pin/unpin a named
+session through its session action. Source cleanliness and publication checks
+for host updates still apply to the pinned source.
+
+## Answer clarification questions
+
+When the agent asks numbered questions, answer each question using its own choices
+or a typed response. This works the same way on desktop and phone. Choices should
+appear beneath the question they answer, with one alternative per option. If an
+option combines opposite answers (for example, “Yes / No”) or belongs to another
+question, do not use it to communicate approval. Ask the agent to restate the
+questions with separate choices. Colleague can explain the questions; your chosen
+answers determine what work is authorized.

package/docs/colleague-usage/teaching-content.md

@@ -66,8 +66,11 @@ confirmed checkpoint. These saves preserve the question and earlier assessments,
 and never grant a pass. If a concurrent assessment conflicts, read its saved
 result and retry its existing operation with the current revision.
 
-The application also has a server-only verified-snapshot installation facility.
-It has no visible control or Colleague tool; the local operator commands in **Author a lesson and publish its source**
+The application also has a server-side verified-snapshot installation facility.
+For official catalogue courses it is reached through **Install** and **Update**
+in Learning's **Courses** pane, or Colleague's `course.install` on a direct
+request (see [Installing and updating Learning courses](learning-course-catalogue.md)).
+For other content, the local operator commands in **Author a lesson and publish its source**
 invoke the original installation owner.
 An admitted owner operation must select the canonical local source and exact
 course pin. Colleague can explain this boundary and offer to help contact the
@@ -122,10 +125,13 @@ does not prepare an exercise, grant access or create learner progress. Colleague
 can explain this prerequisite and offer supported assistance contacting the owner;
 it cannot run the operator upgrade through its current tools.
 
-The server now also retains owner-approved course releases and their enablement.
-This is still an internal facility, with no course-enable control or Colleague
-tool. Colleague can explain the boundary and offer to help formulate an owner
-request through supported conversation actions; it cannot grant course access.
+The server now also retains approved course releases and their enablement.
+Official catalogue courses are enabled by **Install** or **Update**; there is no
+general course-enable or disable control. Colleague can explain the boundary and
+offer to help formulate an owner request through supported conversation actions;
+apart from installing an official catalogue course on request, it cannot grant
+course access. An update disables older releases of that course for new starts
+only.
 A fresh enabled catalogue read admits a new start. Disabling that release
 blocks later admissions without revoking already admitted work or saved attempts.
 Missing or corrupt installed material, even in a disabled release, requires the

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

@@ -0,0 +1,29 @@
+# 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
+**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
+directly without this choice; the dialog appears only if creation fails, with
+its error and **Create chat** to retry. Creating the chat sends no AI request. Enter your question and send it normally.
+The controls work the same way on desktop and compact screens.
+
+The copy contains up to forty visible user, assistant and progress messages at
+the time the server creates the chat. It includes text only, not attachment
+contents, hidden reasoning or internal role instructions. A 64 KiB text limit
+keeps the newest messages first. Until the first message is sent, the temporary
+chat notes how many messages were copied and whether any text was omitted.
+Drafts save automatically; a note appears only if a draft could not be saved. Main continues independently. Later messages and edits in either
+conversation do not update the other. Both still work in the same session source,
+so edits made by either coding agent affect that shared working tree.
+
+A failed creation keeps its error and the same chat identity for retry. Retrying
+a creation that already succeeded retains its original copy. Changing the model
+uses the ordinary conversation history handover; it does not capture Main again.
+Existing temporary chats are unchanged, and opening or reloading them does not
+import context. Close a temporary chat through its tab's existing **Close** control.
+
+Colleague can explain the option and create a temporary chat with copied context
+when explicitly asked, using the existing create-conversation action. It must not
+enable context copying merely because the person asked how the option works.

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

@@ -4,11 +4,51 @@ Open **Temporary AI** from the session toolbar, or from **Session actions** in
 a narrow chat. 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
+selected with its draft intact. Dismissing the dialog has the same effect; no
+chat is created and no message is sent. This applies on desktop and narrow screens.
+
 Ordinary temporary chats offer **Custom**, **Senior** and **Junior**. Choose
 **Custom** to open the **Orchestrator**, **Model** and **Thinking** fields. Select
 an available connection and model, then **Apply**. The next message uses that
 choice and the existing conversation history. Main chat's selection is unchanged.
 
+## Send and steer
+
+Temporary chat uses Main's round Send arrow and square Stop control. While a
+message is being delivered, you can type and send another; it appears as
+**Pending** until the earlier delivery settles. The diagonal arrow sends guidance
+to a working assistant. **Stop** interrupts that chat without closing it.
+**Reply ready · background task still running…** means the answer is already
+shown but a background command Claude started is still running; any later
+follow-up reply appears after the answer without replacing it.
+Completed replies and progress updates are saved about a second after they
+finish, even while the request is still working and nobody has the chat open,
+so other viewers and a later reopen see them with their actual timing.
+The same controls remain available in narrow layouts. Goals are not offered in
+Temporary chat.
+
+Steering can interrupt an unfinished reply. Any partial reply remains attached
+to its original request; the follow-up response belongs to the new request.
+Reloading the chat preserves that relationship and the recorded AI labels.
+After **Stop** confirms a Claude reply has stopped, text already shown remains
+under **Show all … progress updates** on its original request. It is an
+interrupted partial reply, not a completed answer, and remains after reload.
+If Claude saves more of that same output while Stop is finishing, it remains one
+reply; the saved native copy does not add a second bubble on reload. Text already
+retained for a stopped request is not replayed as a new completed answer.
+Claude's internal no-response placeholder after Stop or a model change is not
+an AI reply. It does not add a new answer to the stopped request. Actual assistant
+replies and provider errors remain visible, even when their wording is similar.
+
+Assistant replies show their recorded AI and model, including streaming and
+reopened history. Hover the label to see its provider. Changing Chat mode affects
+the next request; it does not relabel earlier replies. An older reply without
+recorded selection says **agent**, rather than claiming it used today's choice.
+The existing **Retry**, **Cancel** and **Edit** controls belong to the original
+message; uncertain delivery is checked before any resend.
+
 ## Hand a merge repair to another model
 
 **Fix it with AI** for an Update conflict opens a temporary repair using Senior
@@ -23,7 +63,12 @@ Merge repair always retains the Senior role. To hand it to Codex:
 
 The repair instructions, messages and work already in the session remain. A
 model change does not undo edits or prove the merge correct. **Check Update**
-verifies the repaired session through Vibe64's existing repository operation.
+retries Vibe64's repository operation without acknowledging unresolved conflicts.
+If the repair is already complete, choose **Review resolved conflicts**, inspect
+the file list, then **I've resolved these conflicts — apply Update**. This also
+works after a stopped or failed repair, or after edits made in Main chat. No
+additional AI turn is required. The same review is available on the Update error
+without opening a repair chat. See [Update conflict recovery](github-work.md#apply-an-update-after-resolving-conflicts).
 Only available models can be selected; an active goal must finish before a
 model change. An old request admitted to another role must be cancelled and
 resent to Senior; an already running turn must first be stopped.
@@ -39,6 +84,30 @@ chat keeps receiving progress, and a new assistant reply marks it unread. Open
 that chat to clear its unread indicator. Returning to the view or reloading
 restores saved chats and their history; it does not send the request again.
 
+While Save or Update is changing the session source, an existing chat's saved
+messages remain readable, including older pages. You can keep typing in its
+composer; plain draft text saves independently and stays there after reload.
+The draft's saving/saved/error indicator follows that text save, independently
+of background Update-recovery status saves. Successfully saving text does not
+confirm a failed model-setting save. Failed settings remain pending, and their
+error clears only after the pending state saves. A failed draft save retains your
+text; do not assume it will survive reload until it is saved. If another client has
+started Close, queued autosaves stop and the chat explains that cleanup must
+finish; they do not recreate the closing conversation.
+An unsaved new chat still needs its normal creation step. A model or mode choice
+on its own can be saved for the next turn while Save or Update runs. An update
+that also changes files or repair state waits for the source operation, even if
+it includes a model choice. Sending a message, changing files (including pasted
+or dropped files), stopping work and closing the chat also wait for the source
+operation to finish. A slow chat-update notification does not hold up a separate
+plain draft save once the earlier update has been stored. If one of those actions reports that another
+operation is starting, wait for Save or Update to settle and try that action
+again; do not resend a message whose delivery is uncertain.
+
+A temporary chat opened in one browser tab or window appears in the session's
+other open tabs once it is saved, which happens when it is created or its first
+message is sent. A tab that lost its connection catches up when it reconnects.
+
 Leaving the view does not stop work or close a chat. Use **Stop** to interrupt
 work while retaining the conversation, or **Close** to remove that chat after
 cleanup succeeds. Colleague can explain the current state and perform supported
@@ -46,11 +115,17 @@ chat actions when you request them.
 
 ## Recover a lost delivery confirmation
 
+If the assistant finishes just as you send a steer, a confirmed pre-delivery
+completion rejection lets that same queued message continue once as a new request.
+Stop, cancellation and uncertain delivery never trigger that automatic retry.
+An earlier answer remains attached to its original message even when a later
+message is rejected; the rejected message and its recovery controls remain visible.
+
 If a send fails before admission, **Retry** sends the original message with its
 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 **Check delivery**, use that control with the original message.
+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
 connection cannot read the native receipt, keep the chat and retry the check
@@ -64,8 +139,26 @@ preserves the chat.
 Colleague can explain recovery and perform supported chat actions when asked.
 Choosing a model, stopping work and closing a chat remain separate requests.
 
+During Update repair, **Checking Update…** means the repository operation has
+not yet been confirmed. After a disconnect or reload, an uncertain result is
+shown as unconfirmed, not as success or failure. Check the saved Update status
+before trying again. Only its confirmed result clears the checking state; a
+failed conflict check keeps its review and retry controls.
+
 Background focused tasks keep their selected Helper model and workload limits;
 they do not add their exchanges to Main. A profile audit identifies the selected
 request, not independent proof of provider enforcement or successful completion.
 Wait for the task result before reporting success. No new user control or permission
 is introduced by restoring the server's original detached execution entry points.
+
+
+Typing indicators coalesce actual input into one small update at most every five
+seconds, without sending your draft. They expire within ten seconds of the last
+update. Blur, Send, switching chats and reconnecting send no additional typing
+request. Prompt suggestions wait for a five-second typing pause and at least
+thirty seconds between generations; refocusing does not generate new hints.
+
+Messages and replies appear together in time order, including follow-ups sent
+while the assistant is working. This works the same way in Main and Temporary
+chat, on desktop and phone. Reopening or reloading shows the same history without
+resending messages. Colleague can explain the order; no repair action is needed.

package/docs/colleague-usage/voice-chat.md

@@ -39,9 +39,12 @@ transcript. The face starts visible at the top edge of the message area, below
 the header. After hiding it, the anonymous **Show avatar** icon reveals the
 larger face, smaller microphone/speaker buttons and its settings cog. The small
 round minus button at the end of that controls row tucks them away (accessible label
-**Minimise avatar**). There is no size menu. Messages scroll behind the face itself, with
-the space around it transparent. A short container temporarily compresses the
-artwork and restores it when space returns.
+**Minimise avatar**). There is no size menu. In Colleague's narrow drawer and
+full-screen phone view, this row stays above the scrolling transcript so it does
+not cover messages. A short container temporarily compresses the artwork and
+restores it when space returns. The animated face keeps its reserved artwork
+area while you type or scroll; its animation does not change the size of the
+message controls.
 
 Main's microphone and speaker controls sit with the expanded face, outside the
 original message buttons. Before speech is connected, the speaker button opens
@@ -135,46 +138,10 @@ separately cancels the agent's work. The top-right **Close voice chat** X stops
 releases the microphone and closes the session without stopping agent work.
 Closing discards unsent speech; your typed draft and saved messages remain.
 
-Open this assistant's **Voice settings** cog beside the microphone and speaker
-controls, below its face when expanded, then choose **Speaking voice**.
-Opening settings loads the installed choices without recording. The
-change applies to the next spoken reply. In standalone Vibe64 it lasts for the
-current voice session; a host with saved speech preferences can replace this
-selector and retain the choice across sessions. Vibe64 Online saves your avatar
-and voice personally, separately for Colleague and coding assistants across
-projects. Its Management → **Speech and Colleague** page changes only the shared
-Colleague name; use each assistant's cog for your own avatar and voice.
-The personal cog's **Speak replies** choice controls output for that target.
-In Vibe64 Online, older browser-only speaker choices are not copied into personal
-settings; check **Speak replies** when first using your personal controls.
-While that choice saves, the speaker control briefly waits; microphone capture
-and typed chat remain available.
-For coding assistants, **Read thinking**, **Read progress** and **Thinking sounds**
-also select optional thinking, interim work and a short sound while working.
-These activities use the same speaker and queue as answers.
-Thinking and interim speech default off; thinking sounds default on. They follow
-only the exact current, accessible Main view while the page is visible; hiding
-the avatar does not disable them. Loading history primes the narrator rather
-than replaying old activity. Turning off spoken replies silences all narration.
-Choices and defaults come from the installed model pack and may include male and
-female voices. If only one voice is installed it is shown but cannot be changed.
-Server model setup is an operator task.
-
-Answers start speaking in short phrases before completion; code and dense tables
-remain in chat. Spoken answers use up to 4,000 characters after removing code and
-formatting from the first 8,000 characters of the answer. A long code block within
-that window leaves room to speak the explanation after it. Read the chat for the
-rest of a longer answer; reaching the speech limit does not mean the agent has
-finished. Existing history is not replayed when the window opens. Spoken
-“Stop talking”, “Stop speaking” or “Be quiet” stops audio locally in either live
-mode. Other wording is an ordinary message, so use the explicit button if recognition
-is wrong. Pause detection and echo cancellation depend on the recording environment.
-Use push-to-talk or review when pauses/noise make hands-free unreliable.
-The default service preserves native handling of quiet input. An operator may
-configure an input floor; if quiet words then fail to appear, move closer to the
-microphone and ask the operator to review that setting. **Pause** retains captured
-audio and finishes the final word; review the displayed words before retrying a
-message that was already sent.
+## Face and speaking voice
+
+Choosing the assistant's face and speaking voice is described in
+[Assistant face and speaking voice](voice-face-and-speaking-voice.md).
 
 ## Navigate and switch targets