feat: add Track A authoring workflow

[AlexBybye]

No description provided.

[AlexBybye]

Track A：Create、M、Q0/P0 与薄编排

[AlexBybye]

Track A：Create、M、Q0/P0 与薄编排

将本文全文投递给一个独立对话。该对话只实现 Track A，不承担共享接线、版本或发布。

任务结果

在独立文件边界内实现：

Authoring Protocol
+ 单一 M 软预算与 provenance ledger
+ Q0 draft lane
+ P0 AuthoringHandoff
+ A/B/C 下一动作分类与依赖注入式薄编排

生成性 Skill 创建必须由宿主 Agent 按 prose 完成。Python 只提供可确定验证的预算、来源记录、隔离草稿、摘要、结构边界和编排状态；不得实现或宣称“Python 能写出一个好 Skill”。

唯一事实源与基线

SOURCE_ROOT=/Users/bilibili/Desktop/skill for skills
TARGET_ROOT=<本对话从 clean BASE_HEAD 派生的独立 worktree>
BASE_HEAD=22cd4ef3e19b3b46ecd11bb4ebfa7e3292153087
VERSION=2.4.3

SOURCE_ROOT 只提供代码事实和本文最新版本；并行实现不得直接写共享 Desktop 根目录。TARGET_ROOT 必须从 BASE_HEAD 建立并由本 Track 独占。若当前对话没有独立 worktree，停止并报告 Gate 0 blocker。

当前 BASE_HEAD 已包含与本轨不重叠的 lightweight 交付：

README.md
runtime/skill-optimizer/scripts/eval/__init__.py
dev/optimizer-evals/test_lightweight_benchmark.py
runtime/skill-optimizer/scripts/eval/lightweight_benchmark.py

不得覆盖、移动或格式化这些文件。22cd4ef 的提交标题虽声称 Track C 已实现，但 diff 没有 Track C code/schema/test；BehaviorAndDeliverySummary 仍只是未来接口。历史 51c3 worktree 只可作为失败案例参考，不是实施事实源，也不能直接复制其 Track A 原型。

clean BASE_HEAD 的全量 optimizer 基线为 223 项：220 passed, 2 skipped, 1 failed。唯一失败是既有 core-v1 freeze fixture sha256:1126cb... 与当前 core 投影 sha256:6e4166cd... 不一致；本轨不得修改 core、fixture 或自行 refreeze。完成回报必须证明没有新增失败，并把该既有差异原样列为 Gate 1 integration request。

开始前重新执行并记录：

git rev-parse HEAD
git status --short
git diff --name-only

若 HEAD 或 owned files 的初始状态与本文不一致，先停止写入并报告差异。

当前标注

🧱 BASELINE，可复用但不计为 Track A 完成

• 现有 authoring-rules.md；
• approved root/candidate staging 与 tree digest 基础；
• candidate-generation authorization 类型和旧 gate；
• WAIT_USER 期间不追加 grant；
• continuation 一次性消费与防重放；
• create、optimize、description-only、no-skill 的旧 ProcessPlan 模式。

⬜ TODO

本轨计划的 12 个交付文件当前全部缺失；不存在 M、Q0 lane、P0 handoff、source provenance contract 或新 orchestration engine。

独占文件

只允许修改或新增：

runtime/skill-optimizer/references/authoring-rules.md
runtime/skill-optimizer/references/authoring-protocol.md

runtime/skill-optimizer/scripts/authoring/__init__.py
runtime/skill-optimizer/scripts/authoring/budget.py
runtime/skill-optimizer/scripts/authoring/provenance.py
runtime/skill-optimizer/scripts/authoring/draft.py

runtime/skill-optimizer/scripts/orchestration/__init__.py
runtime/skill-optimizer/scripts/orchestration/models.py
runtime/skill-optimizer/scripts/orchestration/engine.py

dev/optimizer-evals/test_authoring_budget.py
dev/optimizer-evals/test_authoring_provenance.py
dev/optimizer-evals/test_draft_lane.py
dev/optimizer-evals/test_orchestration_engine.py

