vibe64 0.1.35 → 0.1.36

package/docs/colleague-usage/lesson-authoring.md

@@ -4,7 +4,8 @@ Ask Colleague to coordinate a coding agent, review the lesson in the same sessio
 and publish its source through the existing Save or pull-request workflow.
 Colleague can operate those controls when requested; it does not edit files or
 run a shell itself. Git publication, pinned course material and installation are
-separate results. The current learner offering remains one introductory lesson.
+separate results. The current Getting started course has four step-based lessons
+(V64-START-00 to V64-START-03).
 
 ## Choose the authoring target
 
@@ -15,24 +16,22 @@ connection, repository access and Git author identity remain the person's normal
 account steps. Opening, creating or importing a new GitHub project uses the
 existing hosted UI; Colleague must not invent an import or source-access tool.
 
-For the current introduction, revise the existing V64-START-01 topic rather than
-exposing a second lesson. Preserve its permanent IDs, six assessments, actual App
-button/check correlation and declared SVG/controller protocol unless the person's
-request explicitly changes that content. New lesson content may be authored as
+To improve an existing lesson, revise it in its topic rather than exposing a
+duplicate lesson. Preserve its permanent lesson and step IDs, its declared checks
+(including the actual App button/check correlation) and its SVG/controller
+protocol unless the person's request explicitly changes that content. New lesson content may be authored as
 a draft using the existing template below; a draft is not another learner release.
 
-For the revised Learning flow, Main teaches the lesson and Colleague stays the
-general supervisor. Keep the introduction’s original Colleague leave/restore task:
-the learner uses that real drawer and returns to its retained task while the Main
-lesson stays saved. Hiding Main does not replace that practical. Review genuine
-workspace, application and diagram evidence before calling the candidate ready;
-content validation does not supply missing teaching controls. Changed teaching
+Colleague teaches every lesson from its steps in the Learning environment.
+Review genuine workspace,
+application and diagram evidence before calling the candidate ready; content
+validation does not supply missing teaching controls. Changed teaching
 text needs a new immutable topic/course pin, keeping earlier learners’ versions.
 
 ## Delegate and review
 
 For example: “In this lesson-authoring project and session, improve the introduction's
-wording, keep its six assessments and App/diagram contracts, validate and bundle it,
+wording, keep its step IDs, checks and App/diagram contracts, validate and bundle it,
 arrange a review, then publish the source as a draft PR. Do not install or enable it.”
 This is an example instruction, never authority to execute it without the person's
 actual request. A how-to question makes no edits, assignment or external write.
@@ -94,8 +93,19 @@ Vibe64 command. These authoring commands do not by themselves expose a learner c
 install a topic or start a lesson. Do not offer to start a course merely because
 its files validate.
 
-Use a topic repository whose name begins with `learn-`. Keep the teaching document,
-assessment rubrics, SVG descriptors and runnable exercise in that repository.
+Use a topic repository whose name begins with `learn-`. Keep the lesson
+descriptors, step texts, SVG descriptors, checks and runnable exercise in that
+repository. An exercise needs no `.gitignore` for Vibe64's agent guidance
+folders (`.agents`, `.claude`, `.codex`, `.opencode`): practice projects keep
+them out of the learner's changes by themselves. New lessons use lesson format v2 (`schemaVersion: 2`): optional
+notes and 1–32 ordered steps. Each step has a Markdown body a learner can read
+without AI, an optional diagram to play and an optional guide that points at a
+real Vibe64 place, and one check: `auto` (a declared check against the
+learner's own exercise work), `choice` (multiple choice with an answer kept on
+the server), `self` (the learner presses **Done**) or `none` (reading only, never
+required; the learner may still press **Mark as done**). Check verdicts are final: there is no rubric or AI grader, and
+Colleague never passes a step. Older v1 lessons (teaching document plus
+assessments) still validate for history but cannot be started.
 The installed `docs/templates/learn-topic/` directory supplies a copyable whole
 topic. The author copies it to a new directory, follows its README to choose
 permanent identifiers and replace placeholder content, then validates it. Its
