mirror-mind 0.0.1 → 0.33.0

package/docs/releases/v0.10.1.md

@@ -0,0 +1,66 @@
+---
+digest: >
+  Mirror Mind v0.10.1 is a small production UX patch after the Web Visibility
+  release. It makes the Pi startup experience clearer when opening the Mirror
+  takes noticeable time, and it reframes release availability as a new version
+  signal rather than a generic update line. The patch does not change the update
+  executor or web visibility behavior; it improves how the runtime communicates
+  what is happening at startup.
+---
+
+# v0.10.1 — Welcome Startup Clarity
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Pi now shows an immediate startup status while checking sessions and memories.
+- Pi shows a second status while checking release availability.
+- The welcome now says `New Version Available` instead of `Update available`.
+- Pi renders welcomes with a new-version notice as warning-level notifications
+  for stronger visual emphasis.
+
+## Where We Started
+
+After publishing v0.10.0, production validation showed that opening Mirror could
+take long enough for the Pi startup counter to become visible. The user could see
+time passing, but not what Mirror was doing. At the same time, the release notice
+was technically correct but too quiet: `Update available` sounded operational,
+while the real product signal was that a new Mirror Mind version existed.
+
+## What Changed
+
+The Pi runtime extension now sets a status message before the startup work begins
+and updates that status before release awareness is checked. This gives the user
+a clear explanation while the counter is running: Mirror is checking sessions,
+memories, and release status.
+
+The welcome wording now uses `New Version Available`. When that line appears,
+Pi sends the welcome as a warning-level notification instead of a normal info
+notification, giving the release notice stronger emphasis within Pi's available
+UI controls.
+
+The welcome product spec was updated to reflect the new wording and emphasis
+expectation.
+
+## Conscious Exclusions
+
+This patch does not change the self-update executor, release detection logic, or
+stable-channel promotion flow.
+
+It also does not hard-code colors. Pi owns notification rendering; Mirror can
+choose the notification level, not exact text color.
+
+## What We Learned
+
+A release notice is not only information. It is an invitation to act. The wording
+and visual weight should match the user's mental model: they are not being told
+that an abstract update exists, they are being told that a new version of their
+Mirror is available.
+
+## Next Horizon
+
+If startup remains slow in production, the next improvement should measure which
+startup stage dominates: stale conversation closure, Pi session backfill,
+pending extraction, release check, or welcome composition. This patch makes the
+current wait legible; it does not yet optimize the wait itself.

package/docs/releases/v0.10.10.md

@@ -0,0 +1,51 @@
+---
+digest: >
+  Mirror Mind v0.10.10 routes welcome update prompts toward cumulative pending
+  release notes. When a new stable version is available, the suggested question
+  now asks for pending release notes, and the release-notes skill treats newly
+  available-version questions as a request for the full update path.
+---
+
+# v0.10.10 — Pending Release Notes Prompt
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Changed the welcome update prompt from ambiguous `what changed?` wording to
+  `show pending release notes`.
+- Updated the release-notes skill so questions about a newly available version
+  prefer `runtime release-notes pending`.
+- Preserved explicit `latest` and `vX.Y.Z` release-note flows for users who ask
+  for a single release.
+
+## Why This Patch Exists
+
+Production validation of v0.10.8 showed release detection working: opening Mirror
+surfaced v0.10.9 automatically. But the suggested question, `what changed?`, was
+too ambiguous. The agent interpreted it as a working-tree question and inspected
+git status instead of showing release notes.
+
+## What Changed
+
+The welcome now suggests:
+
+```text
+Ask: "show pending release notes" or "update my Mirror"
+```
+
+The Pi release-notes skill now maps natural-language questions about the newly
+available Mirror version to:
+
+```bash
+uv run python -m memory runtime release-notes pending
+```
+
+That is the correct final-user answer because it includes every release between
+the installed version and the current stable version.
+
+## Next Horizon
+
+After production updates to this version, publish a later stub release to validate
+the full loop: welcome detects a new release, suggests pending release notes, and
+the user's question renders the cumulative notes instead of git status.

package/docs/releases/v0.10.11.md

