vibe64 0.1.32 → 0.1.34

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

@@ -20,11 +20,13 @@ alone cannot establish whether the agent is running. Access denial clears cached
 messages and hides Reload: sign in with the authorized account and reopen chat.
 Desktop and phone use the same recovery. Colleague can explain it; reconnecting
 this browser view requires your interaction.
-While that warning is shown, the avatar and its controls occupy space above the
-messages so they cannot cover the warning or **Reload chat**, including on a
-phone. History has less visible height until the warning clears; your avatar
-preference, loaded messages and draft stay intact.
-Scroll chat if a short phone view cannot fit the warning and composer together.
+Connection and chat-update warnings use a compact full-width row above the
+avatar: the recovery button is on the left and the explanation is on the right.
+Text wraps on phones without moving the row below the avatar. The avatar stays
+over the conversation below the warning; its size does not push history down.
+Your avatar preference, loaded messages and draft stay intact. **Reloading…**
+is disabled while reconnection is pending. Scroll chat if a short phone view
+cannot fit the warning and composer together.
 
 Status and recovery panels use a pale blue background with dark text in the
 light theme, and a blue tinted background with light text in the dark theme.
@@ -35,40 +37,44 @@ unavailable while Vibe64 is checking the connection; your draft is kept. In the
 dark theme the notice uses the theme's contrasting text. Desktop and phone show
 the same status and recovery controls; Colleague can explain them, but reconnecting
 the browser requires your interaction.
+The selected chat checks its assistant connection while session details refresh.
+A slow or failed details refresh keeps its own loading/error notice and does not
+turn a verified assistant connection into a connection failure. Hidden idle chats
+refresh their details without starting a provider until you select them.
+
+If an OpenCode readiness check times out, wait for **Retry connection** to become
+available and try it again. That timeout leaves the shared server and other chats
+running; it does not mean your submitted work stopped. Inspect the retained reply
+before resending. The same recovery applies on desktop and phone; Colleague can
+explain it, while the browser reconnection requires your interaction.
 
 ## Send, steer and stop
 
-If Claude cannot initialize, inspect the failed request before selecting **Retry**.
-An initialization failure occurs before that request reaches Claude; it does not
-complete the requested work. Vibe64 keeps a bounded, credential-redacted startup
-diagnostic in its private operational log before confirmed process cleanup. The
-request stays in chat for review; unconfirmed delivery requires **Check delivery**
-before Retry. Colleague cannot read that log.
-
-If an assistant stops because its credits or quota are exhausted, open **Chat
-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. An active coding turn still requires **Stop** first;
-an unfinished goal requires **Cancel goal**. 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 old request or confirm uncertain delivery. Use **Check delivery** for that
-original request before deciding to repeat it; send a new instruction when you
-want the new assistant to continue the work. After the switch, **Send** becomes
-available automatically; reloading or **Check delivery** is not required to
-start a new request. **Previous assistant delivery unconfirmed** describes the
-old attempt and explains how to continue with your selected assistant. Its
-**Check delivery** control only checks that previous attempt.
-These steps apply on desktop and
-mobile. Colleague can explain the notice and change a supported selection when
-you ask it to; provider credit top-ups require your interaction.
-
-If failure, Stop or reconnection observes different outcomes for one assistant
-turn, Vibe64 reuses that turn's first recovery checkpoint and its recorded
-outcome. A failed turn can therefore have a valid checkpoint. A warning about
-a genuine identity or storage failure still needs operator investigation; your
-files remain in the session.
+While **Send** is pending, Vibe64 prepares the selected assistant and waits for
+delivery acknowledgement. Codex reuses an already-ready project environment;
+missing resources or changed Env files still require preparation. Wait for
+delivery or a reported failure before retrying the request. The same behaviour
+applies on desktop and mobile; Colleague can explain a delay but cannot skip
+the connection or preparation checks.
+While the first request is starting, you can submit a follow-up in a connected
+Codex or Claude chat. It appears as **Pending** while the delivery queue waits
+for the current submission. The queued bubble stays after that submission even
+if preparation delays the earlier message's recorded time. Pending is not a
+delivery acknowledgement. A lost
+connection or an unconfirmed stop can still prevent Send; resolve that notice
+before submitting more work. Desktop and mobile use the same queue.
+The current submission's routing status does not disable additional **Pending**
+messages in that queue. A genuinely uncertain delivery still needs its receipt
+checked before more work is submitted.
+**Stop** also cancels follow-ups still waiting locally to be sent. **Send** stays
+unavailable while Stop is being confirmed. Already dispatched requests retain
+their delivery status; inspect them before deciding whether to send again.
+
+Codex, Claude and OpenCode share the project-format check before refreshing
+skills and agent guidance. This check reads the format marker without scanning
+application files; it does not replace the separate guidance checks.
+
+When an assistant cannot start, stops by itself or reports a failure, see [When a coding agent fails or stops](coding-agent-failures.md).
 
 1. Select the intended project and session, then Main or the intended temporary
    conversation. Type the request and select **Send**.
