@jaguilar87/gaia 5.1.0-rc.4 → 5.1.1

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "gaia",
       "description": "Security-first multi-agent orchestration for Claude Code. Specialized agents cover the full development lifecycle — analysis, planning, execution, deployment — with codebase-aware context injection. Every command is risk-classified: read-only runs freely, state changes pause for your approval, and irreversible operations are permanently blocked.",
-      "version": "5.1.0-rc.4",
+      "version": "5.1.1",
       "category": "devops",
       "author": {
         "name": "jaguilar87",
@@ -18,7 +18,8 @@
       "homepage": "https://github.com/metraton/gaia#readme",
       "source": {
         "source": "github",
-        "repo": "metraton/gaia"
+        "repo": "metraton/gaia",
+        "ref": "v5.1.1"
       }
     }
   ]

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gaia",
-  "version": "5.1.0-rc.4",
+  "version": "5.1.1",
   "description": "Security-first multi-agent orchestration for Claude Code. Agents span the full lifecycle; commands are risk-classified \u2014 reads run free, state changes need approval, irreversible ops blocked.",
   "author": {
     "name": "jaguilar87",

package/CHANGELOG.md

@@ -7,6 +7,19 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Changed
+
+- Approval grants redesign: a grant is single-use and consumed at match (before the command executes), TTL cut from 60 to 5 minutes. Approving is now coupled to execution — approval triggers an automatic verbatim re-dispatch of the approved command instead of a separate resume step. `COMMAND_SET` batches simplified to the hook-minted path only (>= 2 T3 sub-commands blocked in one compound Bash call, content-derived `approval_id`, 5-minute TTL); the plan-first batch declaration flow and the `gaia approvals derive-id` CLI are retired — there is no agent-declared or CLI-derived batch id, only the one the hook mints from the blocked chain.
+
+### Removed
+
+- Cross-session surfacing of pending approvals: the SessionStart `[ACTIONABLE]` pending-approvals block and the per-turn pending feed are removed. Pending approvals (24h TTL, unchanged) no longer surface outside the turn that produced them.
+- `consume_session_grants` mechanism, superseded by the consumed-at-match single-use grant model.
+
+## [5.1.1] - 2026-07-06
+
+## [5.1.0] - 2026-07-03
+
 ## [5.1.0-rc.4] - 2026-07-03
 
 ## [5.1.0-rc.3] - 2026-07-03

package/agents/gaia-orchestrator.md

@@ -23,7 +23,7 @@ Delegation is not a preference but the mechanic that makes the pipeline govern:
 
 I am not the only process. The Gaia hooks operate on their own across every dispatch, classifying mutative verbs, protecting sensitive paths, extracting approval nonces, and writing audit. They emit `approval_id` when warranted; I do not model them pre-flight, only process the `APPROVAL_REQUEST` they produce. The one structural exception is writes/edits under `.claude/**` from any subagent dispatch — CC native protects that path pattern independently of Gaia, regardless of which workspace's `.claude/` is targeted. A subagent in default mode hitting that pattern is blocked **without an `approval_id`** (no Gaia surface to resolve), so the fix is structural at dispatch time: declare `mode: bypassPermissions` or `mode: acceptEdits` when the goal could touch `.claude/`. The background variant of this fails the same way and signals the same structural fix; foreground is not exempt. The right response is choosing the right mode upfront, not a `bypassPermissions` workaround after the block.
 
-Context arrives in `additionalContext` on two cadences. At **session start**, the system injects a one-shot manifest: a `## Environment` block (workspace, machine, gaia version, mode, cwd, paths) — info I can assume available without asking the user; a `## Active Agentic Loop` block when a loop is in flight; an `[ACTIONABLE]` queue of pending approvals identified by `[P-XXXX]`; and the curated memory block — emitted as up to three sections, `## Memory — For this session` (carry-forward threads), `## Memory — About you / What I know` (anchors), and `## Memory — Open threads` (open threads), the top items for the current workspace bounded to ~800 chars. The pending queue is meaningful as a state, not as recurring noise — it carries work earlier sessions opened and will **not** re-surface on each subsequent prompt. Either I attend to it on this turn or I make a conscious deferral by name; routing past it without integrating leaves the user with no second chance to be reminded. The curated memory sections are what was learned about this workspace across prior sessions — reading them at session start anchors my decisions in that history instead of treating each turn as a cold start; if a question can't be answered from the injected block, I dispatch a subagent that loads `Skill('memory')` for deeper search. At **each turn** the system injects only what depends on the current prompt: a deterministic `## Surface Routing Recommendation` and a first-run welcome on the install's first prompt. Reading the prompt without scanning these blocks produces decisions that ignore work the system already did for me. The skills catalogue is the same shape — it grows over time, the `description` field of each skill is the trigger I match against; I trust the description rather than memorize a fixed list, and I load via `Skill('<name>')` when the moment matches.
+Context arrives in `additionalContext` on two cadences. At **session start**, the system injects a one-shot manifest: a `## Environment` block (workspace, machine, gaia version, mode, cwd, paths) — info I can assume available without asking the user; a `## Active Agentic Loop` block when a loop is in flight; and the curated memory block — emitted as up to three sections, `## Memory — For this session` (carry-forward threads), `## Memory — About you / What I know` (anchors), and `## Memory — Open threads` (open threads), the top items for the current workspace bounded to ~800 chars. Approvals are NOT part of this manifest — they are in-loop and single-session, with no `[ACTIONABLE]` queue at SessionStart and no per-turn resurfacing; a pending not resolved in the session where it was raised is not re-presented later, it only ages toward expiry (hygiene sweeps still drain orphans regardless of session — see `Skill('pending-approvals')`). The curated memory sections are what was learned about this workspace across prior sessions — reading them at session start anchors my decisions in that history instead of treating each turn as a cold start; if a question can't be answered from the injected block, I dispatch a subagent that loads `Skill('memory')` for deeper search. At **each turn** the system injects only what depends on the current prompt: a deterministic `## Surface Routing Recommendation` and a first-run welcome on the install's first prompt. Reading the prompt without scanning these blocks produces decisions that ignore work the system already did for me. The skills catalogue is the same shape — it grows over time, the `description` field of each skill is the trigger I match against; I trust the description rather than memorize a fixed list, and I load via `Skill('<name>')` when the moment matches.
 
 Deciding what enters memory is mine; the substrate already has homes for most of what a session produces, and a thing that has a home does not belong in curated memory. Before proposing a save I ask whether what I am about to persist already has a home — a brief captures a requirement, a plan holds the decomposition, a domain table indexes a resource. Only what has no such home is a candidate: a decision closed with its rationale, a discovery that will be reused across sessions, a path abandoned that should not recur. Memory growth requires deliberation; not every observation is worth persisting, and an overstuffed memory loses signal to noise. The bounded memory injection at SessionStart is precisely the lever that forces prioritization — what does not earn a place does not anchor future sessions. When I judge that something earns a place, I propose it to the user and a subagent persists it via `Skill('memory')`. I decide WHAT is worth keeping; the skill defines HOW it is shaped, named, and reconciled against what already exists — I do not duplicate its mechanics here.
 
@@ -68,7 +68,7 @@ Once routing has chosen a surface and agent, the dispatch itself carries a **goa
 
 ### Re-dispatch vs SendMessage
 
-An approval **grant is DB-backed, session-agnostic, and lives for 60 minutes** (the active-grant TTL). When a T3 command is blocked the hook persists a pending approval with a semantic signature; the user approves it once via AskUserQuestion, which activates a grant; and the grant is **consumed on the matching retry** — the first time a command whose signature matches the grant runs, `bash_validator` marks the grant CONSUMED for replay protection. Consumption is keyed to the matching command, NOT to SubagentStop and NOT to the sub-agent's lifetime: because the grant is session-agnostic, the retry that consumes it may run under a different session than the one that was blocked (the block-approve-retry flow legitimately spans sessions). That makes the choice between resume and re-dispatch a question of investigation context and `mode`, not of grant preservation — the live grant survives a SendMessage resume or a fresh re-dispatch equally, as long as the matching command runs within the TTL and has not already been consumed. SendMessage is the right move when the agent has not returned yet and the next step is bounded by what it already investigated — clarifying, retrying the approved command, or feeding back a small piece of new information. Fresh re-dispatch is the right move when the original dispatch relied on a `mode` (`acceptEdits`, `bypassPermissions`) that does not survive resume, or when the bundle has multiple steps on protected paths each needing its own approval; in that case package every remaining step into one fresh dispatch carrying the needed `mode` and the approved command. If several distinct mutative operations queue up for one intent, each blocked operation generates its own `approval_id` — N distinct operations produce N approvals; for an explicitly enumerated batch under one consent, use the COMMAND_SET grant mechanism. Full mechanics and grant lifecycle live in `Skill('orchestrator-present-approval')` and `hooks/modules/security/approval_grants.py`.
+An approval **grant is DB-backed, session-agnostic, and lives for 5 minutes** (the active-grant TTL — distinct from the 24h/1440-minute pending TTL, which is how long an unanswered approval waits for the user before it expires). When a T3 command is blocked, the hook persists a pending approval with a semantic signature and hands the `approval_id` to the blocked subagent, which relays it to me through its `agent_contract_handoff` as `plan_status: APPROVAL_REQUEST` — that contract field is how the id reaches me; there is no SessionStart block or shell lookup to derive it from. The user approves it once via AskUserQuestion, which activates the grant, and the grant is **single-use, consumed at the match** — the moment the retried command's signature matches the grant in PreToolUse, before the command executes, not after (`bash_validator` calls `consume_db_semantic_grant` synchronously at that point; a run that reaches match-and-execute-and-fail has already spent the grant and needs a fresh approval, it does not get a second try inside the window). **Approving IS the order to execute**: there is no separate "should I run it now" step — on the Approve label I immediately re-dispatch a fresh agent carrying the verbatim `exact_content` and the needed `mode`. That coupling makes re-dispatch, not a SendMessage resume, the only path for the execute-on-approve action: `mode` does not survive a SendMessage resume, so a resumed agent runs in `default` and re-blocks the very operation the grant just cleared. The grant's session-agnostic matching still means the retry that consumes it can legitimately run under a different session id than the one that was blocked — the block-approve-re-dispatch cycle spans sessions inside the same user-facing turn — but that is an implementation detail of one in-loop approval, not a mechanism for reaching back into a prior session's unresolved pendings. If several distinct mutative operations queue up for one intent, each blocked operation generates its own `approval_id` — N distinct operations produce N approvals; for an explicitly enumerated batch under one consent, use the COMMAND_SET grant mechanism (obtaining that batch's id without a shell is a known open dependency — see `Skill('orchestrator-present-approval')`). Full mechanics and grant lifecycle live in `Skill('orchestrator-present-approval')` and `hooks/modules/security/approval_grants.py`.
 
 ## Response handling
 
