mirror-mind 0.0.1 → 0.32.1

package/docs/releases/v0.16.2.md

@@ -0,0 +1,36 @@
+---
+digest: >
+  v0.16.2 is a validation stub for the v0.16.1 runtime update preflight
+  resilience fix. It intentionally contains no functional runtime change, so
+  production can validate a normal stable update executed by the corrected
+  updater already installed in v0.16.1. The release moves only version and
+  release-note metadata.
+---
+
+# v0.16.2 — Runtime Update Validation Stub
+
+**Date:** 2026-05-27
+
+## Highlights
+
+- Published a minimal stable release after v0.16.1.
+- Intentionally contains no functional runtime changes.
+- Exists to validate that the corrected updater in v0.16.1 can execute a normal production update to a newer stable release.
+
+## Why This Patch Exists
+
+v0.16.1 delivered the updater fix that distinguishes strict runtime readiness from a narrow update-safe preflight state. Production confirmed that the fix could be delivered through the normal stable channel.
+
+One more stub lets production validate the next question: can the newly corrected updater itself perform a normal stable update without development-branch bridging?
+
+## What Changed
+
+Only the package version, release note, release index, and worklog move forward. Runtime behavior is unchanged from v0.16.1.
+
+## Conscious Exclusions
+
+This release does not introduce new runtime behavior, database schema, web behavior, or updater logic. It also does not simulate future migration drift by editing production migration ledgers.
+
+## Next Horizon
+
+Open production Mirror on v0.16.1, confirm it detects v0.16.2, run the normal update path, and verify that production reports v0.16.2 with `runtime status` ready and `runtime update --check` up to date.

package/docs/releases/v0.17.0.md

