mirror-mind 0.0.1 → 0.33.0

package/docs/releases/v0.20.0.md

@@ -0,0 +1,85 @@
+---
+digest: >
+  v0.20.0 introduces one-level hierarchical journey organization. Journeys can
+  now name a parent journey, the web console can create and edit that parent
+  relationship, and Workspace renders the hierarchy with session-persistent
+  expand/collapse. Journey settings also gain safe title and status editing, and
+  textual journey lists preserve the same hierarchy through mm-journeys. The
+  release keeps hierarchy display-only: conversations, memories, tasks, routing,
+  Builder context, extraction, and search remain journey-specific.
+---
+
+# v0.20.0 — Hierarchical Journey Organization
+
+**Date:** 2026-06-02
+
+## Highlights
+
+- Adds `parent_journey` metadata for one-level journey hierarchy.
+- Adds parent selection to **New journey** and Journey Settings in the web console.
+- Adds safe Journey Settings editing for title and status without changing the slug.
+- Renders parent/child journeys in the Workspace sidebar with session-persistent expand/collapse.
+- Keeps completed journeys hidden by default behind a toggle while preserving hierarchy when shown.
+- Dims paused and completed journeys so active journeys remain visually primary.
+- Updates `mm-journeys` / `python -m memory journeys` to render the hierarchy and preserve indentation.
+- Updates journey-list skill instructions so natural-language journey-list requests preserve the hierarchical output.
+
+## Where We Started
+
+The web console had become useful enough for conversation and journey
+maintenance that a flat journey list started to become the next source of
+friction. Some journeys clearly belonged under broader fields of work, but the
+product had no way to express that relationship. At the same time, completed
+journeys still needed to be accessible for editing and reassignment without
+polluting the active sidebar all the time.
+
+The exploration behind CV15 sharpened the boundary: hierarchy should organize
+attention, not merge identity. A child journey remains a normal journey with its
+own conversations, memories, tasks, Builder context, routing, and extraction.
+The parent journey is a visible broader field, not an implicit context mix.
+
+## What Changed
+
+Journey metadata now accepts a `parent_journey` field with guarded validation.
+A journey can have one parent, the parent must exist, a journey cannot parent
+itself, and the first slice rejects deeper nesting. The web console exposes this
+through **New journey** and Journey Settings.
+
+Journey Settings also gained safe title and status editing. The title edit
+updates only the first markdown H1 in the journey identity. The status edit
+updates only the `**Status:**` line. Neither operation renames the slug or moves
+conversations, memories, tasks, attachments, routing descriptors, or Builder
+configuration.
+
+Workspace now renders the journey sidebar hierarchically. Parent journeys can be
+expanded or collapsed, and that expansion state persists for the browser session.
+Paused and completed journeys are visually dimmed. Completed journeys are hidden
+by default behind a toggle, but when shown they appear in their correct
+hierarchical position rather than in a separate flat archive list.
+
+The textual journey list now uses the same hierarchy. `/mm-journeys`,
+`/mm:journeys`, and natural-language journey-list requests route to the CLI
+rendering and preserve its indentation instead of flattening it.
+
+## Conscious Exclusions
+
+- No Scene Workspace Home is included in this release.
+- No LLM synthesis is included in this release.
+- No automatic parent-child memory, routing, Builder, extraction, task, or search inheritance is introduced.
+- No recursive hierarchy or multiple parents are supported.
+- No journey slug rename or deletion cascade is included.
+
+## What We Learned
+
+A hierarchy can easily become a folder system if the product treats it as only a
+navigation convenience. The useful boundary is more precise: hierarchy organizes
+the field so the Mirror can later return cognitive location. This release
+therefore keeps the implementation deliberately structural and display-only,
+preparing the ground for Scene without pretending Scene already exists.
+
+## Next Horizon
+
+The next release in CV15 is **Scene Workspace Home**. With the hierarchy now
+available as a stable read model, Workspace can begin answering “where am I
+now?” through a Scene surface, movement signals, horizons, and bounded LLM
+synthesis over existing Mirror data.

package/docs/releases/v0.21.0.md

