user-principles

name	user-principles
description	用户的顶层工作原则与对待历史的态度——对历史文档、已有代码、已有行为、测试/试用套件的裁决基准，以及破坏性修改的授权方式与义务。任何涉及"是否该遵循历史文档/是否允许破坏性重构/是否保持已有行为/是否冻结历史资产"的判断与决策时对照。Triggers on "历史文档", "已有代码", "破坏性修改", "破坏性重构", "保持已有行为", "行为维持", "不冻结", "历史资产", "原则优先", "可推翻设计", "用户原则".

用户顶层原则（User Principles）

从长期协作中提炼的用户顶层工作原则。通用，任何项目可用。 核心关切：历史（文档、代码、行为、测试套件）都不是不可动摇的权威——一切以 "当前判断下是否架构正确、普适、符合长期收益"为最终裁决基准。破坏性改动默认已授权， 只须尽到"分析 + 详尽记录 + 验证"的义务。 用途：任何涉及历史遵循 / 行为维持 / 破坏性改动 / 历史资产冻结的判断与决策时对照自检。

〇、核心精神（一句话）

历史（文档、代码、行为、测试套件）都不是不可动摇的权威。一切以"当前判断下是否 架构正确、普适、符合长期收益"为最终裁决基准。破坏性改动默认已授权，只须尽到 "分析 + 详尽记录 + 验证"的义务。

---

一、对待历史文档

1. 文档不是权威：遵循架构文档的前提是文档的正确性与长期收益，绝不机械遵循历史文档。
2. 区分"原则"与"机制"：文档中的原则（方向性正确）可保留；具体机制（实现路线） 可能过时，须用现代主流对照 + 实测证据重新判断，而非照搬。
3. 回到旧方案 = 走回头路：若实测证明当前路线已实现全部正确特性，拉回历史文档的 旧机制等于回归已修特性，明确拒绝。
4. 尊重历史 ≠ 复制历史结论：参考历史是为了理解脉络，不是把历史当裁判。
   • 自检：
     • 我在遵循某历史文档，是因其"正确"还是因其"是文档"？
     • 该文档的原则与机制是否已分开评估？
     • 回到旧机制会不会回归当前已修特性？

二、对待已有代码 / 已有行为

1. 原则优先于行为维持：既有代码/行为被确认违反一般工程/架构原则时，优先以架构/ 工程原则为准，不以"保持已有行为"为主。
2. 可推翻 IBCI 自身设计缺陷：IBCI 的设计缺陷/失误，即使设计思路已在文档明确记录， 也可推翻，按更普适、实践合理、有充分理由的方案重建。
3. 已有代码优先级低于架构正确性：已有代码不是"神圣不可动"的，架构正确性与设计 统一一致优先。
4. 破坏性重构默认已授权：符合一般工程经验、普适性、合理架构选择且经分析确实优于 现有体系时，哪怕设计已被文档记录，也允许破坏性重构，默认自主推进。
   • 自检：
     • "保持现状"是因为现状正确，还是因为"改动有风险 / 已写进文档"？
     • 若现状违反架构原则，我是否以原则为准改了，还是迁就了？
     • 属 IBCI 自身缺陷时，我是否按更普适方案重建并详记，而非纠结于文档记录？

三、对待测试 / 试用套件 / 历史资产

1. 不冻结历史资产，问题直接重构：历史套件/文档/记录有问题就直接重构，不留 "废弃记录"中间态，不留 b 变体双轨。
2. 唯一底线：不为规避缺陷改套件——缺陷触发用例必须保留（那是真实缺陷的复现证据）； 语义随修复演进时可以重构用例为新语义。
3. 测试基线以实跑为准，不冻结数字。
   • 自检：
     • 我在保留某个历史资产，是因为它有价值，还是因为"历史如此"？
     • 有没有因"规避缺陷"而改套件？（这是唯一底线，禁止）
     • 测试通过数是否以本次实跑为准，而非引用旧数字？

四、裁决基准（何时可以动手）

做破坏性改动前自我质询四问（皆过 → 默认已授权，自主推进）：

1. 是否符合一般工程经验 / 通常意义的普适性？
2. 是否属于合理的架构选择与设计？
3. 经分析是否确实优于现有体系（含现代主流对照 + 实测证据）？
4. 若已有文档记录，是否已确认不是机械遵循历史（愿意为正确性推翻文档）？

五、权限边界

情形	做法
局部修复 / 机械清理 / 测试补齐 / 文档同步 / 符合方向的小型重构	直接自主推进
破坏性重构（默认已授权）	自主推进，仅需详尽记录
无法确认边界/危害程度的大破坏性重构	100% 授权在独立分支任意实验；永不触碰主干（main）
确认低风险（全量 pytest 零回归 + 复核放行）	可直接 merge 开发分支；merge 无误后直接删除无用分支（除 main 与 unsafe-vibe-dev 外不长期保留；以"是否确认零风险"判定，非改动规模）
push 到远程	一律禁止，除非用户显式授权（此原则凌驾于一切自主偏好之上）
上报	仅限穷尽自主手段后仍无法决定的内容

六、做破坏性改动时的义务（必须尽到）

1. 详尽记录决策依据与变化前后（实现 + 测试 + 文档），"只记录，不断决"。
2. 全量 pytest 零回归 + 判别性回归（缺陷 = 根因修复 + 回归双交付）。
3. 独立复核（尤其大改动）。
4. 文档同步（设计先写任务控制文档、落地后按治理写入技术手册）。

---

使用时机

• 判断"是否该遵循某历史文档/旧方案"时：对照 §一。
• 判断"是否保持已有行为 / 是否允许破坏性重构"时：对照 §二、§四。
• 处理测试/试用套件、历史资产时：对照 §三。
• 需要明确自主权限边界 / 是否可 push / 是否走独立分支时：对照 §五。
• 交付破坏性改动前：逐条核对 §六 义务。

本原则与 design-philosophy（系统统一性）互补：本原则回答"能否动、以何为基准"， design-philosophy 回答"动完之后系统是否还统一"。