- 能力文件补 导航元信息(内容描述/使用场景/使用要求),技能目录按目录派生;索引检查与磁盘逐条一致。 - 规则:计划与提交新增「验证期冻结源码」「全量只跑一次」两条纪律并写清与生成、验收数据库的关系; 模块依赖、任务与证据、文档与资源生成、测试隔离等规则同步本轮口径。 - 角色合同与配置的模型白名单保持一致;技能正文不再夹带索引注记(与后端资源加载同口径)。
24 lines
2.1 KiB
Markdown
24 lines
2.1 KiB
Markdown
---
|
||
id: confirm-plan-candidate
|
||
name: 确认规划候选
|
||
category: operation
|
||
contract_version: 1
|
||
commands: [read_plan_candidate, edit_plan_candidate, open_plan_review, decide_plan_candidate, read_plan, list_plans]
|
||
description: 读取新版规划候选和固定版本,执行作者明确的采纳、拒绝或暂缓,并回查正式规划与事务回执。
|
||
---
|
||
<!-- 导航元信息: {"使用场景": "使用新版规划入口", "使用要求": "使用被审版本,回查正式回执\n不以打开审阅或字段通过替代作者确认"} -->
|
||
|
||
# 确认规划候选
|
||
|
||
先用`.venv/bin/python -m muse 规划 <作者配置> 查看候选 <候选ID>`读取内容。当前人工规划候选只做字段与版本检查,不表示模型或文学评审已经通过。
|
||
|
||
作者要修改候选时,使用`编辑候选 <私人请求JSON>`提交command_id、candidate(确切定位)与changes字段操作。服务端在同一身份下追加候选版本,原版保留。编辑后重新读取并打开审阅,旧审阅不能确认改后的内容。
|
||
|
||
向作者展示确切内容和保存后的影响。准备candidate_id、candidate_revision、candidate_hash、plan_id、expected_revision,执行`打开审阅 <私人定位JSON>`取得审阅记录。不能把打开审阅当作确认。
|
||
|
||
作者明确决定后,`决定 <私人请求JSON>`提交command_id、candidate(上述定位)、action、author_review_id、review_hash、approved_changes。action为adopt、reject或defer;采纳整份规划时approved_changes为`["plan"]`。使用实际审阅时的版本和哈希,不自动刷新成最新版本后重试采纳。
|
||
|
||
返回回执后,用`查看 <规划ID>`或`列表 <作品ID>`核对正式内容。网络结果未知时保持同一请求重试;参数改变使用新命令。陈旧候选需要重新比较,不能覆盖新的正式规划。规划确认只写B01,不代替正文或故事事实的独立确认。
|
||
|
||
职责和来源约束见[B01作品规划](../../../../docs/系统架构/新版设计/模块设计/B01-作品规划.md)与[命令与作者决策](../../../../docs/系统架构/新版设计/接口契约/命令与作者决策.md)。
|