Offer a ready update even when an earlier release is still held back

CHANGE_LOG.md

@@ -1,5 +1,28 @@
 # Change Log
 
+## 25/10/26 at 10:02:22 by [Ran Yahalom](mailto:ranya@wix.com)
+
+- Ran the general hosted replay of CLI 0.11.2 and skill 0.58.2 in Cursor on macOS with no replay id set, and recorded every release from 0.8.0 to 0.11.2 as `recommended` on the general rollout. The general rollout had been deferred since 0.8.0, so unverified harnesses (OpenClaw, Claude Code, Cursor) were never offered anything newer than 0.7.0, and CLIs before 0.11.2 stop at the first deferred release. The replay resumed a paid $1 booking in a new conversation, charged once, added the calendar event, ran a fresh Link sign-in, booked a pay-at-appointment service after the business's terms with nothing charged, and cancelled both bookings with status saying cancelled. Caveats are in the evidence: the restart was a new chat on the same machine, and the CLI was installed from the release commit's source folder before publication
+- Added the general rollout to the test that replays the walk inside already-installed CLIs, so a CLI on 0.7.0 is shown to reach 0.11.2, and noted the general backfill in `ops/verified-harnesses.md`
+
+---
+
+## 25/10/26 at 09:08:05 by [Ran Yahalom](mailto:ranya@wix.com)
+
+- Changed the update check so a `deferred` release holds back only itself. It used to stop at the first deferred release, so one held-back release (or a replay with no record for it) hid every later recommended release. Verified harnesses were never offered their approved pair, and unverified harnesses had the same problem on the general rollout. Released as 0.11.2
+- Recorded every release up to 0.11.2 as `recommended` for the Grok Bot, Base44 Superagent, and Muse replays, and pinned all three harnesses to 0.11.2 / skill 0.58.2. CLIs already installed there (0.10.0, 0.10.2, 0.11.1) still stop at the first gap, so without these records they could never reach the fixed CLI. Each added record says it was not replayed on that harness
+- Added tests that a gap or a deferred release no longer blocks a later ready one, that a withdrawn release is never the target, that every verified harness is offered its registry pin from any release since its replay, and that the old installed walk reaches 0.11.2 on each harness. These keep the registry and the runtime decision from drifting apart again
+- Rewrote the `deferred` rule in `CONTRIBUTING.md` and the backfill paragraph in `ops/verified-harnesses.md` to match, including that the backfill through 0.11.2 is a one-off. Raised the skill to 0.58.2 because re-pinning it to the new CLI changes `SKILL.md`
+
+---
+
+## 25/10/26 at 08:06:47 by [Ran Yahalom](mailto:ranya@wix.com)
+
+- Recorded the Muse replay of CLI 0.11.1 and skill 0.58.1 so Muse is a verified harness with its own replay id, install guide, and approved pair. The signed wheel was installed in the Secure VM, the chosen $1 HVAC-Koby booking was resumed after the boot id changed, the charge went through once, Muse added the calendar event without handing the CLI a token, and cancelling afterwards made status say the booking is cancelled. The general rollout stays deferred, so Grok Bot and Base44 Superagent are not offered 0.11.1
+- Wrote Muse's restart and calendar rules from that run: the restart is a Secure VM replacement that keeps `/home/hatch/workspace` (there is no safe Reset button), and calendar is the delegated route that can read busy times
+
+---
+
 ## 23/10/26 at 22:03:47 by [Ran Yahalom](mailto:ranya@wix.com)
 
 - Raised the `booking-agent` skill frontmatter to 0.58.1 and updated its stale literal `--skill-version 0.58.0` example, and re-ran `scripts/sync_skill_bundle.py` to re-pin `README.md`, `packages/cli/README.md`, and `bundled_skill.md`. The CLI 0.11.1 bump had re-pinned the skill's CLI version without raising the skill's own frontmatter version, so the `version` CI job failed on pull request [#66](https://github.com/wix/booking-agent/pull/66) with "changed but its frontmatter version 0.58.0 is not above 0.58.0"

booking-agent/CONTRIBUTING.md

@@ -157,7 +157,7 @@ Decide `change_type`, `update_status`, and `ecosystem_ready` in this order. Do n
    - `available`: a normal fix or internal improvement. Users are not prompted.
    - `recommended`: a ready feature with a clear benefit to users, or a broadly useful fix. Mentioned after a booking, or before one when it is relevant to it. A ready breaking release is offered before the next booking.
    - `urgent`: only for a security, data-loss, payment-safety, or severe correctness problem, and only with the release owner's approval written in the PR as `Release-owner approval: <who, why>`. Offered before the next booking.
-   - `deferred`: the rollout is not finished or evidence is missing. Never offered, and a newer version is not offered past it either, because installing it would bring this release's changes too.
+   - `deferred`: the rollout is not finished or evidence is missing. That release is never offered, but a later `recommended` or `urgent` release still is (from CLI 0.11.2 on; older CLIs stop at the first deferred release). Installing the later release brings this release's changes too, so the later release's evidence has to cover them.
    - `withdrawn`: a released version that must not be installed any more. Needs a newer, installable `replacement_version`.
 6. **Green CI is not readiness.** A newer version, passing tests, or a schema that validates does not show that the registry and live businesses work with the release.
 
@@ -186,7 +186,7 @@ assumed from this general checklist or from another harness passing it.
 
 This checklist is the **unverified** replay. It is what Cursor, Claude Code, and any other harness without its own replay uses. Passing it moves `deferred` to `recommended` only for those harnesses.
 
-A **verified** harness never inherits that result. Grok Bot and Base44 Superagent each have a replay in [ops/verified-harnesses.md](ops/verified-harnesses.md), including the restart that harness actually supports and whether calendar is connected. Passing one moves `deferred` to `recommended` only for the harnesses that share that replay. Two harnesses share a replay when both names in the registry point at the same replay id, so one successful run promotes both. The only way to recommend a release on a verified harness is to pass its replay and record that replay's rollout. A release that is `withdrawn` for everyone stays withdrawn for verified harnesses too.
+A **verified** harness never inherits that result. Grok Bot, Base44 Superagent, and Muse each have a replay in [ops/verified-harnesses.md](ops/verified-harnesses.md), including the restart that harness actually supports and whether calendar is connected. Passing one moves `deferred` to `recommended` only for the harnesses that share that replay. Two harnesses share a replay when both names in the registry point at the same replay id, so one successful run promotes both. The only way to recommend a release on a verified harness is to pass its replay and record that replay's rollout. The one exception is the records through 0.11.2 that let CLIs older than 0.11.2 reach it (see [ops/verified-harnesses.md](ops/verified-harnesses.md)); do not add more. A release that is `withdrawn` for everyone stays withdrawn for verified harnesses too.
 
 Saved session files have their own rule. Adding an optional field keeps `STORE_SCHEMA_VERSION` and `SCHEMA_VERSION` in `session.py` as they are: older builds keep fields they do not know when they save. Raising either number makes every older build refuse the file and ask its user to update, so that is a breaking change, and its release cannot be `available`.
 
@@ -198,7 +198,7 @@ What an installed assistant does with the decision:
 | `urgent`, or a ready `breaking` release that is `recommended` | Asked before the next booking starts |
 | `recommended` feature or fix | Offered after a booking; offered before one only when the request needs an affected capability; otherwise mentioned only if the assistant checks on the user's request |
 | `available` | Nothing |
-| `deferred`, or any release after a `deferred` one | Nothing |
+| `deferred` | Nothing for that release; a later ready release is still offered |
 | The installed version is `withdrawn` | Asked to move to `replacement_version` |
 
 Nothing is ever installed without the user's yes, never during a booking, and never from a source checkout. A user who says no is not asked about that version again. `BOOKING_AGENT_UPDATE_CHECK=0` turns all of it off.

booking-agent/README.md

@@ -23,8 +23,9 @@ These harnesses passed a hosted booking replay of their own. Follow the harness'
 <!-- verified-harnesses:start -->
 | Harness | Install guide | Approved CLI | Approved skill | Hosted replay |
 |---|---|---|---|---|
-| Base44 Superagent | [Install on Base44 Superagent](docs/harnesses/base44-superagent.md) | `0.10.2` | `0.57.4` | Passed 22 Oct 2026 with CLI 0.10.2 |
-| Grok Bot | [Install on Grok Bot](docs/harnesses/grok-bot.md) | `0.10.0` | `0.57.2` | Passed 22 Oct 2026 with CLI 0.9.1 |
+| Base44 Superagent | [Install on Base44 Superagent](docs/harnesses/base44-superagent.md) | `0.11.2` | `0.58.2` | Passed 22 Oct 2026 with CLI 0.10.2 |
+| Grok Bot | [Install on Grok Bot](docs/harnesses/grok-bot.md) | `0.11.2` | `0.58.2` | Passed 22 Oct 2026 with CLI 0.9.1 |
+| Muse | [Install on Muse](docs/harnesses/muse.md) | `0.11.2` | `0.58.2` | Passed 25 Oct 2026 with CLI 0.11.1 |
 <!-- verified-harnesses:end -->
 
 On a verified harness, install the approved pair, not the latest release. A newer release has not passed that harness's replay yet, so the installed CLI will not offer it there either. More about verified harnesses, and how a harness gets added: [docs/harnesses](docs/harnesses/README.md).
@@ -72,7 +73,7 @@ booking-agent skill print \
 Each release also publishes the skill at an immutable tag, `skill-v<frontmatter version>`, and signs it with the same workflow that signs the wheels, so a harness can pin and verify the exact text it follows:
 
 ```bash
-curl -fsSLO https://raw.githubusercontent.com/wix/booking-agent/skill-v0.58.1/booking-agent/skills/booking-agent/SKILL.md
+curl -fsSLO https://raw.githubusercontent.com/wix/booking-agent/skill-v0.58.2/booking-agent/skills/booking-agent/SKILL.md
 gh attestation verify SKILL.md \
   --repo wix/booking-agent \
   --signer-workflow wix/booking-agent/.github/workflows/release.yml

booking-agent/docs/harnesses/README.md

@@ -9,8 +9,9 @@ that release passes the same replay.
 <!-- verified-harnesses:start -->
 | Harness | Install guide | Approved CLI | Approved skill | Hosted replay |
 |---|---|---|---|---|
-| Base44 Superagent | [Install on Base44 Superagent](base44-superagent.md) | `0.10.2` | `0.57.4` | Passed 22 Oct 2026 with CLI 0.10.2 |
-| Grok Bot | [Install on Grok Bot](grok-bot.md) | `0.10.0` | `0.57.2` | Passed 22 Oct 2026 with CLI 0.9.1 |
+| Base44 Superagent | [Install on Base44 Superagent](base44-superagent.md) | `0.11.2` | `0.58.2` | Passed 22 Oct 2026 with CLI 0.10.2 |
+| Grok Bot | [Install on Grok Bot](grok-bot.md) | `0.11.2` | `0.58.2` | Passed 22 Oct 2026 with CLI 0.9.1 |
+| Muse | [Install on Muse](muse.md) | `0.11.2` | `0.58.2` | Passed 25 Oct 2026 with CLI 0.11.1 |
 <!-- verified-harnesses:end -->
 
 The approved CLI is the newest release that the harness's replay recommends. It can be

booking-agent/docs/harnesses/base44-superagent.md

@@ -7,13 +7,15 @@ and a verified copy of the CLI all live there.
 <!-- harness-pins:start -->
 | Item | Value |
 |---|---|
-| Approved Booking Agent CLI | `0.10.2` |
-| Approved Booking Agent skill | `0.57.4`, bundled in that CLI |
+| Approved Booking Agent CLI | `0.11.2` |
+| Approved Booking Agent skill | `0.58.2`, bundled in that CLI |
 | Replay id | `base44-superagent` |
 | Hosted replay | Passed 22 Oct 2026 with CLI 0.10.2 and skill 0.57.4 |
 
+The approved CLI carries every change the replayed CLI ran. Its release notes record why it is approved.
+
 ```bash
-cli=0.10.2
+cli=0.11.2
 replay=base44-superagent
 ```
 <!-- harness-pins:end -->

booking-agent/docs/harnesses/grok-bot.md

@@ -6,15 +6,15 @@ Only the Grok Bot app is installed by you; everything below runs on that cloud c
 <!-- harness-pins:start -->
 | Item | Value |
 |---|---|
-| Approved Booking Agent CLI | `0.10.0` |
-| Approved Booking Agent skill | `0.57.2`, bundled in that CLI |
+| Approved Booking Agent CLI | `0.11.2` |
+| Approved Booking Agent skill | `0.58.2`, bundled in that CLI |
 | Replay id | `grok-bot` |
 | Hosted replay | Passed 22 Oct 2026 with CLI 0.9.1 and skill 0.57.1 |
 
 The approved CLI carries every change the replayed CLI ran. Its release notes record why it is approved.
 
 ```bash
-cli=0.10.0
+cli=0.11.2
 replay=grok-bot
 ```
 <!-- harness-pins:end -->

booking-agent/docs/harnesses/muse.md

@@ -0,0 +1,126 @@
+# Install on Muse
+
+Muse runs the Booking Agent inside its Secure VM. The folder that survives a replacement
+of that VM is `/home/hatch/workspace`, so the booking, the Link sign-in, the skill, and
+a verified copy of the CLI all live there.
+
+<!-- harness-pins:start -->
+| Item | Value |
+|---|---|
+| Approved Booking Agent CLI | `0.11.2` |
+| Approved Booking Agent skill | `0.58.2`, bundled in that CLI |
+| Replay id | `muse` |
+| Hosted replay | Passed 25 Oct 2026 with CLI 0.11.1 and skill 0.58.1 |
+
+The approved CLI carries every change the replayed CLI ran. Its release notes record why it is approved.
+
+```bash
+cli=0.11.2
+replay=muse
+```
+<!-- harness-pins:end -->
+
+## Fastest install: paste this into Muse
+
+```text
+Install the Booking Agent inside your Secure VM, not on my computer, by following
+https://github.com/wix/booking-agent/blob/master/booking-agent/docs/harnesses/muse.md
+exactly. Use the pinned versions in that guide, not the latest release, and keep
+everything it saves under /home/hatch/workspace. List the commands before you run them
+and wait for my OK. Stop after the checks at the end and do not start a booking.
+```
+
+When the checks pass, start a new chat so Muse loads the skill from the beginning.
+
+## What the install runs
+
+1. Install [uv](https://docs.astral.sh/uv/getting-started/installation/) and Node.js if
+   they are missing, then `link-cli`, which handles Link sign-in and payment approval.
+   Keep that install under `/home/hatch/workspace`, which is the folder this VM keeps:
+
+   ```bash
+   root=/home/hatch/workspace
+   npm install -g @stripe/link-cli --prefix "$root/npm-global"
+   export PATH="$root/npm-global/bin:$PATH"
+   ```
+
+2. Set the pinned values from the table above (`cli=...` and `replay=...`).
+
+3. Download the approved CLI, check its signature from this repository's release
+   workflow, and install it from the checked file:
+
+   ```bash
+   mkdir -p "$root/verified-wheels"
+   uvx --python 3.12 pip download "booking-agent-cli==$cli" --no-deps --only-binary :all: \
+     -d "$root/verified-wheels"
+   uvx --python 3.12 pypi-attestations verify pypi --repository https://github.com/wix/booking-agent \
+     "$root/verified-wheels/booking_agent_cli-$cli-py3-none-any.whl"
+   uv tool install --force "$root/verified-wheels/booking_agent_cli-$cli-py3-none-any.whl"
+   ```
+
+4. Write the skill bundled in that CLI. If Muse also requires a `skill.yaml` next to
+   it, that file may point at this one. Leave the skill text unchanged:
+
+   ```bash
+   mkdir -p "$root/custom-skills/booking-agent"
+   booking-agent skill print \
+     | python3 -c 'import json,sys; sys.stdout.write(json.load(sys.stdin)["data"]["skill_text"])' \
+     > "$root/custom-skills/booking-agent/SKILL.md"
+   ```
+
+5. Keep the booking and the Link sign-in in `/home/hatch/workspace`, and set this
+   harness's replay so updates follow Muse's own rollout:
+
+   ```bash
+   booking-agent runtime prepare --persistent-root "$root"
+   grep -qx "BOOKING_AGENT_REPLAY=$replay" ~/.booking-agent/.env 2>/dev/null \
+     || printf '\nBOOKING_AGENT_REPLAY=%s\n' "$replay" >> ~/.booking-agent/.env
+   ```
+
+6. Check the result:
+
+   ```bash
+   readlink -f ~/.booking-agent/.env   # the file is inside /home/hatch/workspace
+   booking-agent skill version         # data shows the approved cli_version and skill_version
+   booking-agent config show           # BOOKING_AGENT_REPLAY is muse, from "user .env"
+   booking-agent runtime doctor        # healthy is true
+   link-cli --help
+   ```
+
+   Before the first VM replacement, `runtime doctor` can report
+   `folder_not_yet_shown_to_survive_a_restart`. That is expected.
+
+## After the Secure VM is replaced
+
+A replacement can remove installed programs. The workspace, including the verified
+wheel and the skill, stays. In the chat that continues the booking, set `cli` as in
+step 2, reinstall whatever is missing, and relink the saved folder. `booking-agent flow
+status` then finds the saved booking and the Link sign-in, so there is no new search
+and no second sign-in:
+
+```bash
+export PATH="/home/hatch/workspace/npm-global/bin:$PATH"
+uv tool install --force "/home/hatch/workspace/verified-wheels/booking_agent_cli-$cli-py3-none-any.whl"
+npm install -g @stripe/link-cli --prefix /home/hatch/workspace/npm-global
+booking-agent runtime prepare --persistent-root /home/hatch/workspace
+```
+
+Do not use Reset in Muse's data settings. That deletes the computer. A new chat on the
+same boot is not this replacement: the boot id has to change.
+
+## What to expect
+
+- **Calendar.** Muse reads and writes Google Calendar itself and does not hand the CLI
+  a token. The assistant connects with `--route delegated --delegated-can-read-busy`,
+  reports busy times when asked, and after payment creates the one event it was given
+  and reports that event back. The booked message includes the raw calendar link.
+- **Payment link.** After you say yes, Muse may ask once more before it posts the Link
+  approval URL. That second yes is Muse's own safety check. Approve the payment only
+  in Link.
+- **Updates.** The CLI offers a newer release only after it passes the Muse replay.
+  Until then it reports that the installed version is up to date.
+- **Not replayed here yet:** a pay-at-appointment booking (one paid in person, with no
+  charge at booking time). A paid booking, and cancelling it afterwards, were replayed.
+
+Replay procedure and evidence: [ops/verified-harnesses.md](../../ops/verified-harnesses.md#muse)
+and the release notes for the approved CLI.

booking-agent/ops/verified-harnesses.json

@@ -4,8 +4,8 @@
       "guide": "docs/harnesses/base44-superagent.md",
       "name": "Base44 Superagent",
       "recommended": {
-        "cli": "0.10.2",
-        "skill": "0.57.4"
+        "cli": "0.11.2",
+        "skill": "0.58.2"
       },
       "replay": "base44-superagent",
       "replayed": {
@@ -19,8 +19,8 @@
       "guide": "docs/harnesses/grok-bot.md",
       "name": "Grok Bot",
       "recommended": {
-        "cli": "0.10.0",
-        "skill": "0.57.2"
+        "cli": "0.11.2",
+        "skill": "0.58.2"
       },
       "replay": "grok-bot",
       "replayed": {
@@ -29,6 +29,21 @@
         "skill": "0.57.1"
       },
       "status": "verified"
+    },
+    "muse": {
+      "guide": "docs/harnesses/muse.md",
+      "name": "Muse",
+      "recommended": {
+        "cli": "0.11.2",
+        "skill": "0.58.2"
+      },
+      "replay": "muse",
+      "replayed": {
+        "cli": "0.11.1",
+        "date": "2026-10-25",
+        "skill": "0.58.1"
+      },
+      "status": "verified"
     }
   },
   "schema_version": 2