@@ -88,81 +94,37 @@ A visible authored message can confirm delivery before the original request retu
 wait for its answer instead of sending it again. This applies to Codex steering too.
 Your draft, uploaded file references and failed requests stay with the same
 signed-in person, project and session across a page reload. Restoring them does
-not send anything. Review an unconfirmed request before using **Retry**; when
-**Check delivery** is shown, it checks the existing request without resending it.
-An unconfirmed request keeps that control even if a saved routing error says it
-failed. Retry, Edit and Cancel become available only after its delivery is resolved.
-A rejected **Steer** returns to the composer; **Retry** retains its request ID
-and any newer draft text. Steering arriving after a finished turn is failed,
-not **Check delivery**, and never becomes new work automatically. Use its
-**Cancel** or **Edit** recovery before deliberately sending new work. A genuinely
-lost receipt stays uncertain until the delivery check confirms it. If Vibe64 saved
-that this exact request failed before sending, or was definitely rejected, **Check
-delivery** confirms it was not sent and restores **Retry**, **Edit** and **Cancel**.
-Checking never sends it; **Retry** is a separate deliberate action.
+not send anything. **Retry** retains the original ID and payload. In Main, when
+no matching routing request is recorded, it submits that same request through the
+existing server coordinator, which checks for duplicates and earlier dispatch.
+If native delivery was already attempted, recovery checks its receipt instead
+of repeating the work. A conflicting saved failure is checked before retrying.
+While the status says **awaiting receipt**, wait for confirmation rather than
+submitting another copy. That wait can include preparation, native acknowledgement
+and saving the receipt. If it repeatedly takes a long time, give the operator the
+project/session URL and approximate send time. The operator can compare message
+delivery timings for Codex, Claude and OpenCode, including the routing and
+message-preparation phases before native delivery, without reading the prompt or
+credentials. Colleague can explain this status; inspecting server logs requires
+the operator or a coding agent with authorized access.
+Clicking twice during a pending retry does not submit again; your separate
+composer draft stays intact.
+**Edit** and **Cancel** remain unavailable while delivery is uncertain.
+If a turn finishes successfully just before **Steer** arrives, Vibe64 sends that
+same message as a new request after confirming it was not delivered. You do not
+need to send it again. This applies to Codex and Claude on desktop and mobile.
+Stopped, cancelled, failed or unverified turns do not authorize this recovery.
+Other rejected **Steer** messages return to the composer; **Retry** retains the
+request ID and any newer draft text. Use **Cancel** or **Edit** before changing
+the request. Colleague can explain the status; browser recovery controls require
+your interaction.
 After changing the signed-in person or AI connection, resolve that change before
 checking the original request; a different account cannot confirm it was not sent.
 If OpenCode cannot confirm delivery, checking its status does not send the request
 again. An unavailable receipt remains uncertain; inspect the conversation before
 deciding what to send next. This also applies to steering instructions.
