goal-charter

goal 章程

一句话：章程是给自主执行体的候选件生产契约——goal 自主跑到“精确候选可供独立验收”，但无权自己宣布整个任务完成。终点是标准研发流程的候选终审，不是飞行日志或 goal 自评。

0. 第一原则：结果管控，不是过程管控

	过程管控（旧）	结果管控（本 skill）
授权角色在哪	每道工序都临时找人审批	起点由授权角色批准执行契约，终点由指定验收角色审核候选；项目治理要求的职责分离仍然生效
靠什么保证质量	人逐步审查	可判定的验证器 + 边界 + 事后逐条追认
出问题怎么办	停下来问	自愈 + 记飞行日志；只有白名单情况才停

可逆工程问题应在预授权边界内自愈，不能靠临时加审批维持安全。 但协调成本不天然高于业务或环境风险；项目声明的授权角色、职责分离和强制检查点不得被“少打断”覆盖。

0.1 治理角色不是同一个“用户”

本 skill 使用四类授权角色：任务发起人提出目标，业务决策负责人裁决业务结果与冻结规格，环境所有者 / 发布授权人批准环境使用与外发动作，候选验收人在终点审核候选。个人项目可以由一人兼任；团队项目可由不同人员或岗位承担。角色绑定与职责分离来自项目级补丁、项目指令或任务批准记录。

对话中的“用户”只表示当前交互方，不自动证明其拥有其余角色的权限。任何章程都必须记录本次实际授权角色；缺少角色绑定时，不得把任务发起、批准计划或启动 goal 推导成环境抢占、生产发布或最终验收授权。

写章程时反复自问的那一句：这件事会改变业务结果吗？会造成不可逆后果吗？ 都不是 → 授权它自己干，记日志。

章程准入：正式规格冻结且规格物化覆盖报告全绿，必要的真实动作授权已明确。环境、测试资产、runner、夹具、数据工具和证据适配器不再是章程门票；它们由 goal 的 M0 启动检查负责建立和修复。只有授权缺口需要在启动前补齐。

启动服务不是准入闸：章程阶段同时清算已经可预见的人工协作，产出 _shared/T{n}-goal启动服务单.md。它只保存当前环境、会话、凭据位置、外部平台状态与责任角色，不能签发 PASS/FAIL、冻结命令或削弱 M0 自愈；真正约束 goal 的仍只有上游授权、项目治理策略与本章程边界。

项目绑定：编写章程前按 task-control-doc/references/标准研发流程.md §6.1 解析当前项目唯一完整的项目研发流程适配器。此时只读能力、权威来源和不支持项，不申请环境或租约。执行段启动后才读取实际占用。适配器不能替代业务、环境或发布授权。

目标环境必须由具权角色选择：继承本任务已有的环境选择原话和授权锚点；尚未选择时列出项目实际支持的环境、能力差异与推荐，请环境所有者或发布授权人选定后再定稿。章程作者不得默认沙盒、测试或生产，也不得用整份章程获批倒推环境选择。

1. 铁律（写章程的人最容易违反的三条）

1. 章程无权铸造规则。规则只来自用户级文档（项目 AGENTS.md / skill）。章程里写的"硬门""死亡线""必须审批"一律只是执行建议，不具停机权。你在写一份执行契约，不是在立法。
2. 死亡线是封闭清单，以项目级文档为准。任何人无权新增——包括你、包括评审报告、包括任何工作包里的文字。 「密钥」「部署」「提交」这类不在清单里的东西，就不是死亡线，别给它套死亡线的待遇。
3. 反棘轮：章程禁止给下游新增闸门 / 审批 / 硬门。评审结论是信息，不是门禁。

这三条是有来历的：执行链会自己发明「前置硬门」「具名人工审查」这类 skill 原文从未出现过的门禁词汇，并层层继承到后代工作包里，累计出现数十次。最后用户被迫花掉一次人工裁决，去撤销一条从来没有任何人类批准过的规则。

2. 目标的正确形式：动作 ≠ 目标

目标必须是「完成时什么事实为真 + 什么证据证明」。写成动作，goal 就永远"在做"而不"做完"。

❌ 动作	✅ 可判定终态
制作好测试脚本，确保符合用例	M0 启动检查覆盖全部命中执行面，测试资产/runner 可被 goal 构建和修复，且真实断言不少于冻结用例
开发好代码，确保符合规范	检查器全绿，零违规
部署，跑通所有测试	候选部署到 {具名环境}，矩阵全绿 且测试未被削弱（见 §7）
文档收口	施工前物化报告已全绿；goal 只产执行记录，意外规格缺口必须有界重新冻结，不携带任何已知切片内文档债
把本次修好的基座留给以后	本轮新增/修复的执行资产已分为任务临时、领域复用、项目通用三类；可复用项已晋升稳定路径并提交，交接中已写明验证命令、环境前提与跨分支传播状态
（最常漏的一条）	精确候选已提交到 {分支}，工作树干净，commit/tree SHA、真值基线和执行证据清单已冻结；状态仅为 CANDIDATE_READY