@@ -0,0 +1,50 @@
+---
+digest: >
+  v0.17.0 hardens conversation titles across the Mirror lifecycle. The release turns first-message titles into provisional state, generates durable titles at conversation close, adds startup maintenance for missed or backfilled conversations, and makes legacy retitling available as a bounded web operation with dry-run cost estimates, backups, progress feedback, remaining counts, and long-run polling. The release also polishes the Operations console so long LLM batches feel observable instead of stalled. It does not add automatic unbounded LLM repair, page-load title generation, raw database editing, or a true streaming transport.
+---
+
+# v0.17.0 — Conversation Title Hardening
+
+**Date:** 2026-05-27
+
+## Highlights
+
+- Conversation titles created from first user messages are now marked provisional instead of being treated as final.
+- Conversation close now attempts safe automatic title generation for blank, truncated, skill-like, long, or provisional titles while preserving manual titles.
+- Startup conversation maintenance now repairs a small bounded batch of ended conversations whose titles still need improvement.
+- The web `batch-conversation-retitle` operation is runnable with dry-run, cost estimates, backup-before-apply, progress events, remaining counts, and long-run polling.
+- The Operations console was polished for batch work: generated titles appear as progress, noisy intermediate messages were removed, output behaves like a tailing console, and long runs keep polling beyond two minutes.
+
+## Where We Started
+
+Mirror had grown a useful conversation web surface, but the title lifecycle still carried an old assumption: the first user message was good enough to name a conversation. In real runtime sessions, that first message can be a skill payload, a command wrapper, a long setup prompt, or a fragment that only makes sense before the assistant responds. Once written, that title often stayed in the database indefinitely.
+
+The web app already supported manual title edits and single-conversation title suggestions, but that helped one conversation at a time. The larger problem had two sides: a legacy database with many weak titles, and a core runtime path that could keep creating more weak titles after the legacy repair finished.
+
+## What Changed
+
+The title lifecycle now carries provenance. Runtime logging marks first-message titles with `title_source=first_user` and `title_status=provisional`. Manual edits mark titles as manual, and generated titles record their source and previous value. This gives the core enough information to improve titles without overwriting user-approved names.
+
+`ConversationService.end_conversation()` now calls a safe title-generation path before extraction returns. It only runs for conversations with both user and assistant content, only replaces titles that are clearly missing or low quality, and fails quietly if the LLM cannot produce a title. Manual titles are explicitly protected.
+
+The startup maintenance path gained a second safety net. `session_maintenance()` now runs a small bounded `retitle_pending_conversations()` step for ended conversations that still need title repair. This covers sessions that missed normal close handling, imported Pi sessions, crashes, and other edge cases. Pi session backfill now also records imported first-user titles as provisional rather than writing them as final titles.
+
+For the legacy database, the existing web operation candidate `batch-conversation-retitle` became runnable. Dry-run estimates candidate count, token use, and cost without calling the LLM or writing to the database. Apply creates a backup before generating or saving titles, processes a bounded batch, records progress events with generated titles, and reports how many candidates remain before and after the batch.
+
+Dogfooding the operation shaped the Operations console. The console now displays useful title-generation progress, avoids noisy “generating” lines, anchors output like a tailing terminal, scrolls to the newest event, and polls long enough for larger LLM batches to finish. A run that appeared to stop at 67/100 was traced to a two-minute browser polling limit; the backend had completed 100/100. The browser now keeps watching long runs for up to thirty minutes.
+
+## Conscious Exclusions
+
+This release does not run unbounded title repair automatically. Startup maintenance uses a small limit and remains fail-quiet so opening Mirror does not become an unexpected large LLM job. Large legacy repair remains an explicit web operation.
+
+The release does not generate titles on transcript page load, does not edit messages, does not expose raw database editing, and does not add arbitrary SQL or shell access. The Operations console still uses polled durable state rather than true SSE/WebSocket streaming.
+
+## What We Learned
+
+The first fix — retitling at conversation close — was necessary but not sufficient. Runtime systems need recovery layers because close hooks can be missed, imports can bypass the normal path, and historical data rarely follows the current contract. The stronger design is layered: provisional title at creation, automatic improvement at close, bounded maintenance at startup, and explicit batch repair for legacy data.
+
+The production batch also reinforced that observability is part of safety. A long-running operation that is technically correct but visually silent feels broken and invites duplicate execution. Showing generated titles, remaining counts, backup evidence, and durable completion state makes the user trust the operation enough to let it finish.
+
+## Next Horizon
+
+The next visible horizon is broader conversation maintenance health: logger failure visibility, better retry/backoff metadata for skipped title attempts, and eventually a true streamed operation console. The title pipeline itself is now stable enough for normal use, but future work can refine title quality heuristics and make failed generation attempts easier to inspect without turning startup into a heavy background job.

package/docs/releases/v0.17.1.md

@@ -0,0 +1,58 @@
+---
+digest: >
+  v0.17.1 is a small Builder Mode boundary patch after v0.17.0. It fixes the
+  production-clone guard so Builder inspects the selected journey's project
+  checkout instead of the current Mirror runtime checkout. This preserves the
+  original safety intent — preventing accidental edits inside production
+  project clones — while allowing a production Mirror runtime to open Builder
+  for journeys whose project paths point at development clones. The release
+  also updates the boundary documentation so the rule is explicit.
+---
+
+# v0.17.1 — Builder Project-Path Guard
+
+**Date:** 2026-05-28
+
+## Highlights
+
+- Fixes `memory build load <slug>` so the clone-role guard evaluates the journey `project_path`.
+- Allows Builder Mode from a production Mirror runtime when the journey project itself is a `dev` clone.
+- Keeps the conservative fallback to the current directory when no `project_path` is configured.
+- Updates runtime boundary docs and decisions to describe the journey-scoped guard.
+
+## Where We Started
+
+The clone-role guard was introduced to prevent accidental development inside the
+Mirror production checkout. That safety boundary was correct, but its placement
+was too broad: Builder Mode inspected the current runtime directory before it had
+loaded the journey. If the user ran a production Mirror runtime and selected a
+journey whose project lived elsewhere, Builder could refuse before seeing the
+project path that actually mattered.
+
+The result was friction in the wrong place. The guard protected the runtime clone
+rather than the project clone that Builder was about to edit.
+
+## What Changed
+
+Builder Mode now loads the journey first, reads its configured `project_path`,
+and passes that path into clone-role inspection. If that project checkout is
+marked `dev`, Builder proceeds even when the Mirror runtime itself is running
+from a production clone. If the project checkout is marked `production`, Builder
+still refuses unless `--ignore-production-role` is passed.
+
+For journeys without a configured `project_path`, the command keeps the prior
+conservative behavior and inspects the current directory. That keeps unscoped
+Builder sessions safe by default.
+
+## Conscious Exclusions
+
+This patch does not change runtime update behavior, clone-role marker semantics,
+or the override flag. It also does not add automatic project-path discovery; the
+journey must still carry the correct `project_path` metadata for the guard to be
+project-scoped.
+
+## Next Horizon
+
+Production should update normally to v0.17.1, then validate a Builder activation
+from the production Mirror runtime against a journey whose project path points to
+a development checkout.