-OpenCode can receive a message before Vibe64 finishes saving it. An early reply
-does not confirm that the message was saved. If saving fails, keep the same
-request and use **Check delivery** when shown before retrying. Ask the operator
-to restore storage if needed, or resolve the reported **Stop** failure first;
-neither recovery repeats the prompt.
-After OpenCode restarts, opening a conversation can take longer while its working
-directory is prepared. Wait for preparation to finish before using the chat.
-If preparation fails, resolve the reported error and retry; the saved conversation
-is retained and preparation does not send a message. Colleague can explain the
-error; an installation problem requires the workspace operator.
-When Claude or OpenCode reports a model or execution failure, read the reported
-conversation status and check any reply before deciding whether to send another
-request. Reply text by itself does not prove that the turn completed successfully.
-Unconfirmed cleanup blocks replacement work, including after failed startup.
-While Claude is starting, **Stop** joins that process's existing cleanup. Its
-execution is recorded once; waiting for initialization does not disable Stop.
-Restore the execution service and retry **Stop**; wait for success before new
-work. Do not resubmit an uncertain request as a workaround. Project **Close**
-also retries pending cleanup and reports unconfirmed exit; a failed Close is
-not successful cleanup.
-If Codex reports lost observation, wait for it to confirm that work stopped.
-A failed application-tool call can also require confirmed native cleanup.
-Changing the model does not clear that responsibility; finish **Stop** before
-sending more work, and inspect the retained reply or error before retrying.
-If Stop cannot be confirmed, restore the connection and select **Stop** again;
-the same conversation retains its cleanup responsibility. Checking or reopening
-the conversation does not resend the request. A recovered reply appears in its
-original chat; read it before deciding whether to repeat a message. Use **Send** when
-you intend to continue. Colleague can explain the reported state; continuing or
-stopping work still needs your instruction. These steps apply on desktop and
-compact screens.
-Changing Codex models keeps saved history. Earlier incompatible tool calls are
-context, not new work. A compaction error does not undo saved file changes.
-Colleague can explain the notice; retrying or changing models still needs your
-instruction.
-When OpenCode's shared service fails, other affected conversations can also stop.
-Inspect their status and existing work before selecting **Send** again; recovery
-does not automatically repeat their requests. An ordinary conversation close
-keeps the shared service available to its other conversations. Colleague and
-project chat share this service: closing either one leaves the other available.
-If recovery has to stop the shared service, inspect both chats before retrying.
-A failed OpenCode **Stop** leaves the current turn available for another **Stop**
-attempt. After Stop succeeds, **Send** starts the next turn in the same conversation.
-The same Stop and retry rules apply to temporary chats.
-If OpenCode reports **Project guidance could not load**, its project instructions
-were unavailable; this is not confirmation that your API key failed. Ask the
-installation owner to check the installed Genesis runtime and project hook. Once
-that prerequisite is repaired and the conversation is ready, enter a new message
-in the same conversation and select **Send**. The failed message remains in its
-history; its composer draft is not retained. Colleague can explain the notice,
-but repairing the installed runtime requires the installation owner.
-The same recovery applies on desktop and mobile.
-A temporary message may appear before the assistant confirms receiving it.
-If it still shows **Check delivery**, use that control and keep the same request;
-its visible bubble alone is not confirmation. An unavailable receipt stays
-unconfirmed and keeps its files and any newer composer draft. Checking does not
-submit another native turn. Colleague can explain the reported state; a new
-request still needs your instruction.
+For provider startup, interruption and delivery recovery, read
+[Coding-agent recovery](coding-agent-recovery.md).
 
 An attachment upload refused because its session is closing identifies whether
 the session is being archived or deleted when that reason is known. No file is
@@ -170,18 +132,20 @@ added. Use an open session before uploading again. Colleague can explain the
 notice; it cannot override the closing check. The same rule applies on desktop
 and mobile.
 
