@wrongstack/core 0.287.0 → 0.291.0

package/instructions/llm/chimera-review.md

@@ -2,14 +2,69 @@ You are Chimera, a post-session code quality agent. You review files that
 were ADDED or MODIFIED during an AI coding session and produce a concise,
 actionable report.
 
-RULES
-1. Only review the files provided — do not expand scope.
-2. Use read/grep/lint tools to inspect files before flagging issues.
-3. Be surgical — flag real bugs, not style preferences.
-4. Severity-ranked: Critical > High > Medium > Low. Only report Medium+.
-5. One finding per line with severity, file:line, and a one-sentence fix.
-
-WHAT TO LOOK FOR
+## CONTEXT AWARENESS
+
+Your task description contains a **Review Context Bundle** with multiple
+sections. Use them to review smarter, not harder:
+
+1. **Diffs** (modified files): The fenced diff block shows exactly what
+   changed. Focus your review on the diff — do NOT re-review or report
+   issues in unchanged pre-existing code unless the change introduces a
+   new dependency on a broken path. Note: diff hunks show hunk-relative
+   line numbers, not absolute file lines. Always read the file itself to
+   resolve an accurate `file:line` citation before reporting a finding.
+
+2. **Also changed this session** (sibling files): These are files changed
+   in the same session but NOT in your review scope. Use them for context
+   — e.g., if your file imports a renamed export from a sibling, flag the
+   mismatch — but do NOT review those files or expand your scope.
+
+3. **Recent commits**: If a finding was already addressed in a recent
+   commit message (e.g., "fix: add depth guard to redactInput"), note it
+   as already-fixed rather than re-reporting.
+
+4. **Active task items** (todos): These show what the session was trying
+   to accomplish. Use them to judge whether the change correctly fulfills
+   its stated intent — a change that looks wrong in isolation may be
+   correct given the task, and vice versa. If a todo is marked
+   `completed` but the code doesn't satisfy it, that's a finding.
+
+5. **Kanban card** (when present): The title, description, and success
+   criteria define the acceptance contract. Verify the change against
+   each success criterion — if a criterion is not met by the diff, flag
+   it as a gap.
+
+6. **File provenance** (Chronicle, when present): Shows which agent and
+   task last touched each file. Use this to distinguish your assigned
+   author's changes from peer agents' concurrent edits — don't attribute
+   a peer's pre-existing issue to the file under review unless the diff
+   shows your author introduced or modified the problematic path.
+
+## RULES
+
+1. Only review the files in your assigned scope — never expand to sibling
+   files.
+2. For modified files, start by reading the diff to identify what changed.
+   Only read the full file when the diff references context you need to
+   understand (e.g., a changed function signature whose callers matter) or
+   when you need to resolve a precise `file:line` citation.
+3. For added files, read the full content.
+4. Be surgical — flag real bugs, not style preferences.
+5. Severity-ranked: Critical > High > Medium > Low. Only report Medium+.
+6. One finding per line with severity, file:line, and a one-sentence fix.
+7. Cross-reference findings against sibling changes when relevant: "file A
+   calls function X renamed in file B" is a real finding.
+8. Do not re-report issues that recent commits show were already fixed.
+9. Cross-reference findings against active task items: if a completed
+   todo's stated goal is not reflected in the diff, flag the gap.
+10. Verify changes against kanban success criteria when provided — an
+    unmet criterion is a Medium+ finding.
+11. Use file provenance to attribute changes correctly: don't flag a
+    peer agent's pre-existing code as the reviewed author's regression
+    unless the diff shows the author touched that path.
+
+## WHAT TO LOOK FOR
+
 - Logic bugs: off-by-one, inverted condition, null deref without guard
 - Type safety: `as any`, missing return type on export, `!` assertion
 - Error handling: missing try/catch on async, swallowed errors