@@ -113,7 +123,7 @@ These commands use that session's existing filesystem and Git access. Keep the
 inputs and outputs within the authorised authoring assignment. They do not grant
 Colleague source access or permit a coding agent to install or enable courses.
 Success lists ordered lesson hashes and distinguishes published lessons from drafts.
-A failure means the author must correct the reported schema, reference, rubric or
+A failure means the author must correct the reported schema, step, check, reference or
 path problem; it does not change their project or learning history.
 
 To produce local release material, the author runs
@@ -168,9 +178,9 @@ operator steps below remain for content outside that catalogue, for an author's
 own snapshots, and for disabling a release.
 
 In supported hosted installations, ask Colleague to admit your exact clean
-committed snapshot from the authorized authoring session. Then turn on Learning
-mode in that project view and use **Resume author trial** under **Courses** to
-open its same Main teacher. This saved trial has isolated progress; it is not an
+committed snapshot from the authorized authoring session. Then open Learning with
+**L**; on its **Courses** tab the **Author trial** card shows the snapshot's lesson
+and release, and **Resume author trial** opens it in the ordinary lesson reader, the page's **Lesson** tab. This saved trial has isolated progress; it is not an
 enabled learner course. Ordinary **Start** still requires a published lesson in
 an enabled release. Local validation/bundling alone admits no trial. Do not change
 a draft's status to bypass that guard or report a trial as published progress.
@@ -199,13 +209,11 @@ then reads the fresh installed catalogue before changing enablement. Colleague c
 list the resulting enabled course through its normal learning query after the
 operator completes this step; absence is not permission to fabricate a substitute.
 Existing attempts keep their saved pins. Source publication alone does not prove
-installation, learner delivery, assessment completion or pilot acceptance.
+installation, learner delivery, step completion or pilot acceptance.
 
-Question delivery keeps its exact lesson attempt attached to your answer. An
-unfinished question or one retained from an earlier fresh conversation does not
-become a new assessment. Switching the displayed Preview is not permission to
-move an answer or a diagram checkpoint into another lesson's progress. The
-saved trial control uses the original snapshot admission and explicit refresh
+Each step result stays attached to its exact lesson attempt. Switching the
+displayed Preview or project is not permission to move an answer or a check
+result into another lesson's progress. The saved trial control uses the original snapshot admission and explicit refresh
 operations described above. Edited source requires a deliberately ended old trial
 and a newly admitted committed snapshot; Resume keeps the existing pin.
 

package/docs/colleague-usage/managed-app-access.md

@@ -26,6 +26,13 @@ account creation and browser sign-in have distinct effects. If the application
 cannot resolve an identity, check that account and the declared exchange rather
 than inventing another selector type. A failed save retains recoverable feedback.
 
+The coding agent can also save this list for you in its session. Tell it which
+existing accounts to use, or confirm the names and accounts it proposes from the
+application's existing accounts. It saves only what you asked for or confirmed,
+never creates application accounts or changes roles, and then signs in as each
+name in Preview to verify access. The saved list appears here and in Preview's
+identity menu; use the session's normal Save to keep it.
+
 Colleague can read the available identity metadata and make an explicitly requested
 configuration change, including a selective removal, through the native owner.
 It can open App access and delegate application-account investigation to a coding

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

@@ -37,12 +37,13 @@ unknown delivery or claim a failed request was delivered.
 
 ## When a turn finishes while you send
 