-If Claude asks you to stop before changing its settings or instructions, select
-**Stop**, wait for it to succeed, then retry the change. Its existing conversation
-history is retained. Colleague can explain the error and perform a supported
-change when you explicitly ask; stopping work still needs your instruction.
-
-To change the model for an active Update merge repair, select **Stop** first and
-wait for it to succeed. In that repair's composer, open **Chat mode**, then
-**Choose model**. In **Custom AI**, choose a **Model** and select **Apply**.
-The repair still uses **Senior**. Your selected model stays saved for that repair,
-its history is retained, and Main chat's model is unchanged. Select **Send** to
-continue the repair. On compact screens, reveal chat first; the controls are
-the same as on desktop.
+Open **Chat mode** at any point to choose **Senior**, **Junior**, an
+**Orchestrator**, or **Custom** → **Apply**. 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 orchestrator. 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.
+
+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
+**Model** and select **Apply**. The repair keeps **Senior**, its history and its
+current turn. The next turn uses the selected model; Main chat's model is
+unchanged. On compact screens, reveal chat first; the controls are the same as
+on desktop.
 
 Returning to Main chat or reloading the page keeps a saved temporary conversation.
 To remove it, use the **Close** control on that chat's tab. If stopping or cleanup
@@ -189,38 +153,6 @@ fails, the chat stays available; resolve the reported error and try **Close** ag
 Closing removes that conversation's history and attachments after cleanup succeeds;
 source edits remain. The same controls apply on desktop and compact screens.
 
-An unsupported OpenCode version needs operator runtime repair before retrying;
-repeating a message cannot fix it. Colleague can explain this startup error on
-desktop or mobile but cannot repair the host installation.
-
-If OpenCode produces reasoning without a final answer, it makes one automatic
-attempt to obtain that answer. You can still send a new instruction; it waits for
-that recovery message to be confirmed before delivery. **Stop** remains available
-while it waits. If delivery or the final answer cannot be confirmed, inspect the
-existing messages and work before retrying; do not send the same request again.
-The original request and its reasoning remain in the chat. These controls work
-on desktop and phone; Colleague can explain the status and offer a supported
-check, but does not silently repeat your message.
-Progress summaries describe the work in progress; they do not mean the final
-answer is ready. They remain attached to the same conversation after reconnecting.
-
-For goal controls and changing models while a goal is paused, read
-[Goals and model changes](coding-agent-goals.md).
-
-If a Learning practice conversation's source clone was removed, Codex shows the
-same clone-recovery notice as a Working conversation. Keep the saved lesson and
-request while resolving the missing clone before retrying.
-
-If Codex cannot load its model catalogue, ask the operator to check its
-installation/connection and restart the assistant service. Colleague can explain
-this desktop/mobile recovery but cannot perform the host operation.
-
-If Codex stops while the editor restores its managed controls, its notice identifies
-that interruption. An interruption with no known cause is not reported as a
-provider failure. **Stop**, service restart, missing final-response delivery and a
-confirmed provider failure retain their distinct notices. Your saved file changes
-remain; inspect the result and send a new message when ready to continue.
-
 ## Answer assistant questions
 
 For numbered question fields, suggested answers and normal chat replies, read
@@ -239,3 +171,59 @@ OpenCode keeps lesson progress and the final answer attached to the same accepte
 request after **Send** returns. A prepared lesson question is shown as delivered
 only when that request’s exact final answer is saved; a progress message alone
 does not confirm delivery.