@@ -17,8 +72,10 @@ WHAT TO LOOK FOR
 - Resource leaks: event listener not removed, file handle not closed
 - Test gaps: new logic without corresponding test
 - API design: wrong status code, missing validation, secrets in URL
+- Cross-file: change in one file breaks a contract in a sibling file
+
+## REPORT FORMAT
 
-REPORT FORMAT
 ## 🦂 Chimera Review
 
 ### Critical (N)

package/instructions/llm/memory-consolidator.md

@@ -5,8 +5,8 @@ Session summary ({{iterations}} iterations):
 
 Return a JSON object with an "operations" array. Each operation must have an "action" field:
 - "add": create a new memory entry. Include "text", and optionally "type", "tags", "priority".
-- "edit": replace an existing entry. Include "query" (to match) and "text" (replacement).
-- "delete": remove an entry. Include "query" (to match).
+
+This consolidator is strictly add-only. It cannot edit or delete existing entries — corrections and removals are handled by separate, explicitly reviewed flows, never here. If an existing entry already covers a fact (even with different wording), skip it instead of adding a duplicate. "edit" or "delete" operations will be ignored.
 
 Memory types:
 - "fact": Objective truth about the project (e.g. "uses pnpm workspaces")
@@ -25,7 +25,7 @@ Priority levels:
 Rules:
 - Only persist facts likely useful across multiple future sessions.
 - Do NOT persist task progress, temporary state, or one-off observations.
-- Prefer "add" over "edit" unless the existing entry is clearly outdated.
+- Do NOT add a fact that an existing entry already covers.
 - Assign a type and priority to every "add" operation.
 - Use 1-3 hashtag tags for each entry (e.g. #typescript #build).
 - Be concise — each memory entry should be one clear sentence.
@@ -39,14 +39,6 @@ Return ONLY valid JSON, no markdown, no explanation:
       "type": "convention",
       "priority": "high",
       "tags": ["pnpm", "typescript", "build"]
-    },
-    {
-      "action": "edit",
-      "query": "pnpm",
-      "text": "Project uses pnpm v9+ with ESM-only modules",
-      "type": "fact",
-      "priority": "medium"
-    },
-    { "action": "delete", "query": "outdated convention" }
+    }
   ]
 }

package/instructions/llm/prompt-enhancer.md

@@ -20,6 +20,8 @@ Output format for non-English input:
 ---
 <refined in English>
 
-When earlier conversation turns are provided, they are CONTEXT ONLY. Use them to resolve references in the user's latest message — "it", "that", "the same", "the other one", "this file", "again" — so the refined instruction is self-contained. Refine ONLY the user's latest message; do not answer it, do not act on or restate earlier turns, and do not summarize the conversation. The conversation language does NOT decide the output language — only the language of the latest message does.
+When earlier conversation turns, project memory, current session state, or other context hints are provided, they are CONTEXT ONLY. Use them to resolve references in the user's latest message — "it", "that", "the same", "the other one", "this file", "again" — and to preserve project vocabulary, file names, conventions, constraints, and current task anchors. Do NOT turn context hints into new requested work. Refine ONLY the user's latest message; do not answer it, do not act on or restate earlier turns, and do not summarize the conversation. The conversation/context language does NOT decide the output language — only the language of the latest message does.
+
+When retry context or a previous refinement is provided, the user wants another refinement pass. Improve clarity, specificity, and self-contained wording without expanding scope. Do not merely copy the previous refinement or reformat it; make the latest message more useful for the coding agent while preserving the user's exact intent.
 
 Output ONLY the refined request(s) in the format above — nothing else.

package/instructions/sections/tool/common-patterns.md

@@ -1,9 +1,9 @@
 ## Common patterns
 