package/docs/releases/v0.17.2.md

@@ -0,0 +1,42 @@
+---
+digest: >
+  v0.17.2 is a validation patch immediately after v0.17.1. It keeps the
+  Builder project-path guard behavior unchanged and fixes the repository
+  formatting drift that made the v0.17.1 main CI run fail at the ruff format
+  gate. The release exists so the latest stable channel points at a green,
+  validated patch commit.
+---
+
+# v0.17.2 — Builder Guard CI Formatting
+
+**Date:** 2026-05-28
+
+## Highlights
+
+- Preserves the v0.17.1 Builder project-path guard behavior.
+- Applies repository formatting expected by CI.
+- Advances the package and release metadata so stable can point at a green patch commit.
+
+## Why This Patch Exists
+
+v0.17.1 published the intended Builder Mode fix, but the main CI run failed at
+`ruff format --check` because a few files were not formatted according to the
+repository-wide formatter gate. The runtime behavior was correct, but the release
+should not leave the latest stable channel on a commit whose CI is red.
+
+## What Changed
+
+This patch formats the affected Python files and advances release metadata from
+v0.17.1 to v0.17.2. The Builder guard semantics are unchanged from v0.17.1:
+Builder inspects the selected journey's `project_path` clone role and falls back
+to the current directory only when no project path is configured.
+
+## Conscious Exclusions
+
+This release does not add new Builder behavior, runtime update behavior, schema
+changes, or web functionality.
+
+## Next Horizon
+
+Validate GitHub Actions for the v0.17.2 main push, then use the normal stable
+update path from production.

package/docs/releases/v0.17.3.md

@@ -0,0 +1,58 @@
+---
+digest: >
+  v0.17.3 completes the Builder Mode boundary fix after the v0.17.2 production
+  validation showed one more false block. Builder now applies the production
+  clone-role guard only to Mirror Mind source checkouts, not to ordinary journey
+  projects that naturally do not carry `.mirror-clone-role`. This preserves the
+  original safety intent — do not edit a production Mirror checkout by accident —
+  while allowing projects such as Software Zen to open Builder normally from a
+  production Mirror runtime.
+---
+
+# v0.17.3 — Builder Guard Non-Mirror Projects
+
+**Date:** 2026-05-28
+
+## Highlights
+
+- Restricts the Builder clone-role guard to Mirror Mind source checkouts.
+- Allows non-Mirror journey projects without `.mirror-clone-role` to load Builder Mode.
+- Keeps protection for Mirror Mind project paths marked `production`.
+- Updates boundary docs to clarify that the marker belongs to Mirror Mind clones, not all journey projects.
+
+## Where We Started
+
+v0.17.2 correctly moved Builder's clone-role inspection from the current runtime
+checkout to the selected journey `project_path`. Production validation then
+showed the remaining problem: ordinary projects without `.mirror-clone-role` were
+still treated as `production` because the clone-role inspector defaults missing
+markers to production.
+
+That default is right for Mirror Mind source checkouts, where safety should be
+conservative. It is wrong for arbitrary journey projects. Software Zen pointed to
+`/Users/alissonvale/Code/szen_play`, a normal project checkout, and Builder still
+refused because there was no Mirror clone-role marker.
+
+## What Changed
+
+Builder now first checks whether the target path appears to be a Mirror Mind
+source checkout. Only then does it apply `inspect_clone_role()` and enforce the
+production/dev boundary. Non-Mirror journey projects skip the Mirror-specific
+clone-role guard and proceed normally.
+
+If a journey points at Mirror Mind itself, the guard still works: production
+Mirror checkouts refuse Builder by default, dev checkouts proceed, and
+`--ignore-production-role` remains the explicit escape hatch.
+
+## Conscious Exclusions
+
+This patch does not introduce a generic production/dev marker for all possible
+user projects. The existing `.mirror-clone-role` marker remains a Mirror Mind
+runtime/source safety mechanism. Projects that want their own environment guards
+should define them in their own tooling.
+
+## Next Horizon
+
+Production should update to v0.17.3 and retry Builder Mode for `softwarezen`.
+The expected result is that `/Users/alissonvale/Code/szen_play` loads without
+requiring `--ignore-production-role`.

