vibe64 0.1.32 → 0.1.34

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

@@ -0,0 +1,73 @@
+# Assistant face and speaking voice
+
+This is part of [Voice chat with Colleague or a project agent](voice-chat.md).
+
+## Choose the assistant's face
+
+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
+**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
+agent's cog works without starting voice; Colleague shows its cog once its voice
+controls are active (tap **Talk**). The face changes immediately, in the header
+button, chat and voice window. On a phone the cog sits in the same row below
+the face. Colleague can explain this but cannot choose for you: pick the
+avatar yourself. In standalone Vibe64 the choice is saved in this browser only
+(**Saved in this browser for this assistant type.**); another browser, a private
+window or cleared site data starts again from the defaults. If browser storage
+is blocked, the choice lasts until the page reloads.
+
+## Choose a speaking voice
+
+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.
+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. New messages wait
+for the current message to finish; arriving progress or an answer does not cut off
+spoken text. Repeated updates do not restart a message. The optional thinking
+sound yields to a real answer. **Stop speaking**, turning off spoken replies and
+switching voice targets still cancel playback.
+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.
+
+Loading **Speaking voice** performs a read-only, authorized catalogue check. It
+does not start the microphone, open an audio connection or send an assistant
+message. The app rechecks your current sign-in before showing installed choices.
+If the catalogue cannot be loaded, sign in again if prompted, then close and
+reopen **Voice settings** after the speech service has recovered; typed chat
+remains available.
+
+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.

package/docs/colleague-usage/workspace-preparation.md

@@ -9,6 +9,25 @@ Select **Prepare workspace**. The notice shows progress while those steps run.
 Use **Expand** to inspect output, or **Dismiss** to hide an inactive notice.
 Preparation does not publish the project.
 
+To rerun preparation after success, select **Prepare workspace** (the wrench)
+in the session header. On narrow screens, open **Session actions** (three dots)
+and select **Prepare workspace**. This stays available after dismissing the
+preparation notice. It runs the complete current recipe, including declared
+database steps and connected-source Prepare/Verify commands. It is unavailable
+while another assistant or repository operation is active, or for archived sessions.
+
+A new session with connected projects starts preparation automatically. Its
+first step, **Preparing connected projects**, creates or reuses each connected
+project's contribution session at the same time and lists the ones still in
+progress, then **Linking connected sources** and **Checking connected sources**
+while it rechecks access to each one. If one fails, the notice names that repository; earlier prepared
+sources are kept and **Retry** reuses them instead of copying them again.
+
+A successful result records the previous recipe execution. It does not prove
+that custom compiled outputs still match later source or script edits. Rerun
+preparation explicitly after those edits when the project needs rebuilt outputs;
+Vibe64 does not automatically rebuild custom connections.
+
 An actual failed command or failure to start preparation still displays an error
 and its diagnostic. Use the available retry or **Fix it with AI** action to deal
 with that failure; do not assume a required preparation step has already failed.
@@ -17,6 +36,55 @@ Colleague can explain the notice and, when explicitly asked, use the session's
 authorized workspace-preparation operation. It should inspect the current
 result before saying preparation succeeded.
 
