muse-agent-example/.agent/skills/decide-candidate/SKILL.md

name, description, disable-model-invocation

name	description	disable-model-invocation
decide-candidate	据用户明确指令接受、合并或丢弃 Shadow 正文候选并更新 Canonical。仅主会话在用户决定后调用；知识卡归 confirm-knowledge-draft，规划归 plan-story。	true

确认 / 丢弃(Shadow→Canonical 的唯一入口)

只在用户明确说"采纳/确认/丢弃"后执行,主会话与智能体不得自行发起。

闸口（05 §2）：产出候选之后，必须经你确认，才能入库为正式正文。accept 授权下游 shadow 草稿自动生成（抽卡等）；草稿转正式仍须你确认。未确认不得把候选当 Canonical，也不得在未 accept 时自动写下游草稿。

数据权威在 PostgreSQL(领域索引 §2)。正文的 Shadow→Canonical = 写库内正文块,不是 git commit;Git 只管代码与文档留痕。

正文候选:接受 / 丢弃(DB 写路径)

两步,顺序不可颠倒:

1. 先过接受前置检查(纯函数,不写库):scripts/check_writer_acceptance.py

   • check_shadow_ready 校验生产模式、acceptanceEligible=true、候选正文 hash、冻结上下文 ID/hash、writer-production-v1 策略、来源状态、候选有效期,以及 detector 最终报告(writer-pipeline-result-v1,要求最终轨迹同时通过机械门与语义审查)对当前 attempt/candidateVersion/candidateSha256 的绑定。
   • 实时状态由 scripts/acceptance_state.py 从库重读(冻结行、授权快照、已确认细纲、Canonical revision、接受窗口),编排层不得用内存旧快照冒充。
   • accept/merge 必须实时匹配 expectedRevision;冲突返回 REVISION_CONFLICT,不得覆盖 Canonical。
   • acceptanceEligible=false 的诊断/评测候选在第一道门硬拒绝,不能靠改参数、重跑 fake 或用户确认混进接受链。
   • 生产链的 detector 终态来自 run_writer_pipeline 的真实机械门 + 语义 detector 双报告;LLM 自然语言 PASS 不是裁决依据,只有结构化报告过检才可接受。

2. 前置通过后,经写入层落库(单事务):scripts/write_canonical.py(复用 access-database 的 DSN)

   • 接受:

     .venv/bin/python .agent/skills/decide-candidate/scripts/write_canonical.py accept <candidate_id> \
       --expected-revision <N> --rationale "为什么接受" --basis-ref "大纲@日期" --command-id <幂等ID> \
       [--approved-deltas <已批准增量JSON数组>]
     # 先试跑(完整走一遍事务再回滚,校验不落库):加 --dry-run
     

   • 丢弃:

     .venv/bin/python .agent/skills/decide-candidate/scripts/write_canonical.py discard <candidate_id> --rationale "为什么丢弃"
     

   • 写入层按落库设计 §2.9 单事务执行:写正文块(content_text,revision+1,CAS 乐观锁)→ 写来源归因(muse_content_block_source_attribution,来源权威落块,架构-02 §3)→ 合并已批准事实增量(fact_delta.py,进 example_fact_ledger 正典账本)→ 登记投影(projection_registry.py,旧 revision 投影翻 stale、新 revision 登记 pending)→ 写命令幂等审计 → 写决策归档(example_user_decision)→ 翻候选 state='accepted'。任一失败整体回滚,绝不留无来源指针的正式正文,也绝不产生正文已提交而事实半合并。
   • DB 级兜底硬校验(不靠调用方自觉):run_type 非 production 拒绝接受(05 §8.4)、state 非 passed 拒绝、semantic_status 非 passed 拒绝(先审后入)、revision 冲突拒绝。

merge(修改后合并)

• 用户以编辑前候选为基线编辑,生成严格 candidateVersion+1 的新候选,正文 hash 必须变化,重跑完整 detector 与接受前置检查,回到 Shadow 再走上面的 accept 流程。
• 接受时归因 --source-type user_merge,记 writer+用户修订。不得修改后不经重检直接合并。

知识卡 / 规划:各自的确认轨

本 Skill 只管正文轨。另外两条轨各有 owner，表集互不相交：

• 知识卡：归 confirm-knowledge-draft。采纳正文 ≠ 确认知识，抽取产出的卡变更要单独确认。
• 规划（大纲/细纲/设定）：归 plan-story，由 plan-story/scripts/persist_planning.py 的 confirm_section 在 example_planning_section 上做 shadow→confirmed。

红线

• 评测/诊断候选(run_type≠production)任何情况下不得成为正式正文。
• 写正文必带来源归因;不接受绕过归因的直接写块。
• 正文的 Shadow→Canonical 只写库,不做 git 操作;知识卡与规划的确认不在本 Skill 执行。

输入

• 用户明确的采纳 / 丢弃指令、候选 id、--expected-revision、rationale、basis-ref、幂等 command-id。
• 接受前必须先过 scripts/check_writer_acceptance.py（Shadow 就绪、detector 终态、实时 Canonical revision）。

输出

• accept：Canonical 正文块 revision+1、来源归因、已批准事实增量、投影登记、决策归档、候选 state=accepted；回执含 next_steps（抽卡等下游草稿 auto=true；转正式与下一章规划仍须人）。
• discard：候选 state=discarded 与决策记录；附 next_steps（不自动改正文）。
• --dry-run：完整走事务后回滚，不落库。

复利合同

• 接受事务提交后经 propose_lesson_dedup 登记 example_lesson（绑 run_id / candidate_id）；lesson 写在接受事务外。
• 升格仍走人工评审，不把单次采纳自动升为公共范式。

数据边界

• 读写范围限于本 Skill 合同声明的表/文件；失败整体回滚，不留半写入状态。
• 模型调用走统一网关；raw 证据由 record-run-evidence 归档。