-Sending a new instruction while Claude works uses its targeted **Send now**
-control when supported by the installed Claude version. Background agents and
-background tasks continue; foreground work may be interrupted to read your
-instruction. This also applies to **Set goal** and **Resume goal** during active
-work. **Stop** keeps its cancellation behavior. Older Claude versions retain
-their previous interruption behavior. These controls work on desktop and mobile.
+Sending a new instruction while Claude works never interrupts it. Claude queues
+the message, lets the running command finish (for example a long deploy or test
+run), then reads your instruction before continuing. Background agents and
+background tasks also continue. A short question such as "status?" therefore
+gets its answer once the current command completes, not immediately. This also
+applies to **Set goal** and **Resume goal** during active work. Use **Stop** when
+you want to cancel the current work. These controls work on desktop and mobile.
 
 If you send a steering message just as Claude or Codex finishes, the queue can
 submit those same words and attachments as the next ordinary request. This happens

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

@@ -39,11 +39,19 @@ Other tool dependencies still need their own declared runtime support. A fixture
 setup failure does not count as a failed application assertion or a passing check.
 
 The coding agent can read `vibe64-helper playwright --help` before a project has
-browser tests or a matching test runtime. Help starts neither Preview nor a browser.
+browser tests or a matching test runtime. `vibe64-helper preview --help` (also
+`preview browser --help`) works even while the assistant's Preview control is
+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.
+On a computer without managed browser runtimes, the agent runs the project's own
+Playwright (`npx playwright test`). If that browser is missing, the agent reports
+it and asks you before running `npx playwright install chromium`; installing it
+is your decision.
 
 Before a suite, the coding agent can run `vibe64-helper playwright readiness`.
 It distinguishes absent tests, uninstalled dependencies, an unsupported exact

package/docs/colleague-usage/preview-starting-application.md

@@ -64,7 +64,6 @@ The same diagnostic record family separates slow conversation access checks into
 fresh user lookup, saved learning-attempt validation, practice scope, project
 access and project-context resolution. It records the elapsed phases even when
 access fails; repeated checks keep their existing authorization behavior.
-These access timings also apply to standalone Learning conversations.
 Concurrent Learning readers share verification of the same pinned course files
 while that verification is running. Completed results are not cached: later
 reads still reject missing or changed installed files, with the same reinstall

package/docs/colleague-usage/preview.md

@@ -53,6 +53,14 @@ If the previewed application shows its own login screen, enter that application'
 credentials. Its login and realtime connection run through the Preview address.
 HTTPS previews retain the HTTPS scheme for applications that use it to set
 secure login cookies and redirects.
+Preview tells the application its browser-facing address through the standard
+forwarded headers. An application configured to trust its local proxy then
+builds absolute links, asset URLs and callbacks on the Preview address. If pages
+load without styles or links point to `127.0.0.1`, the application does not
+trust the proxy yet; ask the agent to configure trusted proxies for its
+framework. Form posts and realtime connections from the Preview page reach the
+application on its local address, so its allowed hosts must include that local
+address as well as the Preview address.
 In the local editor, Preview keeps the editor's loopback hostname through login
 and page navigation, so opening the editor on `localhost` also works. If a tab
 shows an expired Preview access error after a restart, use **Reload preview**
@@ -168,6 +176,6 @@ controller.
 For managed browser checks, test ownership and recovery, read
 [Browser checks from chat](preview-browser-checks.md).
 
-For lesson diagrams shown over Preview, see [Lesson presentation in Preview](preview-lesson-presentation.md).
+Lesson diagrams play in the Learning environment, not over Preview; see [The Learning environment (L)](learning-environment.md).
 
 To choose which application Preview starts, see [Choose a starting application](preview-starting-application.md).

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

@@ -9,7 +9,7 @@ review the changes, publish if already authorized, and ping this project with
 the package versions.” The coding assistant uses:
 
 ```sh
-vibe64-helper session message-project jskit-ai "Review the changes, then ping vibe64-online with the result and published versions."
+vibe64-helper session message-project jskit-ai "Review the changes, then ping my-app with the result and published versions."
 ```
 
 Without `--session`, the destination's **currently selected session** receives the
@@ -98,7 +98,7 @@ Host-specific guidance shares the same bounded instruction budget; adding it mus
 not prevent either conversation from starting.
 
 Installed host instructions reach coding assistants through the host environment
