一句话

挖出 agent 在这个仓库反复犯的同类错误，在结构、类型、lint、测试里挑最高的一级把每类错变成不可能，文档只兜底。

何时用

• 适合：你已经在 chat 里纠正同一类错误两次以上；想让仓库本身挡住下一次。
• 不适合：只发生一次的失误；想改的是技能而不是仓库（那是 pstack-reflect）。

怎么用

/correct agents 老是绕过 repository 层直接调数据库客户端

1. 读最近 commits、reverts、review 评论、agent 指令文件和解释 workaround 的注释，把错误归成类；出现两次才算一类。
2. 按层级修：先架构消灭（单一 owner、唯一正道、删旧写法），再类型和 lint（报错信息里点名正确用法），再测试，文档放最后。
3. 最频繁的几类立即修，一类一个 commit；每个新检查必须在一次真实历史错误上失败过才算数。
4. 在 agent 指令文件里维护「规则-强制手段」对照表；规则已有但无强制就是复发，同级再修。

产出

• 若干修复 commit 加指令文件里的规则对照表；回复列出每类错误、证据、所选层级及更高层不行的原因。

要点与坑

• 假设每个贡献者都是只看了几个文件的 agent：让「从一个文件看是对的改动」对整个仓库也对。
• 例外要写在出错行上，带理由、过期日和人工批准。
• 是 pstack-原则集 的全仓库应用；方法本身与宿主无关。

关联

• 同类：pstack-reflect、addy-constraint-driven-development · 原理：pstack-原则集
• 所属：00-pstack-概览 · 工作流：W7-交付与运维循环