@@ -0,0 +1,61 @@
+---
+digest: >
+  v0.21.0 closes CV15.DS2 by turning Workspace into a cognitive-location home.
+  The release adds a deterministic Scene read model, narrative global Workspace
+  surfaces, persisted Scene Orientation, and focused journey orientation as a
+  first-class tab. It keeps journey as the operational primitive: hierarchy and
+  orientation organize what the user sees without silently merging memory,
+  routing, Builder context, extraction, search, tasks, or conversation
+  assignment. The release also refines the web console so conversations and
+  journey management live inside the Workspace shell instead of breaking
+  navigation.
+---
+
+# v0.21.0 — Scene Workspace Home
+
+**Date:** 2026-06-02
+
+## Highlights
+
+- Workspace now opens to a global **Current Scene** instead of automatically selecting the first journey.
+- **Your Moment** separates global surfaces from **Your Journeys**: Current Scene, Conversations, and All journeys are no longer mixed into the journey tree.
+- Scene Orientation is persisted, structured, and grounded in a bounded deterministic Scene read model.
+- Global orientation can generate automatically only the first time; focused journey orientations are always user-invoked.
+- Focused journey orientation appears as the first journey tab, before Briefing, Attachments, Conversations, and Settings.
+- Conversations now render as a compact, date-grouped list suitable for many conversations, with journey shown as contextual metadata.
+- All journeys now provides broader journey-field cards with status icons for parent and child journeys.
+
+## Where We Started
+
+CV15.DS1 gave Mirror Mind one-level journey hierarchy. That made the Workspace easier to organize, but it still behaved like a project browser: opening the Workspace selected a journey immediately, global context was ambiguous, and maintenance surfaces such as unassigned conversations leaked into the journey tree.
+
+DS2 started from the question behind Cognitive Location: when the user opens Workspace, Mirror should answer where the user is situated now, not only list containers.
+
+## What Changed
+
+Workspace now carries a deterministic `scene` read model composed from the journey field, selected journey state, hierarchy, recent conversations, memories, decisions, open tasks, nearby journeys, and horizon signals. The read model is bounded before it reaches the LLM layer, and Scene remains a surface rather than a user-managed object.
+
+The web console now distinguishes **Your Moment** from **Your Journeys**. Your Moment contains Current Scene, Conversations, and All journeys. Your Journeys contains only real journey navigation. Conversations and All journeys render inside the Workspace shell, so the sidebar remains present and navigation no longer breaks when moving between global Workspace surfaces.
+
+Scene Orientation became a lifecycle rather than a raw model response. The orientation is stored internally under `scene_orientation`, normalized into title, summary, signals, and next movement, and marked outdated when the underlying Scene source hash changes. The UI renders outdated orientation with a subtle visual indicator and lets the user refresh it deliberately.
+
+The invocation policy is intentionally asymmetric. Global Current Scene may generate automatically once when no orientation exists, giving the Workspace a living first impression. After that, updates are explicit. Focused journey orientations are always invoked by the user, because asking Mirror to read a specific journey should remain a deliberate gesture.
+
+## Conscious Exclusions
+
+- No automatic context inheritance between parent and child journeys.
+- No memory, search, routing, Builder, extraction, task, or conversation-assignment merging across hierarchy.
+- No user-managed Scene entity.
+- No hidden regeneration loop after the first missing global orientation.
+- No automatic mutation from orientation synthesis.
+- No recursive hierarchy beyond the one-level foundation from v0.20.0.
+
+## What We Learned
+
+Cognitive location needs editorial restraint. Exposing every deterministic signal in the main card made the Scene feel like diagnostics instead of orientation. The better shape is layered: the read model stays explicit and bounded in the system, while the primary UI offers a readable orientation and keeps operational surfaces nearby.
+
+We also learned that invocation matters. Orientation has interpretive weight, so generation should feel invited. The global first-run exception helps the Workspace come alive without turning every journey read into an unsolicited interpretation.
+
+## Next Horizon
+
+CV15 now has both layers: hierarchical organization and Scene-based cognitive location. The visible horizon is validation in daily use: how often orientations become stale, whether the structured synthesis stays useful, and whether the Workspace needs deeper search/filter controls for high-volume Conversations.