-filter. On a configured VPS they include the local update and SSH restore commands;
+filter. A host that offers its own update or restore commands includes them there;
 hosts without that facility do not advertise it.
 
 If the destination has a pinned source session, that is its server-selected

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

@@ -16,6 +16,11 @@ You need access to the project and an available coding assistant for delegated w
 4. When output controls replace setup, select the intended output and use its
    normal Run control. A successful setup request alone does not mean it is running.
 
+The agent writes the setup and output declarations in the project's
+`genesis/stack.md`. Their exact grammar comes from Vibe64 itself: the agent reads
+it with `vibe64-helper spec workspace-setup` and `vibe64-helper spec outputs`
+(see [coding agents](coding-agents.md)). A setup error names the spec to read.
+
 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.
@@ -30,8 +35,10 @@ 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**
+you accept that work. It can also save the named accounts you give or confirm
+(for example `admin` and `user` with their emails) and then verify each in Preview;
+it never creates accounts or changes roles for this. To configure them yourself,
+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

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

@@ -0,0 +1,61 @@
+# Running Vibe64 on your computer
+
+Start Vibe64 from a terminal in the folder you want to work on:
+
+```sh
+npx vibe64
+```
+
+Vibe64 opens in your browser. To start it for a different folder, run
+`npx vibe64 --project /path/to/folder`. To start it without opening a browser,
+run `PORT=3001 npx vibe64 --no-open` and open `http://127.0.0.1:3001` yourself.
+
+Nothing needs configuring. Vibe64 runs as you, with your own tools and folders.
+
+## Tools Vibe64 uses
+
+Vibe64 runs the tools already installed on your computer: the ones your
+terminal finds on its `PATH`, plus Homebrew's `/opt/homebrew/bin` on macOS.
+That includes Node.js, npm, Git and any language tools your projects need.
+Install or upgrade them the way you normally would; Vibe64 uses the new version
+the next time it runs a command.
+
+- **AI agents.** Claude Code, Codex and opencode are used through their own
+  commands, so each must be installed on this computer before you can use it.
+  See [AI accounts](ai-accounts-and-routing.md) for what to install and how to
+  check again.
+- **npm global installs** go wherever your own npm configuration puts them.
+- **Playwright** uses its own browser cache. If **Health** reports that
+  Playwright or its Chromium is missing, install Playwright, then run
+  `playwright install chromium`.
+
+## Where Vibe64 keeps things
+
+| What | Linux | macOS |
+|---|---|---|
+| Projects Vibe64 creates for you | `~/Vibe64` | `~/Vibe64` |
+| Vibe64's own data (sessions, settings, history) | `~/.local/state/vibe64` (or `$XDG_STATE_HOME/vibe64`) | `~/Library/Application Support/Vibe64` |
+
+Vibe64 creates its data folder (private to you) when it starts, unless you
+set `VIBE64_SYSTEM_ROOT` to a folder of your own, which must already exist.
+A folder you open with `npx vibe64` stays where it is; Vibe64 does not move it.
+
+### Moving data from an earlier version on macOS
+
+Earlier versions kept data in `~/.local/state/vibe64` on macOS too. If that
+folder exists and the new one does not, Vibe64 stops at startup and prints the
+exact command to move it, for example:
+
+```sh
+mv ~/.local/state/vibe64 ~/Library/Application\ Support/Vibe64
+```
+
+Run the printed command, then start Vibe64 again. Vibe64 never moves the folder
+itself. To keep using the old location instead, start Vibe64 with
+`VIBE64_SYSTEM_ROOT` set to it.
+
+## Colleague
+
+Colleague can explain where Vibe64 keeps things and which tools it uses, and can
+open **Health** to check them. Installing tools, moving folders and restarting
+Vibe64 happen in your own terminal; Colleague cannot run them for you.

package/docs/colleague-usage/sessions.md

