vibe64 0.1.44 → 0.1.45

package/docs/colleague-usage/plans.md

@@ -146,9 +146,14 @@ the session has no plan; the native plan icon remains an independent way to
 check. Opening the viewer reads the plan; it never creates,
 edits, approves, archives, reopens or executes one and starts no coding turn.
 Explaining the workflow or offering help is not authorization to change a plan.
-Colleague's plan-reading action cannot archive, reopen, edit or execute it:
-those require the person's Archive or Make current control, or an explicit Main-chat request,
-sent through an already-authorized chat operation when available.
+Colleague's plan-reading action cannot edit or execute a plan. When you ask,
+Colleague can **Archive** the current plan or **Make current** an archived one
+through the same operations as the viewer's buttons, with the same limits: it
+reads the whole current plan first, Archive is refused if the plan changed since
+that read, Make current is refused while a current plan exists, and both wait
+while the assistant or its review is running. Neither starts AI work; ask in
+chat to continue a plan made current. Replacing a current plan with an archive
+(reopen over it), editing and executing remain explicit Main-chat requests.
 
 ## Auto roles and workflow
 

package/docs/colleague-usage/sessions.md

@@ -141,8 +141,10 @@ 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.
+Colleague can explain these steps and the reported error. When you explicitly
+ask it to archive a named session, it archives it through the same action; the
+same pin, renewal and preparation guards apply, and it reports a failed cleanup
+for retry. Stopping an agent or ending Colleague is never an archive request.
 
 ## Chat availability
 
@@ -152,6 +154,8 @@ for team members. 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.
+The owner's Colleague can change Main chat's mode on request; a team member's
+cannot, outside their own lesson (see [Main chat approvals](main-chat-approvals.md)).
 
 To open the coding agent's own terminal, or leave it on a phone, see [Open the coding agent's terminal](session-terminal.md).
 
@@ -248,7 +252,9 @@ Idle cleanup otherwise closes an open project, with its Preview, terminals and
 assistant processes, 30 to 35 minutes after its last recorded activity (opening
 it, session changes and assistant work). Leaving the project or closing the
 browser does not close it sooner; close the project yourself to free its
-memory at once. A running assistant turn or active goal keeps it open.
+memory at once, or ask Colleague to close it: it uses the same Close, which also
+stops other sessions' running work, and reports a failed Close as incomplete
+cleanup. A running assistant turn or active goal keeps it open.
 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**.

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

@@ -98,6 +98,15 @@ Colleague can explain these steps and change a temporary chat's selection throug
 its authorized temporary-conversation action when explicitly asked. Stopping or
 sending work remains a separate requested action.
 
+Colleague offers the same choices as the **Chat mode** menu: **Fix it with AI**,
+**Custom** with a model it has seen in AI setup or the session's access (it never
+invents one), and for the owner **Senior** or **Junior**. A team member's Colleague
+offers only **Fix it with AI** and **Custom**, and a new chat it creates for them
+starts on **Fix it with AI**; the owner's starts on Main chat's mode (Auto becomes
+Senior). A merge repair chat accepts only **Fix it with AI** or **Custom**. Auto
+is Main chat only. Colleague doesn't start an Update conflict's **Fix it with AI**
+repair itself: choose that button on the Update error.
+
 ## Work elsewhere while a chat runs
 
 Select **Main chat** or another temporary tab to continue elsewhere. The hidden

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

@@ -46,6 +46,9 @@ 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.
+Colleague can list the installed voices with their names and languages, so it can
+match "a British female voice" to an installed one or say none matches; you
+then choose it in **Speaking voice**.
 
 Loading **Speaking voice** performs a read-only, authorized catalogue check. It
 does not start the microphone, open an audio connection or send an assistant

package/docs/training-content.md

@@ -598,9 +598,11 @@ the store does not authenticate objects or discover/fetch repositories.
 contains the original course definition, its complete generated `lock`, and an
 `enabled` boolean. Both definition and lock are immutable for a course ID/release;
 changing even its title requires another approved release. A new release is a
-separate retained entry. Enablement is the only mutable field. The pilot retains
-at most 16 course releases in a file bounded to 1 MiB; it never silently removes
-disabled releases. New directories use 0700 and catalogue records use 0600.
+separate entry. Enablement is the only mutable field; `removeCourse` deletes a
+whole entry. The catalogue keeps at most 16 course releases in a file bounded to
+1 MiB. Only a course Update (its older releases) and the operator's
+`remove-course` remove entries; installed topic content is never removed with
+them, so saved attempts keep their pinned lessons. New directories use 0700 and catalogue records use 0600.
 
 Every read freshly verifies all entries, including disabled ones, against installed
 topic pins and the original `createCourseLock` owner. The approved lock must exactly