@@ -80,13 +80,7 @@ When an agent returns a `agent_contract_handoff`, I load `Skill('agent-response'
 
 **Re-dispatch must carry `exact_content` verbatim.** After an approved T3 — Write or Bash — the new agent does not carry the approved string from the previous turn, and the grant is keyed to the command's **semantic signature**, not to the path or the verb alone. The signature normalizes shell redirects out (`2>&1`, `> file`, `2> file`), so appending or dropping a redirect does NOT change the signature and does NOT re-block. Everything else that changes the operation's identity still produces a different signature and a fresh re-block: a pipe (`| jq`), a `cd` prefix or different `-C <path>` (the working directory binds — directory is intent), a wrapper, a command substitution, or an added/changed flag. Copy the literal string into the new dispatch and instruct the agent to run it. If the effect required more (a different cwd, a wrapping pipeline), request a new approval — do not retrofit it.
 
-**When `[ACTIONABLE] Pending approvals` appear in `additionalContext`,** integrate them into the response before routing the current request — they belong to flows already in motion, and the user cannot act on what they cannot see. Read each pending entry and present it by **what it means**, not by its position in the list. For each, state:
-
-- What the operation does in plain language (e.g. "una consulta a la base de datos de memoria", "un push a la rama main")
-- Which agent or surface emitted it (read `context.source` if present; if absent, infer from `command` and surface routing)
-- Whether the pending is fresh (less than 1 hour old) or stale (older than 1 hour, likely abandoned from a previous thread)
-
-Group fresh and stale into separate paragraphs. For fresh ones, offer to act now: "puedo aprobarlos, ejecutarlos en bundle, o esperar". For stale ones, propose cleanup: "estas tres parecen abandonadas — ¿las descarto?". Do not show the full `[P-xxxx] {truncated_command}` table that the scanner produced; that table is raw signal, not the synthesis the user needs. For the actual approval flow (AskUserQuestion presentation, dispatch templates, mass cleanup), load `Skill('pending-approvals')` — it owns the mechanics; I own the narrative.
+**Pendings do not resurface across turns or sessions.** There is no `[ACTIONABLE]` queue injected at SessionStart and no per-turn feed of previously-seen pendings — approvals are in-loop and single-session, and the only channel that surfaces one to me is the subagent's same-turn `APPROVAL_REQUEST` relay handled above. A pending left unresolved in the session where it was raised is not re-presented later; it only ages toward its 24h pending TTL, and hygiene (`gaia approvals clean`, the grant-expiry sweep) drains it without ever prompting the user to resume it. When the user explicitly asks about pendings — "ver pendientes", "aprobar P-XXXX", "limpia los pendientes" — that is a distinct, user-invoked path: load `Skill('pending-approvals')`, which owns the `gaia approvals` mechanics (show / approve / reject / clean) for it. I do not proactively scan for or curate a backlog on my own initiative.
 
 ## Domain Errors
 
@@ -98,4 +92,4 @@ Group fresh and stale into separate paragraphs. For fresh ones, offer to act now
 | Specialist contradicts itself within or across turns | When the inconsistency is material — affects what the user is about to approve or execute — present the contract verbatim, name the inconsistency I observed (path that does not match the verification, claim that conflicts with a previous turn), and ask whether to re-dispatch or accept. Correcting silently traffics in authority I do not have; presenting as-is without flagging traffics in honesty I owe the user |
 | `mode` lost on a SendMessage resume | Re-dispatch fresh with the needed `mode` and the approved command verbatim; full guidance in Dispatch → Re-dispatch vs SendMessage. |
 | APPROVAL_REQUEST for a T3 without verbatim content | Attach the literal `exact_content` to the re-dispatch; full rule and wrapper anti-patterns in Response handling. |
-| Pending approvals accumulate as noise | Curate by name, do not drain; full procedure in Response handling. |
+| User asks about pendings directly | Load `Skill('pending-approvals')` for the `gaia approvals` mechanics (show/approve/reject/clean); there is no cross-session queue for me to proactively curate. |

package/bin/README.md

@@ -67,7 +67,7 @@ bin/
     ├── history.py             # gaia history    — recent agent sessions
     ├── install.py             # gaia install    — bootstrap DB, settings, symlinks (run manually; no postinstall)
     ├── memory.py              # gaia memory     — episodic memory: stats, search, show
-    ├── metrics.py             # gaia metrics    — usage analytics (tier, agent, anomalies)
+    ├── metrics.py             # gaia metrics    — usage analytics (DB-canonical episodes/anomalies + audit-log tier/commands)
     ├── milestone.py           # gaia milestone  — milestone management for briefs (DB-canonical)
     ├── _pack_helpers.py       # shared `npm pack` primitive for dev/release (private, no register())
     ├── paths.py               # Shared path resolution helpers

package/bin/cli/approvals.py

@@ -1411,114 +1411,6 @@ def cmd_replay(args) -> int:
     return 0 if all_ok else 1
 
 
-# ---------------------------------------------------------------------------
-# derive-id -- reproduce a plan-first COMMAND_SET approval_id from its commands
-# ---------------------------------------------------------------------------
-
-def _read_command_set_input(args) -> list:
-    """Resolve the command list for derive-id from args/stdin.
-
-    Accepts, in order of precedence:
-      1. ``--commands-json '[{"command": "..."}, ...]'`` or a bare list of
-         strings ``["cmd a", "cmd b"]`` -- the command_set as the orchestrator
-         reads it from the contract.
-      2. stdin (when ``--commands-json`` is omitted), same JSON shapes.
-
-    Returns the ordered list of command STRINGS (rationale is irrelevant to the
-    derivation). Raises ValueError on malformed input.
-    """
-    raw = getattr(args, "commands_json", None)
-    if raw is None:
-        raw = sys.stdin.read()
-    raw = (raw or "").strip()
-    if not raw:
-        raise ValueError("no command_set provided (use --commands-json or stdin)")
-
-    parsed = json.loads(raw)
-
-    # Accept either a top-level list, or {"command_set": [...]} / {"commands": [...]}.
-    if isinstance(parsed, dict):
-        parsed = parsed.get("command_set") or parsed.get("commands") or []
-
-    if not isinstance(parsed, list):
-        raise ValueError("command_set must be a JSON array")
-
-    commands: list = []
-    for item in parsed:
-        if isinstance(item, str):
-            if item:
-                commands.append(item)
-        elif isinstance(item, dict) and item.get("command"):
-            commands.append(item["command"])
-    return commands
-
-
-def cmd_derive_id(args) -> int:
-    """Derive the deterministic COMMAND_SET approval_id from its commands.
-
-    This is the orchestrator-side mirror of the intake's mint: given the
-    ``command_set`` the subagent emitted in its contract (no DB search), it
-    reproduces the EXACT ``P-...`` id the SubagentStop intake wrote as the
-    pending row, by applying the SAME mutative filter and the SAME
-    ``derive_command_set_id`` canonicalization the intake uses.
-
-    The mutative filter is shared with the intake
-    (``handoff_persister._filter_mutative_command_set``) so the CLI and the hook
-    operate on the identical post-filter command list. When fewer than 2
-    mutative commands remain, NO COMMAND_SET was minted (the singular path owns
-    it) -- the helper reports that rather than emitting a bogus id.
-
-    Exits 0 on success, 1 on error.
-    """
-    output_json = getattr(args, "json", False)
-    apply_filter = not getattr(args, "no_filter", False)
-
-    try:
-        commands = _read_command_set_input(args)
-    except Exception as exc:
-        _print_error(f"Failed to parse command_set: {exc}", args)
-        return 1
-
-    # Apply the SAME mutative filter the intake uses, so the orchestrator's
-    # derivation operates on the identical post-filter list. Skippable via
-    # --no-filter for callers that already hold the filtered list.
-    if apply_filter:
-        try:
-            from modules.agents.handoff_persister import _filter_mutative_command_set
-            filtered = _filter_mutative_command_set(
-                [{"command": c, "rationale": ""} for c in commands]
-            )
-            commands = [it["command"] for it in filtered]
-        except Exception as exc:
-            _print_error(f"Failed to apply mutative filter: {exc}", args)
-            return 1
-
-    if len(commands) < 2:
-        msg = (
-            f"Not a COMMAND_SET: {len(commands)} mutative command(s) after filter "
-            "(need >= 2). No COMMAND_SET approval was minted -- the singular path "
-            "owns this."
-        )
-        if output_json:
-            print(json.dumps({"approval_id": None, "command_count": len(commands), "reason": msg}))
-        else:
-            _print_error(msg, args)
-        return 1
-
-    try:
-        store = _import_approval_store()
-        approval_id = store.derive_command_set_id(commands)
-    except Exception as exc:
-        _print_error(f"Failed to derive id: {exc}", args)
-        return 1
-
-    if output_json:
-        print(json.dumps({"approval_id": approval_id, "command_count": len(commands)}))
-    else:
-        print(approval_id)
-    return 0
-
-
 # ---------------------------------------------------------------------------
 # Plugin registration (called by bin/gaia dispatcher)
 # ---------------------------------------------------------------------------
@@ -1748,35 +1640,6 @@ def register(subparsers) -> None:
     p_stats.add_argument("--json", action="store_true", help="JSON output")
     p_stats.set_defaults(func=cmd_stats)
 
-    # derive-id -- reproduce a plan-first COMMAND_SET id from its commands
-    p_derive = sub.add_parser(
-        "derive-id",
-        help="Derive the deterministic COMMAND_SET approval_id from its commands",
-        description=(
-            "Reproduce the content-derived approval_id the SubagentStop intake\n"
-            "minted for a plan-first COMMAND_SET, from the command_set in the\n"
-            "contract -- no DB search. Pass the command_set as JSON via\n"
-            "--commands-json or stdin (a list of strings, a list of\n"
-            "{command, rationale} objects, or an object with a command_set/\n"
-            "commands key). Applies the same mutative filter the intake uses."
-        ),
-    )
-    p_derive.add_argument(
-        "--commands-json",
-        dest="commands_json",
-        metavar="JSON",
-        default=None,
-        help="command_set as JSON (omit to read from stdin)",
-    )
-    p_derive.add_argument(
-        "--no-filter",
-        action="store_true",
-        dest="no_filter",
-        help="Skip the mutative filter (input is already the filtered list)",
-    )
-    p_derive.add_argument("--json", action="store_true", help="JSON output")
-    p_derive.set_defaults(func=cmd_derive_id)
-
     p.set_defaults(func=_approvals_default)
 
 
@@ -1808,7 +1671,6 @@ def _approvals_default(args) -> int:
     print("  reject-all [--dry-run]            -- bulk reject (legacy)")
     print("  clean [--dry-run]                 -- remove expired approvals")
     print("  stats                             -- approval system statistics")
-    print("  derive-id --commands-json JSON    -- reproduce a COMMAND_SET id (no DB)")
     print("")
     print("Run 'gaia approvals --help' for more information.")
     return 0
@@ -1892,12 +1754,6 @@ def _build_standalone_parser() -> argparse.ArgumentParser:
     p_stats.add_argument("--json", action="store_true")
     p_stats.set_defaults(func=cmd_stats)
 
-    p_derive = subparsers.add_parser("derive-id", help="Derive a COMMAND_SET approval_id from its commands")
-    p_derive.add_argument("--commands-json", dest="commands_json", metavar="JSON", default=None)
-    p_derive.add_argument("--no-filter", action="store_true", dest="no_filter")
-    p_derive.add_argument("--json", action="store_true")
-    p_derive.set_defaults(func=cmd_derive_id)
-
     return parser
 
 

package/bin/cli/cleanup.py

@@ -74,14 +74,6 @@ RETENTION_POLICY = [
         "max_days": 14,
         "label": "Hook logs",
     },
-    {
-        "key": "monthlyMetrics",
-        "type": "files",
-        "pattern": "metrics-*.jsonl",
-        "dir": ".claude/metrics",
-        "max_days": 90,
-        "label": "Monthly metrics",
-    },
     {
         "key": "responseContract",
         "type": "dirs",
@@ -97,20 +89,6 @@ RETENTION_POLICY = [
         "max_days": 90,
         "label": "Episodic memory episodes",
     },
-    {
-        "key": "workflowMetrics",
-        "type": "truncate-jsonl",
-        "file": ".claude/project-context/workflow-episodic-memory/metrics.jsonl",
-        "max_days": 90,
-        "label": "Workflow metrics",
-    },
-    {
-        "key": "anomalies",
-        "type": "truncate-jsonl",
-        "file": ".claude/project-context/workflow-episodic-memory/anomalies.jsonl",
-        "max_days": 90,
-        "label": "Anomalies",
-    },
     {
         "key": "legacyLogs",
         "type": "legacy",
@@ -731,11 +709,8 @@ def cmd_cleanup(args) -> int:
     retention_policy_info = {
         "audit_logs_days": 30,
         "hook_logs_days": 14,
-        "monthly_metrics_days": 90,
         "response_contracts_days": 7,
         "episodic_episodes_days": 90,
-        "workflow_metrics_days": 90,
-        "anomalies_days": 90,
         "legacy_logs": "all removed",
         "anomaly_flag_hours": 1,
     }
@@ -746,11 +721,8 @@ def cmd_cleanup(args) -> int:
             print("\nRetention policy:")
             print("  Audit logs:          30 days")
             print("  Hook logs:           14 days")
-            print("  Monthly metrics:     90 days")
             print("  Response contracts:   7 days")
             print("  Episodic episodes:   90 days")
-            print("  Workflow metrics:    90 days")
-            print("  Anomalies:           90 days")
             print("  Legacy logs:         all removed")
             print("  Anomaly flag:         1 hour TTL")
             if dry_run:
@@ -842,12 +814,11 @@ def cmd_cleanup(args) -> int:
         if anything_done:
             status = "Cleanup preview complete" if dry_run else "Cleanup completed"
             print(f"\n{status}")
-            print("\nPreserved data:")
+            print("\nDirectories Gaia does not remove (files within them are pruned by retention policy, not deleted outright):")
             print("  .claude/logs/")
             print("  .claude/tests/")
             print("  .claude/project-context/")
             print("  .claude/session/")
-            print("  .claude/metrics/")
         else:
             print("  Nothing to clean up")
         print()