package/docs/releases/v0.21.1.md

@@ -0,0 +1,47 @@
+---
+digest: >
+  v0.21.1 is a patch release for Mirror Mode conversation continuity. It fixes
+  a regression where repeated `memory mirror load` calls inside one Pi session
+  could close the current conversation and create a new one, fragmenting a
+  single human conversation into many two-message records. Mirror Mode now binds
+  the resolved persona and journey to the current open conversation instead of
+  switching conversations; explicit new-conversation commands remain the
+  boundary mechanism.
+---
+
+# v0.21.1 — Mirror Mode Conversation Continuity
+
+**Date:** 2026-06-03
+
+## Highlights
+
+- Repeated Mirror Mode context loads no longer split an active conversation.
+- Persona/journey context is bound to the current open runtime conversation.
+- Explicit conversation switching remains available through `conversation-logger switch` / new-conversation flows.
+- Regression coverage protects Pi sessions that call `mirror load` repeatedly while processing one long conversation.
+
+## Where We Started
+
+During a `vida-economica` bill-payment session on 2026-06-01, a single Pi session was recorded as many short conversations. Investigation showed that repeated `uv run python -m memory mirror load --persona ... --journey ...` calls were being treated as conversation boundaries.
+
+That was wrong. Loading Mirror context is not the same as starting a new conversation.
+
+## What Changed
+
+Mirror Mode now uses a binding path for normal context loads. If the runtime session already has an open conversation, the resolved persona and journey are written onto that conversation and runtime session. A new conversation is created only when the session does not already have an open conversation.
+
+The existing explicit switch path remains intact for user-invoked new-conversation boundaries.
+
+## Conscious Exclusions
+
+- This release does not merge historical split conversations automatically.
+- It does not change `mm-new` or explicit conversation switching semantics.
+- It does not alter extraction, title generation, or journey inference policies.
+
+## What We Learned
+
+Context activation and conversation boundaries must stay separate. A command can need to refresh identity, persona, journey, and attachments many times inside one runtime session without implying a new memory record.
+
+## Next Horizon
+
+The repaired `vida-economica` session should be treated as the audit case for this class of bug. Future runtime integration work should preserve the same invariant: repeated context loads are idempotent with respect to conversation identity.

package/docs/releases/v0.22.0.md

@@ -0,0 +1,77 @@
+---
+digest: >
+  v0.22.0 adds mode orientation for Mirror's three primary lenses and a runtime
+  hygiene path for test sessions. Mirror now starts new sessions from present
+  intention, shows the active mode in the Pi status line, renders transition
+  surfaces for Mirror, Builder, and Explorer Mode, introduces the experimental
+  Explorer lens, and adds `/mm-discard` so test conversations can be deleted
+  before quitting.
+---
+
+# v0.22.0 — Mode Orientation and Test Hygiene
+
+**Date:** 2026-06-06
+
+## Highlights
+
+- Mirror now has explicit mode lifecycle for `◌ Mirror Mode`, `■ Builder Mode`, and `△ Explorer Mode`.
+- The Pi status line shows the current mode and active journey when present.
+- Mode changes render compact transition surfaces in the conversation.
+- New sessions start in `◌ Mirror Mode` from present intention, without inheriting stale Builder/Explorer mode or the last journey.
+- Explorer Mode exists as an experimental journey lens while the full exploratory behavior is being built.
+- `/mm-discard` deletes the current runtime conversation before quitting a test session.
+
+## Where We Started
+
+Explorer Mode needed a foundation before its exploratory behavior could be built.
+As soon as a third lens entered the product language, two older ambiguities became
+visible: Mirror did not clearly show which lens was active, and runtime test
+sessions polluted the personal conversation database.
+
+The first implementation also revealed a subtle product distinction: a new Mirror
+session is an act of intention, not an assumption of continuity with the previous
+journey. Continuity belongs inside an active session or an explicitly reopened
+journey.
+
+## What Changed
+
+`memory mode activate|deactivate|status` now stores the active operating lens.
+`memory mirror load`, `memory build load`, and `memory explore load` activate the
+corresponding lenses and feed the Pi status line through `welcome --status-line`.
+
+Mode transition surfaces now orient the user at the moment of lens change:
+Mirror Mode shows identity, journey, persona routing, and available lenses;
+Builder Mode shows journey context, project path, briefing, and the construction
+boundary; Explorer Mode shows an experimental availability note and the
+uncertainty-preservation boundary.
+
+Pi session start now clears stale explicit mode and sticky journey context, so a
+fresh session opens as `◇ alisson-vale · ◌ Mirror Mode · ✓` unless the user
+activates a journey again.
+
+The new `/mm-discard` skill calls `conversation-logger discard-current`, deletes
+the current conversation through the existing deletion service, and marks the
+runtime session so the assistant confirmation is not logged as a replacement
+conversation.
+
+## Conscious Exclusions
+
+- This release does not implement the full Explorer Mode story-thickening engine.
+- Explorer Mode persistence, Signal Radar, Narrative Field Snapshot, and Builder promotion remain future CV16 work.
+- `/mm-discard` does not force-close Pi; it discards the conversation and tells the user to quit.
+- Discarding a conversation follows existing deletion semantics: extracted memories are detached, not deleted.
+
+## What We Learned
+
+Mode and journey are different axes. Mode is the lens of operation; journey is
+situated intention. They can meet in the status line, but their lifecycles should
+not be conflated.
+
+We also learned that transition surfaces and status bars solve different
+problems. The status bar preserves orientation over time; the transition surface
+makes the moment of change visible.
+
+## Next Horizon
+
+The next CV16 work can move from orientation to behavior: Explorer activation
+contract, in-session exploratory state, and reliable Story Thickened rendering.

