mirror-mind 0.0.1 → 0.32.1

package/docs/releases/v0.10.6.md

@@ -0,0 +1,47 @@
+---
+digest: >
+  Mirror Mind v0.10.6 makes runtime update more resilient when the production
+  database is temporarily unavailable during the status gate. The updater now
+  attempts a safe MemoryClient bootstrap and retries status before failing,
+  avoiding a manual repair step for the common running-surface scenario.
+---
+
+# v0.10.6 — Update Status Recovery
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Runtime update now detects database-unavailable status-gate failures.
+- The updater attempts a safe database bootstrap through `MemoryClient` and
+  retries the status check before blocking the update.
+- Post-update status performs the same recovery attempt before reporting failure.
+- Recovery guidance now uses `uv run python -m memory ...` so production users do
+  not accidentally call a Python environment without the `memory` package.
+
+## Why This Patch Exists
+
+Production update validation showed a repeated failure mode: when a local Mirror
+surface has recently used the production database, `runtime status` can report
+`unable to open database file`. The update command then refuses to continue at
+the status gate.
+
+This is too likely for final users. They should not need to discover processes,
+kill a web server, or run a one-off Python command just to let the updater open
+the database again.
+
+## What Changed
+
+Before failing a status gate because the database is unavailable, runtime update
+now tries the same safe open path that previously fixed the issue manually:
+constructing a production `MemoryClient`, opening the configured database, and
+closing it. If that succeeds, the updater rebuilds status and continues.
+
+The same recovery is applied after fast-forward/migrations if post-update status
+sees the database as unavailable.
+
+## Next Horizon
+
+If users still hit database-unavailable update failures, the next step is to add
+explicit local surface lifecycle coordination so the updater can gracefully ask
+Mirror web surfaces to stop before update and restart after update.

package/docs/releases/v0.10.7.md

@@ -0,0 +1,53 @@
+---
+digest: >
+  Mirror Mind v0.10.7 reconciles runtime updater and release-management
+  documentation with the current command surface. The command reference,
+  troubleshooting guide, repair policy, release-note process, docs index, and
+  top-level help now describe cumulative release notes, updater repair, release
+  promotion options, and database-unavailable update recovery coherently.
+---
+
+# v0.10.7 — Runtime Operations Documentation
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Documented `runtime release-notes pending [--from] [--ref]` for cumulative
+  release-note visibility.
+- Documented `release-doctor --stable` and `release-promote --stable --remote
+  --dry-run --push`.
+- Documented the `v0.10.6` database-unavailable update recovery behavior.
+- Updated top-level `python -m memory --help` runtime usage with the current
+  arguments.
+- Clarified that final users should not need to kill web/runtime processes for
+  the common database-unavailable update case.
+
+## Why This Patch Exists
+
+The release train from `v0.10.0` through `v0.10.6` added several operational
+surfaces quickly: stable promotion, cumulative release notes, updater repair, and
+status-gate recovery. The code was ahead of the docs.
+
+Because these commands are safety boundaries, stale documentation is not just a
+cosmetic issue. It can push users toward manual repair paths when the runtime now
+has a safer command path.
+
+## What Changed
+
+The command reference now lists the current runtime command arguments and
+explains when to use pending release notes, updater repair, release doctor, and
+release promotion flags.
+
+The troubleshooting guide now has a dedicated entry for `unable to open database
+file` during update, pointing users to the repaired updater path for older clones
+and explaining that current versions recover automatically.
+
+The runtime repair policy now treats temporarily unavailable production
+databases as a bounded recovery scenario, not as a normal manual process-killing
+workflow.
+
+## Next Horizon
+
+Future operator-facing commands should update `REFERENCE.md`, the top-level help,
+and troubleshooting/repair docs in the same patch that introduces the behavior.

package/docs/releases/v0.10.8.md