package/docs/releases/v0.18.0.md

@@ -0,0 +1,84 @@
+---
+digest: >
+  v0.18.0 completes the Conversation Metadata Lifecycle release arc. Mirror now
+  finalizes non-manual title, summary, and tags when conversations close;
+  exposes contextual metadata maintenance in the web conversation detail; and
+  gives Operations a production-ready historical metadata backfill with dry-run,
+  safe/force modes, all-conversation batches, resume scopes, approval, backups,
+  per-conversation progress, no-change evidence, and orphan conversation cleanup.
+  Manual metadata remains preserved by default.
+---
+
+# v0.18.0 — Conversation Metadata Lifecycle
+
+**Date:** 2026-06-01
+
+## Highlights
+
+- Finalizes non-manual conversation metadata at close time.
+- Adds web conversation-detail maintenance for title, summary, and tags.
+- Adds historical metadata backfill through Operations with dry-run, approval, backups, progress, and final result evidence.
+- Supports `safe` and `force` backfill profiles while preserving manual metadata by default.
+- Adds all-conversation and resume/review scopes for production-scale backfill.
+- Adds approval-gated orphan conversation cleanup with backup and deletion progress.
+
+## Where We Started
+
+Mirror already had first-message/provisional titles and batch retitling, but
+conversation metadata still behaved too narrowly. Old conversations could have
+thin titles, missing summaries, missing tags, or stale metadata provenance. The
+runtime also had no close-time finalization step, and users had to use CLI tools
+for broad historical repair.
+
+That was especially painful in the web console: Operations could run long tasks,
+but metadata lifecycle maintenance was not yet visible enough for a real user to
+trust a broad production backfill.
+
+## What Changed
+
+Conversation metadata now has explicit lifecycle policy and execution profiles.
+`safe` mode applies clear repairs conservatively, `force` regenerates selected
+non-manual metadata, and close-time finalization refreshes non-manual metadata
+when a conversation ends. Manual title, summary, and tag edits remain protected.
+
+The web conversation detail now exposes contextual maintenance: check whether
+metadata needs updating, review user-facing reasons, suggest/save title and
+summary, edit tags, and apply a report-driven metadata update.
+
+Operations now includes **Historical metadata backfill**. It can preview or
+apply batches, choose safe/force from a dropdown, filter by journey, process all
+matching conversations, or scope to `not_backfilled` and `no_change_latest_run`
+for recovery/review. Apply requires approval, creates a backup, emits progress
+per conversation, and renders final result details including changed and
+no-change evidence.
+
+A companion **Orphan conversation cleanup** operation handles the cleanup found
+during real production backfill: short orphan conversations that produced no
+metadata changes. It supports dry-run, candidate review, approval, backup,
+reference cleanup, per-conversation deletion progress, and final deleted counts.
+
+## Production Validation
+
+This release was validated against the user's real Mirror database. The broad
+force backfill processed 579 conversations, changed 482, and identified 97
+no-change results. A follow-up orphan cleanup preview found short orphan
+conversations; the cleanup path was hardened after production revealed foreign-key
+and database-lock failure modes.
+
+The final operation path now handles referenced orphan conversations, commits
+before emitting progress, and marks unexpected thread failures as failed instead
+of leaving runs stuck as running.
+
+## Conscious Exclusions
+
+- No automatic unbounded background backfill is enabled.
+- `force` still preserves manual metadata by default.
+- Orphan cleanup does not infer journeys or recover content; it deletes only the selected previewed candidates after approval.
+- Operations still uses polling rather than true streaming/SSE.
+- Active per-turn metadata refresh remains future work beyond close-time and explicit maintenance/backfill operations.
+
+## Next Horizon
+
+The remaining CV9 stabilization work can now focus on boundary hardening,
+release readiness, and any polish discovered after production uses v0.18.0 as
+the baseline metadata lifecycle release.

