| name | lite |
| description | 不动产品定义的局部改动:无需 brief / demo / definition 任何前置输入与设计,直接 TDD 式实现并由 harness 自动验收(先红后绿、证据留痕)。改动复杂度看起来超出判定时仅提醒确认、不强制拦截,用户确认后仍可走 lite。 |
| license | MIT |
lite
和 build 同一套裁决纪律,只是没有前置文档:契约就是"这一个改动本身"。
判定与提醒
不动产品定义(不改 PD / TD / AC 语义)的改动走 lite。若发现改动实际会改变产品语义、
领域边界或长期技术约束,提醒一次并给出理由,建议走 design → build;
用户确认后仍可继续 lite,不强制拦截——但收尾时如实标注该风险。
永远不按预计工时判定。
做法(TDD 验收)
- 先为目标行为写出会失败的测试(bug 修复先复现失败),确认 RED 再实现。
- 行为已被既有 AC 覆盖时直接复用已锁的 Case,不新写第二份口径;
纯文案 / 静态样式 / 文档 / 注释等无运行时语义的改动,用对应的静态或
轻量真实入口 before/after 检查,不跑整条旅程。
- 转绿后跑受影响范围的回归(棘轮:已绿的不许变红);触碰主链路时补跑 Core-Case。
- 收尾交付:diff、命令与退出码、before/after 证据;止步于哪一级验证,直说。
边界
- 不产生任何 feature 工件(brief / definition / 计划 / 报告),不派子代理。
- 不许悄悄修改已定案的 Oracle——需要改就是在动产品定义,回
design。
- 破坏性 / 生产 / 权限 / 不可逆操作仍需人类显式批准。
产出
已验收的改动 + 简洁证据。