BackToCimaCoppi plan-goal：轻量任务流程
一句话：把「调查 → 设计 → 测试设计 → 章程 → goal 执行 → 验收」整条研发流水线压进一份计划文件，保留计划批准与候选验收两个治理检查点；两者可由一人兼任，也可按项目职责分离。
设计 DNA：砍过程、不砍验收。保留防「不可逆风险 / 真值分叉 / 工具机制事实」的规则；废弃「跨会话交接 / 脚本可解析 / 弱模型防呆」类脚手架（SD/TOPIC/哈希对账、总控目录、六要素表格、多套报告模板——它们防的失败模式在单文件单会话形态下不存在）。内核只有三问：选了什么 / 为什么 / 怎么验。
0. 定位与分档
| 档位 | 判据 | 模式 |
|---|---|---|
| 直接做 | 无业务语义决策、无新增测试义务（排版/注释/配置微调） | 计划模式，不出文档 |
| 本档（plan-goal） | 有决策点或测试义务，单会话可完成，未命中升级触发 | 一份全包计划 → 批准 → goal |
| 升级 | 命中任一升级触发 | lightweight-design 或总控 |
升级触发（命中任一就不许硬塞轻量档）：跨 ≥2 域写入 · 不可逆数据迁移 · 钱/权/数据整链路重构 · 阻塞级决策相互耦合无法一次拍板收敛 · 预计跨会话。
- 判据按「碰了什么」，不按改动量——三行 diff 改掉一条优惠券核销规则不是小任务。
- 死亡线局部小改准入本档：计划开场声明强制标记命中；是否加评审由项目治理策略或指定审查角色决定（对齐
lightweight-design§0.1：死亡线局部改造不升档、升评审强度）。
1. 流程
（可选）调查——亲自读，或有界并行派叶子
（可选）方向对齐——和业务决策负责人对齐结果
│
计划模式：按 §2 模板写一份全包计划
│
项目治理或授权角色可触发对抗评审（AI 永不自行加闸）
│
业务决策负责人批准 = 决策点逐条生效 + 计划冻结落盘（一个文件）
│
执行启动服务：清算 PRE_GOAL，按治理策略合并人工协作窗口
│
生成一条 /goal 条件（§4 四段式）
│
goal 自主跑到底：M0 启动检查并修执行基础设施 → 施工 → 测试 → 文档同步 → 钩子 → commit → 追加执行记录
│
CANDIDATE_READY ──→ 指定候选验收人终点验收 ──→ 完成
2. 计划模板（9 节）
简单任务半屏写完；每节都有写「无」的权利，但不许整节省略——省略和「无」是两回事：前者没扫过，后者扫过没命中。
| # | 节 | 最低要求 |
|---|---|---|
| 1 | 目标终态 | 可判定，不写动作写终态；必含「已提交、工作树干净」 |
| 2 | 开场声明 | 五项：命中哪几层文档 / 死亡线命中与否（逐条对照项目封闭清单）/ 涉及哪些域 / 是否跨域 / 目标环境 |
| 3 | 事实基线 | 改造类必填：在真实代码里读到的关键约束（读过才算，列文件名不算）；未验证的假设显式标注 |
| 4 | 决策点清单 | 每个改变业务结果/契约/持久化语义的选择单列一行：选了什么 / 放弃了什么 / 为什么；死亡线命中项单独标记；禁止多项打包成一次总体同意；无则写「无」 |
| 5 | 改动清单 | 文件/模块级，含接口与 DB 变更 |
| 6 | 测试计划 | ① 命中面判定表：逐面写命中/不命中及理由（矩阵沿用 test-standards §2），不许写「暂不需要」；② AC 表，最低列：编号 / 断言（given-when-then 可简写，但两人照着写脚本行为必须一致）/ 取证形态（实测/推导/替身）/ 执行方式（自动化；手工须写例外理由）/ 规格出处 |
| 7 | 文档同步清单 | 要改的 L1-L7 具体文件 + DDL 快照 + 运行资产台账；有长期回归价值的用例列 L7 落点；无则逐层写「不涉及」 |
| 8 | 执行章程 | 固定要素见 §2.1 |
| 9 | 执行记录 | goal 期间追加专用：一行式飞行日志（时间/类别/改了什么/依据）、测试结果、commit SHA、交付证据 |
2.1 第 8 节「执行章程」的固定要素
- 可达性边界：goal 能碰到什么就写什么禁区（环境、目录、凭据），不按动作枚举；启动前扫一遍测试脚本里硬编码的外部端点。
- 预授权不可逆动作显式清单：goal 期间允许的不可逆/外发动作逐条列出（如「允许部署到测试机」「允许 commit」）。清单之外一律停机；推送远端、生产操作永不默认预授权。
- 停机出口白名单（仅三条，同 goal-charter §4，细则以彼处为真值）：① 两份冻结真值存在改变业务结果的矛盾 ② 死亡线业务规则要变 ③ 需要计划未预授权的不可逆/外发动作。凭据定位、实现取舍、测试/runner/环境/证据工具缺陷和重复失败都在同一 goal 自愈，不升级成业务裁决。
- 限轮：必写（轻量档建议 5-15 轮）。
- 有界并行授权：已枚举叶子可并行；禁二级派生、禁为补背景派子执行体。
- 角色与环境治理：记录任务发起人、业务决策负责人、环境所有者/发布授权人、候选验收人及职责分离要求；共享环境必须引用项目占用策略，启动 goal 不构成环境授权或抢占授权。
- 启动服务表：把密钥、登录、第三方后台、真实设备与外部平台事项分为
AI_AUTO / PRE_GOAL / CANDIDATE_DEPENDENT / LONG_LATENCY_EXTERNAL，记录环境、责任角色、凭据受控位置、状态、回滚和planned_human_windows；禁止记录秘密明文。该表无 PASS/FAIL，不冻结命令，不限制 M0。
3. 批准与冻结语义
- 业务决策负责人批准 = 本档的评审等价物。批准即：第 4 节决策点逐条生效（等价 DEC）、计划取得冻结件资格——对齐
doc-layer-system§2.3 goal 执行态例外的三前提：施工前冻结 ✓ / goal 之外产出且经相应授权角色逐条批准 ✓ / 第 9 节承担飞行日志 ✓。 - 批准后计划文件分区：§1-§8 冻结——改动决策点或 AC 表必须显式声明并重新获业务决策负责人批准，禁止静默改写；§9 追加专用——goal 期间只许 append。
- 「计划赢」的边界：goal 中遇「计划 ↔ 代码/现实」不一致，计划明写的语义按计划改、不停机；计划未覆盖但可由正式真值唯一推出的内容在 goal 内对齐；只有两份冻结真值形成改变业务结果的矛盾才进入停机白名单。不许拿冻结件资格给计划没写的东西背书。
- 断言不许削弱：AC 表批准后即是裁判席；施工中改测试脚本前先问一句——改完更接近 AC 表 = 忠实化 ✅；更接近代码 = 作弊 ❌。
- 批准后、建 goal 前清算：
AI_AUTO留给 goal；PRE_GOAL当场完成，只有对应责任角色明确批准延期才转人工里程碑；CANDIDATE_DEPENDENT在不违反职责分离的前提下合并人工协作窗口；LONG_LATENCY_EXTERNAL升为上游任务。不设通用固定窗口次数，每个不可合并窗口必须写明客观原因与责任角色。
4. /goal 交接
机制事实全部继承 goal-charter §13（那是工具机制不是流程仪式），照着用，别凭印象：
/goal <完成条件>只有一个参数、上限 4000 字符 → 条件指针化指向计划文件，不复制计划内容。条件 = 启动物，只有一条，不另发启动提示词。- evaluator 不跑命令不读文件，只看对话 → 每条终态必须带举证义务（「
git status --porcelain输出已贴出且为空」而非「工作树干净」）。 - 停机出口必须写进完成条件才生效：漏写哪个，哪个形同虚设。
- 无人值守必须叠 auto mode；
/goal clear停。
条件模板（四段）：
/goal 执行 {计划文件路径}。首次启动、--resume、新会话或自动上下文压缩后，第一次写入前从磁盘重读计划全文（唯一执行契约）、当前 goal 断点与执行记录尾部；背景自己亲自补读，
不派子 agent 调查。按计划自主跑到底，中途不汇报。
完成条件：{计划 §1 终态逐条，每条带「输出已贴出」举证}；执行记录（§9）已追加完整；
终态报出 CANDIDATE_READY。
约束：{计划 §8 章程里最致命的 3-6 条压缩转述}。
出口（命中任一并已在对话写明出口编号与现状，即视为条件满足）：计划 §8 停机白名单三条 /
SPEC_STALE 停机出修改方案 / 已跑满 {N} 轮并交付 EXECUTION_BLOCKED。
5. 执行期纪律
- 测试五件本质（本档不可砍的全部测试义务）：命中面判定 / 断言可对账 / 断言先于代码冻结且不许削弱 / 写链路必验 DB 终态 / 失败分类 + 取证形态不升格（替身绿只证明代码路径被走到，不证明功能对用户可用）。
- 与测试链的边界：读
test-standards§2 命中面矩阵判义务；不走test-case-design的冻结管线（spec_hash / assertion_index / 两阶段冻结）——AC 表即本档的冻结载体。该管线原文只对中大任务强制，无冲突。 - 失败分类沿用
test-execution-router；产品、测试资产/runner/夹具/环境与证据工具缺陷均在同一 goal 自愈并按影响面重跑；SPEC_STALE（AC 表本身错了）→ 停机附修改方案（改哪些计划节/AC、影响面、恢复点），业务决策负责人按项目治理批准后改好计划、断点续跑同一 goal；只有计划骨架不成立时才终止 goal 重批整份计划。两条路都不许在执行中就地改断言。 - 执行记录（§9）随做随记，一行一条，不写小作文。
6. 收尾与验收
- 项目钩子照常跑（如项目自带的变更后检查 / 交接前检查脚本）；文档同步清单（第 7 节）逐项完成，不许「回头再补」；commit 按项目提交规范（跨域前缀等照常）。
- goal 终态只能是
CANDIDATE_READY——goal 无权宣布任务完成。执行记录里备齐：commit SHA、工作树干净证据、测试结果、已知豁免。 - 指定候选验收人完成终点验收后任务才算完成。验收材料就是计划文件本身：§1 终态 vs §9 执行记录，一屏对完；若项目要求施工与验收职责分离，必须由不同角色执行。
7. 反棘轮与项目注入
- 反棘轮：禁止执行体自行加闸门、加审批、加必跑评审；项目治理预先声明的强制检查点与职责分离不属于棘轮。给本 skill 新增规则必须经流程治理负责人裁决。事故后的正确动作是「审计 → 授权角色拍板 → 靶向修」，不是往模板里塞新必填节。
- 项目注入：本 skill 不复制任何项目规则。治理角色、职责分离、共享环境占用策略、死亡线清单、域边界、钩子命令、承重不变量由项目级 skill 运行时注入（项目强制加载的 skill 照常加载，本档不豁免）。
- 计划落盘路径由项目补丁声明（见
templates/项目级补丁模板/）；无项目约定时落仓库文档过程区，由文档所有者确认路径。