@@ -0,0 +1,49 @@
+---
+digest: >
+  Mirror Mind v0.10.8 fixes welcome release awareness when a stable release is
+  published soon after a cached up-to-date check. Opening Mirror on the stable
+  channel now refreshes both update-available and up-to-date cache entries so
+  newly published versions can appear without manual cache or git commands.
+---
+
+# v0.10.8 — Welcome Release Awareness
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Welcome now refreshes fresh `up_to_date` update-cache entries on the stable
+  channel.
+- Newly published stable releases can appear when opening Mirror even inside the
+  normal cache TTL.
+- The fix preserves the existing remote-check disable switch:
+  `MIRROR_WELCOME_REMOTE_UPDATE_CHECK=off`.
+
+## Why This Patch Exists
+
+Production validation showed a gap between the update command and the welcome
+experience. `runtime update --check` correctly detected a new stable release,
+but opening Mirror did not show that a new version was available.
+
+The cause was the welcome cache. A cached `up_to_date` result was trusted for six
+hours. If stable advanced during that window, users could open Mirror and still
+see no update prompt.
+
+## What Changed
+
+The welcome update-awareness cache now refreshes on stable when the cached state
+is either `update_available` or `up_to_date`. This keeps startup awareness aligned
+with newly published stable releases without asking users to run `git fetch` or
+delete cache files.
+
+## Conscious Exclusions
+
+This patch does not remove caching and does not make non-stable channels perform
+the same remote awareness refresh. The behavior is targeted at the user-facing
+stable release channel.
+
+## Next Horizon
+
+A follow-up stub release can validate the behavior end-to-end: update production
+to this version, publish a later stable tag, then open Mirror and confirm the
+welcome detects the new release.

package/docs/releases/v0.10.9.md

@@ -0,0 +1,37 @@
+---
+digest: >
+  Mirror Mind v0.10.9 is a release-awareness validation stub. It intentionally
+  carries no functional runtime change beyond the version and release note, so a
+  production clone on v0.10.8 can validate that opening Mirror detects a newly
+  published stable release.
+---
+
+# v0.10.9 — Release Awareness Validation Stub
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Published a minimal stable release after the v0.10.8 welcome-awareness fix.
+- Intentionally contains no functional runtime changes.
+- Exists to validate that production Mirror shows a newly available stable
+  version when opened normally.
+
+## Why This Patch Exists
+
+v0.10.8 changed welcome release awareness so the stable channel refreshes cached
+`up_to_date` checks. To validate that behavior like a final user, production must
+already be on v0.10.8 and then a newer stable release must be published.
+
+This release provides that newer stable target without mixing the validation with
+unrelated product changes.
+
+## What Changed
+
+Only the package version, release note, release index, and worklog move forward.
+Runtime behavior is unchanged.
+
+## Next Horizon
+
+Open production Mirror on v0.10.8 and confirm it shows that v0.10.9 is available
+without manually running cache, git, or update-check commands first.

package/docs/releases/v0.11.0.md

