b0bc7a8745
一、技能重组（动作-对象命名） - 旧目录 clean/confirm/continuation/db/detect/embed/… 重组为 clean-book-text/decide-candidate/write-next-chapter/access-database/ check-content-consistency/embed-knowledge/…（git 识别为 rename，内容保持） - agents/*.md、AGENTS.md/CLAUDE.md 收编、example_skill 登记表同步新名 二、先审后入创作闭环（本次核心） 正文接受从"机械门一过就写正典"改为"机械门+语义审查双通过+用户批准+单事务原子提交"， DB 级兜底，编排层跳步即被硬拒。 - candidate_cas.py + example_candidate_cas(109)：持久化 CAS 状态链 - fact_delta.py + example_fact_delta/example_fact_ledger(106)：结构化事实增量， 模型只提六型闭集增量+正文证据引文，仅用户批准的增量随正文同事务入账本 - projection_registry.py + example_projection_run(107)：投影登记与恢复 - acceptance_state.py：接受前置实时状态重读 - lesson_registry.py + example_lesson(108)：经验升格链，禁止自动升格 - DDL 105：example_candidate 增 semantic_status/semantic_report_sha256 - write_canonical.accept：语义兜底+同事务合并增量+登记投影； run_writer_pipeline/persist_writer_run/run_writer_semantic_detector/step2 接入全链 - claude_runtime：兼容新 CLI modelUsage 信息字段 三、审查修复（独立子代理四维审查后） - 事实增量 propose→approve 翻态正道，不撞唯一键 - 冻结配置探针重刷（CLI 2.1.211→2.1.231 漂移），profileSha256/adapterVersion 再登记 - 可视化合同悬空路径/五六空间矛盾、 SoT 旧技能名漂移、行尾空白清理 测试：离线 65 套 + 真实库集成 5 套（CAS/接受故障注入/事实增量/投影/经验升格）+ 回放 79 项全绿。 创作内容（docs/design、生成正文 artifacts）按"框架与创作分开"未入本提交。
4.7 KiB
4.7 KiB
name, description
| name | description |
|---|---|
| decide-candidate | 根据用户明确指令接受、合并或丢弃 Shadow 候选，并以受控事务更新 Canonical、归因和决策记录。用户已经对正文、知识卡或规划作出决定时使用；不得由 Agent 自行触发。 |
确认 / 丢弃(Shadow→Canonical 的唯一入口)
只在用户明确说"采纳/确认/丢弃"后执行,主会话与智能体不得自行发起。
数据权威在 PostgreSQL(领域索引 §2)。正文的 Shadow→Canonical = 写库内正文块,不是 git commit;Git 只管代码与文档留痕。
正文候选:接受 / 丢弃(DB 写路径)
两步,顺序不可颠倒:
-
先过接受前置检查(纯函数,不写库):
scripts/check_writer_acceptance.pycheck_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 不是裁决依据,只有结构化报告过检才可接受。
-
前置通过后,经写入层落库(单事务):
scripts/write_canonical.py(复用access-database的 DSN)- 接受:
.venv/bin/python .claude/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 .claude/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+用户修订。不得修改后不经重检直接合并。
知识卡 / 规划:各自的确认轨
- 知识卡:确认 =
muse_knowledge_draft翻confirmed+ 落muse_knowledge_entity(active)（关系卡落muse_knowledge_relation），并在同一事务内确保作品↔知识库绑定、迁移实体向量 owner。使用.venv/bin/python .claude/skills/decide-candidate/scripts/confirm_knowledge.py --draft-id <id> --dry-run试跑；实际确认只能在用户明确确认后执行。批量实体/关系必须显式给--all-entities <work_id>或--all-relations <work_id>。采纳正文 ≠ 确认知识,抽取产出的卡变更要单独确认;有冲突的卡先裁决再确认。 - 规划(大纲/细纲/设定):规划表(100)落库前,暂以 git 提交确认——只
git add用户点名的创作文件,严禁混入框架文件(agents/skills/meta);提交信息作品(书名): 确认 设定包/大纲vN | 来源: planner。规划表建成后改为库内 shadow→confirmed。
红线
- 评测/诊断候选(run_type≠production)任何情况下不得成为正式正文。
- 写正文必带来源归因;不接受绕过归因的直接写块。
- 推送:用户要求时
git push origin main;失败原样报错,不静默。