| --- | |
| name: the-beaver | |
| description: Analyze repeated, human-approved lessons and draft the smallest structural repair that could prevent recurrence. Use when an agentic system keeps rediscovering the same failure, memory is accumulating without behavior changing, or a lesson may need to graduate into a hook, default, skill, template, or code path. Remain advisory unless accepted authority explicitly permits implementation. | |
| --- | |
| # The Beaver | |
| ## Constraint | |
| A stored lesson is not an improvement. If the same failure returns, the system has memory, but the dam still leaks. | |
| ## Boundary | |
| Work only from human-approved, provenance-backed lessons and current source. Treat semantic similarity as a lead, not proof of recurrence. | |
| A human may waive the recurrence threshold on severity. One instance plus an explicit human call is sufficient authority for a proposal, never for automatic promotion. | |
| Do not create new authority, promote a proposal, mutate production, or close a claim merely because a repair was suggested. If the system has no accepted rules for failure-class identity, recurrence thresholds, evidence anchors, subsumption, or the observation window, stop at a repair proposal and name the missing contract. | |
| ## Loop | |
| 1. Collect the branch. Read the approved lesson, its evidence anchors, and its provenance. | |
| 2. Confirm the leak. Find independent instances of the same failure class using the system's accepted deterministic key. Do not infer recurrence from wording alone. | |
| 3. Find the owner. Read the hook, default, skill, template, or code path that currently produces the behavior. | |
| 4. Shape the repair. Propose the smallest change that could prevent the failure upstream. Reuse or amend the existing owner before adding a new layer. | |
| 5. Keep the human gate. Present the evidence, proposed repair, denial behavior, and proof plan for approval. Never promote automatically. | |
| 6. Prove the structure. Drive the repaired surface live and test the dangerous denial case. A landed change is not yet evidence that recurrence stopped. | |
| 7. Watch for silence. Observe the accepted window. Only then report that the repair holds and let the lesson be subsumed by the structure that now carries it. | |
| 8. Reopen on return. If the same failure class appears after subsumption, reopen the proposal. The failed repair is now evidence. Repair v2 starts from what v1 missed, never from scratch. | |
| ## Output | |
| Return: | |
| - Constraint: the repeated failure in plain language. | |
| - Recurrence evidence: independent, source-linked instances. | |
| - Existing owner: the narrowest surface that should absorb the lesson. | |
| - Smallest repair: the bounded structural change. | |
| - Dangerous denial: what must still fail closed. | |
| - Human decision: approve, edit, dismiss, or request more evidence. | |
| - Proof window: how recurrence will be checked after the change. | |
| - Status: candidate, proposed, landed, observed, dismissed, or reopened. | |
| - Retires: the memory-only path or repeated workaround this repair makes unnecessary. | |
| ## Standard | |
| Do not call a system self-improving because it stored more memory. | |
| Call the repair proven only when the structure changed and the same mistake stopped recurring. |