@@ -0,0 +1,86 @@
+[< Releases](index.md)
+
+# v0.11.0 — Read-only Web Refinement
+
+## Digest
+
+This release closes CV13.E1, the first Mirror Web Experience epic. It refines
+the local read-only web surface after the 1.0 visibility foundation: Workspace
+becomes the front door, Identity becomes easier to scan, memory categories and
+search become navigable, and conversation cards become more useful without
+introducing writes or background operations.
+
+## Highlights
+
+- Workspace opens first and the main navigation is ordered Workspace, Identity,
+  Docs.
+- The header now presents Mirror Mind as the app identity and the current Mirror
+  user as a separate avatar/name lockup.
+- Docs, Workspace, Identity, memory category pages, and search results now share
+  the same contextual-bar rhythm.
+- Identity persona tokens use stable three-letter icons.
+- Identity memory categories open read-only category pages backed by surface
+  DTOs.
+- Header search opens a read-only results page over recent retained memories.
+- Workspace conversation cards show clearer message, persona, journey, and date
+  metadata.
+
+## Narrative context
+
+CV9.E6 made the Mirror visible on the web. CV13.E1 makes that visibility feel
+less like a diagnostic surface and more like a product. The work stayed inside a
+read-only boundary, but it changed the user's path through the app: Workspace is
+now the natural home, Identity remains a reflective map, Docs sits inside the
+same visual grammar, and memory/conversation surfaces have enough affordance to
+invite exploration.
+
+This is a pre-1.0 minor release. The earlier CV13 planning label was `v1.1`, but
+Mirror Mind has not yet crossed the CV9 `v1.0.0` boundary. Under the prospective
+versioning rule, closing this epic increments the current minor version to
+`v0.11.0`.
+
+## What changed
+
+- Added CV13.E1 roadmap stories and marked S1–S5 done.
+- Made Workspace the default perspective when no stored preference exists.
+- Removed task-oriented noise from Workspace metrics and tabs.
+- Removed the redundant perspective badge from the header.
+- Reworked the header and perspective switcher visual treatment.
+- Moved Docs navigation into the main content frame so Docs aligns with the
+  other perspectives.
+- Generated three-letter persona tokens in the Atlas surface read model.
+- Added a memory category drilldown surface and web route.
+- Replaced misleading progress bars with low/medium/high presence chips.
+- Added lexical read-only search over recent memory summaries.
+- Added a specialized renderer for Workspace conversation cards.
+
+## Conscious exclusions
+
+- No writes or editing flows.
+- No multi-Mirror selector or profile/preferences page.
+- No Mirror or journey configuration console.
+- No conversation transcript page.
+- No conversation retitle operation.
+- No semantic/vector web search.
+- No LLM calls during web page rendering.
+- No background Pi agent execution.
+
+## Validation
+
+Focused validation passed during the story cycle:
+
+```bash
+uv run pytest tests/unit/memory/surfaces/test_atlas.py tests/unit/memory/surfaces/test_search.py tests/unit/memory/surfaces/test_workspace.py tests/unit/memory/web/test_server.py tests/unit/memory/web/test_preferences.py
+uv run ruff check src/memory/web src/memory/surfaces tests/unit/memory/surfaces tests/unit/memory/web
+uv run ruff format --check src/memory/web src/memory/surfaces tests/unit/memory/surfaces tests/unit/memory/web
+node --check src/memory/web/static/app.js
+git diff --check
+```
+
+Navigator browser validation accepted each story.
+
+## Next horizon
+
+The next CV13 epic is Multi-Mirror and Preferences: choosing among local Mirrors
+under `~/.mirror-minds`, user profile/preferences, avatar, and dark/light/system
+mode.

package/docs/releases/v0.12.0.md

@@ -0,0 +1,67 @@
+[< Releases](index.md)
+
+# v0.12.0 — Multi-Mirror and Preferences
+
+## Digest
+
+This release closes CV13.E2, the Multi-Mirror and Preferences slice of the Mirror Web Experience. The local web app can now discover local Mirrors, switch safely among discovered Mirror databases, and persist user-facing web preferences per Mirror: display name, avatar symbol, and light/dark/system theme.
+
+## Highlights
+
+- The header Mirror selector discovers local Mirrors with `memory.db` and filters out non-Mirror directories such as backups.
+- Mirror switching is constrained to server-discovered local Mirror names; the browser never submits arbitrary filesystem paths.
+- Workspace, Identity, memory, and search surfaces reload against the selected Mirror database for the running web session.
+- A Preferences page shows the active Mirror context and the local preferences file path.
+- Display name and avatar symbol are stored per Mirror under `<mirror-home>/web/preferences.json`.
+- Theme preference supports `system`, `light`, and `dark`, applies immediately, and persists per Mirror.
+- The Mirror selector shows each Mirror's display name and avatar while keeping the technical directory name as detail.
+
+## Narrative context
+
+`v0.11.0` made the read-only web surface feel like a product. `v0.12.0` makes that product local-user aware. Mirror Web can now answer: which Mirror am I looking at, can I switch to another local Mirror safely, and how do I want this interface to identify and present this Mirror?
+
+The boundary remains intentionally local-first. This release does not add remote access, arbitrary database paths, identity mutation, configuration editing, authentication, or background operations. Preferences are web preferences, not changes to the Mirror identity graph.
+
+## What changed
+
+- Added a read-only Mirror registry for local web discovery.
+- Added `/api/mirrors` and safe `/api/mirrors/select` web endpoints.
+- Extended `/api/shell` with active Mirror path, discovered Mirrors, profile, theme, and preferences path.
+- Added server-side validation so Mirror selection only accepts discovered local Mirrors with `memory.db`.
+- Added a Preferences perspective to the web shell.
+- Added profile preference persistence for display name and avatar symbol.
+- Added theme preference persistence for `system`, `light`, and `dark`.
+- Applied selected theme through the document root while keeping `system` delegated to OS color preference.
+- Added final coherence coverage for cross-Mirror preference isolation.
+- Updated CV13.E2 roadmap and worklog records through S1–S5.
+
+## Conscious exclusions
+
+- No arbitrary path input.
+- No remote Mirror selection.
+- No authentication system.
+- No Mirror creation, deletion, migration, backup, or repair flows.
+- No identity graph/profile mutation.
+- No `.env` or runtime configuration editing.
+- No journey metadata editing.
+- No conversation retitle operation.
+- No LLM calls during page load or switching.
+- No web operation runner.
+
+## Validation
+
+Focused validation passed during the story cycle:
+
+```bash
+uv run pytest tests/unit/memory/web/test_preferences.py tests/unit/memory/web/test_mirrors.py tests/unit/memory/web/test_server.py
+uv run ruff check src/memory/web tests/unit/memory/web/test_preferences.py tests/unit/memory/web/test_mirrors.py tests/unit/memory/web/test_server.py
+uv run ruff format --check src/memory/web tests/unit/memory/web/test_preferences.py tests/unit/memory/web/test_mirrors.py tests/unit/memory/web/test_server.py
+node --check src/memory/web/static/app.js
+git diff --check
+```
+
+Navigator browser validation accepted S1–S5, including final cross-Mirror preference isolation and the Mirror selector's display-name/avatar presentation.
+
+## Next horizon
+
+The next CV13 epic is Configuration Console: inspect Mirror configuration and journey metadata through guarded web surfaces without weakening service boundaries.

