Procedure maintenance: score, compact, and prune reusable skills

[joshyorko]

Outcome

Add score-based maintenance for procedures so the store stays compact and high-quality as more experiences arrive.

Why

ProcMEM emphasizes reusable skills with verification and score-based maintenance. codex-memoryd has procedures and lifecycle issues, but it also needs compactness pressure so repeated or low-value procedures do not accumulate endlessly.

Scope

• Track per-procedure success, failure, reuse count, last_used_at, evidence_count, and confidence trend.
• Add maintenance rules for merge, split, retire, quarantine, or promote.
• Add compaction preview that proposes procedure changes with evidence refs.
• Add negative examples and failed reuse as counter-evidence.
• Add eval metrics for compactness, reuse rate, false activation, and utility versus neutral recall.

Acceptance

• Procedure maintenance preview emits deterministic candidate actions.
• Low-score or duplicate procedures can be retired or merged through review.
• Useful procedures become easier to recall without becoming authority.
• Evals report procedure compactness and reuse quality.
• Existing tests stay green.

Non-goals

• No autonomous procedure execution.
• No hidden prompt mutation.
• No model-only maintenance without evidence refs.

[joshyorko]

September 8 scope refinement: useful procedures, not self-reinforcing popularity

Keep the existing procedure/maintenance preview and explicit apply contract. Do not build a generic self-modifying skill engine or make a retrieved procedure executable authority.

Add these edge cases to the current acceptance before promotion/retirement automation:

• A procedure being recalled, suggested, copied into a summary, or marked useful by the same generating model is not successful execution evidence.
• Separate exposure, attempted use, independently verified outcome, failure/counterexample, and human review. Repeated use is selection-biased; don't inflate confidence from exposure counts.
• Bind applicability to known repo/project, runtime/tool version, architecture and preconditions where supported. An old successful command can be wrong after an upgrade; absent environment evidence means unknown applicability.
• Attach negative outcomes to the exact procedure version and environment. One transient network failure is not proof the procedure is wrong; a genuine counterexample must not be overwritten by later popularity.
• A proposed merge/split preserves supporting and contradicting sources and invalidates stale preview plans when inputs change.
• Retire/quarantine/supersede remain reversible where their retention policy permits; erasure is distinct and follows feat(memory): make corrections and forgetting survive derived views, replay and import #234.
• No model-authored procedure acquires shell, secret, repository-write or live-execution permission through consolidation.

Measure a bounded procedure pack against the same tasks without it: avoided repeated investigation, correctness, misleading recall, context cost and successful verification. Do not optimize only compactness or number of stored skills. Keep zero-model deterministic inspection/preview useful.

Coordinate #228/#233 for producer lineage, #231 for case-sensitive command identity, #234 for withdrawal propagation. Large autonomous procedural maintenance remains later work; first land the explicit version/applicability/outcome ledger and preview tests that the actual current store can support.