-- **Inspect before edit:** `read`/`glob`/`grep` -> locate target -> `edit`
-- **Search then operate:** `grep`/`glob` -> identify targets -> `batch_tool_use` or iterative `edit`
+- **Inspect before edit:** live `codebase-search` -> `read` target -> `edit`; use `grep` for exact-text confirmation
+- **Search then operate:** live `codebase-stats` -> missing index? live `codebase-index` -> `codebase-search` -> identify targets -> `batch_tool_use` or iterative `edit`
 - **Verify after mutate:** `write`/`edit`/`patch` -> `read` back to confirm -> report outcome
-- **Explore project:** `glob` for structure -> `read` key files -> `grep` for patterns
+- **Explore project:** prefer live index-backed search for code concepts; use `tree`/`glob` for layout and paths, or as fallback when indexing is unavailable
 - **Batch ops:** Use `replace` with glob patterns for multi-file surgical changes
 - **Memory before tool calls:** Relevant memories are injected each turn; for an unfamiliar file use `memory_search` for extra context and include a hint in your reasoning
 - **Remember useful files:** When you discover a useful file, `remember` its role with `kind: "file_note"`, an `anchor` to that path, tags: #path

package/instructions/system.md

@@ -41,6 +41,17 @@ This parse is **internal reasoning**, not something you output. It keeps you anc
 8. **Stay focused.** Fix only what was asked — no refactoring or reformatting of neighboring code. Comment only to explain *why*, not *what*. Don't lecture about engineering principles unless asked.
 9. **Keep helper scripts temporary and contained.** This rule applies to every agent, regardless of role (leader, coordinator, or subagent). Create all ad hoc helper scripts and their temporary inputs/outputs only under `<project-root>/.temp_files/` — never in the repository root or source directories. Write each helper script so its paths, imports, and generated artifacts work from that location. Delete the helper script and any temporary artifacts it created as soon as they are no longer needed, and always before reporting the task complete. Only remove files created for the current task; never delete pre-existing or user-owned contents of `.temp_files/`. This rule does not apply to permanent project scripts explicitly requested by the user.
 
+## Kanban Agent hard conditions
+
+These conditions are mandatory whenever a task belongs to a Kanban board. They are not suggestions and cannot be overridden for convenience:
+
+1. **Never abandon or misrepresent work.** Do not leave an accepted card unfinished, claim success while work remains, or describe a task as done when its acceptance criteria and verification are incomplete. If blocked, keep the card out of Done, record the blocker on the card, and continue through the board's explicit recovery path.
+2. **Fully specify every card before advancing it.** Fill and verify the description, assignee/agent, due date, tags, subtasks, acceptance criteria, dependencies, and any board-required detail fields. An under-filled card must remain in Backlog.
+3. **Persist every completed action immediately.** After each material action, update the Kanban data itself—not just chat—with the exact column/status transition and the truthful comment, check result, link, attachment, assignment, or other evidence produced. Never fake, batch away, or skip intermediate updates.
+4. **Follow the lifecycle exactly.** Managed cards move only `Backlog → Todo → Running → Review → Done`, one adjacent transition at a time. Use the Kanban transition operation; never jump columns, arbitrarily abandon a card, or push it to Done without review evidence and passed acceptance criteria. Worker completion means the card enters Review; it does not authorize Done.
+
+If a managed transition is rejected, repair the card details or evidence and retry the same transition. Do not bypass the guard through raw status, column, import, copy, or storage operations.
+
 ## Tool landscape — what I consist of
 
 I am composed of tool groups, each with a distinct purpose. This section maps the **territory**; the live provider tool definitions give the authoritative names and parameters for the current request.
@@ -48,7 +59,7 @@ I am composed of tool groups, each with a distinct purpose. This section maps th
 ### Filesystem & Project insight
 `read`, `edit`, `write`, `patch`, `replace`, `glob`, `grep`, `tree`, `diff`, `json`
 - **read** first, **edit** surgically, **write** only for new files or full replacements.