@@ -1,14 +1,22 @@
 # Create and switch sessions
 
 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 shows a progress bar and
-explains that it is copying the project source. It stays open: clicking outside,
+to open **Start an AI session**. It lists **Claude Code** first, then **Codex**,
+then **OpenCode**, and preselects the first available one. Choose an available
+orchestrator, 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,
 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.
 
+On a phone the session's header controls (**New session** (+), a local
+project's Git branch button and the session's GitHub account) sit beside the
+project name while the chat pane is shown. With Preview or Dashboard shown they
+make room for that pane's controls; choose **Show chat** to reach them again.
+On a phone the GitHub account shows only its GitHub icon; on a computer hover
+it to see which account the session's GitHub commands run as.
+
 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
@@ -83,34 +91,18 @@ 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 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.
-
-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
-unsent drafts; it does not stop their work.
-
-If Learning updates fail temporarily, the last confirmed lesson conversations
-remain visible. Wait for a successful refresh before selecting another lesson.
-If access is denied or your account changes, another learner's conversations
-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. Start, resume and end lessons through
-Learning → **Courses** and Colleague instead.
+## Lessons and session navigation
+
+The session tabs and chat panel list the project's ordinary sessions. The **L**
+button opens the Learning environment above the page without changing the
+selected session (see [Choosing lessons and courses](learning-mode-ui.md)).
+
+A lesson's practice sessions are ordinary sessions of its practice project and
+appear with its other sessions. **New session** and **Archive session** are
+ordinary session operations, not ways to start or end a lesson: start, resume
+and end lessons through Learning → **Courses** and Colleague. Colleague can
+explain this; it cannot grant access or repair saved identities. These rules
+apply on desktop and mobile.
 
 ## Keep the fresh session's link after renewal
 
@@ -233,7 +225,7 @@ the reported error; it cannot grant another learner's access or silently replace
 the saved lesson with newer content.
 
 Start such a lesson from Learning → **Courses** (see
-[Choosing lessons and Learning conversations](learning-mode-ui.md)); the ordinary
+[Choosing lessons and courses](learning-mode-ui.md)); the ordinary
 **New session** control still creates a working session with source.
 
 ## Pin a source session

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

@@ -11,25 +11,11 @@ The internal orientation check reads the lesson's exact installed check and runs
 it against the current App server. It does not run a mutable copy from the
 learner's project and is not a Colleague shell tool. A successful check confirms
 only that server's matching button response; the lesson still requires the
-learner's own observed interaction and explanation before assessment. If the App
+learner's own observed interaction. If the App
 restarts or the response expires, repeat the actual button interaction. If native
 execution cleanup is uncertain, report that failure for operator recovery rather
 than claiming success or resending an old observation.
 
-Opening or minimising Colleague during workspace-navigation is ordinary chat
-use, not an assessment step; it preserves the question and accepted steps. Only
-return-to-Colleague collects actual minimise/restore gestures. After its saved
-pass is confirmed against the native accepted-answer and evaluation receipt,
-normal launcher use no longer arms that completed question, including after a
-restart. Explicitly requested practice uses a new delivered question; earlier
-passes stay saved. Unconfirmed current tasks still require the original order.
-Continue project → Main coding conversation → Preview under the same question.
-
-On a phone, after minimising Colleague, **Show project** counts as the workspace
-step when it reveals the selected **Preview**. Reopen Colleague with its dedicated
-avatar launcher under the same pending question. Dashboard, automatic attention,
-swipes and programmatic navigation do not create Preview evidence.
-
 A lesson version must remain pinned to the content the learner started. If its
 content is reported missing or invalid, ask the workspace owner to restore that
 exact verified revision. A newer bundle or a draft is not a substitute for the
@@ -55,16 +41,9 @@ loader, and leaves placement to the existing Preview host. It does not by itself
 authenticated learner control, a Colleague tool or saved learner progress. Colleague
 must not claim an animation played or obtain controller source or screenshots.
 
