Correct

Own recurring failure prevention: connect actual mistakes to a repair that prevents the same failure mechanism. Use Engineering Principles for design decisions and enforcement selection, and the shared guard proof for historical rejection and repaired-path success.

Establish the evidence

Honor the requested repository, area, history window, and finish line. A request for a plan ends with a supported plan; a request to fix recurring mistakes includes implementation and verification within that scope.

Start with the supplied examples. Otherwise choose and report a bounded recent history window, then inspect commits, reverts, substantive review feedback, and instructions or comments that explain past failures. Follow promising records to their actual diffs. When conversations could explain a correction, use scoped T3 thread search/read or available local session logs. Report searched sources, coverage limits, and unavailable records; bounded search is not exhaustive recall.

Group examples by failure mechanism. Count separate occurrences, not several records of one incident. Cite at least two occurrences before calling a class recurring. Keep single incidents and suspected risks distinct. Check current code and enforcement: an old mistake that is already prevented is evidence of a resolved class, not a reason to rebuild its guard.

Rank the live classes by observed frequency, impact, and current exposure. Keep observed facts separate from inferred causes. Finish this step with cited examples, a current path that still permits each failure, and the limits of the search. If no recurring class is supported, say so rather than inventing one.

Choose and test the repair

For each class worth addressing, identify the invariant and its owner. Apply Encode Lessons in Structure and explain why a higher-level repair would not help or would cost too much.

Resolve technical uncertainty with focused architecture experiments. Use the experiment evidence to decide routine technical questions within the requested scope.

Return a prioritized plan connecting each class to:

• Its occurrences, frequency, impact, and current exposure.
• The invariant, owner, proposed repair, and enforcement mechanism.
• The historical failing case and repaired path that will prove the guard.
• Experiment results, tradeoffs, affected callers, migration steps, and checks.

Label proposed proof separately from checks already run. Include reproduction commands and artifact paths for experiments, and name unresolved facts with the next check that would settle them. Keep the plan in chat unless the user or project requests another destination. No permanent rule table is required.

Implement within the requested finish line

For a planning request, hand back the evidence and recommendation for review. For an authorized repair, migrate the affected callers and examples, implement the guard, and prove historical rejection and repaired-path success using the shared guidance. Verify legitimate supported paths too; narrowing the accepted behavior to hide the failure is not prevention.

Use orchestration for bounded assignments and review-fix-loop for behavior or procedure changes. Use verify when the repair changes a user workflow. Requested stacked delivery uses gh-stack; explicitly requested goal or swarm execution uses goal-swarm. The requested finish line governs PR publication and merging.

Report each class as planned, prevented, partly covered, resolved already, or deferred, with its evidence, checks, and remaining exposure. Planning is complete when the recommendations have traceable evidence and a usable migration/proof plan. Implementation is complete when the selected repairs and checks pass, required review is settled, and remaining classes have explicit dispositions.