@mthanh/vespercli 1.7.0 → 1.8.0

package/README.md

@@ -153,6 +153,44 @@ A single project can have both targets installed at once — `.vesper/` (code in
 
 </details>
 
+<details>
+<summary><b>Optional: <code>i-have-adhd</code> output-style skill</b> — opt-in, off by default</summary>
+
+Vesper can install a **reviewed, pinned snapshot** of the third-party MIT-licensed [`i-have-adhd`](https://github.com/ayghri/i-have-adhd) skill (Copyright (c) 2026 Ayoub Ghriss) into a Claude Code project. It reshapes response *format* only — lead with the next concrete action, keep it brief and scannable — and explicitly defers to the harness system prompt and preserves safety confirmations. It's vendored once, verbatim, at a pinned commit SHA; it is never fetched at runtime and never auto-refreshed (re-vendoring is a deliberate, reviewed pull request).
+
+**How you're asked**: on `vespercli init` (and re-init) for the Claude target, Vesper asks once — `Install the third-party i-have-adhd output-style skill? (MIT, reviewed snapshot, added to this repo)` — defaulting to **Yes** (a quick Enter accepts). Your answer is remembered in your user-level `~/.vesperrc` (`vendored.adhd.optIn`, a boolean-only setting — no secrets), so you're **only prompted once per machine**; later inits honor the stored answer without asking again.
+
+Change or preset the answer any time:
+
+- `vespercli init --adhd` — install and remember Yes; `vespercli init --no-adhd` — skip and remember No. Both overwrite the remembered answer non-interactively.
+- Pre-set `~/.vesperrc` to `{ "vendored": { "adhd": { "optIn": true } } }` (or `false`) before your first init to answer ahead of time and suppress the prompt. (A pre-1.8 `{ "adhd": { "optIn": … } }` key is still honored.)
+
+**Headless safety**: in a non-interactive run (`-y`/`--force-default` or no TTY) with no remembered answer and no flag, the skill is **skipped** — Vesper never lets the default-Yes flow into an unattended third-party install. A stored `true` installs; a stored `false` skips.
+
+The gate is **per-user** (your answer lives once in `~/.vesperrc`), but whether the asset is actually present is tracked **per-project** (recorded in that project's `.vesperrc` once installed). This split matters for scope:
+
+- `vespercli init` / re-init are the **only** commands that can *introduce* the asset into a project — they check the opt-in gate and, if enabled, install `.claude/skills/i-have-adhd/SKILL.md`, `.claude/rules/i-have-adhd.md`, and a marker-scoped `@import` in `CLAUDE.md` (outside the Vesper guard block), then record the per-project install.
+- `vespercli update` and `vespercli worktree bootstrap` only **maintain** an already-recorded install (content-compared re-write, no churn on unchanged files) — they never introduce it, even if the opt-in gate is on. On a fresh worktree or clone, the git-tracked artifacts are already there but the local per-worktree record isn't (it isn't git-tracked), so maintain is a no-op there until the project runs `init`/re-init again with the gate enabled.
+- `vespercli reset` fully removes it — the skill directory, the rule file, and the `CLAUDE.md` import region — and clears the per-project record.
+
+</details>
+
+<details>
+<summary><b>Optional: <code>ponytail</code> decision-ladder skill</b> — opt-in, off by default</summary>
+
+Vesper can install a **reviewed, pinned snapshot** of the third-party MIT-licensed [`ponytail`](https://github.com/DietrichGebert/ponytail) skill (Copyright (c) 2026 DietrichGebert) into a Claude Code project. It nudges coding work toward the **laziest solution that actually works** — a YAGNI/minimalism decision ladder (does this need to exist? → reuse what's here → stdlib → native feature → existing dependency → one line → minimum code) — while never simplifying away understanding, correctness, validation, or security. **Rule-text only**: only the decision-ladder markdown is vendored. The upstream repo's auto-executing hooks, scripts, other-editor variants, and auxiliary skills are **excluded** — no executable code is vendored, and nothing is ever fetched or run at install time (see `assets/vendor/ponytail/VENDOR.md`). It's vendored once, verbatim, at a pinned commit SHA; re-vendoring is a deliberate, reviewed pull request.
+
+**How you're asked**: a second one-time prompt on `vespercli init`/re-init — `Install the third-party ponytail decision-ladder skill? (MIT, reviewed snapshot, rule-text only, added to this repo)` — defaulting to **Yes**. It's **independent** of the i-have-adhd prompt: you can accept one and decline the other. Your answer is remembered in `~/.vesperrc` (`vendored.ponytail.optIn`), so you're only prompted once per machine.
+
+Change or preset the answer any time:
+
+- `vespercli init --ponytail` — install and remember Yes; `vespercli init --no-ponytail` — skip and remember No.
+- Pre-set `~/.vesperrc` to `{ "vendored": { "ponytail": { "optIn": true } } }` (or `false`) before your first init.
+
+**Headless safety** and the **introduce (init/reinit only) vs. maintain (update/bootstrap) vs. reset (full teardown)** scoping are identical to the i-have-adhd asset above — this is the same registry-driven vendored-asset engine. When enabled, init installs `.claude/skills/ponytail/SKILL.md`, a minimal always-on `.claude/rules/ponytail.md` pointer, and a marker-scoped `@import` in `CLAUDE.md`.
+
+</details>
+
 <details>
 <summary><b>Local overrides</b> — customize specific assets</summary>
 
@@ -291,6 +329,14 @@ vespercli mcp sync                         # Re-sync tool auto-approval (Copilot
 vespercli mcp reindex --full               # Clear and rebuild the shared code index
 ```
 
+`mcp status`'s "Server built" line is a tri-state health check, not a simple built/not-built flag — it probes the manifests of the `vesper-indexing` server's two direct runtime dependencies (`@modelcontextprotocol/sdk`, `zod`) rather than just checking that their `node_modules` folders exist, so a corrupted install (present as a directory but missing its own `package.json`, e.g. from an interrupted install) is caught instead of misreported as healthy:
+
+- `✓ yes` — built and dependencies verified.
+- `⚠ yes, but dependencies missing — run 'npm install' in src/mcp/vesper-indexing (or reinstall Vesper)` — the build output exists but a dependency is corrupted/missing; the server will crash at startup with `ERR_MODULE_NOT_FOUND` until repaired.
+- `✗ no` — not built yet; run `cd src/mcp/vesper-indexing && npm install && npm run build`.
+
+This check is detective, not a repair itself — `npm install`/reinstalling Vesper afterward is still a manual step for an already-corrupted install. `npm install` for the bundled CLI package self-heals this automatically going forward via `postinstall.js`, which uses the same canary to decide whether to skip or re-run its own install.
+
 </details>
 
 <details>

package/assets/claude/agents/clickup-agent.md

@@ -2,7 +2,7 @@
 name: clickup-agent
 description: ClickUp specialist that handles all ClickUp API operations with proper multi-level fetching
 model: claude-haiku-4-5-20251001
-tools: Grep, Glob, Read, mcp__vesper-indexing__vesper_search, mcp__vesper-indexing__vesper_symbols, mcp__vesper-indexing__vesper_status, mcp__vesper-indexing__vesper_reindex, mcp__memory__create_entities, mcp__memory__create_relations, mcp__memory__add_observations, mcp__memory__search_nodes, mcp__memory__open_nodes
+tools: Grep, Glob, Read, mcp__clickup__clickup_add_tag_to_task, mcp__clickup__clickup_add_time_entry, mcp__clickup__clickup_attach_task_file, mcp__clickup__clickup_create_document, mcp__clickup__clickup_create_document_page, mcp__clickup__clickup_create_folder, mcp__clickup__clickup_create_list, mcp__clickup__clickup_create_list_in_folder, mcp__clickup__clickup_create_task, mcp__clickup__clickup_create_task_comment, mcp__clickup__clickup_find_member_by_name, mcp__clickup__clickup_get_chat_channels, mcp__clickup__clickup_get_current_time_entry, mcp__clickup__clickup_get_document_pages, mcp__clickup__clickup_get_folder, mcp__clickup__clickup_get_list, mcp__clickup__clickup_get_task, mcp__clickup__clickup_get_task_comments, mcp__clickup__clickup_get_task_time_entries, mcp__clickup__clickup_get_workspace_hierarchy, mcp__clickup__clickup_get_workspace_members, mcp__clickup__clickup_list_document_pages, mcp__clickup__clickup_remove_tag_from_task, mcp__clickup__clickup_resolve_assignees, mcp__clickup__clickup_search, mcp__clickup__clickup_send_chat_message, mcp__clickup__clickup_start_time_tracking, mcp__clickup__clickup_stop_time_tracking, mcp__clickup__clickup_update_document_page, mcp__clickup__clickup_update_folder, mcp__clickup__clickup_update_list, mcp__clickup__clickup_update_task, mcp__vesper-indexing__vesper_search, mcp__vesper-indexing__vesper_symbols, mcp__vesper-indexing__vesper_status, mcp__vesper-indexing__vesper_reindex, mcp__memory__create_entities, mcp__memory__create_relations, mcp__memory__add_observations, mcp__memory__search_nodes, mcp__memory__open_nodes
 skills: [agent-fundamentals]
 ---
 

package/assets/claude/agents/context7.md

@@ -2,7 +2,7 @@
 name: context7
 description: Expert in latest library versions, best practices, and correct syntax using up-to-date documentation
 model: claude-haiku-4-5-20251001
-tools: Read, Grep, Glob, WebFetch, WebSearch, mcp__context7__resolve-library-id, mcp__context7__get-library-docs, mcp__vesper-indexing__vesper_search, mcp__vesper-indexing__vesper_symbols, mcp__vesper-indexing__vesper_status, mcp__vesper-indexing__vesper_reindex, mcp__memory__create_entities, mcp__memory__create_relations, mcp__memory__add_observations, mcp__memory__search_nodes, mcp__memory__open_nodes
+tools: Read, Grep, Glob, WebFetch, WebSearch, Agent, mcp__context7__resolve-library-id, mcp__context7__get-library-docs, mcp__vesper-indexing__vesper_search, mcp__vesper-indexing__vesper_symbols, mcp__vesper-indexing__vesper_status, mcp__vesper-indexing__vesper_reindex, mcp__memory__create_entities, mcp__memory__create_relations, mcp__memory__add_observations, mcp__memory__search_nodes, mcp__memory__open_nodes
 skills: [agent-fundamentals]
 ---
 

package/assets/claude/agents/history-logger.md

@@ -82,13 +82,13 @@ This is a **separate, explicitly-invoked mode** — distinct from your normal ap
 
 ### 2. Archive completed tracking stories
 
-1. List `.vesper/.tracking/stories/completed/`. For story files older than N days (default 30, or as specified), move them (via `Bash mv`, not delete) into `.vesper/.tracking/stories/completed/archive/YYYYMM/`, grouped by the month they were completed.
+1. List `.vesper/.tracking/stories/completed/`. Move **every** story file found there (via `Bash mv`, not delete) into `.vesper/.tracking/stories/completed/archive/YYYYMM/`, grouped by the month they were completed. There is no age condition — every run archives the entire current contents of `completed/`.
 2. Never touch `refining/`, `backlog/`, `inprogress/`, or `inreview/` — only `completed/`.
 3. Report the count moved and where.
 
 ### 3. Archive correlated tracking artifacts
 
-For each `stories/completed/<slug>` entry older than the same N-day threshold (default 30), move its correlated tracking artifacts — every `research/`, `plans/`, `details/`, `prompts/`, and `changes/` file whose name contains that `<slug>` — into `.vesper/.tracking/archive/YYYYMM/<slug>/` (grouped by the month the story was completed), via `Bash mv`, never delete.
+For each `stories/completed/<slug>` entry archived in Step 2 (i.e., every completed story, unconditionally — this section no longer applies its own separate age gate; it always runs for whatever Step 2 just archived), move its correlated tracking artifacts — every `research/`, `plans/`, `details/`, `prompts/`, and `changes/` file whose name contains that `<slug>` — into `.vesper/.tracking/archive/YYYYMM/<slug>/` (grouped by the month the story was completed), via `Bash mv`, never delete.
 
 1. **Idempotent move**: if the source is already gone and the destination already holds the file, treat it as already done (a concurrent worktree archived it). Never error, never re-move.
 2. **Archive-with-a-flag fallback**: archive regardless of whether `feature-wrap-document` extracted durable knowledge for the slug first. Check the MCP memory graph (or a recorded wrap marker) for a completed feature-wrap for that slug; if none exists, write an empty `.unwrapped` marker file into the archived `<slug>/` folder so `/revalidate-knowledge` treats it as a **priority re-extraction candidate**. This preserves the non-destructive invariant (nothing is lost — archived, just flagged) without blocking retention indefinitely on a wrap step that may legitimately never run (Lightweight-path tasks have no wrap).

package/assets/claude/agents/modernization.md

@@ -2,6 +2,7 @@
 name: modernization
 description: Human-in-the-loop modernization assistant for analyzing, documenting, and planning complete project modernization with architectural recommendations.
 model: claude-opus-4-8
+tools: Grep, Glob, Read, Edit, Write, Bash, Agent, TodoWrite, WebFetch, mcp__vesper-indexing__vesper_search, mcp__vesper-indexing__vesper_symbols, mcp__vesper-indexing__vesper_status, mcp__vesper-indexing__vesper_reindex, mcp__memory__create_entities, mcp__memory__create_relations, mcp__memory__add_observations, mcp__memory__search_nodes, mcp__memory__open_nodes
 skills: [agent-fundamentals]
 ---
 

package/assets/claude/commands/compact-knowledge.md

@@ -4,7 +4,7 @@ description: Compact persisted Vesper knowledge (history.md, memory.jsonl, compl
 
 Compact persisted Vesper knowledge. Delegate in parallel:
 
-1. `history-logger` in Compaction Mode: rotate `.vesper/history.md` (archive entries older than the last 30 into `.vesper/history-archive/YYYYMM.md`), archive `.vesper/.tracking/stories/completed/` entries older than 30 days, and archive each completed story's correlated `research/plans/details/prompts/changes` tracking artifacts into `.vesper/.tracking/archive/YYYYMM/<slug>/` (idempotent move; flag any slug with no recorded feature-wrap as `.unwrapped` so `/revalidate-knowledge` re-extracts it).
+1. `history-logger` in Compaction Mode: rotate `.vesper/history.md` (archive entries older than the last 30 into `.vesper/history-archive/YYYYMM.md`), archive **every** `.vesper/.tracking/stories/completed/` entry unconditionally, and archive each completed story's correlated `research/plans/details/prompts/changes` tracking artifacts into `.vesper/.tracking/archive/YYYYMM/<slug>/` (idempotent move; flag any slug with no recorded feature-wrap as `.unwrapped` so `/revalidate-knowledge` re-extracts it).
 2. `feature-wrap-document` in Memory Compaction Mode: merge/dedupe stale entities in the MCP memory graph, never touching `current_task` or active entities.
 
 Report what was archived/merged from both. Nothing is deleted — only moved to archive files or consolidated within the memory graph.

package/assets/claude/skills/java/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: java
-description: Guidelines for building Java base applications Use when working with files matching: **/*.java.
+description: Guidelines for building Java base applications. Use when working with Java files.
 ---
 
 # Java Development

package/assets/claude/skills/nextjs-tailwind/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: nextjs-tailwind
-description: Next.js + Tailwind development standards and instructions Use when working with files matching: **/*.tsx, **/*.ts, **/*.jsx, **/*.js, **/*.css.
+description: Next.js + Tailwind development standards and instructions. Use when working with TSX, TypeScript, JSX, JavaScript, or CSS files.
 ---
 
 # Next.js + Tailwind Development Instructions

package/assets/claude/skills/reactjs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: reactjs
-description: ReactJS development standards and best practices Use when working with files matching: **/*.jsx, **/*.tsx, **/*.js, **/*.ts, **/*.css, **/*.scss.
+description: ReactJS development standards and best practices. Use when working with JSX, TSX, JavaScript, TypeScript, CSS, or SCSS files.
 ---
 
 # ReactJS Development Instructions

package/assets/claude/skills/self-explanatory-code-commenting/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: self-explanatory-code-commenting
-description: Guidelines for GitHub Copilot to write comments to achieve self-explanatory code with less comments. Examples are in JavaScript but it should work on any language that has comments. Use when working with files matching: **/*.py, **/*.js, **/*.ts, **/*.java, **/*.cs, **/*.cpp, **/*.go, **/*.rb.
+description: Conventions for writing and reviewing code comments: prefer self-explanatory code, comment WHY not WHAT, and avoid obvious, redundant, outdated, dead-code, or decorative comments. Language-agnostic (examples in JavaScript). Use when working with Python, JavaScript, TypeScript, Java, C#, C++, Go, or Ruby files.
 ---
 
 # Self-explanatory Code Commenting Instructions

package/assets/claude/skills/tailwind-v4-vite/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tailwind-v4-vite
-description: Tailwind CSS v4+ installation and configuration for Vite projects using the official @tailwindcss/vite plugin Use when working with files matching: vite.config.ts, vite.config.js, **/*.css, **/*.tsx, **/*.ts, **/*.jsx, **/*.js.
+description: Tailwind CSS v4+ installation and configuration for Vite projects using the official @tailwindcss/vite plugin. Use when working with TypeScript, JavaScript, CSS, TSX, or JSX files.
 ---
 
 # Tailwind CSS v4+ Installation with Vite

package/assets/claude/skills/task-implementation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: task-implementation
-description: Instructions for implementing task plans with progressive tracking and change record - Brought to you by microsoft/edge-ai Use when working with files matching: **/.vesper/.tracking/changes/*.md.
+description: Instructions for implementing task plans with progressive tracking and change record - Brought to you by microsoft/edge-ai. Use when working with task change-record files under .vesper/.tracking/changes/.
 ---
 
 # Task Plan Implementation Instructions

package/assets/claude/skills/vesper-catalog-editing-safety/SKILL.md

@@ -50,7 +50,7 @@ Most edits hit exactly one checklist. If unsure, read Checklist D first — it's
 | `assets/skills/<name>/`                                | `assets/claude/skills/<name>/` (near-verbatim)             |
 | `assets/instructions/<name>/<name>.instructions.md`    | `assets/claude/skills/<name>/SKILL.md` (new skill)         |
 
-**That table is the entire remit.** `assets/core/` is never read by this script, at all — by design, not by omission (the script's own comment: *"the 12 core agents + the orchestrator playbook are hand-authored separately in assets/claude/ and are never touched by this script"*).
+**That table is the entire remit.** `assets/core/` is never read by this script, at all — by design, not by omission (the script's own comment: *"the 12 core agents + the orchestrator playbook are hand-authored separately in assets/claude/ and are never touched by this script"*). Neither is `assets/vendor/` — reviewed, pinned third-party snapshots (e.g. `assets/vendor/i-have-adhd/`, `assets/vendor/ponytail/`) live outside the four scan roots and the three write targets on purpose. A vendored asset is edited only by re-vendoring (a reviewed PR bumping its pinned SHA), never through the generator; do not move it under `assets/skills/` or `assets/claude/` to "make the generator pick it up."
 
 - [ ] Is the file under `assets/core/`?
   - **Yes** → There is no generator step for you. Hand-edit **both** the Copilot source (`assets/core/{agents,skills,instructions,prompts}/...`) **and** its `assets/claude/` twin. Before editing the twin, check it for **Claude-only content that doesn't exist in the Copilot source** and preserve it — e.g. `assets/claude/skills/agent-fundamentals/SKILL.md`'s `## Direct Collaboration (Nested Delegation)` section has no Copilot-side counterpart. Never diff the two sides expecting them to match; they're allowed to diverge by design.
@@ -130,6 +130,7 @@ If your edit changes *where* either target looks, or *what* gets written into th
 
 - `assets/` — the Copilot-format source catalog (`core/` hand-authored default install; `agents/`, `skills/`, `instructions/`, `prompts/` extended/opt-in)
 - `assets/claude/` — generated Claude-target twin of the extended tree, plus hand-maintained Claude-only twins of `assets/core/`
+- `assets/vendor/` — reviewed, pinned snapshots of third-party assets (e.g. `assets/vendor/i-have-adhd/`, `assets/vendor/ponytail/`); a generator-excluded category, installed project-level at init time, never scanned/written by the generator and never a scan root
 - `scripts/generate-claude-assets.js` — the extended-tree generator; never touches `assets/core/`
 - `src/cli/utils/settings.js` — `VSCODE_SETTINGS_MAP`, `getCoreAssetEntries()`, `VESPER_GIT_PATHS`
 - `src/cli/utils/claude-target.js` — `getClaudePluginDir()`, `installClaudePluginCatalog()`, `ensureClaudeMdGuardBlock()`, `VESPER_REINJECT_COMMAND`

package/assets/claude/vesper-orchestrator.md

@@ -110,6 +110,8 @@ All workspace-related actions live here: initialization, re-initialization, team
 
 > **Exception — externally-synced GitLab skills (closed list).** Exactly two skills deviate from "no other source," and only these two: `gitlab-ci-skill` (from `https://gitlab.com/gitlab-org/ci-cd/gitlab-ci-skill.git`) and `github-actions-to-gitlab-ci` (from `https://gitlab.com/gitlab-org/ci-cd/github-actions-to-gitlab-ci.git`). **Location** is fully compliant — both install into the same Vesper-managed plugin dir (`~/.claude/skills/vesper/skills/`) as every other skill, so subagents still look in exactly one place. **Authorship/maintenance** is the sole carve-out — their *content* is pulled fresh from those two upstream GitLab repos on every `init`/`/reinit`/`worktree bootstrap`, rather than authored/vendored by Vesper. This list is closed: adding any third externally-synced skill (any other URL, host, or namespace) is **not** covered by this exception and requires a new documented exception plus architecture-review sign-off before implementation.
 
+> **Vendored (externally-sourced-once) assets — a distinct category, NOT part of the closed list above.** Separately from the externally-*synced* skills, Vesper may carry **vendored** third-party assets: a one-time reviewed snapshot **pinned to a commit SHA**, committed into `assets/vendor/` and installed project-level at init time, **never fetched at runtime** and with the upstream install instructions **never executed**. Each snapshot passes a **per-snapshot human content-review** (prompt-injection / behavioral-override / tool-permission-escalation / data-exfiltration / destructive-instruction scan) with the reviewer recorded in the asset's `VENDOR.md`, ships the upstream **LICENSE verbatim + attribution** (e.g. `i-have-adhd` — MIT, Copyright (c) 2026 Ayoub Ghriss), and is re-vendored **only by a deliberate reviewed PR, never automatically**. This category is *distinct from* the externally-synced closed list and does **not** expand it — the closed list stays literally closed at two.
+
 ### State Check (before any work)
 
 **Check**: Does `.claude/vesper/orchestration.md` exist with a **Team Roster** section?

package/assets/core/agents/history-logger.agent.md

@@ -83,13 +83,13 @@ This is a **separate, explicitly-invoked mode** — distinct from your normal ap
 
 ### 2. Archive completed tracking stories
 
-1. List `.vesper/.tracking/stories/completed/`. For story files older than N days (default 30, or as specified), move them (via terminal `mv`, not delete) into `.vesper/.tracking/stories/completed/archive/YYYYMM/`, grouped by the month they were completed.
+1. List `.vesper/.tracking/stories/completed/`. Move **every** story file found there (via terminal `mv`, not delete) into `.vesper/.tracking/stories/completed/archive/YYYYMM/`, grouped by the month they were completed. There is no age condition — every run archives the entire current contents of `completed/`.
 2. Never touch `refining/`, `backlog/`, `inprogress/`, or `inreview/` — only `completed/`.
 3. Report the count moved and where.
 
 ### 3. Archive correlated tracking artifacts
 
-For each `stories/completed/<slug>` entry older than the same N-day threshold (default 30), move its correlated tracking artifacts — every `research/`, `plans/`, `details/`, `prompts/`, and `changes/` file whose name contains that `<slug>` — into `.vesper/.tracking/archive/YYYYMM/<slug>/` (grouped by the month the story was completed), via terminal `mv`, never delete.
+For each `stories/completed/<slug>` entry archived in Step 2 (i.e., every completed story, unconditionally — this section no longer applies its own separate age gate; it always runs for whatever Step 2 just archived), move its correlated tracking artifacts — every `research/`, `plans/`, `details/`, `prompts/`, and `changes/` file whose name contains that `<slug>` — into `.vesper/.tracking/archive/YYYYMM/<slug>/` (grouped by the month the story was completed), via terminal `mv`, never delete.
 
 1. **Idempotent move**: if the source is already gone and the destination already holds the file, treat it as already done (a concurrent worktree archived it). Never error, never re-move.
 2. **Archive-with-a-flag fallback**: archive regardless of whether `@Feature Wrap and Retrospective Agent` extracted durable knowledge for the slug first. Check the MCP memory graph (or a recorded wrap marker) for a completed feature-wrap for that slug; if none exists, write an empty `.unwrapped` marker file into the archived `<slug>/` folder so `/revalidate-knowledge` treats it as a **priority re-extraction candidate**. This preserves the non-destructive invariant (nothing is lost — archived, just flagged) without blocking retention indefinitely on a wrap step that may legitimately never run (Lightweight-path tasks have no wrap).

package/assets/core/prompts/compact-knowledge.prompt.md

@@ -8,7 +8,7 @@ Compact persisted Vesper knowledge — distinct from Claude Code's `/compact` or
 
 Delegate:
 
-1. `@History Logger` in Compaction Mode: rotate `.vesper/history.md` (archive entries older than the last 30 into `.vesper/history-archive/YYYYMM.md`), archive `.vesper/.tracking/stories/completed/` entries older than 30 days, and archive each completed story's correlated `research/plans/details/prompts/changes` tracking artifacts into `.vesper/.tracking/archive/YYYYMM/<slug>/` (idempotent move; flag any slug with no recorded feature-wrap as `.unwrapped` so `/revalidate-knowledge` re-extracts it).
+1. `@History Logger` in Compaction Mode: rotate `.vesper/history.md` (archive entries older than the last 30 into `.vesper/history-archive/YYYYMM.md`), archive **every** `.vesper/.tracking/stories/completed/` entry unconditionally, and archive each completed story's correlated `research/plans/details/prompts/changes` tracking artifacts into `.vesper/.tracking/archive/YYYYMM/<slug>/` (idempotent move; flag any slug with no recorded feature-wrap as `.unwrapped` so `/revalidate-knowledge` re-extracts it).
 2. `@Feature Wrap and Retrospective Agent` in Memory Compaction Mode: merge/dedupe stale entities in the MCP memory graph, never touching `current_task` or active entities.
 
 Report what was archived/merged from both. Nothing is deleted — only moved to archive files or consolidated within the memory graph.