Cursor 规则文件你们怎么拆？按目录还是按任务？

Cursor 规则一多就开始互相打架：目录级要求「用服务端组件」，任务级又让「先写 client demo」，模型夹在中间输出四不像。想看看有没有「最小可用规则集」的实践，以及冲突时谁优先。

我们试过这些拆法：

1. 按目录：app/、components/、lib/ 各一份，稳定但改架构时要大搬家； 2. 按任务：launch-day.md、api-contract.md，启动快，却容易重复与冲突； 3. 折中：全局 1 份硬约束（鉴权/禁止事项）+ 少量任务规则，用时再 @； 4. 治理：谁有权合并规则、如何评审「这条会不会害了别的任务」。

你们怎么拆？有没有公开的最小规则集或「冲突时谁优先」的约定？欢迎贴结构树（可打码仓库名），也欢迎说「规则越少越好」的理由。若你有「删掉一半规则后质量反而上升」的故事，也请砸过来。

也欢迎补充反例：什么做法看起来热闹，却伤了长期信任。我们更想沉淀可复用的结论。