package/docs/releases/v0.13.0.md

@@ -0,0 +1,64 @@
+[< Releases](index.md)
+
+# v0.13.0 — Configuration Console
+
+## Digest
+
+This release closes CV13.E3, the Configuration Console slice of the Mirror Web Experience. The local web app can now inspect non-sensitive Mirror/runtime configuration, understand selected environment boundaries with secrets masked, and manage selected journey metadata from the Workspace context where journeys already live.
+
+## Highlights
+
+- Added a read-only Configuration page for active Mirror paths and runtime defaults.
+- Organized Configuration into internal tabs to reduce visual clutter.
+- Added an Environment boundary section with selected allowlisted settings and secret masking.
+- Kept global Configuration scoped to Mirror/runtime settings instead of duplicating journeys.
+- Added a Workspace Settings tab for the selected journey.
+- Added safe journey metadata editing for project path, sync file, icon, and color.
+- Added final coherence coverage for secret masking, configuration boundaries, and journey metadata persistence.
+
+## Narrative context
+
+`v0.12.0` made Mirror Web local-user aware through Mirror switching and per-Mirror preferences. `v0.13.0` makes the local configuration boundary visible and safer to operate. The release separates concerns clearly: Configuration explains Mirror/runtime settings, Workspace owns journey settings, and Preferences owns user-facing web preferences.
+
+The release deliberately avoids raw configuration editors. It does not expose complete environment dumps, raw `.env` editing, YAML editing, database editing, or journey content editing. Where writes exist, they pass through a bounded service method and are limited to selected journey metadata fields.
+
+## What changed
+
+- Added `GET /api/configuration/overview` for non-sensitive configuration overview.
+- Added a Configuration tab to the web shell.
+- Shows Mirror home, database, preferences file, backups, exports, transcript exports, extensions, runtime environment, memory search model, memory extraction model, LLM audit logging, and conversation routing.
+- Added Environment boundary visibility for selected runtime variables.
+- Masks sensitive environment-derived values such as API keys.
+- Added a Workspace Settings section for the selected journey.
+- Added `POST /api/journeys/metadata` for safe metadata updates.
+- Added `JourneyService.update_metadata_fields()` for selected field updates.
+- Added tests for configuration serialization, masking, Workspace placement, safe write behavior, and final coherence.
+
+## Conscious exclusions
+
+- No raw `.env` editing.
+- No complete `os.environ` dump.
+- No secret disclosure.
+- No raw JSON/YAML/database editor.
+- No journey content or briefing editor.
+- No remote configuration management.
+- No operation runner.
+- No conversation retitle.
+
+## Validation
+
+Focused validation passed during the story cycle:
+
+```bash
+uv run pytest tests/unit/memory/surfaces/test_workspace.py tests/unit/memory/web/test_configuration.py tests/unit/memory/web/test_server.py
+uv run ruff check src/memory/services src/memory/surfaces src/memory/web tests/unit/memory/surfaces/test_workspace.py tests/unit/memory/web/test_configuration.py tests/unit/memory/web/test_server.py
+uv run ruff format --check src/memory/services src/memory/surfaces src/memory/web tests/unit/memory/surfaces/test_workspace.py tests/unit/memory/web/test_configuration.py tests/unit/memory/web/test_server.py
+node --check src/memory/web/static/app.js
+git diff --check
+```
+
+Navigator browser validation accepted S1–S5, including final Configuration/Workspace boundary coherence, environment masking, and safe journey metadata edit persistence.
+
+## Next horizon
+
+The next CV13 epic is Conversation Intelligence: readable transcripts, useful conversation titles, and safe retitle operations for individual and legacy conversations.