@@ -657,7 +659,8 @@ retry returns `changed:false`; the same name with a different definition returns
 `VIBE64_TRAINING_COURSE_INVALID`, `VIBE64_TRAINING_COURSE_TOPIC_UNAVAILABLE`,
 `VIBE64_TRAINING_COURSE_LIMIT` and the original catalogue revision/busy/save
 errors. To retire a custom course, disable its exact release with
-`vibe64 training disable-course custom-<name-slug> 1.0.0 <system-root> <revision>`.
+`vibe64 training disable-course custom-<name-slug> 1.0.0 <system-root> <revision>`,
+or remove it with `remove-course` to free its place.
 
 Course progress in the **Courses** pane is read-only: `learning.read` adds
 `lessonProgress`, one `{lessonCode,lessonHash,required,passed,completed,open}`
@@ -921,9 +924,9 @@ fetches its canonical repository at exactly the locked commit (`git init`,
 original `installTopic` with `topicHash = manifestHash`. That owner re-verifies
 the clean commit, canonical source and every byte. It then calls
 `enableCourse` with a fresh revision, retrying once on a revision conflict.
-Older enabled releases of the same course are then disabled with
-`disableCourse` (fresh revision; new starts only). Saved attempts keep their pin
-and resume. Installs run one at a time; repeated requests for the same release
+Older releases of the same course are then removed with `removeCourse` (fresh
+revision), freeing their places; the result lists them in `retired`. Saved
+attempts keep their pin, installed content and resume. Installs run one at a time; repeated requests for the same release
 share one operation. Git runs through `runVibe64Command` as the daemon with
 hooks disabled; no fetched file is executed.
 
@@ -933,10 +936,11 @@ from sources, and are removed in `finally`. The managed exec helper admits the
 daemon's generic commands in exactly that one-level directory under
 `~/.local/state/vibe64/training-sources/`.
 
-An already enabled exact release is a no-op. A disabled release is re-enabled
-only for the workspace owner (`VIBE64_TRAINING_COURSE_DISABLED` otherwise). A new
-entry beyond the installed catalogue's 16 retained releases fails before any
-download with `VIBE64_TRAINING_COURSE_LIMIT`; nothing is deleted.
+An already enabled exact release is a no-op. A disabled release is refused for
+everyone, the owner included (`VIBE64_TRAINING_COURSE_DISABLED`); re-enabling
+stays the operator's `enable-course`. A new entry beyond the installed
+catalogue's 16 releases fails before any download with
+`VIBE64_TRAINING_COURSE_LIMIT`; the operator frees a place with `remove-course`.
 
 The actions are `vibe64.training.available.list` (`GET
 /api/vibe64/training/available`) and `vibe64.training.course.install` (`POST
@@ -960,6 +964,7 @@ vibe64 training install-topic /absolute/path/to/learn-topic /absolute/vibe64/sta
 vibe64 training installed-courses /absolute/vibe64/state
 vibe64 training enable-course /absolute/path/to/course.json /absolute/path/to/course.lock.json /absolute/vibe64/state 0
 vibe64 training disable-course first-course 0.1.0 /absolute/vibe64/state 1
+vibe64 training remove-course first-course 0.1.0 /absolute/vibe64/state 2
 ```
 
 `install-topic` derives the exact pin from the clean committed topic repository;
@@ -971,7 +976,9 @@ install a new pin rather than replacing retained content.
 `installed-courses` returns the freshly verified catalogue, including its
 revision, enablement and exact course locks. A missing catalogue reads as revision
 zero without creating files. Supply that exact current nonnegative decimal
-revision to `enable-course` or `disable-course`. The original catalogue owner
+revision to `enable-course`, `disable-course` or `remove-course`. Removing an
+exact release takes it out of the catalogue and frees its place; its installed
+topic content stays, so saved attempts keep resuming. The original catalogue owner
 verifies the course/lock against every installed topic, preserves immutable
 release definitions, and serializes writes. A stale revision requires a new read
 and deliberate retry. An unconfirmed save requires inspecting the current

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vibe64",
-  "version": "0.1.44",
+  "version": "0.1.45",
   "private": false,
   "description": "Run Vibe64 against the current project.",
   "type": "module",