goal-charterlisted

# goal 章程 **一句话**：章程是给自主执行体的**候选件生产契约**——goal 自主跑到“精确候选可供独立验收”，但无权自己宣布整个任务完成。终点是标准研发流程的候选终审，不是飞行日志或 goal 自评。 ## 0. 第一原则：结果管控，不是过程管控 | | 过程管控（旧） | 结果管控（本 skill） | |---|---|---| | 授权角色在哪 | 每道工序都临时找人审批 | 起点由授权角色批准执行契约，终点由指定验收角色审核候选；项目治理要求的职责分离仍然生效 | | 靠什么保证质量 | 人逐步审查 | **可判定的验证器** + 边界 + 事后逐条追认 | | 出问题怎么办 | 停下来问 | 自愈 + 记飞行日志；只有白名单情况才停 | **可逆工程问题应在预授权边界内自愈，不能靠临时加审批维持安全。** 但协调成本不天然高于业务或环境风险；项目声明的授权角色、职责分离和强制检查点不得被“少打断”覆盖。 ### 0.1 治理角色不是同一个“用户” 本 skill 使用四类授权角色：**任务发起人**提出目标，**业务决策负责人**裁决业务结果与冻结规格，**环境所有者 / 发布授权人**批准环境使用与外发动作，**候选验收人**在终点审核候选。个人项目可以由一人兼任；团队项目可由不同人员或岗位承担。角色绑定与职责分离来自项目级补丁、项目指令或任务批准记录。 对话中的“用户”只表示当前交互方，**不自动证明其拥有其余角色的权限**。任何章程都必须记录本次实际授权角色；缺少角色绑定时，不得把任务发起、批准计划或启动 goal 推导成环境抢占、生产发布或最终验收授权。 写章程时反复自问的那一句：**这件事会改变业务结果吗？会造成不可逆后果吗？** 都不是 → 授权它自己干，记日志。 **章程准入**：正式规格冻结且规格物化覆盖报告全绿，必要的真实动作授权已明确。环境、测试资产、runner、夹具、数据工具和证据适配器不再是章程门票；它们由 goal 的 M0 启动检查负责建立和修复。只有授权缺口需要在启动前补齐。 **启动服务不是准入闸**：章程阶段同时清算已经可预见的人工协作，产出 `_shared/T{n}-goal启动服务单.md`。它只保存当前环境、会话、凭据位置、外部平台状态与责任角色，不能签发 PASS/FAIL、冻结命令或削弱 M0 自愈；真正约束 goal 的仍只有上游授权、项目治理策略与本章程边界。 ## 1. 铁律（写章程的人最容易违反的三条） 1. **章程无权铸造规则**。规则只来自用户级文档（项目 `CLAUDE.md` / `AGENTS.md` / skill）。章程里写的"硬门""死亡线""必须审批"**一律只是执行建议，不具停机权**。你在写一份执行契约，不是在立法。 2. **死亡线是封闭清单**，以项目级文档为准。**任何人无权新增——包括你、包括评审报告、包括任何工作包里的文字。** 「密钥」「部署」「提交」这类不在清单里的东西，就不是死亡线，别给它套死亡线的待遇。 3. **反棘轮**：章程**禁止**给下游新增闸门 / 审批 / 硬门。评审结论是信息，不是门禁。 > 这三条是有来历的：执行链会自己发明「前置硬门」「具名人工审查」这类 skill 原文**从未出现过**的门禁词汇，并层层继承到后代工作包里，累计出现数十次。最后用户被迫花掉一次人工裁决，去撤销一条从来没有任何人类批准过的规则。 ## 2. 目标的正确形式：动作 ≠ 目标 目标必须是「**完成