package/docs/releases/v0.18.1.md

@@ -0,0 +1,51 @@
+---
+digest: >
+  v0.18.1 expands the v0.18.0 cleanup operation so production users can remove
+  empty conversation records as well as journey-orphan records. The default
+  no-change cleanup source now includes latest-backfill no-change conversations
+  that are either orphaned or empty, which covers sessions with a journey but no
+  messages. Deletion remains dry-run, approval, and backup gated.
+---
+
+# v0.18.1 — Empty Conversation Cleanup
+
+**Date:** 2026-06-01
+
+## Highlights
+
+- Expands Orphan conversation cleanup to include empty conversations.
+- Adds an explicit `empty_conversations` cleanup source.
+- Makes the default latest-backfill no-change cleanup include records that are orphaned or empty.
+- Shows cleanup reason and journey in candidate result lists.
+- Keeps deletion protected by dry-run, approval, and backup.
+
+## Where We Started
+
+After v0.18.0 shipped, production cleanup showed a second low-substance record
+shape: conversations with `message_count = 0` but a valid journey association.
+They are not orphan conversations, so the original cleanup operation correctly
+left them alone even though they were just abandoned session shells.
+
+## What Changed
+
+The existing cleanup operation now treats low-substance cleanup as a superset of
+orphan cleanup. `all_orphans` still means records with no journey. The new
+`empty_conversations` source targets records with zero messages even if they have
+a journey. The default `no_change_latest_backfill` source now includes latest
+metadata-backfill no-change records when they are either orphaned or empty.
+
+Candidate rows now include a cleanup reason (`orphan`, `empty`, or
+`orphan_and_empty`) and the journey value, so the user can understand why each
+record is eligible before approving deletion.
+
+## Conscious Exclusions
+
+- Non-empty conversations with a journey are still not cleanup candidates.
+- Empty cleanup does not infer whether an abandoned session was important; it only exposes a preview and requires explicit approval.
+- The operation remains backup-gated before deletion.
+
+## Next Horizon
+
+If more low-substance shapes appear, cleanup should become a clearer
+Conversation Cleanup operation with named policies rather than continuing to
+stretch the orphan-specific title.

package/docs/releases/v0.18.2.md