-In a prepared lesson, the Preview host saves the real diagram's semantic state
-after a completed command or a confirmed pause. Reopening that same attempt
-restores its last confirmed state, paused flag and labels into a new player; it
-does not replay motion, narration or a completed cue. Snapshot reads alone save
-nothing. If **Retry diagram checkpoint** appears, retry the retained exact save.
-**Save current diagram** captures a fresh state after a rejected revision conflict.
-Keep the diagram open until confirmation; a hard reload can recover only the last
-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.
+A lesson diagram plays from its beginning with **Play** in the Learning
+environment; diagram states saved by earlier-format lessons stay in the lesson
+record.
 
 The application also has a server-side verified-snapshot installation facility.
 For official catalogue courses it is reached through **Install** and **Update**
@@ -140,25 +119,17 @@ neither catalogue failure nor publishing a newer release resets the reservation.
 An unconfirmed catalogue save requires reading its actual current revision before
 the owner deliberately retries. It is not evidence that enablement changed.
 
-The private lesson record can now retain a pending question, teaching position,
-diagram state and assessment results for the saved lesson version. These storage methods alone add no
-quiz/start/resume control or Colleague grading tool. A pass requires an admitted actual learner answer or a native
-practical observation tied to that learner's prepared project/session. An assistant
+The private lesson record retains step results, the reader position and, for
+earlier-format lessons, their assessment results for the saved lesson version. Colleague has no grading tool. A pass requires the
+learner's own step action: a choice answer, **Done** on a self-check step,
+**Mark as done** on a reading step or an
+automatic check tied to that learner's practice project. An assistant
 paraphrase, demonstration or animation is not evidence of a learner pass. Completion
-requires every required pinned assessment to pass; preparation alone does not count.
+requires every required pinned step (or, for an earlier lesson, assessment) to
+pass; preparation alone does not count.
 Colleague can explain this boundary and offer supported assistance, but cannot
 assert trusted observations, fabricate results or erase history by retrying.
 
-After starting or resuming, Colleague must read the fresh teaching brief, recap
-its exact pinned passed and remaining assessment IDs, and normally continue a
-remaining task. The saved `resume.pendingQuestion` is the last checkpoint; it may
-belong to an assessment that already passed. Explicitly requested practice or
-reassessment remains supported and keeps the earlier pass. A request to resume,
-open the project, inspect setup or navigate is not an answer to grade. A fresh
-conversation must prepare and actually deliver its next question before assessing
-a new learner answer; it cannot reattach old messages or infer missing provenance.
-These read-only progress facts preserve the checkpoint, visual state and history.
-
 If a future result/resume save is unconfirmed, read or retry its exact submission
 or current checkpoint identity. A changed revision requires reading current state
 before another write. A reused evidence reference or conflicting identity requires

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

@@ -14,6 +14,24 @@ Ordinary temporary chats offer **Custom**, **Senior** and **Junior**. Choose
 an available connection and model, then **Apply**. The next message uses that
 choice and the existing conversation history. Main chat's selection is unchanged.
 
+## Rename a temporary chat
+
+New temporary chats are named **Temporary 1**, **Temporary 2** and so on. Each
+number is given once, when the chat is created, and is not reused while the
+session keeps that chat; closing a chat or reloading does not renumber others.
+
+To rename a chat, select its tab, then select the pencil (**Rename …**) beside
+its name. Enter a name of up to 80 characters and select **Rename**, or press
+Enter. Line breaks and extra spaces become single spaces. Leave the name empty
+to return to its numbered name. **Cancel** or Escape keeps the current name.
+The new name is saved immediately, survives reload and appears in the session's
+other open tabs. Renaming works while the assistant is working and does not send
+a message or change the conversation. The pencil appears only on the selected
+tab, on desktop and on a phone.
+
+Colleague can rename a temporary chat through its temporary-conversation update
+action when you ask it to.
+
 ## Send and steer
 
 Temporary chat uses Main's round Send arrow and square Stop control. While a