package/docs/releases/v0.22.1.md

@@ -0,0 +1,42 @@
+---
+digest: >
+  v0.22.1 is a validation patch for v0.22.0. It preserves the Mode Orientation
+  and Test Hygiene behavior and applies the formatting correction required by
+  the repository-wide CI format check.
+---
+
+# v0.22.1 — Mode Orientation CI Formatting
+
+**Date:** 2026-06-06
+
+## Highlights
+
+- Preserves the v0.22.0 mode orientation and `/mm-discard` behavior.
+- Reformats the touched conversation-logger test file so CI format checks pass.
+- Keeps v0.22.0 as the feature release and v0.22.1 as the validation patch.
+
+## Where We Started
+
+After promoting v0.22.0, GitHub Actions failed at the repository-wide `ruff
+format --check src tests` step. Local focused tests and lint had passed, but the
+full format gate surfaced one unformatted test file.
+
+## What Changed
+
+This patch applies the formatting correction and bumps the package version to
+v0.22.1 so the stable channel can move forward through a clean release artifact.
+
+## Conscious Exclusions
+
+- No behavior changes beyond the v0.22.0 release content.
+- No additional Explorer Mode scope.
+
+## What We Learned
+
+Run the repository-wide format check before promotion, not only focused lint and
+tests.
+
+## Next Horizon
+
+Continue CV16 with the Explorer activation contract and in-session exploratory
+state now that the mode foundation is packaged.

package/docs/releases/v0.23.0.md