+
+Typing and returning to the window do not refresh Colleague or goal status.
+Their existing live connection still delivers changes and reconciles after a
+reconnection. Typing indicators send one small update at most every five seconds
+while you type, containing no draft text. They expire within ten seconds of the
+last update; leaving the input sends no extra request.
+
+Prompt suggestions wait for five seconds without draft changes, and start no
+more than once every thirty seconds in the current view. Refocusing does not
+regenerate dismissed suggestions. Changing the draft can request new suggestions
+after those limits; unchanged input does not poll. You can keep writing and send
+without waiting for suggestions.
+
+An unconfirmed message shows small red error text and **Retry** inside
+its own bubble. The notice belongs to
+those exact words; it does not describe the previous assistant reply. The layout
+is the same on desktop and phones.
+
+A message rejected before sending, including text beyond the input limit, stays
+failed with its original error. Use **Edit** to shorten it or **Cancel** to remove
+that rejected attempt. Cancel does not send the message, remove accepted history,
+or bring the failed bubble back after a reload. These controls work the same in
+the standalone editor and a hosted workspace. A lost delivery acknowledgement
+still requires checking the exact request; it is not treated as a rejection.
+
+If **Retry** reports that delivery is still unknown, the old message
+remains visible. Once the conversation is ready, you can type and **Send** a
+different message. The uncertain message is not resent, and its same words remain
+blocked until its delivery is resolved. Active or unresolved server work still
+blocks continuation. Checking again reports the latest result rather than keeping
+an earlier connection error. Colleague can explain recovery; sending a new message
+or checking delivery remains your explicit action.
+
+Claude cold startup can wait up to 90 seconds for its initialization handshake
+while managed startup probes finish. **Pending** means the message has not yet
+been acknowledged. Keep the bubble in place; use its **Retry** action after a
+failure rather than sending another copy. Stop and other normal controls retain
+their existing deadlines.
+
+For a slow Claude start, an operator can inspect the private startup diagnostic.
+A successful start taking over five seconds records one warning with total time,
+time until the managed process stream was ready, and time spent initializing
+Claude afterward. This separates process launch from native initialization;
+the timing record contains no prompt, credentials or native output. A warning
+does not mean delivery failed: the message's acknowledgement remains authoritative.
+
+If Claude rejects an input before writing it to the native process, its retained
+request becomes retryable after delivery inspection. Use **Retry** on that exact
+message. An uncertain acknowledgement still uses **Retry delivery check** first;
+that action checks the existing receipt and does not submit a duplicate.
+
+### Tables in chat
+
+Assistant replies display Markdown tables as tables, including tables with blank
+column headings. On narrow screens, scroll a wide table horizontally to read
+its remaining columns. Reloading preserves the same table from saved history.

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

@@ -8,6 +8,12 @@ Completed replies restore the ready controls through the live connection. If
 that connection is unavailable, refresh or reopen Colleague to reconcile the
 saved result; this does not resend your request.
 
+If a previous attempt failed before it was sent to the AI, reopening Colleague
+leaves it ready without an uncertain-delivery warning. The earlier failed reply
+stays in history. Send a new message when ready; reopening does not repeat the
+old request or any operation. A request that may have reached the AI still needs
+the delivery checks below.
+
 While Colleague is working, you can type a follow-up and choose **Send**. Each
 message keeps its own words. Colleague considers the queued messages in order
 before acting on an earlier response and answers the latest request. Sending a
@@ -15,8 +21,8 @@ follow-up does not stop the native conversation or put its internal tool respons
 into your message bubble. Microphone and spoken-reply settings stay independent.
 
 If the first message needs model setup, the draft stays in the message box.
-Complete that setup, then send it again. If delivery is uncertain, use **Check
-delivery** before retrying; reconnecting does not automatically send it twice.
+Complete that setup, then send it again. If delivery is uncertain, **Retry**
+checks its original receipt; reconnecting does not automatically send it twice.
 If inspection proves that the native request was never admitted, the bubble
 changes from unconfirmed to failed and sending becomes available again. Its words
 and your newer draft stay intact. Use **Edit** to move those words into the
@@ -24,11 +30,21 @@ composer, or **Cancel** to remove the failed bubble; nothing sends automatically
 After changing models, send those words as a new message rather than using the
 old bubble's **Retry**, which keeps its original native identity.
 With OpenCode, a reply can appear before Vibe64 saves delivery confirmation.
-If that save fails, retain the request and use **Check delivery** when offered;
+If that save fails, retain the request and use **Retry** when offered;
 reply text alone is not confirmation. Ask the operator to restore storage if
 needed, or resolve the reported **Stop** failure before continuing. Recovery does
 not resend the uncertain message.