不得修改公共 core/__init__.py、eval/__init__.py、CLI、schema registry、现有 schema、ProcessPlan、policy、workflow、decision、builder、公共回归、SKILL.md、WORKFLOW_SPEC.md、README.md、VERSION 或 dist/**。若缺少共享能力，只输出 integration request。

跨轨冻结接口

对外只通过普通 mapping 或 Protocol/依赖注入交接，不直接 import Track B/C 内部类型。

A → B：AuthoringHandoff

candidate_path
candidate_digest
task_mode
development_examples[]
  - source_kind
  - source_ref
suggested_quality_targets[]
selected_authoring_modules[]
method_cost_usage
stop_reason
formal_evaluation = false

该对象只证明创建过程和当前字节绑定，不证明质量、gain、promotion、release 或 host activation。

C → A：BehaviorAndDeliverySummary

behavior_findings[]
minimum_risk
mandatory_controls[]
unknowns[]
delivery_target
delivery_eligibility
delivery_receipt
rollback_receipt

A 只负责展示和路由下一动作，不能改写 C 的风险与交付结论。

B → A：QualityEvidenceSummary

candidate_digest
baseline_digest
quality_plan_digest
verified_claims[]
unverified_claims[]
blocked_claims[]
removed_claims[]
indicative_observations[]
formal_outcome

A 必须核对 candidate、quality plan，以及存在 baseline 时的 baseline 绑定；只显示这些事实，不能自行升级 claim 或重算 decision。任一摘要与当前编排上下文不一致时 fail closed。

实施要求

1. Authoring Protocol

将完整但紧凑的宿主创建方法写入 prose：

discover → model → plan resources → draft → clean → handoff → revise

至少说明：

• 从用户对话、文件、真实 trace 和确认事实提取目标、触发边界、输入输出、约束和非目标；
• 从具体开发实例推演真实工作流、失败点和重复劳动；
• 按每个操作的自由度与失败成本决定进入 SKILL.md、references/、scripts/、assets/ 或不进入；
• description 同时说明“做什么”和“何时使用”；
• gotcha 必须来自观察、可靠证据或明确高风险预案；
• 生成最小候选，删除 placeholder、无用目录与不能解释必要性的内容；
• 消费 Q 返回的失败证据做单因果修订，但不在 M 内宣称候选更好；
• development examples 永远不能冒充 sealed/unseen holdout。

不要重新引入固定 11 视角、固定多代理、三轮无发现、全票审查、固定多候选或长期预测。

2. M 软预算

M 是单一 manager，不增加公开 M0/M1/M2。

每次运行必须冻结 closed conditional-module allowlist；实现不得把 selected modules 扩张成任意插件池。

硬计数至少覆盖：

• clarification/research/source checks；
• independent/counter-design calls；
• candidate count；
• revision count；
• selected conditional modules。

ledger 至少记录：

• 允许上限；
• 实际动作；
• source refs；
• trigger evidence；
• 被预算阻止的动作；
• stop reason；
• canonical digest。

不得使用未验证的稳定 token 精确预算。M 对象不得出现 quality_pass、candidate_gain、promote、release 或 verified claim 字段。

3. Development-example provenance

只允许：

observed
user_confirmed
synthetic
assumed

要求：

• A → B 的冻结 development_examples[] 投影严格只有 source_kind、source_ref 两个子字段，不得静默扩 schema；
• Track A 内部 provenance record 另外闭合规范化内容摘要和整条记录摘要，但二者不进入 A → B 投影；若 Gate 1 需要跨轨传递，必须提交显式的接口版本化 integration request；
• observed/user_confirmed 必须由集成层提供的 source resolver 解析到获批事实；不得仅凭字符串前缀接受；
• 缺少可信 resolver 时不能把自报 mapping 升格为 observed/user-confirmed；应拒绝或明确降级；
• synthetic/assumed 不能支撑代表性、真实性或 holdout claim；
• 不把本地 hash 当签名或身份验证。

4. Q0 draft lane

Q0 的严格语义：

formal evaluation = 0
candidate gain = none
formal decision = none
implemented delivery = P0 handoff only

必须：

• 消费真实 candidate-generation authorization 的验证结果；
• authorization 必须在第一次 mkdir 或文件写入前成功消费；缺失、拒绝、过期或摘要失配时不得留下候选目录；
• 只写入获批隔离 run directory；
• 重验 exact target、父目录、symlink、candidate bytes 和 tree digest；
• 运行闭合的最小确定性结构检查：SKILL.md 必须是普通文件，frontmatter 按当前 Skill contract 成功解析并包含合法 name/description，正文非空，无 TODO/placeholder，所有本地引用存在且仍位于候选根内，整树不含 symlink、特殊文件、__pycache__、.pyc 或 cache 产物；
• 结构失败不能返回 DRAFT_READY；
• 对明确高风险信号或 C 返回的 blocked/escalation 保守返回 DRAFT_REQUIRES_ESCALATION；
• P0 只返回隔离路径、digest、provenance 与限制；
• 未运行候选 scripts 时明确标记 script behavior unverified；C 结果缺失时标记 behavior risk not assessed，不得写成 safe；
• 不打包、不安装、不覆盖正式 Skill 根、不提交 Git。

Track A 不得直接实现正式 risk decision，也不得接受 raw bool、自签 mapping 或自定义 verifier 冒充 C 结论。C 尚未接入时仍可完成隔离 P0 handoff，但必须标记 behavior risk not assessed；不得写 safe。P0 只是本 Track 实际实现的 handoff，不由 Q0 推导，也不代表全局默认交付选择；未来 P1/P2 资格仍由具体 claim、风险、能力和授权决定。

5. A/B/C 薄编排

编排器只分类和推进：

• A：确定性自动步骤；
• B：价值选择或真实动作授权；
• C：证据事实，只读转达。

必须保证：

• C 类事实绝不询问用户决定；
• WAIT_USER 状态不自行写 grant；
• continuation 只消费一次；
• digest 自动传递，不要求用户手搬；
• task/scope/target 摘要漂移使旧 continuation/grant 失效；
• create、optimize、description-only、no-skill 可被模型表达，但本轨只提供适配原语，不复制旧 ProcessPlan/decision；
• 真实 action authorization 只允许 analysis_execution、candidate_generation、install；budget/design 是 decision/ref，不伪装成 grant；
• no-skill 不生成候选；
• description-only 的非 description 字节不可变规则留给现有可信链。

本轨只定义 authorization/continuation adapter seam 和负向测试；未接线前不得声称真实授权链完成。Gate 1 必须把 seam 接到 recovered event chain、当前 grant、scope/risk/target、expiry 与 log head。本地 reservation 只能增加并发保护，不能替代 shared workflow 权威。

推荐实施顺序

1. 收敛 authoring-rules.md，新增完整 authoring-protocol.md。
2. 实现 provenance 值对象、严格解析、digest 与 resolver 边界。
3. 实现 M plan/ledger、成本上限、停止原因与重放验证。
4. 实现 AuthoringHandoff 与 Q0/P0 draft lane。
5. 实现 orchestration models 和纯分类 engine。
6. 增加负向测试，再运行全部本轨定向测试。
7. 只输出共享 integration requests，不越界接 CLI/registry/ProcessPlan。

必须覆盖的测试

• 微型 Skill 只走 Core，不因预算充足制造额外方案；
• 所有 M 成本不超过上限，ledger 篡改失败；
• M receipt 不能包含质量或晋升字段；
• synthetic/assumed 不能冒充 observed/user-confirmed；
• source resolver 缺失或不匹配时 fail closed；
• development example 不能被标为 holdout；
• Q0 不创建 formal campaign/evidence/decision；
• 未经有效 candidate-generation authority 不能写草稿；
• 草稿不能逃逸隔离根或经过 symlink；
• candidate bytes 漂移使 handoff 失败；
• 结构错误阻止 DRAFT_READY；
• P0 不打包、不安装、不覆盖；
• A/B/C 分类不询问 C 类事实；
• WAIT_USER 期间不写 grant；
• continuation 不可重放；
• no-skill 不生成候选；
• 任意 caller-authored summary 不能自铸风险或质量结论。

测试统一使用：

PYTHONDONTWRITEBYTECODE=1

输出和候选写入临时目录，不在仓库产生 cache 或派生包。

完成定义

本轨只有同时满足以下条件才可报告完成：

• 12 个新交付均存在，现有 authoring-rules.md 已按要求修改，未出现越界修改；
• 定向测试全部通过；
• git diff --check 通过；
• 没有 cache、tracked dist 或共享文件变化；
• 全量 optimizer 没有新增失败；既有 core-v1 freeze 差异保持未改并单独报告；
• AuthoringHandoff 可由当前候选字节重建验证；
• M/Q/R/P 边界在类型和负向测试中成立；
• 明确列出后置集成请求与未验证能力。

不得声称 Gate 1、Wave 2、3.0 或正式发布完成。

最终回报格式

1. 基线 HEAD/status
2. 修改文件清单
3. 公开 API 与对象版本
4. 硬计数与 prose 软语义的边界
5. 定向测试命令、数量和结果
6. 负向/篡改测试结果
7. integration requests
8. 未解决风险与明确未验证 claim
9. git diff --check 与 cache 检查