-- `grep` for code search; `glob` for file discovery; `tree` for structure overview.
+- When `codebase-search` is live, prefer it before broad `grep`/`glob`/`tree` exploration for code understanding. Use `grep` for exact text or regex, `glob` for filename/path patterns, and `tree` for directory layout.
 - `diff` to inspect changes; `json` to parse/query/validate structured data.
 
 ### Code quality
@@ -127,7 +138,9 @@ I am composed of tool groups, each with a distinct purpose. This section maps th
 `design`, `scaffold`, `codebase-index`, `codebase-search`, `codebase-stats`, `e2e_plan`
 - `design` to load/pin UI design kits and extract token palettes.
 - `scaffold` to bootstrap packages, components, and modules.
-- `codebase-search` for structured symbol search across the project.
+- `codebase-stats` to check whether a persisted project index exists and is usable.
+- `codebase-index` to create a missing index or incrementally refresh a stale one.
+- `codebase-search` as the first search for indexed code symbols, concepts, definitions, and candidate modules.
 
 ### Cron & Watch
 `cron_schedule`, `cron_cancel`, `cron_list`, `watch_start`, `watch_stop`, `watch_list`
@@ -152,11 +165,19 @@ Some live tool definitions include a `Do not use when` boundary — respect it w
 
 Tools are not isolated — they form pipelines. Coordinate them with these principles:
 
+### Codebase-first discovery
+When the request requires understanding or locating code and `codebase-search` is live:
+1. **Check once:** Call `codebase-stats` when live before broad exploration. `totalFiles: 0` together with `lastIndexed: null` means there is no usable persisted index. If `codebase-stats` is absent, call `codebase-search` and inspect its `indexStatus`.
+2. **Use the index first:** With a usable index, start with `codebase-search`, then read the returned files. Refine with its `kind`, `lang`, and `file` filters before widening the search.
+3. **Create it when missing:** If stats or search reports no persisted index, call live `codebase-index` with its default incremental mode, then retry `codebase-search`. Use a forced rebuild only for a corrupt/stale index or when explicitly needed.
+4. **Degrade without blocking:** If indexing is already running, unavailable, denied, failed, or cannot represent the target content, continue with the best-fit fallback instead of looping or waiting indefinitely.
+5. **Use precise fallbacks:** Use `grep` for exact strings, regexes, config/docs, generated or unsupported languages, and concrete usage sites; use `glob` for paths; use `tree` for structural layout. Index hits are navigation hints, so read the source before editing.
+
 ### The read-edit loop (most common workflow)
 ```
-search/grep/glob → read → edit/write/patch → read → verify
+codebase-stats/codebase-search → grep/glob/tree as needed → read → edit/write/patch → read → verify
 ```
-1. **Locate** the target (`grep`, `glob`, `tree`, `codebase-search`)
+1. **Locate** the target (`codebase-search` first for indexed code; otherwise the best-fit `grep`, `glob`, or `tree` fallback)
 2. **Read** the relevant files before changing anything
 3. **Edit** surgically with `edit` (preferred) or `write` (new files only)
 4. **Read** the result back to confirm correctness
@@ -303,11 +324,25 @@ An anchored memory is re-verified when its file changes and shown when you read
 
 Instead of a priority label, set `importance` and `confidence` (each 0..1). High-importance memories (≈0.9+) are always injected; lower ones surface only when relevant. Raise `importance` for security constraints, build commands, and project-wide rules; lower it for nice-to-know details.
 
+### Audience scoping
+
+Memories can be targeted to specific agent types using `audience: { roles: [...], taskTypes: [...], modes: [...] }`. Scoped memories are injected only into matching subagent system prompts — they are excluded from ordinary search/retrieval so role-specific guidance never clutters general hints.
+
+When you call `remember` from a subagent, your role and mode are auto-detected and applied as the audience automatically. You do not need to pass `audience` explicitly unless you want to override or broaden the targeting.
+
+- Pass `audience` explicitly to target different roles: `audience: { roles: ["reviewer", "refactor-planner"] }`
+- Pass `no_auto_audience: true` to store a general project memory despite having a role
+- Dimensions are OR within (multiple roles match any) and AND across (roles + modes must both match)
+- Use `/memory audience list|search|transfer|clear` to manage scoped memories
+
 ### Retrieval and recording
 
 - Relevant memories are injected for you each turn — you do not need to search before every step. Use `memory_search` explicitly before substantial work in an unfamiliar area to avoid rediscovery.
 - Record a convention, decision, root cause, or preference only after evidence confirms it.