@@ -0,0 +1,39 @@
+---
+digest: >
+  Mirror Mind v0.10.11 is a validation stub for the v0.10.10 pending release
+  notes prompt. It intentionally includes no functional runtime change beyond the
+  version and release note, so production can validate that the welcome suggests
+  cumulative pending notes and routes the user's question correctly.
+---
+
+# v0.10.11 — Pending Notes Prompt Validation Stub
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Published a minimal stable release after the v0.10.10 prompt-routing patch.
+- Intentionally contains no functional runtime changes.
+- Exists to validate the final-user flow: welcome detects a newer stable release,
+  suggests pending release notes, and the user's question renders cumulative
+  release notes.
+
+## Why This Patch Exists
+
+v0.10.10 changed the welcome update prompt from the ambiguous `what changed?` to
+`show pending release notes` and updated the release-notes skill to prefer the
+cumulative pending view for newly available versions.
+
+To validate that behavior in production, a newer stable release must exist while
+production is already running v0.10.10.
+
+## 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.10 and confirm the welcome shows v0.10.11 with
+`show pending release notes`. Then ask that suggested question and confirm the
+answer uses `runtime release-notes pending` instead of git status.

package/docs/releases/v0.10.12.md

@@ -0,0 +1,57 @@
+---
+digest: >
+  Mirror Mind v0.10.12 fixes cumulative pending release notes when the local
+  stable ref is stale. `runtime release-notes pending` now safely fetches
+  remote-tracking refs before rendering, and welcome release awareness can map
+  short remote commits to full tag hashes so the version label appears reliably.
+---
+
+# v0.10.12 — Pending Release Notes Ref Refresh
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- `runtime release-notes pending` now safely fetches `remote/branch` refs before
+  reading release notes.
+- Added `--no-fetch` for local smoke tests such as `--ref HEAD --no-fetch`.
+- Welcome release awareness now matches short remote commit ids against full tag
+  hashes.
+- Updated runtime help and release-note documentation for the new pending-notes
+  fetch behavior.
+
+## Why This Patch Exists
+
+Production validation of the v0.10.11 stub showed that the welcome and prompt
+routing were working: opening Mirror detected a new stable release and the user
+question triggered `runtime release-notes pending`.
+
+But the pending command returned `Pending releases: none`. The reason was that
+welcome had detected the new remote stable commit without fetching, while
+`release-notes pending` read the local `origin/stable` ref. If that local ref was
+stale, the command could not see the newly published release note.
+
+## What Changed
+
+When the pending release-note source looks like a remote-tracking ref such as
+`origin/stable`, the command now runs a safe fetch for that branch before reading
+notes:
+
+```bash
+git fetch origin stable
+```
+
+This updates remote-tracking refs only. It does not merge, checkout, migrate,
+modify the working tree, or update the runtime.
+
+For local release-candidate smoke tests, use:
+
+```bash
+uv run python -m memory runtime release-notes pending --ref HEAD --no-fetch
+```
+
+## Next Horizon
+
+After production updates to this version, publish another minimal stable stub and
+validate the full final-user flow: welcome detects the new release, asks for
+pending notes, and pending notes render the cumulative release path.

package/docs/releases/v0.10.13.md

@@ -0,0 +1,35 @@
+---
+digest: >
+  Mirror Mind v0.10.13 is a validation stub for the v0.10.12 pending release
+  notes ref refresh. It intentionally contains no functional runtime change, so
+  production can validate that pending release notes fetch stable and render a
+  newly published release without manual git commands.
+---
+
+# v0.10.13 — Pending Notes Ref Refresh Validation Stub
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Published a minimal stable release after the v0.10.12 pending-notes fetch fix.
+- Intentionally contains no functional runtime changes.
+- Exists to validate that `show pending release notes` renders newly available
+  stable release notes without manual `git fetch`.
+
+## Why This Patch Exists
+
+v0.10.12 changed `runtime release-notes pending` so it safely fetches
+remote-tracking refs before reading release notes. To validate that behavior like
+a final user, production must already be on v0.10.12 and a newer stable release
+must exist.
+
+## 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.12, confirm it detects v0.10.13, then ask
+`show pending release notes`. The expected output should include this release.

package/docs/releases/v0.10.14.md