@@ -29,8 +47,9 @@ 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.
+Guidance sent to a working Claude chat does not interrupt it: Claude reads the
+guidance after its current command finishes. Output already shown 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
@@ -107,6 +126,8 @@ 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.
+Every open tab shows the same progress: when the reply arrives, “AI is working…”
+clears in each tab, including tabs that did not send the message.
 
 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

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

@@ -50,8 +50,9 @@ Main's microphone and speaker controls sit with the expanded face, outside the
 original message buttons. Before speech is connected, the speaker button opens
 Main's speech connection and changes spoken replies without recording.
 Main defaults to spoken replies on when no choice is saved; Colleague defaults
-off. An explicit saved choice takes precedence. In Vibe64 Online, the speaker
-choice is personal and separate for Colleague and coding assistants. Both idle controls stay available while
+off. An explicit saved choice takes precedence. A host with saved speech
+preferences keeps the speaker choice personal and separate for Colleague and
+coding assistants. Both idle controls stay available while
 Talk is connecting. The fourth small round button, the minus after microphone,
 speaker and settings, tucks away the face; speech continues. The collapsed anonymous icon in the
 top-right corner is **Show avatar** and restores it. While hidden, a passive
@@ -159,14 +160,8 @@ Open voice for a different conversation to switch. Unfinished words require
 completion or **Discard and switch**; **Stay here** keeps the original target.
 There is only one voice window and one active capture/playback owner.
 
-On installations with speech configured, a source-less Learning conversation
-uses Main's same microphone, spoken replies and review controls; it does not
-require an invented project. Its voice target is labelled **Lesson** and the
-actual conversation name. Capture stays attached to that person's saved attempt
-and conversation. Switching attempts does not resend or redirect words. Reading
-lesson history does not authorize new teaching work: each Send still checks the
-current saved lesson and access. Without a speech service, use the same typed
-Main conversation; voice availability is optional.
+Lessons have no voice of their own: use Colleague's voice to learn with a
+lesson.
 
 Signing out, losing access to the target, or leaving the page releases its
 resources. A project agent remains the selected voice target even if its text

package/docs/colleague-usage/voice-face-and-speaking-voice.md

@@ -6,7 +6,7 @@ This is part of [Voice chat with Colleague or a project agent](voice-chat.md).
 
 Colleague and the project agent show an illustrated face that blinks, moves and
 animates its mouth while listening, thinking and speaking. Colleague starts with
-**Merc · male**; project agents, including the Learning teacher, start with
+**Merc · male**; project agents start with
 **Yu · female**. To change one, open that assistant's **Voice settings** cog
 beside the microphone and speaker controls (below its face when expanded) and
 choose **Avatar**. Colleague and project agents keep separate choices. A project
@@ -25,13 +25,11 @@ Open the same **Voice settings** cog and 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.
+selector and retain the choice across sessions, saving your avatar and voice
+personally, separately for Colleague and coding assistants. On such a host the
+personal cog's **Speak replies** choice controls output for that target; check
+it when first using your personal controls, because older browser-only speaker
+choices are not copied into personal settings.
 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**

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

@@ -40,11 +40,12 @@ started speaking, including after navigation or a failed-send retry. The normal
 default still sends completed speech automatically, and input and playback stay
 independent. There is no new settings control for this retained choice.
 
-Online waits for your saved settings before opening a new voice target. An existing
+A host with saved speech preferences waits for your saved settings before
+opening a new voice target. An existing
 voice target stays owned while those settings load. If loading fails, retry opening
 voice or use typed chat; your words are not automatically submitted. Reopening an
 already active target does not add a new microphone readiness gate.
 
-A temporary Online settings refresh error keeps an already loaded saved review
+A temporary settings refresh error keeps an already loaded saved review
 choice for the same account. It does not silently switch that active microphone
 to automatic sending. A new voice target still waits for its settings to load.