package/docs/releases/v0.14.0.md

@@ -0,0 +1,68 @@
+[< Releases](index.md)
+
+# v0.14.0 — Conversation Intelligence
+
+## Digest
+
+This release closes CV13.E4, the Conversation Intelligence slice of the Mirror Web Experience. Conversations are now readable as transcript pages, Workspace conversation cards navigate directly to those transcripts, titles can be corrected manually, and a single conversation can request an explicit OpenRouter-backed title suggestion that is previewed before saving. The release also improves configuration awareness with detailed reference links and adds read-only journey attachment visibility.
+
+## Highlights
+
+- Added read-only conversation transcript pages.
+- Linked Workspace conversation cards to transcript pages with mouse and keyboard navigation.
+- Added manual conversation title editing through a bounded service endpoint.
+- Added explicit single-conversation title suggestions through OpenRouter, with preview-only behavior and manual save approval.
+- Added detailed Configuration Reference documentation and compact reference icons in the Configuration page.
+- Added required/optional indicators for surfaced configuration items.
+- Removed transcript export directory visibility from the Configuration surface because it is not yet a clear product-facing operation.
+- Added read-only journey attachment visibility in Workspace.
+- Refined Workspace journey sidebar and metric card density.
+
+## Narrative context
+
+`v0.13.0` made Mirror/runtime configuration visible and safer to inspect. `v0.14.0` turns conversation history into a usable local reading surface. Conversation cards are no longer dead summaries: they open transcripts, show speaker labels aligned with the active Mirror profile, and allow intentional title improvement.
+
+The release keeps generation controlled. No LLM calls run on page load. Title suggestions happen only after clicking `Suggest title`, are not saved automatically, and must be approved through the existing manual `Save title` path.
+
+## What changed
+
+- Added `GET /api/conversations/detail` for bounded read-only transcript payloads.
+- Added direct `#conversation/<id>` navigation.
+- Added clickable and keyboard-accessible Workspace conversation cards.
+- Added `ConversationService.update_title()` and `POST /api/conversations/title`.
+- Added conversation title textbox to transcript pages.
+- Added `ConversationService.suggest_title()` and `POST /api/conversations/title-suggestion`.
+- Added `CONVERSATION_TITLE_PROMPT` and `generate_conversation_title()`.
+- Added Configuration Reference docs under `docs/reference/configuration.md`.
+- Added `docHref` and required/optional metadata to surfaced Configuration items.
+- Added read-only Workspace Attachments tab and attachment metric for selected journeys.
+- Propagated configured journey icons into the Workspace journey sidebar.
+
+## Conscious exclusions
+
+- No batch retitle execution.
+- No LLM call on transcript page load.
+- No automatic save after title suggestion.
+- No message editing.
+- No conversation deletion.
+- No attachment upload, editing, or deletion.
+- No raw configuration editor.
+- No transcript export operation surfaced in the web UI.
+
+## Validation
+
+Focused validation passed during the story cycle:
+
+```bash
+uv run pytest tests/unit/memory/surfaces/test_workspace.py tests/unit/memory/web/test_configuration.py tests/unit/memory/web/test_server.py
+uv run ruff check src/memory/services src/memory/surfaces src/memory/web tests/unit/memory/surfaces/test_workspace.py tests/unit/memory/web/test_configuration.py tests/unit/memory/web/test_server.py
+uv run ruff format --check src/memory/services src/memory/surfaces src/memory/web tests/unit/memory/surfaces/test_workspace.py tests/unit/memory/web/test_configuration.py tests/unit/memory/web/test_server.py
+node --check src/memory/web/static/app.js
+git diff --check
+```
+
+Navigator browser validation accepted transcript reading, card navigation, manual title edit, explicit title suggestion/approval, configuration reference links, compact configuration icons, journey sidebar refinements, metric density, and read-only attachment visibility.
+
+## Next horizon
+
+The next CV13 epic is Web Operations Runner: allowlisted maintenance operations with parameters, dry-runs, streaming progress, audit evidence, and controlled execution paths.