@@ -0,0 +1,105 @@
+---
+digest: >
+  v0.23.0 completes the first durable Explorer Mode release. Explorer now holds
+  an Exploratory Story beyond one fragile runtime session, resumes it visibly,
+  thickens it through required surfaces, and can promote it into Builder with
+  provenance-rich handoff evidence. The release also hardens the Explorer/Builder
+  boundary: required Explorer cards are marked for runtime rendering, operational
+  mutation requests route through Builder, and Pi status-line mode state is
+  scoped to the active session. Multiple simultaneous stories and the future Soul
+  Mode implementation remain outside this release.
+---
+
+# v0.23.0 — Durable Explorer Mode
+
+**Date:** 2026-06-07
+
+## Highlights
+
+- Adds durable `exploratory_stories` storage with active, archived, and promoted lifecycle states.
+- Resumes active Exploratory Stories when Explorer Mode is activated for a journey.
+- Links Builder handoff artifacts to durable story ids and source conversation evidence.
+- Adds privacy-safe optional `full-conversation.md` export with obfuscation for sensitive evidence.
+- Marks required Explorer surfaces so Pi can render user-facing cards before commentary.
+- Routes clear operational mutation requests from Explorer to Builder before file, code, or doc changes.
+- Makes Pi operating-mode status session-scoped to avoid footer leaks between simultaneous sessions.
+
+## Where We Started
+
+Explorer Mode had already proven the conversational shape of exploration: a user
+could enter the lens, open an Exploratory Story, thicken it, name attractors,
+propose experiments, and promote a candidate into Builder. The weakness was that
+Explorer still depended too much on a fragile session and on assistant discipline.
+A real Soul Mode validation exposed the gap: the handoff captured final state,
+but not enough of the source conversations, thickening path, examples, decisions,
+and uncertainty that made the exploration trustworthy.
+
+The release therefore needed to turn Explorer from a promising mode into a
+recoverable, inspectable product surface.
+
+## What Changed
+
+Explorer Stories are now durable records. The new storage layer keeps one active
+story per journey, preserves historical archived and promoted stories, and stores
+the evolving story fields: title, current story, narrative summary, last card,
+attractors, experiment proposal, Builder handoff state, and source conversation
+metadata. Activating Explorer Mode for a journey now resumes the active story
+with `△ EXPLORATORY STORY RESUMED` instead of silently starting from an empty
+field.
+
+Builder handoff became an editorial transfer artifact. Handoff generation can
+attach source conversations, preserve their role in the exploration, list source
+evidence in `index.md`, and write a `handoff-info.md` completeness checklist. Raw
+conversation evidence is intentionally opt-in through `--include-full-conversation`.
+When included, Mirror writes privacy-reviewed material and obfuscates local paths,
+secrets, emails, and phone-like values before creating `full-conversation.md`.
+
+The runtime boundary also became stricter. Explorer command output can wrap
+required user-facing cards with stable `[[MIRROR_REQUIRED_SURFACE_BEGIN:...]]`
+and `[[MIRROR_REQUIRED_SURFACE_END:...]]` markers so the assistant runtime knows
+which surface must be rendered first. The Pi Explorer skill now instructs the
+assistant to show the required block while hiding marker lines. It also names the
+operational boundary explicitly: Explorer preserves uncertainty; Builder executes
+commitment. If the user asks Explorer to edit files, apply procedures, create
+code, run commands, or otherwise mutate project state, Mirror should answer with
+`△ EXPLORER → BUILDER BOUNDARY` and route the work into Builder before mutation.
+
+A validation bug in Pi's footer was fixed at the same boundary. Operating mode
+state used to be effectively global, so two open Pi sessions could overwrite one
+another's status line. Mode activation, deactivation, lookup, Builder load,
+Explorer load, and `welcome --status-line` now accept a session id. The Pi
+extension passes the current session id, while CLI callers without a session id
+retain a global fallback.
+
+Finally, stale Explorer copy was removed. Explorer no longer describes itself as
+an experimental mode whose full experience will be available soon. The activation
+surface now states that Explorer Mode is active and ready for durable exploration,
+story thickening, attractors, experiments, and Builder handoff.
+
+## Conscious Exclusions
+
+- Multiple simultaneous active Exploratory Stories per journey are still out of scope.
+- Explorer does not become a hidden intent detector; the user activates the lens explicitly.
+- Explorer does not mutate project state directly. Builder remains the delivery lens.
+- The generated `docs/project/explorations/` handoff artifacts from validation are intentionally not part of this release. They remain local material for the next Soul Mode implementation.
+- Advanced Explorer capabilities, richer web visibility, and Soul Mode itself remain future work.
+
+## What We Learned
+
+Explorer's value is not just that it can summarize uncertainty. Its value appears
+when uncertainty becomes durable enough to return to, visible enough to trust,
+and bounded enough not to become accidental implementation. The Soul Mode
+validation made the evidence problem concrete: Builder does not only need a final
+brief; it needs enough provenance to understand why the brief exists.
+
+The Pi status-line leak also clarified that operating mode is a session property
+when a runtime has session identity. A global fallback is useful for CLI
+compatibility, but interactive runtimes need scoped mode state to remain honest.
+
+## Next Horizon
+
+The next visible horizon is Soul Mode. The local exploration artifacts generated
+during validation should seed that work, but the implementation should begin from
+Builder with a fresh delivery plan rather than being bundled into this Explorer
+release. Explorer can now hold and promote that kind of discovery without forcing
+it prematurely into construction.