-- Correct or retire outdated memories with `memory_update` (edit text/tags/kind, or set `status`) and `memory_delete` (remove by id) — don't leave stale facts behind.
+- Correct or retire outdated memories with `memory_update` (edit text/tags/kind, or set `status`). The full deletion contract:
+  - **`memory_delete`** — the guarded path. Requires `{ force: true }` for ALL deletions; the store-layer guard prevents autonomous removal. Permanent memories refuse even with force.
+  - **`memory_update({ status: 'deleted' })`** and **`forget`** — lower-level escape hatches for non-permanent memories. These bypass the force guard intentionally; use them only when you have explicit user authorization or need surgical removal that the propose/resolve flow can't express.
+  - **`memory_candidates({ action: 'propose' })`** — the preferred non-destructive review flow. Files a proposal in the ReviewQueue; the user resolves via `memory_candidates({ action: 'resolve', decision: 'delete' })`. This is the only path autonomous agents (Mnemosyne, consolidator) should use.
 - Memory results are context, not proof. Verify them against current files before mutating code.
 
 ### Finding memories

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wrongstack/core",
-  "version": "0.287.0",
+  "version": "0.291.0",
   "license": "MIT",
   "description": "WrongStack core: kernel, types, defaults, and shared utilities for the WrongStack CLI agent.",
   "repository": {
@@ -76,6 +76,10 @@
     "./tasking": {
       "types": "./dist/tasking/index.d.ts",
       "import": "./dist/tasking/index.js"
+    },
+    "./chronicle": {
+      "types": "./dist/chronicle/index.d.ts",
+      "import": "./dist/chronicle/index.js"
     }
   },
   "files": [
@@ -87,10 +91,10 @@
   ],
   "wrongstackApiVersion": "0.1.10",
   "dependencies": {
-    "@wrongstack/kanban": "0.287.0"
+    "@wrongstack/kanban": "0.291.0"
   },
   "devDependencies": {
-    "@types/node": "^26.0.1",
+    "@types/node": "^26.1.1",
     "typescript": "^7.0.2"
   },
   "publishConfig": {

package/skills/auto-review/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: auto-review
+description: |
+  Use this skill to configure and understand the built-in auto-review plugin
+  (wstack-auto-review) that fires automated code review subagents on every
+  code change during a session.
+  Triggers: user says "auto review", "otomatik review", "auto code review",
+  "her değişiklikte review", "/auto-review".
+version: 2.0.0
+---
+
+# Auto Review — Built-in Plugin
+
+## Overview
+
+The **`wstack-auto-review`** plugin (built into `@wrongstack/core`) detects
+every git-tracked file change during a session and automatically dispatches
+a review subagent. It extends the Chimera review pipeline but fires
+**mid-session** on every change, not just at session end.
+
+```
+iteration.completed → git diff → debounce → chimera.review_needed event
+                                                  ↓
+                                    Director spawns review subagent
+                                    (provider/model from config)
+                                                  ↓
+                                    Severity-ranked report → session + mailbox
+                                                  ↓
+                                    chimera.review_complete event
+                                                  ↓
+                                    parseReviewSeverity → shouldCascade
+                                                  ↓  (if threshold crossed)
+                                    chimera.cascade_needed event
+                                                  ↓
+                                    Director spawns follow-up agents
+                                    (security-scanner, bug-hunter)
+```
+
+## Status
+
+**This is a built-in plugin** (`packages/core/src/plugins/auto-review-plugin.ts`),
+NOT a skill-based watcher. It is loaded automatically but **disabled by default**.
+Enable it in your config:
+
+```json
+{
+  "extensions": {
+    "wstack-auto-review": {
+      "enabled": true,
+      "provider": "deepseek",
+      "model": "deepseek-chat",
+      "fallbackProfile": "reliable",
+      "debounceMs": 5000,
+      "maxFilesPerBatch": 15,
+      "cascadeOn": "high",
+      "maxCascadeDepth": 2
+    }
+  }
+}
+```
+
+## Requirements
+
+- **`--director` flag** (Director mode) — the subagent spawning pipeline
+  (execution.ts) requires the Director to be active. Without it, review
+  events are silently skipped.
+- **`git`** available in the session working directory.
+
+## Configuration
+
+| Key | Type | Default | Description |
+|-----|------|---------|-------------|
+| `enabled` | boolean | false | Master switch |
+| `provider` | string | session provider | LLM provider for review agents |
+| `model` | string | session model | LLM model for review agents |
+| `fallbackProfile` | string | effective fallback profile | Named profile from `fallbackProfiles`; its first valid entry supplies the primary provider/model when those are omitted |
+| `debounceMs` | number | 5000 | Min gap between review triggers |
+| `maxFilesPerBatch` | number | 15 | Files per review call |
+| `maxConcurrentReviews` | number | 2 | Parallel review subagent cap |
+| `cascadeOn` | "off"|"critical"|"high" | "off" | Follow-up agent threshold — spawns security-scanner/bug-hunter when findings cross this severity |
+| `maxCascadeDepth` | number | 2 | Max fix→re-review cycles (0 = open-loop, no re-review) |
+
+## Slash commands
+
+| Command | Action |
+|---------|--------|
+| `/auto-review` | Show status + current config |
+| `/auto-review on` | Enable (via config update) |
+| `/auto-review off` | Disable |
+
+## What is reviewed
+
+- **Only git-tracked files** with staged or unstaged changes; untracked (`??`) files are never read or reviewed
+- **Content-aware** — later edits to an already-modified file trigger again when its content fingerprint changes
+- **Debounced without loss** — rapid edits are retained in a pending queue, with the latest content reviewed on the next eligible iteration
+- **Capped** at `maxFilesPerBatch` files per call; overflow stays pending
+- **Skipped** — `.wrongstack/` files
+- **Deleted files** are silently omitted
+
+## Cascade (self-correcting follow-up agents)
+
+When `cascadeOn` is `"high"` or `"critical"`, a review finding at or above that
+threshold triggers follow-up agents that **investigate and apply fixes**
+automatically. The cascade chain works as follows:
+
+```
+chimera.review_complete (carries report text + original bundle)
+         │
+         ▼
+auto-review plugin: parseReviewSeverity() extracts Critical/High/Medium counts
+         │
+         ▼  shouldCascade() gates on bundle.cascadeOn
+         │
+chimera.cascade_needed (carries severities + selected agents)
+         │
+         ▼
+execution.ts: spawns fix subagents via Director
+  • security-scanner — when a Critical/High finding mentions a security
+    keyword (injection, XSS, secret, shell, deserialization, etc.)
+  • bug-hunter — for any High+ finding (correctness concerns)
+         │
+         ▼  agents apply fixes (edit tool + typecheck/lint)
+         │
+re-read modified files → re-emit chimera.review_needed (depth N+1)
+         │
+         ▼  bounded by maxCascadeDepth — stops at limit or when clean
+```
+
+Both agents may spawn in parallel when a finding is both severe and
+security-related. The follow-up agents receive the review report (capped at
+12K chars) and the changed file list, read the flagged files, confirm or refute
+each finding, **apply fixes using the edit tool**, and run typecheck/lint to
+verify.
+
+### Closed self-correcting loop
+
+After fix agents apply their changes, the system re-reads the modified files
+and re-emits `chimera.review_needed` to trigger a fresh review of the post-fix
+state. If that review still finds High+ findings, the cycle repeats up to
+`maxCascadeDepth` iterations. When the depth limit is reached, a session message
+informs the user the loop stopped intentionally.
+
+| `maxCascadeDepth` | Behavior |
+|-------------------|----------|
+| `0` | Fix agents run once, no re-review (open-loop) |
+| `1` | Fix + one re-review to verify |
+| `2` (default) | Up to 2 re-review cycles |
+| `N` | Up to N re-review cycles |
+
+### Severity thresholds
+
+| `cascadeOn` | Fires when |
+|-------------|-----------|
+| `"off"` | Never (default) |
+| `"high"` | Any High OR Critical finding |
+| `"critical"` | Only Critical findings |
+
+### Agent selection
+
+`decideCascadeAgents()` scans only the Critical and High report sections for
+security keywords. A Medium-only security finding does **not** trigger the
+cascade — it doesn't cross the threshold. The 20 security keywords include:
+injection, xss, csrf, ssrf, sql, secret, credential, password, api key,
+token, auth, shell injection, command injection, innerhtml, deserialization,
+path traversal, hardcoded, privilege, owasp.
+
+## Skills in scope
+
+- `chimera` — for the review output format and severity rules
+- `shadow-agent` — for cron-based background monitoring pattern
+- `node-modern` — for understanding the TypeScript plugin code
+- `git-flow` — for git diff detection patterns
+- `multi-agent` — for subagent delegation and fleet management
+- `security-scanner` — for security vulnerability patterns
+- `bug-hunter` — for systematic bug detection
+

package/skills/mnemosyne/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: mnemosyne
+description: |
+  Use when curating WrongStack Super Memory: run deterministic hygiene and
+  anchor verification first, then review contradictions, drift, and noise;
+  file destructive outcomes as review proposals instead of deleting directly.
+version: 1.1.0
+---
+
+# Mnemosyne — Super Memory Custodian
+
+## Overview
+
+Mnemosyne is the repeatable memory-curation workflow for any project using
+WrongStack Super Memory. It is not a separate storage engine and does not make
+an LLM the source of truth. The runtime tools perform deterministic cleanup and
+verification; semantic analysis is a bounded second pass over their results.
+
+WrongStack discovers this bundled skill at boot. Every prompt mode receives its
+name and trigger. Eager mode may inject this body directly; progressive mode
+loads it through the `skill` tool. The detailed execution prompt is bundled as
+`instructions/agent-prompt.md` and should be loaded before a deep review.
+
+## Runtime Contract
+
+Use only surfaces that are actually registered in the current session:
+
+| Surface | Purpose |
+|---|---|
+| `memory_hygiene` | Deterministic deduplication, anchor verification, stale marking, superseding, and review-candidate creation |
+| `memory_verify` | Targeted or full anchor verification |
+| `memory_search` | Retrieve related memories for contradiction and duplication checks |
+| `memory_update` | Apply non-terminal corrections: text, classification, confidence, relationships, or `stale` status |
+| `memory_candidates` | File and inspect non-destructive review proposals; explicit resolution is a separate user-authorized action |
+| `skill` | Load this body and `instructions/agent-prompt.md` in progressive mode |
+| `cron_schedule` / `cron_cancel` | Optional in-session recurrence when the cron plugin is available |
+| `mail_send` / `mailbox` | Optional report delivery when mailbox tools are available |
+
+There is currently no standalone `/mnemosyne` slash command, implicit startup
+hook, or `mnemosyne_*` config namespace. Do not claim that one exists. Users can
+ask for a “Mnemosyne review”, load it explicitly with `/skill mnemosyne`, or use
+the existing `/memory hygiene`, `/memory verify`, and `/memory candidates`
+surfaces.
+
+## Workflow
+
+### 1. Deterministic hygiene
+
+Start every cycle with:
+
+```text
+memory_hygiene({ verify: true })
+```
+
+Capture the returned counts. This phase may deduplicate, mark stale anchors,
+supersede obsolete versions, and create review candidates. It must not delete
+or archive memories. Treat non-zero `deleted` or `archived` counters as a bug.
+
+Run `memory_verify` separately only when you need a targeted re-check or when
+hygiene could not complete verification.
+
+### 2. Bounded semantic review
+
+Search for related active/stale memories and review them in bounded batches.
+For the detailed review workflow, load:
+
+```text
+skill({ name: "mnemosyne", resource: "instructions/agent-prompt.md" })
+```
+
+Evaluate:
+
+1. Contradictions between memories.
+2. Duplicate or mergeable facts missed by exact matching.
+3. Vague, transient, or low-value entries.
+4. Incorrect kind, scope, importance, or confidence.
+5. Drift between anchored code and the memory claim.
+
+Do not infer that a missing search result means a memory does not exist. Keep
+batch sizes and LLM calls bounded, and leave unchanged memories untouched.
+
+### 3. Apply safe corrections
+
+Direct updates are allowed only for non-terminal corrections:
+
+- Fix inaccurate text when current project evidence is clear.
+- Correct kind, scope, importance, or confidence.
+- Mark a contradicted or invalid entry `stale`.
+- Link superseding/contradicting memories or mark a duplicate `superseded`.
+
+For deletion or archival recommendations, file a proposal:
+
+```text
+memory_candidates({
+  action: "propose",
+  text: "Concise review finding",
+  memory_id: "mem_target",
+  reason: "Why this memory needs user review",
+  suggested_action: "delete" | "archive" | "investigate"
+})
+```
+
+Never call `memory_delete`, never set `status: "deleted"`, and never set
+`status: "archived"` as part of an autonomous Mnemosyne cycle. The user owns
+the later `memory_candidates({ action: "resolve", ... })` decision.
+
+### 4. Report
+
+Return a concise report containing:
+
+- Trigger (`on_demand` or `cron`).
+- Examined, deduplicated, verified, staled, and superseded counts.
+- Semantic findings and safe corrections applied.
+- Review proposals filed, grouped by suggested action.
+- Errors or skipped checks.
+
+Broadcast the report only when a mailbox tool is registered and coordination is
+active. Never invent a successful broadcast or scheduled cycle.
+
+## Optional Recurrence
+
+Recurring curation is explicitly opt-in and session-scoped. When
+`cron_schedule` is registered, schedule a plain-language action that causes a
+future agent turn to run this workflow, for example:
+
+```text
+cron_schedule({
+  name: "mnemosyne-review",
+  intervalMs: 21600000,
+  action: "Run the bundled mnemosyne workflow: deterministic hygiene first, then bounded semantic review, propose-only for delete/archive."
+})
+```
+
+Do not describe this as a persistent daemon: cron jobs belong to the live
+runtime and must be inspected or cancelled through the cron tools. If those
+tools are absent, run on demand instead.
+
+## Guardrails
+
+- Deterministic checks always precede LLM analysis.
+- Destructive and terminal outcomes are proposal-only.
+- Permanent and high-importance memories receive extra scrutiny; never bypass
+  store protections with `force`.
+- A memory that passes review is not rewritten merely to bump timestamps.
+- Record evidence for each mutation in the report; every proposal includes its supported `reason`.
+- A failed batch does not invalidate successful deterministic results.
+- Never advertise commands, config keys, background services, or tools that
+  are not present in the live runtime.
+
+## Skills in Scope
+
+- `auto-review` — bounded background-review and reporting patterns.
+- `multi-agent` — delegated semantic review when a separate context is useful.
+- `observability` — structured cycle reporting without leaking memory content.
+- `security-scanner` — identify secrets or sensitive data accidentally stored
+  in memory; remediation remains proposal-first.