package/docs/releases/v0.15.0.md

@@ -0,0 +1,48 @@
+---
+digest: >
+  v0.15.0 closes CV13.E5 Web Operations Runner with the first safe action surface in Mirror Web. The release moves the web app beyond read-only inspection by introducing a server-owned operation catalog, bounded runnable operations, local audit evidence, and a visible Operations page. Execution is intentionally synchronous-first: operations run inside the current request, return structured evidence, and leave a local history record. Job-based execution, streaming, cancellation, restore flows, arbitrary commands, and runtime updates remain outside this release.
+---
+
+# v0.15.0 — Web Operations Runner
+
+**Date:** 2026-05-26
+
+## Highlights
+
+- Added a server-owned allowlist catalog for web operations.
+- Added runnable operations for runtime health, database backup, and conversation journey repair.
+- Added local audit persistence in `operation_runs` and a recent-runs API.
+- Added the visible Operations page with compact operation rows, operation detail panels, readable result cards, and recent audit evidence.
+- Kept execution synchronous-first, with no arbitrary shell command, raw SQL, restore, delete, update, background job, streaming, or cancellation surface.
+
+## Where We Started
+
+Mirror Web had become useful for visibility: Workspace, Identity, configuration, conversations, and attachments were inspectable without going to SQLite or the terminal. But operational care still lived mostly in CLI commands. Runtime health, database backup, and conversation journey repair were real maintenance needs, but asking users to run the right command with the right flags kept the web surface contemplative rather than operational.
+
+The risk was symmetrical. Moving operations into the browser could make Mirror easier to care for, but it could also accidentally become a remote command runner. The release had to create action without giving the web raw power over the machine.
+
+## What Changed
+
+The first layer was the operation contract. Mirror Web now exposes a catalog of server-owned operations with ids, descriptions, risk levels, dry-run behavior, execution state, and parameter declarations. The browser does not invent operations or submit command strings; it can only request operations that the server has declared.
+
+The second layer was bounded execution. `runtime-health` runs read-only runtime inspection and returns structured status data. `database-backup` creates and optionally verifies a local backup using the existing backup path for the selected Mirror home. `conversation-journey-repair` previews high-confidence journey association repairs by default and only applies them when `dryRun` is explicitly false, creating a backup first.
+
+The third layer was evidence. Operation runs are recorded locally in the selected Mirror database through the new `operation_runs` table. Successful and failed known-operation requests receive a `runId`, and recent runs can be listed through the web API. The audit record stores bounded parameters, status, outcome, timestamps, summaries, result evidence, and errors.
+
+The final layer was the surface. The Operations page shows operations as compact rows, keeps configuration inside an operation detail panel, renders operation-specific result cards, keeps raw JSON collapsed as evidence, and presents recent audit history as a simple list. Runtime health now explains what needs attention instead of only reporting `attention needed`.
+
+## Conscious Exclusions
+
+This release does not introduce background jobs, streaming events, cancellation, retry, scheduling, backup restore, backup download, backup deletion, runtime update execution, extension installation, arbitrary filesystem paths, arbitrary SQL, or arbitrary shell commands.
+
+Those exclusions are part of the safety boundary. v0.15 proves that Mirror Web can act through small, allowlisted, auditable operations before it learns to coordinate long-running work.
+
+## What We Learned
+
+The Operations surface clarified that audit evidence is not the same thing as a user interface. Raw JSON was useful while validating the contract, but the release only became coherent when results were rendered as operation-specific cards and raw payloads moved into collapsible evidence.
+
+The work also clarified the next architectural threshold. Synchronous execution is enough for small maintenance operations, but it should not be stretched into long-running work. The future job model should be introduced deliberately, not smuggled in through larger POST requests.
+
+## Next Horizon
+
+The visible horizon is an operation job model with polling, then streaming events and cancellation for operations that can take longer or need progress feedback. That future layer should build on the contracts created here: operation ids, declared parameters, local audit records, and explicit user approval.

