workflow_requirement_decomposition_core
道-方法 · 道层 skill 全文
本页是 <code>rules/skills/drafts/workflow_requirement_decomposition_core.md</code> 的逐字投影（仅隐私清洗，零改写）。
时点提示：本页是仓内文件 rules/skills/drafts/workflow_requirement_decomposition_core.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。
草案 Workflow：需求拆解 Core
状态
Draft skill。来源候选：adhoc_jobs/large_context_compression_method_loop_20260523/requirement_decomposition_core_workflow_20260523/WORKFLOW_v0_1.md。
当 Loop、大上下文任务或跨 session 任务需要在执行前拆解用户需求时使用这个 draft。它尤其适用于信息收集跨多个 Unit、局部可解但可能偏离用户真实目标、或收束依赖 core judgment 的场景。
这个 draft 还不是正式晋升的 Workflow skill。workflow_controller_loop 仍可通过 task card 的 protocol_visibility 路由 requirement-analysis Unit 读取它。
目标
在执行前构造任务定义面：
source universe
+ requirement evidence
+ proof obligations
+ core judgment
+ phase graph
+ first bounded Unit输出应让 Controller 能判断任务真正关心什么、哪些证据会改变下一步行动，以及哪个 first Unit 可以安全执行。
七门顺序骨架
每个 gate 必须按顺序通过；未完成前一个不得进入下一个。
| Gate | 名称 | Entry | Exit 产物 | Stop 条件 |
|---|---|---|---|---|
| 0 | Boundary | 收到用户请求 | USER_PROMPTS/、CONTROL.md、初始 forbidden claims | Controller 能陈述允许产出和不能声明的内容 |
| 1 | Decomposition | Gate 0 完成 | provisional REQUIREMENTS.md、proof obligation list | 吸引人但不在 scope 的任务已识别并排除 |
| 2 | Info-Acquisition | Gate 1 完成 | SOURCE_MANIFEST.tsv、token budget、no-hit receipts | source universe 已建、覆盖率已量化 |
| 3 | Requirement | Gate 2 完成 | REQUIREMENT_EVIDENCE.md、finalized REQUIREMENTS.md | 每条 requirement 有 source anchor 或标 provisional |
| 4 | Core-Judgment | Gate 3 完成 | core_judgment YAML | lever requirement 和 weakest allowed claim 明确 |
| 5 | Phase-Graph | Gate 4 完成 | PHASES.md、phase graph | 每个 phase 有 entry/exit criteria 和 turn options |
| 6 | Unit-Dispatch | Gate 5 完成 | 第一张 bounded TASKS/Txxx.md | Unit 有 1-3 个方向、read paths、预期产物 |
| 7 | Review/Stop | 每轮结束 | 文件产出审查、effect 审查、phase decision、stop certificate | allowed claim + residuals + forbidden claims 均已写明 |
必需输出
USER_PROMPTS/或当前请求及相关历史 prompt 的 source anchors。- 当来源超过一个稳定 context 时，
SOURCE_MANIFEST.*必须包含 coverage、no-hit 和 residual receipts。 REQUIREMENT_EVIDENCE.md区分用户原文、推断需求、缺失来源和无证据假设。REQUIREMENTS.md写明 requirement ids、proof obligations、所需 evidence class 和禁止的更强声明。core_judgment:
core_judgment:
central_problem:
lever_requirement:
decision_value_frontier: []
essential_effect:
accidental_or_wrapper_only: []
next_action_implication:
allowed_claim:
forbidden_claims: []PHASES.md或等价 task phase plan，包含 entry criteria、exit criteria、evidence required 和 turn options。- 第一张 bounded
TASKS/Txxx.md，包含一个 phase owner、1 到 3 个方向、必需读取路径、预期产物和审查要求。
硬规则
- 在 source coverage 和 proof obligations 明确前，不要把用户需求改写成实现步骤。
- 没有 source anchor 的 requirement 只能是 provisional。
- 大上下文提取只证明 coverage，不裁决业务 closure。
- 如果 core judgment 不清楚，增加信息获取或需求仲裁，而不是扩张执行。
- Phase 是 proof state，不是 time box。
- 文件存在、PASS 字符串、sub-agent 自报和报告不能自行升级 evidence class。
- 预检复用（intake 硬门）：把用户需求改写成执行步骤、或新建任何文件前，先
grep -r全仓查同名 / 同主题的已有产物与旧 skill；下「某产物不存在 / 未生成」结论前，先find全仓（含兄弟目录、顶层路径）确认。派 sub-agent 时输出路径必须绝对化，禁用.../相对缩写。跳过预检导致重复实现，或把错路径产物误判为缺失，是 FAM-J（IB-22）/ FAM-K（IB-36）。 - 一个 Unit 超过 3 个方向 = 仍处于 requirement-analysis 阶段，不得进入执行。方向数量是 scope 膨胀的早期信号，这是防过早执行的首要启发式。
Loop 集成
在 workflow_controller_loop 中，本 draft 属于 information_search 和 requirement_analysis Phase。Controller、requirement reviewer、scale-up reviewer 或指定的 requirement-decomposition Unit 可以读取它。普通 task execution Unit 只应接收由它产出的 task card、requirements 和 phase contract。
测试验收
测试通过需分项证明：task quality、protocol integrity、review quality、reconstruction fidelity，不可合并声明。
允许的测试声明：bounded workflow utility（有界流程有效性）；protocol gain without task-quality proof（协议增益不等于任务质量）；reconstruction incomplete（重建不完整）；invalid comparison（对照无效）。
无 mutation 或 negative control，不得声称 empirical validation。