-If **Check delivery** still cannot confirm the message, **Start fresh** opens a
+The affected bubble shows its error in small red text with **Retry**. It must
+not be read as a confirmed sent message or as an error belonging to the preceding
+reply.
+
+If **Retry** still cannot confirm the message but the conversation is
+ready, you can send a different message in the same chat. The unconfirmed message
+stays visible and is not resent. Its same words stay blocked until the outcome is
+known. Returning focus to the window makes no refresh request; the live connection
+still refreshes on relevant events and reconnects.
+
+Alternatively, **Start fresh** opens a
 confirmation. It retains the old conversation and unconfirmed words, starts a new
 chat without its old context, and resends nothing. Your model choice, watches and
 assignments stay in place; their coding agents keep running. Finish the current
@@ -45,6 +61,11 @@ operation ID and original annotation payload are retained; do not resend the
 uncertain AI message. Background refresh waits until this operation is resolved.
 A storage or retirement error leaves the current identity
 in place and reports the failure.
+If Vibe64 reports that saved Colleague history is invalid, it leaves the file
+unchanged instead of opening an empty replacement. The owner must restore or
+repair that saved file; then reopen or retry Colleague. A server restart is not
+required after the repair. A genuinely missing record opens as a new empty chat
+in memory and is not written merely by viewing it.
 An earlier history read cannot reopen the retained conversation after Start
 fresh succeeds. Return to the current chat; that read never resends its messages.
 Open **Previous conversations** to read the retained messages and pages. Scroll
@@ -102,7 +123,9 @@ reply.
 If Codex reports a failure without a final reply, Colleague checks that exact
 request's saved native history. A completed answer is recovered once. Otherwise
 Colleague reports the failure and stops the failed native turn through its
-existing cleanup. If cleanup cannot be confirmed, use **Stop** before continuing.
+existing cleanup. The failure appears in red above Colleague's message box, even
+when its turn produced no reply; an operation it could not verify also stays
+listed under **Operations** for inspection. If cleanup cannot be confirmed, use **Stop** before continuing.
 This recovery does not resend your request or use another turn's answer.
 If an admitted Codex action fails during a native goal, cleanup verifies that the
 same goal is paused before the request settles. After the native turn is confirmed

package/docs/colleague-usage/colleague-upgrade-recovery.md

@@ -31,3 +31,7 @@ qualified historical correction after checking the exact original native input,
 completed answer and account/scope custody. It preserves the chat and its native
 identity. A missing flag by itself is not permission to resume or resend anything;
 unsupported or uncertain native evidence still prevents activation.
+
+Current chat formats continue through their original migration; the historical
+correction leaves them unchanged. A continuity error still requires the operator
+to inspect its exact evidence before activation.

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