package/docs/releases/v0.16.0.md

@@ -0,0 +1,50 @@
+---
+digest: >
+  v0.16.0 closes CV13 Mirror Web Experience with the first coherent async and agent-shaped web operations substrate. The release moves Operations from request-bound actions into durable asynchronous runs with lifecycle events, result timelines, controlled command execution, cooperative cancellation, approval checkpoints, and a bounded read-only agent-run prototype. The browser now opens operation results in a full-width run console with polled output, completion handling, historical result navigation, and a slow demo operation for validating progress. True SSE/WebSocket streaming, unrestricted headless agent execution, arbitrary shell access, and broad mutation authority remain intentionally outside this release.
+---
+
+# v0.16.0 — Async Operations and Agentic Web Console
+
+**Date:** 2026-05-27
+
+## Highlights
+
+- Converted web operations from synchronous `POST` execution into durable asynchronous operation runs.
+- Added `operation_run_events` so queued, running, progress, completed, failed, cancelled, approval-required, and approved states can be inspected as evidence.
+- Added a controlled command executor with fixed argv, `shell=False`, explicit cwd, sanitized environment, timeout, and bounded stdout/stderr capture.
+- Added cooperative cancellation, approval checkpoints before selected persistent writes, and a read-only `agent-run-prototype` operation.
+- Reworked the Operations UI into a full-width run console with polled output, result details, historical run navigation, completion messaging, and a bounded slow demo operation.
+
+## Where We Started
+
+v0.15.0 proved that Mirror Web could run small allowlisted maintenance operations safely. But those operations still lived inside the original request/response cycle. That was acceptable for runtime health, backups, and small repair flows, but it was the wrong shape for anything that takes time, asks for approval, emits evidence, or resembles agent work.
+
+The next step was not to add an unconstrained agent. It was to give operations the body an agent would eventually need: durable runs, visible progress, cancellation, approval, evidence, and a console where the user can watch work unfold.
+
+## What Changed
+
+Operations now start as asynchronous runs. `POST /api/operations/run` validates the server-owned operation and parameters, creates a queued run, returns a run id, and lets a local worker execute outside the original web request. Runs can be fetched directly and remain visible in recent history.
+
+Each run now records lifecycle evidence in `operation_run_events`. The event timeline preserves meaningful state transitions and progress messages. The UI uses that evidence to reopen historical results and to show current work in a run console instead of burying everything in audit cards.
+
+The release also adds the first command-shaped execution boundary. `runtime-diagnose` runs through a controlled executor: fixed argv, no shell, explicit cwd, sanitized environment, timeout, and captured bounded output. This is not a terminal in the browser. It is a code-owned command capability behind the operation catalog.
+
+Mutating work gained a pause point. Conversation journey repair apply requests now enter `approval_required` before persistent writes and continue only after an explicit approval action. Active runs can receive cancellation requests, with the current implementation remaining cooperative and evidence-based rather than forcibly killing Python threads.
+
+Finally, the release adds a bounded `agent-run-prototype`. It accepts an intent and returns a read-only proposal with explicit boundaries through the same run, event, approval-capable, and evidence model. The Operations UI now opens a full-width execution console with tabs for polled console output and result details, temporary completion messaging, clickable historical run cards, and a `run-console-demo` operation for validating progress over time.
+
+## Conscious Exclusions
+
+This release does not introduce true SSE/WebSocket streaming. The console updates by polling durable run state. It also does not embed an unrestricted Pi or headless agent runtime, expose arbitrary shell commands, accept user-supplied argv/cwd/env, run raw SQL, perform git mutation, execute runtime updates, install extensions, or provide broad write approval.
+
+The agent prototype is deliberately read-only and proposal-oriented. It proves the product shape and execution substrate without granting autonomous power over the local machine.
+
+## What We Learned
+
+The core design move was treating the agent as an extreme case of the operation model, not as a privileged bypass. Once that was clear, the sequence became coherent: async runs before events, events before command execution, command execution before cancellation and approvals, and only then an agent-shaped prototype.
+
+The browser validation also clarified that evidence is not enough. Users need to feel the run as a visible execution surface. The final console polish changed Operations from an audit page into a place where work can be watched, inspected, and trusted.
+
+## Next Horizon
+
+The visible horizon is hardening the run substrate toward real streaming and richer agent execution. Future work can replace polling with SSE/WebSocket, make cancellation cooperate with longer-running subprocesses, and connect a real headless agent behind the same allowlisted capability boundary. The boundary remains the important part: agent work should request explicit Mirror capabilities, not raw access to the machine.