+## Missing project-owned Stack sections
+
+**Project setup needs attention** can report a missing section such as
+`## Connected development` after the installed Stack catalog changes. This is
+a declaration problem; repeatedly retrying dependency installation will not
+repair it.
+
+For an older Genesis project format, follow the diagnostic's `genesis migrate`
+instruction first. If the missing-section diagnostic remains after migration,
+explicitly reconcile the selected component as described below. A format upgrade
+does not necessarily add newer catalog proposals, and migration on a
+current-format project does not add them. Use **Fix it with AI** or ask your
+coding assistant to inspect
+`genesis/stack.md` and reconcile the missing section with the actual application.
+If `nodejs` is already listed under **Components**, the existing explicit repair
+is `genesis stack add nodejs`. Use the project's installed Genesis command
+(`npm exec --no -- genesis stack add nodejs` when it declares `genesis-compiler`).
+Do not select Node or another technology merely to dismiss a warning.
+
+The command preserves existing complete project sections and adds missing
+proposals. Review its returned preparation instructions and the source diff;
+keep the application's real setup, launch and database commands. Node's default
+`Connected development` declaration selects `npm` treatment only; it adds no
+connected repositories and performs no dependency installation by itself.
+
+After the declaration is repaired, select **Recheck setup**. If workspace
+preparation is still required, **Prepare workspace** or **Retry** runs the
+declared recipe; inspect it before rerunning database or installation steps.
+The same recovery applies on desktop and mobile. Colleague can explain the
+warning and offer the supported repair flow; source edits and terminal commands
+belong to the coding assistant or the person, not Colleague.
+
+## Competing Stack proposals
+
+When two selected technologies propose different bodies for the same section,
+for example Node and Python both proposing `## Connected development`, Genesis
+leaves that heading unwritten and reports `STACK_SECTION_AMBIGUOUS` until the
+project chooses. **Project setup needs attention** shows Genesis's message,
+which quotes each proposal; workspace preparation shows **Workspace setup needs
+a choice** with the same text. Vibe64 never picks a proposal for you, and
+retrying preparation alone does not resolve it.
+
+Chat stays available: use **Fix it with AI** or ask your coding assistant to
+author one complete project-owned section in `genesis/stack.md` that fits the
+application (a multi-language project chooses one `Default package type`).
+Then select **Recheck setup** and **Prepare workspace** or **Retry**. Skill
+refresh waits until the section is decided. Colleague can explain the choice;
+the source edit belongs to the coding assistant or the person.
+
 ## Locally installed command-line tools
 
 When you open a directory with the local Vibe64 editor, start Vibe64 from the
@@ -29,3 +97,24 @@ works in that terminal, then restart the local editor after correcting the
 installation or shell path. Hosted workspaces use their host's prepared tools.
 Colleague can explain this recovery; installing a local tool and restarting the
 local editor require the person to use their terminal.
+
+
+## Resource recovery after a daemon restart
+
+When the host supports database preservation checks, reopening a previously
+prepared session can restore its managed environment without repeating unchanged
+Workspace setup commands. Vibe64 requires the same successful recipe and resource
+identity, and the host must verify that its databases already existed. Recreated,
+changed or unverified resources run the full recipe, including application database
+initialization. An older successful setup without that identity runs once to
+establish it; existing session metadata is not guessed or rewritten on opening.
+
+**Retry** still runs the declared setup again. If resource recovery fails, inspect
+the preparation error before retrying. Colleague can inspect that result and retry
+when asked; it should not call an unchanged setup successful merely because saved
+database connection settings exist. The controls are the same on desktop and mobile.
+
+If someone manually drops and recreates a database under the same name outside
+Vibe64's preparation, use **Retry** to rerun the application's setup. Preservation
+checks cover Vibe64's own provisioning; they do not inspect or reconstruct an
+application schema changed outside that operation.

package/docs/training-content.md

@@ -49,14 +49,94 @@ An assessment declares `id`, `kind` (`answer` or `practical`), `required` and
 `rubric`. Use an explicit `<a id="assessment-id"></a>` line in the teaching
 document and refer to it as `lesson.md#assessment-id`. Answer assessments use
 the admitted learner answer and that rubric. Practical assessments also declare
