mirror of
https://github.com/alirezarezvani/claude-skills.git
synced 2026-10-06 02:50:08 +00:00
e716c6ada0
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
60 lines
2.2 KiB
Markdown
60 lines
2.2 KiB
Markdown
---
|
|
description: Run only the blocking forgetting gate on a memory design or store — what leaves, and on what rule.
|
|
argument-hint: "[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:
|
|
|
|
```bash
|
|
python skills/memory-engineering/scripts/forgetting_policy_linter.py --policy <policy.json>
|
|
```
|
|
|
|
If given a directory, first show what is actually accumulating, then gate:
|
|
|
|
```bash
|
|
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.
|