@@ -0,0 +1,69 @@
+---
+digest: >
+  v0.18.2 adds manual and assisted journey association tools for conversation
+  organization. The Workspace now exposes unassigned conversations, conversation
+  detail pages can assign or transfer a conversation to any journey, and the
+  unassigned list supports selecting multiple conversations and assigning them
+  together. Operations also gains a conservative Conversation journey backfill
+  with dry-run, explicit/title-alias modes, approval, backup, progress, and
+  evidence. Completed journeys are available in assignment dropdowns.
+---
+
+# v0.18.2 — Conversation Journey Assignment
+
+**Date:** 2026-06-02
+
+## Highlights
+
+- Adds an **Unassigned** entry in Workspace for conversations without a journey.
+- Adds a Journey selector on conversation detail pages for manual assignment or transfer.
+- Adds multi-select bulk assignment from the Unassigned conversations list.
+- Includes completed/non-active journeys in assignment dropdowns.
+- Adds a conservative **Conversation journey backfill** Operation with preview/apply modes.
+- Keeps automated apply protected by approval, backup, and per-conversation progress.
+
+## Where We Started
+
+After the metadata lifecycle release, production data showed that many historical
+conversations still had no journey. Automatic repair was too conservative to fix
+most of them, and the web UI did not give the user enough control: unassigned
+conversations were hard to find, individual conversations could not be moved, and
+there was no way to bulk-correct the remaining obvious cases.
+
+## What Changed
+
+Workspace now includes an **Unassigned** surface. It lists conversations whose
+`journey` field is missing and lets the user open each one. Conversation detail
+pages now include a Journey section with a selector, so a user can assign a
+conversation, transfer it to another journey, or mark it unassigned.
+
+For cleanup at scale, the Unassigned surface now supports selecting multiple
+conversations and assigning them to a chosen journey in one explicit action. The
+journey selector uses all journey identities, not only active journeys, so older
+or completed journeys can receive historical conversations.
+
+Operations also includes **Conversation journey backfill**. Its `explicit_only`
+mode uses strong activation signals such as `$mm-build mirror-mind`, `/mm:build
+ariad`, or explicit jornada/travessia mentions. Its `title_alias` mode adds
+unambiguous title aliases. Dry-run is the default; apply requires approval,
+creates a backup, and emits assignment progress.
+
+## Production Validation
+
+Production dry-runs found 29 `explicit_only` candidates and 60 `title_alias`
+candidates. The manual Unassigned UI and spacing were validated in the local web
+server. The completed-journey issue was caught in production use and corrected so
+assignment dropdowns include completed journeys.
+
+## Conscious Exclusions
+
+- No LLM-based journey inference is included.
+- Ambiguous semantic matches are intentionally excluded from automatic backfill.
+- Bulk assignment is selected-only; it does not assign everything visible by default.
+- Individual manual journey changes do not require a heavy approval checkpoint, but batch/operation apply remains explicit.
+
+## Next Horizon
+
+If more historical repair is needed, the next step is an assisted review surface
+that shows suggested journey, confidence, and evidence with per-row accept/reject
+rather than applying ambiguous suggestions automatically.

package/docs/releases/v0.19.0.md