-`evidence: {producer, operation, check?, explanationRequired?}`. Supported producers
-are `workspace`, `colleague` and `exercise`. Exercise evidence requires an exercise
-and a declared check; other producers cannot execute checks. Declare checks as
-`checks: [{id,file,assets?}]`. Declare auxiliary check inputs in `assets`, relative to the lesson descriptor.
+`evidence: {producer, operation, check?, explanationRequired?, files?}`. Supported producers
+are `workspace`, `colleague`, `exercise` and `code`. Exercise and code evidence
+require an exercise and a declared check; other producers cannot execute checks. Declare checks as
+`checks: [{id,file,assets?,kind?,timeoutSeconds?}]`. Declare auxiliary check inputs in `assets`, relative to the lesson descriptor.
 The validator includes these files but never executes them.
 The managed application execution owner will run approved pinned checks; teaching
 tools do not gain arbitrary shell access. Demonstrations cannot earn learner passes.
 
+An exercise lesson may optionally declare the practice app's data-changing routes
+so a Learning watch can name a failed request the learner started:
+`appRoutes: [{method, path}]`, at most 16 unique entries. `method` is `POST`,
+`PUT`, `PATCH` or `DELETE`; `path` starts with `/`, has no query, fragment or
+trailing slash, and each segment is a literal or `:id` (the Preview replaces
+numeric and UUID segments with `:id`). For the notes exercise:
+`"appRoutes": [{ "method": "POST", "path": "/api/notes" }]`. A failed request on
+any other path is still reported, as `other`, so route segments that might carry
+typed text never leave the learner's browser. Routes only label watch hints; they
+never grade, and a lesson without an exercise cannot declare them.
+
+### Authoring a code question
+
+A `code` practical asks the learner to change exercise code in the lesson
+Dashboard's **Code** tab and press **Check my code**. Declare it like this
+(the test fixture `tests/fixtures/training/code-practical/` is a complete,
+validating example):
+
+```json
+"exercise": { "kind": "bundled", "source": "app", "reuse": "attempt" },
+"checks": [{ "id": "notes-title-required", "file": "checks/notes/title.mjs",
+             "kind": "code", "timeoutSeconds": 15 }],
+"assessments": [{ "id": "require-note-title", "kind": "practical", "required": true,
+  "rubric": "lesson.md#require-note-title",
+  "evidence": { "producer": "code", "operation": "edit-and-check",
+                "check": "notes-title-required", "files": ["notes.mjs"],
+                "explanationRequired": true } }]
+```
+
+- `files` lists 1–8 exercise-relative paths the learner edits. Each must be an
+  ordinary bundled exercise file (no `..`, absolute path, `.git`,
+  `node_modules` or `.genesis` segment) and may appear once. Only `code`
+  evidence may name files.
+- The check must declare `kind: "code"`; a code check can only be named by
+  `code` evidence and an `exercise` check must not be a code check. Omitted
+  `kind` means the existing `response` kind. `timeoutSeconds` (1–60, default
+  15) is allowed only on a code check. The operation is any lesson ID.
+- `reuse:"attempt"` is the supported exercise mode; sequence-reused baselines
+  are not part of this first slice.
+- The rubric should ask for the learner's own explanation. The check alone
+  never passes: the existing tool-free grading Helper grades the explanation
+  against the rubric with the check result.
+
+The check runs with Node in the managed execution owner on a private copy laid
+out like the topic: the pinned exercise at its topic path, with only the
+declared files replaced by the learner's saved bytes, plus the pinned check and
+its assets. Its working directory is the exercise copy, its environment is
+empty, output is limited to 4 KiB and it has no dependency installation, so an
+exercise and its check must need no packages. Import learner code relative to
+the check (for example `new URL("../../app/notes.mjs", import.meta.url)`); the
+same command works in the topic checkout. The check reads one JSON object on
+stdin, `{check, filesHash, files:[{path,sha256}]}`, and prints exactly one JSON
+line echoing `check` and `filesHash`:
+
+- exit 0 and `{check, filesHash, outcome:"verified"}` — the code is correct;
+- exit 1 and `{check, filesHash, outcome:"incomplete", reason}` (reason at most
+  256 characters) — shown to the learner as "Not yet: …".
+
+A different `filesHash` or any other success-shaped output is rejected as an
+invalid check result. A check stopped by its timeout, or learner code that
+crashes the check before it prints a result, is "not yet passed" with a fixed
+explanation. stderr is ignored. Use plain `node:assert`-style logic rather than
+`node --test`, whose reporter writes to stdout.
+
+Authorship: when Main prepares a code question, Vibe64 records the SHA-256 of
+each declared file in the live practice project as the question's starting
+point. Each save from the learner's lesson Dashboard Files section is recorded server-side
+with its base hash, intended hash and saved hash. At **Check my code** the chain
+from the starting point through those saves must reach the current bytes
+exactly; otherwise the check is not run and the question is automatically not
+passed with "needs an independent attempt: other edits detected in `<file>`".
+In a practice lesson Main is also the learner's agent, but while a code
+question is open the teaching brief instructs Main not to write that question's
+declared files (even when asked) or send solution code, and to warn the learner
+that an agent edit there voids the attempt. The ledger above enforces this; there
+is no technical write-deny for agents in this slice. Teacher chat
+is not shared with the grader. The check is learner-run code on the learner's
+own machine and has no network isolation: for hosted use, sandboxing and network
+denial of the check job are an open gap.
+
 An optional exercise uses `{kind:"bundled", source, reuse:"attempt"}`. Continued
 work uses `reuse:"sequence"`, `sequenceId` and `sequenceMode:"create"|"continue"`.
 One creation precedes continuations in topic order, with the same source directory.