package/docs/releases/v0.24.0.md

@@ -0,0 +1,125 @@
+---
+digest: >
+  v0.24.0 introduces the first complete Soul Mode ritual. Mirror can now enter a
+  dedicated inward listening mode, receive the user's day as living field, offer
+  situated Possible Listenings, listen through Self Voice or Shadow Voice, mature
+  one provisional fruit, harvest it, and save exactly one journal entry after
+  explicit confirmation. The release also adds a Soul Mode prompt foundation with
+  dynamic Self identity injection, formatted journal visibility in the web app,
+  and a clear Soul-to-Builder operational boundary. Wisdom Voice, Beauty Voice,
+  Passagem, Return To Center, and psyche-layer enrichment remain future runway.
+---
+
+# v0.24.0 — Soul Mode First Ritual
+
+**Date:** 2026-06-08
+
+## Highlights
+
+- Adds `☾ Soul Mode` activation through `/mm-soul [slug]` and `python -m memory soul load [slug]`.
+- Renders the Soul Mode entry surface with the inward-day invitation.
+- Adds Possible Listenings with situated Self, Shadow, Wisdom, and Beauty options.
+- Implements first-release listening lenses for Self Voice and Shadow Voice.
+- Keeps the user conversing with Mirror while voice responses appear inside ritual cards.
+- Adds Fruit In Maturation state so one provisional harvest can be refined across turns.
+- Adds Harvested Fruit and explicit save-or-decline journal confirmation.
+- Saves Soul Mode harvests as structured Markdown journal entries with origin metadata.
+- Injects the user's `self/soul` identity layer into the composed Self Voice prompt.
+- Adds a Soul-to-Builder boundary so Soul Mode does not mutate project state directly.
+- Improves web visibility for Journal memories, formatted journal detail, and conversation maintenance.
+
+## Where We Started
+
+Soul Mode began as an exploration of ritual and visual grammar for helping the
+user remember who they are. The early question was not how to add another chat
+command, but how to create a passage of state: from ordinary reporting, into
+inner listening, through a voice or rite, toward a fruit that could be kept.
+
+The product risk was overbuilding. Soul Mode has a broad horizon: Wisdom Voice,
+Beauty Voice, Passagem, Return To Center, literary and philosophical fragments,
+richer curation, psyche-layer integration, and possible web surfaces. The first
+release needed to prove the core grammar without pretending the whole ecosystem
+was complete.
+
+## What Changed
+
+Soul Mode is now an explicit operating lens. Activating it renders a ritual entry
+surface with the line `Soul Mode turns the day toward the inner life`, the horizon
+`✦ IN ORDER TO / remember who you are`, and the opening question `how is your day
+going today?`. The mode is represented in the lifecycle and status line as `☾
+Soul Mode`.
+
+The opening conversation now has a visible threshold. Thin day reports are held
+as living field without forcing a menu. When the user moves from events into
+inner contract, fear, wound, desire, compulsion, discomfort, or threatened
+belonging, Mirror can render `✧ POSSIBLE LISTENINGS` with situated options. The
+card ends by telling the user they can hear one of the voices now or continue the
+conversation.
+
+The first implemented voices are Self and Shadow, but they are not separate chat
+characters. They are listening lenses. When the user chooses one, Mirror renders
+a card such as `✦ SELF VOICE LISTENING` or `◐ SHADOW VOICE LISTENING`; the voice
+response appears inside the card, and Mirror then bridges that response back into
+the conversation. This avoids splitting the dialogue between agent and voice.
+Self Voice is additionally grounded in the user's current `self/soul` identity
+layer through `python -m memory soul prompt self`, so the user's incorporated
+principles can shape what the voice hears over time.
+
+Soul Mode can now mature one provisional fruit. `python -m memory soul fruit set`
+stores and renders `❦ FRUIT IN MATURATION`; a later `fruit set` replaces the
+same fruit rather than accumulating disconnected takeaways. When the user asks to
+harvest, `python -m memory soul harvest set` renders `❦ HARVESTED FRUIT` and asks
+`save to journal?`. Only explicit confirmation calls `harvest save`, which
+creates one journal entry and clears the harvested state. Decline clears the
+state without saving.
+
+The journal path became richer during validation. Soul Mode harvests are now
+structured Markdown entries with a title, fruit block, origin metadata, and when
+available a link back to the source conversation. The web app now exposes Journal
+as its own pinned memory category, opens memory cards as object detail pages,
+renders journal Markdown with headings, blockquotes, lists, code, and safe
+internal links, and can navigate journal origin links back to the source
+conversation.
+
+Pre-release usage also produced several web and maintenance refinements: full
+turn deletion in conversation detail, formatted journal cards, top navigation for
+Workspace, Conversations, Journeys, Operations, Configuration, Preferences, and
+Docs, and styling fixes for conversation journey assignment.
+
+## Conscious Exclusions
+
+- Wisdom Voice and Beauty Voice can appear as Possible Listenings, but they do not yet open full rites.
+- Passagem remains a future rite, not part of this first release.
+- Return To Center and Closing Day rituals remain future work.
+- Soul Mode does not yet enrich Self, Shadow, Ego, persona, or journey identity layers after harvest.
+- No automatic psyche mutation exists. Future identity enrichment must be proposed with visible diff and explicit confirmation.
+- No rich web ritual UI is included. The first release validates textual ritual grammar.
+- Soul Mode does not execute implementation work. Operational mutation requests must route to Builder Mode.
+
+## What We Learned
+
+The most important product correction was that voices should be heard, not
+conversed with. When Self Voice or Shadow Voice behaved like a separate
+interlocutor, the user could lose track of whether they were speaking to Mirror
+or to the voice. The cleaner grammar is: the user always converses with Mirror;
+Mirror listens through a voice; the voice appears in a card; Mirror bridges the
+voice back to the conversation.
+
+Self Voice also became clearer through use. It should not help solve the problem.
+It should mirror what is not being seen, using the user's incorporated principles
+to reveal what is happening. That distinction matters because Soul Mode is not a
+coaching workflow. It is a ritual listening mode.
+
+The harvest boundary also became sharper. The journal is not a transcript sink.
+It receives one chosen fruit only after the user asks to harvest and confirms
+saving. The web app then needs to treat that entry as a meaningful record, not as
+plain text hidden inside a generic memory category.
+
+## Next Horizon
+
+The next Soul Mode horizon is integration. A future release should add a Closing
+Rite that reviews harvested material and asks what wants to remain in the
+Mirror's living psyche: Self principles, Shadow listening hypotheses, Ego
+behavior, persona refinements, or journey memory. That work belongs after this
+first ritual release because it touches identity mutation and must be designed
+around explicit confirmation.