@@ -0,0 +1,42 @@
+---
+digest: >
+  Mirror Mind v0.10.14 polishes the welcome update prompt after the full
+  release-awareness cycle was validated in production. The prompt now asks
+  "what's new in this update?" instead of the more technical "show pending
+  release notes," while still routing to cumulative pending notes.
+---
+
+# v0.10.14 — Update Prompt Wording
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Changed the welcome update prompt to `what's new in this update?`.
+- Kept the prompt routed to cumulative pending release notes.
+- Added the new phrase to the release-notes skill routing examples.
+
+## Why This Patch Exists
+
+Production validation confirmed the full cycle works: welcome detects a new
+stable release, the suggested release-notes question renders cumulative pending
+notes, and `update my Mirror` updates the runtime. The remaining issue was tone.
+`show pending release notes` is accurate but too technical for a final-user
+welcome.
+
+## What Changed
+
+The welcome now renders:
+
+```text
+Ask: "what's new in this update?" or "update my Mirror"
+```
+
+The release-notes skill recognizes that phrase and continues to use the pending
+release-notes flow.
+
+## Next Horizon
+
+This closes the release-awareness wording loop. Future update UX can build on
+this by making the welcome actions more command-like or clickable in runtimes
+that support richer UI affordances.

package/docs/releases/v0.10.15.md

@@ -0,0 +1,53 @@
+---
+digest: >
+  Mirror Mind v0.10.15 adds explicit routing for the welcome action “update my
+  Mirror.” The new update skill maps natural-language update requests to the
+  safe runtime updater, so users are not asked to clarify between code updates
+  and identity/memory edits.
+---
+
+# v0.10.15 — Update Action Routing
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Added an `mm-update` skill for natural-language Mirror runtime update requests.
+- Routes `update my Mirror` to `uv run python -m memory runtime update`.
+- Documents the command in help, AGENTS/CLAUDE context, and the command reference.
+- Explicitly prevents agents from substituting manual `git pull`, `git fetch`, or
+  migration commands for the safe updater.
+
+## Why This Patch Exists
+
+Production validation showed that the welcome action `update my Mirror` was still
+ambiguous to the agent. Instead of running the safe updater, it asked whether the
+user meant a code update or an identity/memory update.
+
+For the welcome to behave like product UX, both suggested actions must be
+routable. Release-note questions already route to cumulative pending notes; the
+update action now routes to the runtime updater.
+
+## What Changed
+
+A new skill, `mm-update`, handles natural-language variants such as:
+
+```text
+update my Mirror
+apply the Mirror update
+install the new Mirror version
+```
+
+The skill runs:
+
+```bash
+uv run python -m memory runtime update
+```
+
+and shows the output verbatim.
+
+## Next Horizon
+
+After production updates to this version, publish one more stub if needed to
+validate that the welcome's `update my Mirror` action routes directly to the safe
+updater in a live release-available state.

package/docs/releases/v0.10.16.md

@@ -0,0 +1,35 @@
+---
+digest: >
+  Mirror Mind v0.10.16 is a validation stub for the v0.10.15 update-action
+  routing. It intentionally contains no functional runtime change, so production
+  can validate that the welcome action “update my Mirror” invokes the safe
+  runtime updater directly.
+---
+
+# v0.10.16 — Update Action Routing Validation Stub
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Published a minimal stable release after the v0.10.15 `mm-update` skill.
+- Intentionally contains no functional runtime changes.
+- Exists to validate that `update my Mirror` routes to `runtime update` in a live
+  release-available state.
+
+## Why This Patch Exists
+
+v0.10.15 added explicit routing for the welcome action `update my Mirror`. To
+validate that behavior like a final user, production must already be running
+v0.10.15 while a newer stable release is available.
+
+## 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.15, confirm it detects v0.10.16, then ask
+`update my Mirror`. The expected behavior is that the safe runtime updater runs
+without asking for clarification.

package/docs/releases/v0.10.17.md

@@ -0,0 +1,43 @@
+---
+digest: >
+  Mirror Mind v0.10.17 changes new-version welcome notifications from warning
+  tone to normal informational tone. The welcome text now uses a ✨ icon to call
+  attention to available updates without implying that something is wrong.
+---
+
+# v0.10.17 — Update Notice Tone
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- New-version welcome notices now use the ✨ icon.
+- Pi renders the welcome notification as informational instead of warning.
+- Update availability remains visible without looking like an error or problem.
+
+## Why This Patch Exists
+
+Production validation showed the release-awareness loop working end to end. The
+remaining visual issue was tone: Pi rendered the welcome as a yellow warning
+whenever a new version was available.
+
+An available update is useful information, not a problem. It should attract
+attention without implying danger.
+
+## What Changed
+
+The welcome update line now renders like:
+
+```text
+✨ New Version Available: v0.10.17
+Ask: "what's new in this update?" or "update my Mirror"
+```
+
+The Pi extension now sends the welcome notification with `info` severity even
+when the welcome includes an available update.
+
+## Next Horizon
+
+The release-awareness loop is now functionally validated and visually calmer.
+Future polish can focus on richer UI affordances if Pi exposes actionable
+notification buttons or links.

