claude-skills/engineering/memory-engineering/commands/cs-forgetting-audit.md
Claude e716c6ada0
fix(memory-engineering): use plugin-root-relative paths in command files
CI gate G1 (scripts/check_paths.py) failed with 8 unresolvable references.

Both command files referenced `scripts/<tool>.py` and `assets/<file>` as if
they were relative to the command file, but commands/ sits at the plugin root
while the scripts live under skills/memory-engineering/. SKILL.md was correct
already — it sits inside the skill directory, so its bare `scripts/...` paths
resolve — which is why this only showed up in the two command files.

Rewritten to the plugin-root-relative form
(`skills/memory-engineering/scripts/...`), matching how agent-harness writes
its command paths.

check_paths.py --all now reports 0 findings across 586 files. Also re-ran the
other five blocking gates locally: check_plugin_json, check_dual_publish,
smoke_scripts, smoke_json_output, derive_counters --check — all pass, plus
compileall on the plugin.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jt1sqt5kQmopyfXu2Hhjnv
2026-08-09 04:31:15 +00:00

2.2 KiB

description argument-hint
Run only the blocking forgetting gate on a memory design or store — what leaves, and on what rule. [policy JSON, or a memory directory to audit]

/cs:forgetting-audit

The short pass. Skip the cost and architecture work; answer one question about $ARGUMENTS:

What leaves this store, and on what rule?

Run

If given a policy JSON:

python skills/memory-engineering/scripts/forgetting_policy_linter.py --policy <policy.json>

If given a directory, first show what is actually accumulating, then gate:

python skills/memory-engineering/scripts/memory_density_auditor.py --dir <path>
python skills/memory-engineering/scripts/forgetting_policy_linter.py --policy <policy.json>

If no policy file exists, that is the answer — nothing leaves the store. Show what --sample-failing blocks, then help write one from skills/memory-engineering/assets/forgetting_policy_template.md.

The two blocking checks

  • F1 — an explicit forgetting rule (TTL, capacity bound with a stated eviction order, or relevance decay). None of the memory systems in the Stanford evaluation prunes or forgets by default: if it was not built, it does not exist.
  • F4 — contradictions surfaced, never auto-merged. newest_wins, auto_merge, overwrite and last_write_wins all fail. Two memories that disagree may both have been true in different contexts, and silently resolving them destroys the only evidence the conflict existed.

The other six checks (dedup, consolidation, scope, audit trail, rollback, growth-slope monitoring) degrade the verdict to CONDITIONAL rather than failing it.

Report

  1. Verdict — PASS (0) / CONDITIONAL (2) / FAIL (4)
  2. Every failing check with its ID, why it matters, and its fix
  3. The one thing to fix first — F1 or F4 if either failed; otherwise the highest-leverage warning

Do not

  • Do not soften a FAIL into a suggestion. Retrofitting forgetting onto a full store is a data migration with a judgment call attached to every record — which is exactly why it never happens.
  • Do not accept "we will add pruning later." Later is the failure mode.
  • Do not propose auto-resolution for contradictions, in any form.