| name | user-principles |
| description | 用户的顶层工作原则与对待历史的态度——对历史文档、已有代码、已有行为、测试/试用套件的裁决基准，以及破坏性修改的授权方式与义务。任何涉及"是否该遵循历史文档/是否允许破坏性重构/是否保持已有行为/是否冻结历史资产"的判断与决策时对照。Triggers on "历史文档", "已有代码", "破坏性修改", "破坏性重构", "保持已有行为", "行为维持", "不冻结", "历史资产", "原则优先", "可推翻设计", "用户原则". |
用户顶层原则（User Principles）
从长期协作中提炼的用户顶层工作原则。通用，任何项目可用。
核心关切：历史（文档、代码、行为、测试套件）都不是不可动摇的权威——一切以
"当前判断下是否架构正确、普适、符合长期收益"为最终裁决基准。破坏性改动默认已授权，
只须尽到"分析 + 详尽记录 + 验证"的义务。
用途：任何涉及历史遵循 / 行为维持 / 破坏性改动 / 历史资产冻结的判断与决策时对照自检。
〇、核心精神（一句话）
历史（文档、代码、行为、测试套件）都不是不可动摇的权威。一切以"当前判断下是否
架构正确、普适、符合长期收益"为最终裁决基准。破坏性改动默认已授权，只须尽到
"分析 + 详尽记录 + 验证"的义务。
一、对待历史文档
- 文档不是权威：遵循架构文档的前提是文档的正确性与长期收益，绝不机械遵循历史文档。
- 区分"原则"与"机制"：文档中的原则（方向性正确）可保留；具体机制（实现路线）
可能过时，须用现代主流对照 + 实测证据重新判断，而非照搬。
- 回到旧方案 = 走回头路：若实测证明当前路线已实现全部正确特性，拉回历史文档的
旧机制等于回归已修特性，明确拒绝。
- 尊重历史 ≠ 复制历史结论：参考历史是为了理解脉络，不是把历史当裁判。
- 自检：
- 我在遵循某历史文档，是因其"正确"还是因其"是文档"？
- 该文档的原则与机制是否已分开评估？
- 回到旧机制会不会回归当前已修特性？
二、对待已有代码 / 已有行为
- 原则优先于行为维持：既有代码/行为被确认违反一般工程/架构原则时，优先以架构/
工程原则为准，不以"保持已有行为"为主。
- 可推翻 IBCI 自身设计缺陷：IBCI 的设计缺陷/失误，即使设计思路已在文档明确记录，
也可推翻，按更普适、实践合理、有充分理由的方案重建。
- 已有代码优先级低于架构正确性：已有代码不是"神圣不可动"的，架构正确性与设计
统一一致优先。
- 破坏性重构默认已授权：符合一般工程经验、普适性、合理架构选择且经分析确实优于
现有体系时，哪怕设计已被文档记录，也允许破坏性重构，默认自主推进。
- 自检：
- "保持现状"是因为现状正确，还是因为"改动有风险 / 已写进文档"？
- 若现状违反架构原则，我是否以原则为准改了，还是迁就了？
- 属 IBCI 自身缺陷时，我是否按更普适方案重建并详记，而非纠结于文档记录？
三、对待测试 / 试用套件 / 历史资产
- 不冻结历史资产，问题直接重构：历史套件/文档/记录有问题就直接重构，不留
"废弃记录"中间态，不留 b 变体双轨。
- 唯一底线：不为规避缺陷改套件——缺陷触发用例必须保留（那是真实缺陷的复现证据）；
语义随修复演进时可以重构用例为新语义。
- 测试基线以实跑为准，不冻结数字。
- 自检：
- 我在保留某个历史资产，是因为它有价值，还是因为"历史如此"？
- 有没有因"规避缺陷"而改套件？（这是唯一底线，禁止）
- 测试通过数是否以本次实跑为准，而非引用旧数字？
四、裁决基准（何时可以动手）
做破坏性改动前自我质询四问（皆过 → 默认已授权，自主推进）：
- 是否符合一般工程经验 / 通常意义的普适性？
- 是否属于合理的架构选择与设计？
- 经分析是否确实优于现有体系（含现代主流对照 + 实测证据）？
- 若已有文档记录，是否已确认不是机械遵循历史（愿意为正确性推翻文档）？
五、权限边界
| 情形 | 做法 |
|---|
| 局部修复 / 机械清理 / 测试补齐 / 文档同步 / 符合方向的小型重构 | 直接自主推进 |
| 破坏性重构（默认已授权） | 自主推进，仅需详尽记录 |
| 无法确认边界/危害程度的大破坏性重构 | 100% 授权在独立分支任意实验；永不触碰主干（main） |
| 确认低风险（全量 pytest 零回归 + 复核放行） | 可直接 merge 开发分支；merge 无误后直接删除无用分支（除 main 与 unsafe-vibe-dev 外不长期保留；以"是否确认零风险"判定，非改动规模） |
| push 到远程 | 一律禁止，除非用户显式授权（此原则凌驾于一切自主偏好之上） |
| 上报 | 仅限穷尽自主手段后仍无法决定的内容 |
六、做破坏性改动时的义务（必须尽到）
- 详尽记录决策依据与变化前后（实现 + 测试 + 文档），"只记录，不断决"。
- 全量 pytest 零回归 + 判别性回归（缺陷 = 根因修复 + 回归双交付）。
- 独立复核（尤其大改动）。
- 文档同步（设计先写任务控制文档、落地后按治理写入技术手册）。
使用时机
- 判断"是否该遵循某历史文档/旧方案"时：对照 §一。
- 判断"是否保持已有行为 / 是否允许破坏性重构"时：对照 §二、§四。
- 处理测试/试用套件、历史资产时：对照 §三。
- 需要明确自主权限边界 / 是否可 push / 是否走独立分支时：对照 §五。
- 交付破坏性改动前：逐条核对 §六 义务。
本原则与 design-philosophy（系统统一性）互补：本原则回答"能否动、以何为基准"，
design-philosophy 回答"动完之后系统是否还统一"。