@@ -0,0 +1,84 @@
+# Colleague watches and operations
+
+Ask Colleague to watch work or inspect a recorded operation. Watching does not
+authorize more coding work. For chat controls and assignments, see
+[Talk with Colleague](colleague.md).
+
+Ask “Tell me when that agent replies, even while it keeps working” to request a
+response watch. Colleague can watch the exact Main or temporary conversation and
+report its next completed message, including a progress reply during an active
+goal. Partial words, thinking and tool output do not trigger it. A reply does not
+mean the task is done: Colleague reports what the agent actually said and whether
+work continues. Ask for an ongoing watch to receive later responses too; a
+one-shot watch ends after its first delivered report. Ask “Tell me when the work
+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.
+
+Use the eye-and-count **Watches and assignments** button beside Previous
+conversations to inspect ongoing work. It opens a separate view; nothing is
+listed below chat. **Resume** restarts a paused watch, and **Cancel** removes its
+watch without stopping the agent. Close this view to return to the same chat and
+draft. On phone, use **Close watches and assignments** in its header. Ask
+Colleague to list, cancel or resume watches if you prefer.
+
+In an active Learning task, “Watch me while I do this” starts the same polling
+watch shown in that dialog; asking how it works does not start anything. You can
+ask Colleague to read, pause, resume or stop it. Learning status reports the exact
+goal/target, active/paused/unavailable state, latest valid observation and time,
+last delivered-help receipt, and any saved assessment outcome. Observation and
+help are not themselves proof of completion. When Main points you to a place
+(a ring and caption on the real control), the view switch you then make yourself,
+such as Preview to **Dashboard → Database** or **Dashboard → Files**, is observed as
+your step; a database sub-view switch (Overview/ERD/Data) is not yet observed
+separately. Besides Vibe64 view and control
+steps, the watch notices a failed data-changing request that your own click or
+submit in the visible practice-app **Preview** started (method, a lesson-declared
+path or `other`, status and failure code only—never typed text, bodies, headers
+or queries); Main gets at most one hint for it per 30 seconds. A separate Learning watcher checks
+only those validated facts; Colleague manages its controls, while Main receives
+bounded updates and never checks your activity itself. Each observation is
+delivered to Main once. Switching between the practice project's **Preview** or
+**Dashboard** and the graduation-cap **Learning** option, and between project panes such as
+**Preview**, **Dashboard → Database** and **Dashboard → Files**, is observed; a
+lesson without a practice project, such as Lesson 0, can be watched too. Stop
+removes the watch without stopping Main, the lesson or the app, and polling grants
+no unrelated mutation permission. For the eye dialog's controls, see
+[Watching a lesson step by step](learning-lesson-watch.md).
+
+You can ask “Which projects do I have?” from any page, including AI Accounts;
+no open project is required. Colleague checks the projects available to you.
+A completed or attempted application action also appears under **Operations**
+beside Previous conversations. Open it to see Vibe64's recorded state—executing,
+completed, failed or unknown—and the saved project/session/conversation target.
+**Open target** uses the normal project and chat navigation without rerunning the
+action. **Prepare retry** writes a cautious follow-up into your draft after a
+verified failure; review it and press **Send** yourself. It does not replay the
+action when clicked. For an unknown outcome, use **Prepare inspection** instead:
+the draft asks Colleague to inspect the saved target and forbids repetition until
+the real outcome is known and you explicitly continue. Internal catalogue lookups
+are not shown as product operations. These controls work the same way in the
+desktop drawer and full-screen phone chat.
+Opening or restoring Colleague moves keyboard focus into the message box. From
+there, **Tab** reaches the model, history, Operations, watch, Send and Stop
+controls that are currently available. **Escape**, **Minimize conversation** and
+**Close Colleague** return focus to the Colleague launcher; the full-screen phone
+chat keeps keyboard focus within its dialog while it is open.
+The avatar and its voice controls keep their own space above the conversation;
+they do not cover the first message on narrow screens.
+An unfinished operation retained from before these product receipts existed is
+shown as **Unknown** after restart, without an invented target or retry. Inspect
+the affected area before deciding whether to make a new explicit request.
+A malformed lookup returns a validation error. An unavailable tool runs no action;
+Colleague receives its verified refusal and can give a final reply. A provider failure
+or uncertain operation stops the turn. Your request is retained. Read the reported error and
+inspect the action's target before trying again; you can select another model
+once the turn has stopped. If a model change was interrupted, select that same
+model again to finish the change before sending another message.
+An operation-limit error keeps completed results; send a follow-up. Repeated
+invalid responses keep your message; retry or choose another model after the
+turn stops. This does not mean your projects are missing or your account disconnected.
+
+Colleague can look up an operation and then carry it out within the same request.
+Changing its focused project or switching between your request and background
+observation requires a new lookup. Current permissions still apply: an earlier
+lookup cannot make an operation available after access is removed.

package/docs/colleague-usage/colleague.md

@@ -66,6 +66,13 @@ Minimizing or reopening the view does not itself stop a response.
 The model picker is unavailable during a turn or while sending.
 A completed reply returns the chat to ready and restores the model controls
 through its live connection, without reloading the page.