@@ -102,6 +182,12 @@ A `course.json` declares schema version 1, `courseId`, `title`, an exact three-p
 `release`, `status` (`preview` or `released`) and ordered `topics` containing
 `{topicId,release}`. A course selects whole topics; lesson selection or reordering
 is rejected. A released course requires released topics with no required drafts.
+A preview course is for the workspace owner to review: `lesson.start` admits its
+published lessons only when the actor is the workspace owner (on local Vibe64,
+the OS user), and refuses everyone else with `VIBE64_TRAINING_COURSE_PREVIEW`.
+`courses.list` reports `canTryPreviews`, and Courses shows the owner **Try
+preview**. The started attempt is an ordinary saved lesson. Releasing the course
+offers **Start** to everyone; draft lessons and disabled courses stay refused.
 
 Run `vibe64 training publish-manifest <course.json> <committed-topic-directory...>`
 with one canonical repository root for each selected topic. Each topic's package
@@ -119,6 +205,26 @@ ordered lesson identities. If a topic changes during generation, commit the
 intended content and retry. This command generates local release material only;
 it does not push Git, create a remote release, install content or enable a course.
 
+### Lesson 0 is supplied by each installation
+
+Local and hosted Vibe64 are set up very differently, so "Set yourself up"
+(Lesson 0) is not part of the shared topic. Each installation supplies its own
+Lesson 0 topic and lists it first in the same course, followed by the shared,
+installation-agnostic topic:
+
+```json
+{ "schemaVersion": 1, "courseId": "vibe64-getting-started-local", "title": "Getting started with local Vibe64",
+  "release": "0.1.0", "status": "preview",
+  "topics": [{ "topicId": "vibe64-local-setup", "release": "0.1.0" },
+             { "topicId": "vibe64-getting-started", "release": "0.1.12" }] }
+```
+
+Local Vibe64 uses `learn-vibe64-local-setup` (V64-SETUP-00). It checks the
+machine through the real **Dashboard → Health** checks and **Account settings**,
+which Colleague can also read for the person. A hosted service keeps its own
+Lesson 0 topic in its own repository. Every later lesson stays in the shared
+topic and must work the same way on both.
+
 ## Server reads of installed snapshots
 
 This release provides a read-only server API at