package/docs/releases/v0.10.2.md

@@ -0,0 +1,64 @@
+---
+digest: >
+  Mirror Mind v0.10.2 fixes stale welcome release awareness when stable advances
+  again inside the welcome cache window. A clone behind stable should see the
+  latest available version, not an intermediate version cached a few minutes
+  earlier. This patch keeps healthy up-to-date cache behavior cheap while making
+  visible update notices refresh before they are shown.
+---
+
+# v0.10.2 — Fresh Release Awareness
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Welcome update notices refresh even inside the cache TTL when an update is
+  already visible.
+- Users behind stable now see the latest stable tag after the stable branch
+  advances again.
+- `up_to_date` cache entries still respect the TTL to avoid unnecessary remote
+  checks.
+- Regression coverage now verifies that a cached `v0.10.0` notice refreshes to
+  `v0.10.1` when remote stable has advanced.
+
+## Where We Started
+
+After publishing v0.10.1, production validation showed the welcome still saying
+`v0.10.0` was available even though `origin/stable` and the `v0.10.1` tag already
+pointed to the newer release. The cache was technically fresh, but semantically
+stale: it preserved an intermediate update notice after stable moved again.
+
+## What Changed
+
+The welcome now treats visible update notices differently from healthy
+up-to-date cache entries. If the cache says `update_available`, Mirror refreshes
+release awareness before rendering the welcome, even when the cache is still
+inside its normal TTL. If the cache says `up_to_date`, the TTL behavior remains
+unchanged.
+
+This means a user can leave a production clone on an older version, publish a
+new patch shortly afterward, and still see the newest available release without
+manually deleting `runtime/update-check.json`.
+
+## Conscious Exclusions
+
+This patch does not implement cumulative release notes across all versions
+between the installed version and latest stable. It only ensures the visible
+latest-version signal is fresh.
+
+It also does not change `runtime update --check`, which remains intentionally
+conservative and does not fetch release-note files.
+
+## What We Learned
+
+A cache can be fresh by time and stale by meaning. For a status that is already
+asking the user to act, correctness matters more than avoiding one lightweight
+remote check. The cheap path is still correct for `up_to_date`; the action path
+must be more vigilant.
+
+## Next Horizon
+
+The next improvement is cumulative release awareness: when a user asks `what
+changed?`, Mirror should be able to show all release notes between the installed
+version and the latest stable version, not only the latest release note.

package/docs/releases/v0.10.3.md

@@ -0,0 +1,78 @@
+---
+digest: >
+  Mirror Mind v0.10.3 moves expensive Pi startup maintenance out of the blocking
+  startup path. Opening Pi now activates conversation logging quickly, renders
+  the welcome/status, and runs stale conversation closure, Pi session backfill,
+  and pending extraction in the background. This patch keeps the maintenance
+  work, but stops it from making the runtime feel stuck while it runs.
+---
+
+# v0.10.3 — Pi Startup Maintenance
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Pi now uses `conversation-logger session-start --fast` during startup.
+- Slow conversation maintenance runs in the background through
+  `conversation-logger session-maintenance`.
+- Maintenance output includes per-step timing for stale conversation closure,
+  Pi session backfill, and pending extraction.
+- The original blocking `session-start` path remains available for runtimes or
+  manual use that want startup maintenance inline.
+
+## Where We Started
+
+Production validation after v0.10.2 showed that Pi could still spend a long time
+opening Mirror. The status messaging improved, but the counter kept running and
+the user still experienced startup as blocked. Manual timing confirmed the slow
+path was conversation maintenance, not the release check.
+
+The startup command had accumulated too much work: it unmutes logging, closes
+stale conversations, backfills Pi JSONL sessions, and extracts pending
+conversations. Extraction can call LLMs, so doing all of that before the runtime
+feels open is the wrong boundary.
+
+## What Changed
+
+The conversation logger now has a fast startup path:
+
+```bash
+uv run python -m memory conversation-logger session-start --fast
+```
+
+This path only unmutes logging and returns immediately. Pi uses it during
+`session_start` so the runtime can open and render the welcome without waiting
+for historical maintenance.
+
+The heavier work moved into:
+
+```bash
+uv run python -m memory conversation-logger session-maintenance
+```
+
+Pi launches this command in the background. The command reports per-step timing,
+which makes future performance work concrete instead of speculative.
+
+## Conscious Exclusions
+
+This patch does not remove stale conversation closure, Pi session backfill, or
+pending extraction. It changes when that work runs.
+
+It also does not yet optimize the maintenance itself. If maintenance remains too
+slow or too expensive in the background, the next step is to tune individual
+stages, especially pending extraction.
+
+## What We Learned
+
+The product problem was not only slowness. It was blocked opening. Some
+maintenance belongs to eventual consistency, not the critical path of entering
+the runtime. A mirror can keep cultivating memory after the user has crossed the
+threshold.
+
+## Next Horizon
+
+Production validation should confirm whether Pi's startup counter now stops
+normally. If it still spins, the next investigation belongs to Pi lifecycle
+completion rather than Python maintenance cost. The timing output will also show
+whether pending extraction or backfill is the next optimization target.

