plan-tasklisted

# 设计技术方案 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。 若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。 ## 行为边界 / 关键规则 - 本技能仅产出技术方案文档（`plan.md` 或 `plan-r{N}.md`）—— 不修改任何业务代码 - 这是一个**强制性的人工审查检查点** —— 不要自动进入实现阶段 - 方案涉及兼容、迁移、旧格式或旧入口时，先读取 `.agents/rules/compatibility-policy.md`；未通过准入门槛时不得设计 adapter、shim、双写或并行状态机 - 执行本技能后，你**必须**立即更新 task.md 中的任务状态 版本戳规则：创建或更新 `task.md` frontmatter 时，先读取 `.agents/rules/version-stamp.md`，并写入或刷新 `agent_infra_version`。 ## 第 0 步：状态核对（执行前硬约束） 在加载 workflow / skill / rules 指令之后、做任何任务状态判断或用户可见结论之前，必须先执行状态核对。指令类文件读取不算对外动作或结论。 运行以下命令，并把原文粘贴到本轮产物的 `## 状态核对` 段： ```bash agent-infra-internal task-snapshot {task-id} --format text ``` 状态核对完成前，禁止任何关于外部状态的断言（例如“代码没变”“测试已通过”“没有其他引用”），包括思考阶段。本门禁只提供结构下限；逐条证据配对和真实性仍需按报告模板与审查要求核对。 ## 任务上下文解析 > 入口可省略 task ref；显式 task scope 仅接受 `--task <ref>` 或 `-t <ref>`，不再解释位置 task ref。保留其余业务操作数后调用 `agent-infra-internal task-context resolve {task-scope}`；`{task-scope}` 为空或 task flag 之一。只读取结构化结果的 `taskId`，后续把 `{task-id}` 绑定为完整 `TASK-YYYYMMDD-HHMMSS`。解析失败时透传非零退出码，不自行扫描任务。 > 解析任务引用，并确认任务位于本技能支持的状态或目录且存在 `task.md`；无法定位时按未找到任务处理并停止。 ## 步骤开始：声明 started 事件 确认前置条件和轮次后、本轮第一个产出动作之前执行： ```bash agent-infra-internal task-event {task-id} plan.started --agent {standard-agent-token} ``` ## 执行步骤 ### 1. 验证前置条件 检查必要文件： - `.agents/workspace/active/{task-id}/task.md` - 任务文件 - 至少一个分析产物：`analysis.md` 或 `analysis-r{N}.md` 注意：`{task-id}`