@@ -236,8 +342,8 @@ The exact schema-version-1 pin contains `topicId`, `release`, canonical `reposit
 40-character `commit` and trusted `topicHash`, as well as `schemaVersion`. Map the
 course lock's topic `manifestHash` to `topicHash` at that owning operation.
 This low-level service does not authenticate callers, fetch Git repositories,
-enable courses or grant access. No browser/assistant install action or terminal
-install command is exposed yet.
+enable courses or grant access. Its callers are the operator `install-topic`
+command, the owner author trial and the official catalogue installer below.
 
 Installation reuses the clean committed-source proof, original bundle command
 and installed reader. It checks the approved identity before and after bundling,
@@ -271,6 +377,8 @@ runs no authored exercise, check or visual controller.
 `enableCourse({course,lock,expectedRevision})` and
 `disableCourse({courseId,release,expectedRevision})`. These are internal server
 facilities, with explicit local operator commands documented below and no browser control or Colleague tool.
+The one exception is `createCourse({title,topics,expectedRevision})`, described
+under [Custom courses](#custom-courses).
 An admitted owner caller supplies the approved course and its exact lock together;
 the store does not authenticate objects or discover/fetch repositories.
 
@@ -306,12 +414,45 @@ exercise execution is introduced. This projection can be reconstructed only by
 an explicit owner operation from the same approved definitions/pins; it is not a
 backup of learner state.
 
-The future authenticated start action chooses an enabled exact entry from a fresh
+The authenticated `lesson.start` action chooses an enabled exact entry from a fresh
 read. That read admits the start; a later disable blocks future admissions but
 does not revoke work already admitted or a saved attempt. This store does not
 serialize its lock with reservation writes or add an action/authentication layer.
 Resume continues through the saved learner pin independently of the catalogue.
 
+### Custom courses
+
+The workspace owner can create a custom course from Learning → **Courses** →
+**New course**, or through the owner-only `vibe64.training.courses.create` action
+(`POST /api/vibe64/training/courses` with `{title,topics,expectedRevision}`).
+`courses.list` reports `canCreateCourses` for the signed-in person and each
+course's ordered `topics` with their installed titles. On local Vibe64 the OS user
+is the owner; on hosted Vibe64 only the workspace owner may create one, through
+the existing `ownerRequired` action check.
+
+`createCourse` adds no storage and no new record format. It accepts 1–32
+different whole topics, each an exact `topicId`/`release` already pinned by an
+**enabled released** catalogue course, and resolves them through those existing
+lock pins and the installed snapshots. It builds an ordinary course definition
+`{courseId:"custom-<name-slug>",title,release:"1.0.0",status:"released",topics}`,
+generates its lock with the original `createCourseLock` and saves it with the
+original `enableCourse` (same lock, revision check, 16-release limit and atomic
+writer). The entry is therefore immutable like any other release and is verified
+on every catalogue read. Lessons keep their exact code and hash, so saved passes
+count in every course containing them; lesson content never changes. An identical
+retry returns `changed:false`; the same name with a different definition returns
+`VIBE64_TRAINING_COURSE_EXISTS`. Other refusals are
+`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>`.
+
+Course progress in the **Courses** pane is read-only: `learning.read` adds
+`lessonProgress`, one `{lessonCode,lessonHash,required,passed,completed,open}`
+summary per saved lesson pin, computed from the same verified passes as
+`completion`. The browser joins it with `courses.list` to show lesson statuses and
+"N of M lessons complete" (required lessons, or all lessons when none is required).
+
 ## Private learner reservations
 
 `@local/vibe64-training/server/learner-state` exports
@@ -469,6 +610,66 @@ which preserves private bytes and validates candidates through the existing
 reservation and installed-content readers. Its fixture proof does not establish
 live fleet stopping, off-host retention or power-loss durability.
 
+## Official catalogue installation
+
+`@local/vibe64-training/server/course-installer` exports
+`createTrainingCourseInstaller({systemRoot, catalogue, repository})`. It is the
+only in-app installation path and reads one GitHub repository, the official
+catalogue: `mobily-enterprises/vibe64-learning-catalog` by default, or the
+server's `VIBE64_LEARNING_CATALOG_REPOSITORY` (`owner/name`). The browser never
+supplies a repository, commit or path.
+
+Catalogue format (default branch):
+
+- `domains.json`: `{schemaVersion:1, domains:[{domainId,title}]}`. The UI calls
+  these **topics**.
+- `topics.json`: `{schemaVersion:1, topics:[{topicId, repository, domainId?,
+  releases:[{release,status,commit,manifestHash}]}]}`. The optional `domainId`
+  (one of `domains.json`) groups that topic's courses; a course is listed under
+  its first topic's domain, or under **Other courses** when none is declared.
+- `courses/<courseId>/course.json` and `course.lock.json`: the exact descriptor
+  and the `publish-manifest` lock. The directory name must equal `courseId`.
+
+`listAvailable()` shallow-fetches the default branch into a private scratch
+directory, reads the files with `git cat-file` (no checkout), validates them with
+the content schemas (strict fields, canonical `owner/learn-*` repositories,
+40-character commits, 64-character hashes, lock/course identity and order) and
+caches the result for 60 seconds. A fetch failure is
+`VIBE64_TRAINING_AVAILABLE_UNREACHABLE`; invalid content is
+`VIBE64_TRAINING_AVAILABLE_INVALID`. Reading never installs anything.
+
+`installCourse({courseId, release, actor})` rereads the catalogue, selects that
+exact course/lock, and for each locked topic not already installed and verified
+fetches its canonical repository at exactly the locked commit (`git init`,
+`fetch --depth=1 <commit>`, detached checkout, `HEAD` check) and calls the
+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
+share one operation. Git runs through `runVibe64Command` as the daemon with
+hooks disabled; no fetched file is executed.
+
+Scratch sources live in `<systemRoot>/training-sources/(catalogue|topic)-<uuid>`
+(mode 0700), beside the `training/` namespace that `installTopic` keeps separate
+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.
+
+The actions are `vibe64.training.available.list` (`GET
+/api/vibe64/training/available`) and `vibe64.training.course.install` (`POST
+/api/vibe64/training/courses/install`, input `{courseId, release}`). Any signed-in
+user may call them, as for `lesson.start`: they can only install hash-pinned
+releases from the official catalogue, and arbitrary sources remain operator
+commands. Hosts that compose `createTrainingActions` without a `courseInstaller`
+return `available:false`.
+
 ## Local operator provisioning
 
 These commands run locally under the OS identity that owns the selected Vibe64

package/node_modules/@jskit-ai/assistant-core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/assistant-core",
-  "version": "0.1.215",
+  "version": "0.1.236",
   "type": "module",
   "exports": {
     "./client": "./src/client/index.js",

package/node_modules/@jskit-ai/assistant-runtime/README.md

@@ -0,0 +1,29 @@
+
+With the existing realtime diagnostic option (`JSKIT_REALTIME_DEBUG=1`, or
+`config.realtime.debug=true`), conversation subscriptions emit one `pending`
+warning if admission/snapshot reading has not returned within the client's
+10-second acknowledgement budget. The warning names the current stage and the
+server-generated epoch; a conversation identity is included only after its
+successful authorized open. Observer release also records the current stage and
+reason. While diagnostics are enabled, every stage transition is recorded at
+warning level with its duration and total elapsed time, so warning-only logs
+retain the earlier admission costs as well as the step pending at timeout.
+Timers are removed on acknowledgement, failure, replacement, unsubscribe
+and connection close. Diagnostics contain no request body or conversation text,
+and do not change authorization, subscription deadlines or model work.
+
+Released subscriptions stop setup at the next completed phase. The existing
+socket owner supplies its current subscription identity to the subscribe action;
+an obsolete open cannot attach a new observer, and a late observer is detached
+without starting a snapshot. Reads already in progress may finish, but cannot
+acknowledge into a replacement view. Reload performs fresh authorization, and
+releasing a view never stops its model turn.
+
+Prepared application submissions may explicitly enable `queueWhileSending` to
+reuse the binding's serial delivery queue while application preparation is still
+running. Each queued request retains its captured payload and receipt identity.
+Stop and conversation retirement cancel queued preparation through the existing
+owner. A typed, definite ended-turn rejection may become one ordinary Send with
+the same identity, without repeating preparation; uncertain delivery never
+permits replay. With the option absent or false, prepared submissions retain
+their existing non-queueing behavior.

package/node_modules/@jskit-ai/assistant-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/assistant-runtime",
-  "version": "0.1.208",
+  "version": "0.1.230",
   "type": "module",
   "exports": {
     "./client": "./src/client/index.js",

package/node_modules/@jskit-ai/assistant-voice/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/assistant-voice",
-  "version": "0.1.15",
+  "version": "0.1.37",
   "type": "module",
   "exports": {
     "./client": "./src/client/index.js",

package/node_modules/@jskit-ai/connector-google-calendar/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/connector-google-calendar",
-  "version": "0.1.54",
+  "version": "0.1.61",
   "type": "module",
   "exports": {
     "./shared": "./src/shared/definition.js",

package/node_modules/@jskit-ai/connectors-catalog/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/connectors-catalog",
-  "version": "0.1.54",
+  "version": "0.1.61",
   "type": "module",
   "exports": {
     "./shared/ai": "./src/shared/ai.js",

package/node_modules/@jskit-ai/connectors-core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/connectors-core",
-  "version": "0.1.54",
+  "version": "0.1.61",
   "type": "module",
   "exports": {
     "./shared/configuration": "./src/shared/configuration.js",

package/node_modules/@jskit-ai/http-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/http-runtime",
-  "version": "0.1.235",
+  "version": "0.1.242",
   "type": "module",
   "exports": {
     "./client": "./src/client/index.js",

package/node_modules/@jskit-ai/kernel/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/kernel",
-  "version": "0.1.237",
+  "version": "0.1.244",
   "type": "module",
   "exports": {
     "./_testable": "./_testable/index.js",

package/node_modules/@jskit-ai/payments-core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/payments-core",
-  "version": "0.1.54",
+  "version": "0.1.61",
   "type": "module",
   "exports": {
     "./shared": "./src/shared/configuration.js",

package/node_modules/@jskit-ai/realtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/realtime",
-  "version": "0.1.234",
+  "version": "0.1.242",
   "type": "module",
   "exports": {
     "./server/RealtimeProvider": "./src/server/RealtimeProvider.js",

package/node_modules/@jskit-ai/resource-core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/resource-core",
-  "version": "0.1.179",
+  "version": "0.1.186",
   "type": "module",
   "exports": {
     "./shared/resource": "./src/shared/resource.js"

package/node_modules/@jskit-ai/resource-crud-core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/resource-crud-core",
-  "version": "0.1.179",
+  "version": "0.1.186",
   "type": "module",
   "exports": {
     "./shared/crudFieldContract": "./src/shared/crudFieldContract.js",

package/node_modules/@jskit-ai/uploads-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/uploads-runtime",
-  "version": "0.1.212",
+  "version": "0.1.219",
   "type": "module",
   "exports": {
     "./client": "./src/client/index.js",

package/node_modules/@local/vibe64-core/package.json

@@ -30,6 +30,7 @@
     "./server/studioRoots": "./src/server/studioRoots.js",
     "./server/terminalWebSocketRoutes": "./src/server/terminalWebSocketRoutes.js",
     "./server/vibe64MembershipStore": "./src/server/vibe64MembershipStore.js",
+    "./server/watch-observations": "./src/server/watchObservations.js",
     "./server/projectState": "./src/server/projectState.js",
     "./server/projectPromptHints": "./src/server/projectPromptHints.js",
     "./server/projectRecordMetadata": "./src/server/projectRecordMetadata.js",