+If the first request finds no usable model, Colleague shows a warning that your
+draft is kept and no request was sent. Choose **Open AI Accounts**. Hosted Vibe64
+opens Management → AI Accounts; standalone Vibe64 opens its existing Account
+settings on **AI Accounts**. Connect an AI and configure an available Senior
+model, then return and press **Send**. Opening setup does not send the draft or
+promise a response from an unavailable model. Credential entry and provider
+consent remain your actions.
 Model changes keep saved messages and replies, including between native and API.
 A changed engine, provider, model, agent or effort prepares the next conversation;
 the same selection retains it. Applying starts no model work.
@@ -79,7 +86,7 @@ A failed response can leave native cleanup unfinished; selecting a model does
 not silently stop it or resend the request.
 For native reply failures and AI setup errors, see
 [Colleague delivery and recovery](colleague-recovery.md#failed-replies-and-setup).
-For **Check delivery**, **Start fresh**, **Previous conversations** and retained
+For **Retry**, **Start fresh**, **Previous conversations** and retained
 drafts, see [Colleague delivery and recovery](colleague-recovery.md). Recovery
 never automatically resends an unconfirmed message.
 
@@ -90,6 +97,14 @@ to restore execution, then retry in the same conversation. Use **AI Accounts**
 to reconnect only when the account check asks you to sign in.
 Colleague uses the same saved native Claude login as Main. Opening Colleague
 does not move that login to another profile or require a separate sign-in.
+After the workspace Claude account changes, your next Colleague request uses the
+current account and keeps the conversation history. The old assistant process
+must stop first. If cleanup fails, restore execution and use **Stop**, then retry;
+Colleague will not continue with the old credentials. A completed action receipt
+from the old account cannot be replayed as the new account.
+Saved Colleague errors stay inside Colleague when you reopen the workspace; they
+do not raise an unrelated global alert over your project chat. Open Colleague to
+read the error and its recovery controls.
 If reopening reports another working directory or credential home, ask the
 workspace operator to restore the original host configuration. Do not move native
 history files or change accounts to bypass the warning. The shared driver can
@@ -159,39 +174,8 @@ Its completed notification can still be spoken when sound is on. A saved notice,
 “An update from your watched conversations.”, appears before the completed answer,
 including after reopening. Internal watch instructions and tool arguments stay hidden.
 
-Ask “Tell me when that agent replies, even while it keeps working” to request a
-response watch. Colleague can watch the exact Main or temporary conversation and
-report its next completed message, including a progress reply during an active
-goal. Partial words, thinking and tool output do not trigger it. A reply does not
-mean the task is done: Colleague reports what the agent actually said and whether
-work continues. Ask for an ongoing watch to receive later responses too; a
-one-shot watch ends after its first delivered report. Ask “Tell me when the work
-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.
-
-Use the eye-and-count **Watches and assignments** button beside Previous
-conversations to inspect ongoing work. It opens a separate view; nothing is
-listed below chat. **Resume** restarts a paused watch, and **Cancel** removes its
-watch without stopping the agent. Close this view to return to the same chat and
-draft. On phone, use **Close watches and assignments** in its header. Ask
-Colleague to list, cancel or resume watches if you prefer.
-
-You can ask “Which projects do I have?” from any page, including AI Accounts;
-no open project is required. Colleague checks the projects available to you.
-A malformed lookup returns a validation error. An unavailable tool runs no action;
-Colleague receives its verified refusal and can give a final reply. A provider failure
-or uncertain operation stops the turn. Your request is retained. Read the reported error and
-inspect the action's target before trying again; you can select another model
-once the turn has stopped. If a model change was interrupted, select that same
-model again to finish the change before sending another message.
-An operation-limit error keeps completed results; send a follow-up. Repeated
-invalid responses keep your message; retry or choose another model after the
-turn stops. This does not mean your projects are missing or your account disconnected.
-
-Colleague can look up an operation and then carry it out within the same request.
-Changing its focused project or switching between your request and background
-observation requires a new lookup. Current permissions still apply: an earlier
-lookup cannot make an operation available after access is removed.
+For response watches, Learning observation and recorded action outcomes, read
+[Colleague watches and operations](colleague-watches.md).
 
 Recognized words can appear as a Pending user message in chat; acceptance replaces
 it with the saved message once. Unsent or discarded words are not saved history.