package/docs/releases/v0.10.4.md

@@ -0,0 +1,42 @@
+---
+digest: >
+  Mirror Mind v0.10.4 fixes the remaining Pi startup lifecycle issue after
+  v0.10.3. Startup maintenance now runs as a fully detached fire-and-forget
+  process, so the extension does not keep Node child-process handles open while
+  Pi is trying to finish startup.
+---
+
+# v0.10.4 — Pi Startup Lifecycle
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Pi startup maintenance is now launched as a detached background process.
+- The extension no longer keeps stdout/stderr pipes or child-process close
+  handlers alive for maintenance.
+- Maintenance still appends its output to `mirror-logger.log` for diagnostics.
+
+## Why This Patch Exists
+
+v0.10.3 moved expensive conversation maintenance out of the blocking startup
+path. Production validation confirmed Mirror opened quickly again, but Pi's
+startup counter still did not stop.
+
+That narrowed the problem: the issue was no longer Python maintenance cost. It
+was extension lifecycle cleanup. The background process was still owned by the
+extension through active child-process handles and pipes.
+
+## What Changed
+
+The Pi extension now starts maintenance through a detached shell process with
+ignored stdio and immediately calls `unref()` on the child process. The command
+redirects its output into `mirror-logger.log`, preserving diagnostic evidence
+without keeping the extension's event loop attached to maintenance.
+
+## Next Horizon
+
+Production validation should confirm that Pi opens quickly and that the startup
+counter stops normally. If it still does not stop, the remaining cause is likely
+inside Pi's own lifecycle/working-indicator state rather than Mirror's child
+process handling.

package/docs/releases/v0.10.5.md

@@ -0,0 +1,57 @@
+---
+digest: >
+  Mirror Mind v0.10.5 adds cumulative pending release notes for users who are
+  more than one release behind. The runtime can now show every release newer than
+  the installed version instead of only the latest note.
+---
+
+# v0.10.5 — Cumulative Release Notes
+
+**Date:** 2026-05-25
+
+## Highlights
+
+- Added `runtime release-notes pending` to list all releases newer than the
+  current runtime version.
+- Added `--from <version>` for explicit comparison, useful for smoke tests and
+  support flows.
+- Added `--ref <git-ref>` so the command can read release notes from a specific
+  source such as `origin/stable` or `HEAD`.
+- Kept the existing `runtime release-notes latest` and explicit version behavior
+  unchanged.
+- Made Pi assistant-message logging fire-and-forget so Mirror persistence does
+  not sit on Pi's `agent_end` lifecycle path.
+
+## Why This Patch Exists
+
+After the Web Visibility release train, production validation showed a gap in the
+user experience: when a user is several versions behind, showing only the latest
+release note is not enough. They need the whole path between their installed
+version and the current stable release.
+
+## What Changed
+
+The runtime release notes command now supports a pending mode:
+
+```bash
+uv run python -m memory runtime release-notes pending
+```
+
+For diagnostics and validation, the comparison can be made explicit:
+
+```bash
+uv run python -m memory runtime release-notes pending --from 0.10.2 --ref HEAD
+```
+
+The output groups each pending release with its digest and highlights, preserving
+the concise release-note style while making cumulative updates visible.
+
+This patch also keeps the Mirror logger aligned with that lifecycle principle:
+assistant response persistence now runs in the background instead of being
+awaited inside Pi's `agent_end` extension hook.
+
+## Next Horizon
+
+The pending release flow should become the default companion to runtime update
+notices. A future polish pass can wire it directly into welcome/update guidance
+so users can ask what changed before applying an update.