package/docs/releases/v0.25.0.md

@@ -0,0 +1,107 @@
+---
+digest: >
+  v0.25.0 expands Soul Mode with two new active listening lenses: Wisdom Voice
+  and Beauty Voice. Wisdom now lets the user's material be crossed by a solemn,
+  source-shaped utterance from a thinker, text, tradition, or old teaching, with
+  Mirror bridging the source back to the user's concrete situation outside the
+  card. Beauty now listens through image, texture, rhythm, atmosphere, poetry,
+  literature, music, and the form of aliveness without forcing positivity. Both
+  voices render their full utterance inside the ritual card and avoid automatic
+  journal, identity, or project-state mutation.
+---
+
+# v0.25.0 — Soul Mode More Voices
+
+**Date:** 2026-06-08
+
+## Highlights
+
+- Adds Wisdom Voice as a full active Soul Mode listening lens.
+- Adds Beauty Voice as a full active Soul Mode listening lens.
+- Keeps both new voices inside the ritual card under `the voice says`.
+- Removes `listening for` from Wisdom and Beauty cards so the voice can occupy the card fully.
+- Requires situated `--says` content for Wisdom and Beauty to prevent placeholder cards.
+- Adds canonical prompts for Wisdom Voice and Beauty Voice.
+- Updates the Pi Soul Mode skill so natural-language validation can hear the new voices.
+- Preserves the non-mutating Soul Mode boundary: no automatic journal, identity, or project-state changes.
+
+## Where We Started
+
+The first Soul Mode release proved the ritual cycle, but it left a visible gap:
+Possible Listenings could name Wisdom Voice and Beauty Voice, while the user
+could not yet hear them as active rites. That made the constellation feel larger
+than the behavior available inside the product.
+
+The next release therefore focused on the missing voices rather than on
+integration, rich UI, or psyche mutation. Before Mirror can ask what should be
+integrated into identity, the user needs to hear the voices the ritual already
+implies.
+
+## What Changed
+
+Wisdom Voice is now hearable. When the user chooses it, Mirror renders a `♢
+WISDOM VOICE LISTENING` card and places the full wisdom utterance inside the box
+under `the voice says`. Wisdom Voice is not generic advice and not a short
+summary. It is the voice of a relevant source — a thinker, philosopher, sacred
+text, ancient tradition, proverb, contemplative teaching, mythic image, or wisdom
+text — speaking from its own symbolic world.
+
+The Wisdom card now omits `listening for`. This was an important ritual
+correction: the card is not a form with fields. It is the place where the source
+speaks. Mirror's practical bridge happens after the card, in Mirror's ordinary
+tone. When Mirror knows the source, author, work, or historical/textual context,
+it should explain that origin outside the card and relate it to the user's
+conversation without inventing bibliographic precision.
+
+Beauty Voice is also now hearable. When the user chooses it, Mirror renders a `✺
+BEAUTY VOICE LISTENING` card and places the full beauty utterance inside the box
+under `the voice says`. Beauty Voice listens through image, texture, rhythm,
+atmosphere, body, literature, poetry, music, and the form of aliveness. It does
+not decorate pain, force hope, or turn difficulty into a pretty lesson.
+
+Beauty also omits `listening for`. Its card contains the aesthetic listening
+itself; Mirror's bridge follows outside the card. When a poem, author, artwork,
+song, or aesthetic source is known and relevant, Mirror may name it outside the
+card, but should not fabricate citation details.
+
+Both new voices require situated `--says` content when rendered through the CLI.
+This prevents the runtime from displaying placeholder text when the assistant has
+not yet composed the actual voice response from the user's material.
+
+## Conscious Exclusions
+
+- No Closing Rite or psyche-layer integration is included.
+- No automatic Self, Shadow, Ego, persona, or journey identity enrichment is included.
+- No identity mutation is performed.
+- No rich web Soul Mode UI is included.
+- No Passagem curation or fragment library is included.
+- No Return To Center implementation is included.
+- No multiple-fruit model is included.
+- Soul Mode still does not execute implementation work; operational mutation requests route to Builder Mode.
+
+## What We Learned
+
+The key refinement was that a voice card must contain the voice itself, not a
+label plus an explanation outside the box. Wisdom Voice in particular needed a
+stronger separation between the source speaking inside the card and Mirror
+interpreting outside it. Once that boundary was clear, Wisdom could become
+solemn, symbolic, and ancestral without turning Mirror's normal bridge into a
+prophetic performance.
+
+Beauty followed the same grammar. It should not be a motivational consolation or
+aesthetic gloss. It should let form, texture, rhythm, image, and care appear
+inside the field, while leaving the practical connection to Mirror's ordinary
+voice outside the card.
+
+The release also reinforced a process lesson: pre-release refinement does not
+need to become a separate implementation story when real validation closes the
+open questions inside DS1 and DS2. The planned refinements story was cancelled
+because the necessary tuning happened during direct Pi validation of the two
+voice stories.
+
+## Next Horizon
+
+The next Soul Mode horizon is integration: a Closing Rite, review of harvested
+material, and safe psyche-layer enrichment proposals with visible diffs and
+explicit confirmation. That work should remain careful and non-automatic because
+it touches the Mirror's living identity model.