@@ -0,0 +1,85 @@
+---
+digest: >
+  v0.19.0 expands the Mirror web console from conversation organization into
+  direct conversation and journey maintenance. Users can now create journeys
+  from Workspace through a reviewable draft flow, delete individual
+  conversations, delete selected unassigned conversations in bulk, and see a
+  larger conversation trail for selected journeys. The release keeps destructive
+  actions explicit, preserves extracted memories when conversations are deleted,
+  and treats journey creation as an editable identity artifact rather than a
+  brittle administrative form.
+---
+
+# v0.19.0 — Web Console Conversation and Journey Maintenance
+
+**Date:** 2026-06-02
+
+## Highlights
+
+- Adds **New journey** in Workspace with natural-language input, generated markdown draft, editable preview, and bounded create validation.
+- Adds explicit conversation deletion from conversation detail pages.
+- Adds **Delete selected** beside **Assign selected** on the Unassigned conversations surface.
+- Preserves extracted memories when deleting conversations by detaching their `conversation_id` instead of deleting the memory records.
+- Expands selected-journey conversation visibility from a small eight-item slice to a larger bounded trail.
+- Polishes maintenance controls so destructive and primary actions remain visually distinct.
+
+## Where We Started
+
+The previous release made unassigned conversations visible and assignable, which
+surfaced the next maintenance gap immediately. Once conversations could be
+organized, users also needed to remove disposable or accidental conversation
+records without leaving the web console. The same Workspace surface also exposed
+a second gap: journeys still had to be created through Mirror skills or direct
+identity editing, even though the web console had become the place where
+conversation organization happens.
+
+Journey creation was the more delicate problem. A journey is not just a row in a
+database. It is an identity artifact that the Mirror uses for routing, memory,
+Builder context, and future continuity. A dry CRUD form would create valid rows
+that could still be weak journeys.
+
+## What Changed
+
+Workspace now includes a **New journey** action. The first slice asks for the
+raw material of a journey in natural language, then generates a structured
+markdown draft with title, status, stage, description, current focus, scope, and
+done condition. The user reviews and edits the draft before saving. Creation is
+bounded by slug validation, duplicate checks, minimum content checks, required
+status, and a required description section. Optional metadata such as project
+path, icon, and color can be set during creation.
+
+Conversation maintenance also became explicit. Conversation detail pages now
+include a confirmed **Delete conversation** action. The Unassigned conversations
+surface now supports selecting multiple conversations and deleting them as a
+batch, beside the existing assignment flow. Deletion removes messages and
+conversation embeddings, clears runtime-session and LLM-call references, and
+preserves extracted memories by nulling their source conversation id.
+
+The selected journey conversation list now uses a larger bounded read model so a
+journey with more than eight assigned conversations does not appear artificially
+short. This is still a protective limit for the browser payload, not a final
+pagination model.
+
+## Conscious Exclusions
+
+- Journey draft generation is deterministic in this release; it does not yet use an LLM to infer richer fields from the user's description.
+- Journey slug rename, journey deletion, and migration of conversations or memories between renamed slugs are not included.
+- The Workspace conversation list still uses a bounded payload rather than pagination or **Load more**.
+- Conversation deletion is direct web-console maintenance, not an asynchronous Operation with approval and backup.
+- Deleted conversations do not delete extracted memories, even when those memories originated from the deleted conversation.
+
+## What We Learned
+
+The web console is becoming the maintenance home for the personal Mirror. That
+changes the design standard: actions must be available where the user notices
+the problem, but identity-bearing artifacts still need review and shape before
+persistence. The right journey-creation form is not a replacement for the
+Mirror's inference. It is a structured drafting surface that keeps the user in
+control of the final identity prompt.
+
+## Next Horizon
+
+The visible next step is refinement, not expansion for its own sake: browser
+validation of the journey-creation flow, better disclosure when a bounded list
+has more items, and eventually a **Load more** or paginated conversation trail
+for mature journeys with long histories.

package/docs/releases/v0.19.1.md

@@ -0,0 +1,46 @@
+---
+digest: >
+  v0.19.1 is a validation patch for the web console conversation and journey
+  maintenance release. It preserves the v0.19.0 behavior and corrects CI
+  formatting drift in the touched Python files so the release line returns to a
+  green automated validation state. No product behavior changes are introduced
+  beyond the v0.19.0 scope.
+---
+
+# v0.19.1 — Web Console Maintenance CI Formatting
+
+**Date:** 2026-06-02
+
+## Highlights
+
+- Preserves the v0.19.0 web-console journey creation and conversation deletion behavior.
+- Applies repository formatting to the touched Python files.
+- Restores the release line to green CI after the v0.19.0 main push failed at `ruff format --check`.
+
+## Where We Started
+
+The v0.19.0 release was promoted and pushed with the intended product behavior,
+but GitHub Actions failed on the formatting gate. Local validation had run ruff
+linting, full tests, JavaScript syntax checks, and release-note checks, but did
+not include the repository-wide `ruff format --check src/ tests/` gate that CI
+runs.
+
+## What Changed
+
+This patch applies ruff formatting to the files reported by CI and bumps the
+release line to `v0.19.1`. It does not change the web-console product surface:
+journey creation, single conversation deletion, selected bulk deletion, memory
+preservation on delete, and broader selected-journey conversation visibility are
+unchanged from v0.19.0.
+
+## Conscious Exclusions
+
+- No additional journey-creation behavior is added.
+- No pagination or Load more behavior is added.
+- No destructive-action semantics are changed.
+
+## Next Horizon
+
+Keep `ruff format --check src/ tests/` in the local release validation sequence
+before future promotion so formatting patches do not need to follow immediately
+after feature releases.