[yahalomran]

Summary

Two pieces of work ship together as CLI 0.11.2 / skill 0.58.2.

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

The installed CLI's update check stopped at the first deferred release. Every later release was then hidden, even a recommended one. Release notes treat the approved release as the newest recommended one and allow deferred releases in between, so the two rules disagreed:

• Verified harnesses were never offered their approved pair. For example, Base44 Superagent on 0.10.2 could not be offered a later replayed release, because 0.11.0 and 0.11.1 had no Base44 record.
• Unverified harnesses had the same problem on the general rollout. One deferred release hid every later recommended release.

Changes:

• select_target() in updates.py now skips a deferred release instead of stopping at it. A withdrawn release is still never the target. This covers both the general rollout and each replay's effective status, because both go through the same function. deferred still holds back a specific release on purpose.
• Bridge for CLIs already installed. Installed wheels keep the old walk, so every release up to 0.11.2 is recorded as recommended for grok-bot (0.10.1 to 0.11.2), base44-superagent (0.11.0 to 0.11.2), and muse (0.11.2). Each added record says it was not replayed on that harness and exists only so the installed CLI (Grok Bot 0.10.0, Base44 Superagent 0.10.2, Muse 0.11.1) can reach 0.11.2. From 0.11.2 on, only the newest recommended release needs a record. CONTRIBUTING.md and ops/verified-harnesses.md say this backfill is a one-off.
• ops/verified-harnesses.json pins all three harnesses to 0.11.2 / 0.58.2, because release_notes.py --check requires the pin to match the newest recommended release. The README tables and the install guides were regenerated from it. The replayed pairs are unchanged.
• Tests: a gap or an explicit deferred record no longer blocks a later ready release. A deferred release holds back only itself on the general rollout. A withdrawn release in a gap is never the target. Using the committed index and registry, every verified harness is offered its pin from any release since its replay. A copy of the old walk reaches 0.11.2 from each harness's installed CLI. The new behavior tests fail on the old code.

General replay of 0.11.2: recommend 0.8.0 through 0.11.2 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. CLIs before 0.11.2 also stop at the first deferred release. A general hosted replay of 0.11.2 was run on 25/10/26 in Cursor on macOS, with BOOKING_AGENT_REPLAY unset. Every release from 0.8.0 to 0.11.2 is now recommended with ecosystem_ready: true on the general rollout, and each points at that replay. Installing 0.11.2 brings all of their changes.

• Booking 1: the $1 HVAC-Koby AC Repair, with Google Calendar reconnected through the local sign-in. After the slot was chosen, a new Cursor chat was asked "what's going on with my booking?" and resumed at the summary. There was no second search, no second sign-in, and no reconnect request. After yes, "Booking it now." came at once and the Link approval URL was posted once. The chat noticed the approval with no further message. The $1.00 was charged once, the booked message included the raw calendar link, and flow status then returned the same message.
• Booking 2: started signed out of Link, so the sign-in URL was posted before any question. The calendar clash check removed 4 slots, including booking 1. The $2 HVAC-Koby AC Diagnostic & Inspection is paid at the appointment. flow book stopped for the business's payment terms and terms-of-service link. After the user accepted, checkout completed with nothing charged, and the booked message included the calendar link and "Nothing was charged".
• Cancel: both bookings were cancelled and both calendar events deleted. HVAC-Koby kept the $1.00, and the message gave the refund steps. flow status on the paid booking says it is cancelled.
• runtime doctor: healthy: true, with one info finding, not_persistent.
• Caveats in the evidence: the CLI was installed from the release commit's source folder before publication, so the signed-release check was not exercised. The restart was a new conversation on the same machine, not a fresh sandbox. The connector and delegated calendar routes, a deposit, and bank verification were not run. The release owner confirmed that the fault-report support service was redeployed and smoke-tested, and that pay-at-appointment is generally available.
• With the committed index, an unverified install on 0.5.0 through 0.11.1 is offered 0.11.2 through both the new and the old update check. A new test covers the old check from 0.7.0. Verified harnesses are unaffected: they still follow their own replay records.

Record the Muse replay of 0.11.1

This records the hosted replay of published CLI 0.11.1 and skill 0.58.1 on Muse as the muse rollout for that release (recommended). Muse gets its own replay id, procedure, and install guide.

• Evidence: the signed wheel came from PyPI and was kept under /home/hatch/workspace/verified-wheels. Skill 0.58.1 was written from booking-agent skill print. BOOKING_AGENT_REPLAY=muse was read from the persistent user .env (Muse does not inject it). The $1 HVAC-Koby AC Repair was chosen, then the chat stopped. Overnight the Secure VM was replaced: the boot id changed, /home/hatch/workspace was kept, and Reset was not used. The saved booking resumed with no second search and no second Link sign-in, and "what's going on?" returned that waiting recap. The user said yes and approved the $1 in Link once. The message included "You're booked" plus the raw calendar link. Muse wrote the event itself; the CLI had no token. The same turn cancelled the throwaway and reported the delete. flow status says the booking is cancelled and does not repeat the calendar link. runtime doctor reported survived_restart: true, boot_id_changed, healthy: true, and no findings.
• Calendar used the delegated route with --delegated-can-read-busy. Muse reported 10 busy intervals, and availability showed 14 slots after one conflict was removed.
• Caveats written into the evidence:
  • There is no control that replaces the Secure VM. This restart was the platform's own replacement. A new chat on the same boot does not count.
  • Muse held the Link approval URL behind its own safety check until a second yes, then noticed the approval with no further message. That second yes was not a second charge.
  • Pay-at-appointment was not run. HVAC-Koby did not refund the $1.00.

Test plan

• uv run python scripts/check_version.py --base origin/master
• uv run python scripts/release_notes.py --check
• uv run python scripts/harness_docs.py --check
• uv run python scripts/sync_skill_bundle.py --check
• uv run python scripts/generate_platform_profile.py --check
• uv run pytest -q (1642 passed, 3 skipped)

Release and rollout

• Version: 0.11.2
• Change type: fix
• Update status: recommended
• Affected capabilities: none for 0.11.2 itself (the update check only). The general rollout of 0.8.0 to 0.11.2 covers search, sign-in, calendar, booking, payment, and cancel.
• Interoperability impact: none. No USP, UCP, or platform profile change, no request shape change, and no session format change.
• Readiness evidence: the general hosted replay of 0.11.2 on 25/10/26 is recorded on every release from 0.8.0 to 0.11.2, together with the release owner's confirmation of the backend prerequisites. The replay rollouts for grok-bot, base44-superagent, and muse are the one-time bridge described above, not replays of 0.11.2 on those harnesses. The update decision is covered offline in test_updates.py.
• Hosted replay: passed on the general rollout in Cursor on macOS, 25 Oct 2026, CLI 0.11.2 (source-folder install of the release commit) and skill 0.58.2, with a paid booking, a pay-at-appointment booking, and cancel. Muse passed its own replay of 0.11.1 on 25 Oct 2026.
• Release-owner approval: n/a