package/docs/releases/v0.16.1.md

@@ -0,0 +1,55 @@
+---
+digest: >
+  v0.16.1 publishes the runtime update preflight resilience fix validated during
+  CV9.E2 stabilization. The updater now distinguishes full runtime readiness
+  from a narrow update-safe preflight state, so old code no longer blocks a
+  stable update only because the database already contains a core migration
+  introduced by the target version. Runtime status also recovers SQLite WAL
+  sidecar absence during read inspection. The normal safety path remains intact:
+  clean git state, backup, backup verification, fast-forward, migrations, and
+  post-update status are still enforced.
+---
+
+# v0.16.1 — Runtime Update Preflight Resilience
+
+**Date:** 2026-05-27
+
+## Highlights
+
+- Published the CV9.E2.S3 updater hardening fix as a patch release.
+- Allows `runtime update` to pass a narrow pre-update gate when the only blocker is core migration drift that the target release may resolve.
+- Keeps dirty git trees, missing databases, extension health issues, checksum drift, and unreadable migration ledgers blocked.
+- Recovers SQLite WAL sidecar absence during runtime status inspection without creating a missing database.
+- Preserves the normal backup, backup verification, fast-forward, migration, and post-update status gates.
+
+## Where We Started
+
+Production Mirror was on `0.15.0` while stable had advanced to `0.16.0`. The welcome correctly detected the new version, but the update command stopped at the status gate before fetching or fast-forwarding.
+
+The root problem was not the specific migration. It was the updater's shape. The old checkout used its own strict `runtime status` as a hard pre-update gate. When the database already contained a migration row introduced by the newer target release, the old code called that row unknown and blocked the very update that would make it known.
+
+A second fragility appeared in the same diagnosis: strict SQLite read-only inspection can report `unable to open database file` for a WAL database when sidecar files are absent or need refresh.
+
+## What Changed
+
+`runtime status` remains strict. It still reports attention when installed code sees pending or unknown core migrations.
+
+`runtime update` now has a narrower preflight interpretation. If mirror home resolution, git state, database existence, and extension health are safe, and the only remaining blocker is readable core migration drift, the updater may proceed into the normal update path. It still fetches the configured channel, accepts only no-op or fast-forward plans, creates and verifies a database backup before migrations, applies migrations through `MemoryClient`, and requires post-update status to be ready.
+
+The SQLite status reader still tries strict read-only mode first. If that fails with `unable to open database file`, it retries against the existing database in bounded read-write mode so SQLite can recreate WAL sidecars. It does not create a missing database file or mutate semantic Mirror data.
+
+## Conscious Exclusions
+
+This release does not add broad automatic repair. Dirty worktrees, diverged branches, missing databases, invalid extension manifests, extension migration drift, checksum drift, and unreadable migration ledgers still require explicit diagnosis and repair.
+
+This release also does not deliberately reproduce future migration drift in production by editing migration ledgers. That remains unsafe for a user's real memory database. The production recovery evidence and focused regression tests cover the failure class without corrupting the ledger.
+
+## What We Learned
+
+A self-updater cannot treat current-code status and update-preflight status as the same question. Runtime readiness asks whether the installed checkout and database are coherent now. Update readiness asks whether it is safe to move to code that may restore that coherence.
+
+The boundary is narrow, but important. Safety is not the same as refusing to move. Sometimes the safest operation is the controlled update path.
+
+## Next Horizon
+
+The next validation step is to update production from `0.16.0` to `0.16.1` through the normal user-facing flow. If we want to validate the newly installed updater executing another update, a later minimal stub such as `v0.16.2` can exercise that path without development-branch bridging.