workflow_requirement_intake

道-方法 · 道层 skill 全文

本页是 <code>rules/skills/drafts/workflow_requirement_intake.md</code> 的逐字投影（仅隐私清洗，零改写）。

name: workflow_requirement_intake
status: draft (Beta) — 2026-06-04 起草（IT-01/IT-02）；晋级前需 intake 工具 + intake_gate 在真实新需求上跑通 ≥1 次
description: 把用户随口提的一条新需求 / ToDo 收进系统：逐字原文进真源、任务入队、执行序更新、requirement record 落盘，且放进哪个 phase 是想出来的不是查表查出来的。触发场景：用户说『把这条需求记下来 / 加进执行序 / 这也是要做的需求』、或要判断一条新需求该落哪个实践 phase、或新 session 收到中途新需求要 intake。配套确定层工具 `todo intake` + 共生检测器 `intake_gate`。

需求 intake：一句话需求 → 系统里可被消费的对象

目标（一句话）

把一条新需求从「用户的一句话」变成系统里四个文件都接通的对象：逐字原文进真源文件、任务进队列、执行序更新它落哪一段、requirement record 单独落盘，而落哪一段是一个消费边论证的结果，不是查前缀表查出来的。

为什么需要它（根因，别跳过）

2026-06-04 诊断（adhoc_jobs/landing_requirement_decomposition_20260531/meta_analysis_20260604/DIAGNOSIS_order_intake_insight.md）查实：intake 一直只有一半零件。todo dispatch 能从真源读出逐字原文，但没有任何命令把新原文写进真源；执行序是散文，没有可机械插入的对象；load_pipeline.py 的 phase_for() 是硬编码前缀表，只在批量装载时跑，对单条新需求不可调用，且 I-04 还被写死成 Phase 2、跟 steering 把它移到段D叶子的纠正打架。

更深一层：放哪个 phase 这件事没有机械完成信号，所以 agent 历来要么手工编辑 markdown、再把「我手工做了一遍」说成「能力可用」，要么干脆套前缀表。这个 skill 给 intake 装上语义层的判断纪律，配套的 todo intake 给确定层的写入，intake_gate 给独立误差信号，三者合起来才是闭环。

四文件验收（无上下文 agent 可自判完没完）

一条需求算 intake 完成，当且仅当四个文件都接通：

1. 逐字原文文件：REQUIREMENTS_ORIGINAL_TEXT.md 里有该 req_id 的行，原文是用户原话逐字（不是转述、不是蒸馏、不是把『你对我的要求』改写进去），来源锚标了 session id；todo dispatch <task> 能抽到它。
2. TODO 文件：TODO.md 里有该任务，带 label / req_id / prompt_ref，priority = medium（等权默认；只有真有服务边硬依赖、被后续所有任务消费时才 high，且理由写进 description）。
3. 执行序文件：EXECUTION_ORDER.md §6 表里有该 req 一行，落段 和 消费边 两列都非空，且 消费边 是一个真的消费边论证（说清谁消费这条需求的产出），不是 recency / 重要性 / 前缀归类的伪论证。
4. record 文件：requirement_records/<req_id>.md 存在，frontmatter 有 req_id / session_id / source_kind，正文保留逐字原话、来源锚、变化路径、agent 建议和关联，供 record-first dispatch 抽全文。

任一文件不接通 = 没 intake 完成。四文件齐了还要过 intake_gate（确定性壳验原文 / TODO / 执行序 / record 结构，regulator 验消费边论证真伪），别拿自评当数。

phase 决策纪律（IT-02 的核心，最容易滑）

放哪一段只有一个合法依据：消费边。谁产出谁需要的东西，谁先；高扇出枢纽（被很多后续任务消费）落最早的段A，零扇出叶子（没人等它、用户之后才用）落最晚的段D。段的定义在 EXECUTION_ORDER.md §5。

定段前先想清楚一个问题再写进消费边列：谁消费这条需求的产出？ 把答案写成「X 用它来做 Y」，那就是消费边论证。

三条红线（接 [[feedback_equal_weight_requirements]]）：

• 不拿 recency 当依据。用户最后聊到的话题不等于最该先做（98c28ab1 把 Git 排第一就是 recency 偏置传染，靠下个 session 主动拒绝继承才纠回来）。
• 不拿重要性 / 紧急感当依据。需求等权，顺序只来自依赖。
• 不套前缀表。phase_for() 那种「E- 进 Phase 2」是反模式样本：它对单条需求不可调用、还和 steering 散文矛盾。看到自己在按编号前缀归类就停下，回到「谁消费它」。

不确定落哪段时，列出候选段 + 各自的消费边假设，宁可把任务标 needs-discussion 也不硬塞一个段。硬塞一个没有消费边支撑的段，就是把伪论证写进了结构化对象，比留空更糟。

逐字原文纪律

收用户的原话进真源，逐字，不蒸馏不转述（接 [[feedback_distilled_vs_raw_requirement_coverage]]）。蒸馏产物只记 agent 做了什么，丢掉用户中途临时提的新要求；真源要的是原话本身。也别把「等权 / 反 recency / 方法论」这类你对自己的工作要求写进真源（接 [[feedback_no_instructions_in_deliverable]]）——真源只放需求原文，怎么做是你默默应用的。来源锚标 session id，让后续能回查。

怎么做（术，指向工具）

1. 先按上面的 phase 决策纪律想清楚落哪段 + 消费边论证。这步是你想，命令不替你想。
2. 跑 todo intake（确定层）：它要求你传 --phase 和 --rationale（消费边论证），做四文件机械写入并打印信息引导。不带这两个参数它不写、只打印引导让你先去想。
3. 收口跑 intake_gate（共生检测器）：确定性壳验四文件结构是否齐、字段是否非空，regulator 验消费边论证是真论证还是 recency/重要性/查表伪论证，给可定位反例。FLAG 就按反例修，别声称 intake 完成。
4. 新增 handoff 时保留这条需求（IT-01 (b) 明确要求），并把入序结果写进 EXECUTION_ORDER（§6 表），不要只写进 handoff（handoff 是运行说明、不是需求真源）。

边界（不做什么）

• 不自动决定 phase。自动查表违反 IT-02；命令故意要求 agent 传 phase + rationale，就是为了逼出那一步思考。
• 不蒸馏后入库。真源放原话，不放改写版。
• order 的结构化对象是 EXECUTION_ORDER.md §6 表，单一文件（接 WORKSPACE 单一文件原则）。不另起平行 order 文件、不把同一入序信息抄进第二处，第二处只放指针。
• regulator 判的是论证形态（是不是消费边论证），不是论证内容的全部真伪。一条编造得很像消费边、但实际喂错下游的论证，单个 checker 兜不住全部；它兜住的是 recency/重要性/查表/空循环这几类高频反模式（V6 诚实边界）。深一层的真伪靠后续真实消费来证伪。

已知陷阱（真实发生过）

• 散文改了机制没改：steering 把 I-04 移到段D，load_pipeline.py:147 还写 Phase 2。纠正落在散文层、没同步落到机制，下一轮注意力一变就漂回去。intake 的入序必须落到 §6 这个结构化对象，不能只在散文里改一句。
• 同一纠偏被重提 7 次：等权 / 消费边 / skill 也是 tool / 单一文件，从 06-01 到 06-03 反复被纠，甚至同 session 内隔 38 分钟重提两次。根因不是听不懂，是认可停在散文、从没转成机械可验证的约束。intake_gate 就是把「按消费边入序」这条原则转成机械约束的尝试。

配套与跨域联系

• 确定层工具 todo intake + 共生检测器 intake_gate（tools/intake_gate/）。检测器形态遵循 [[workflow_complexity_drift_detection]] 的 V1–V6（确定性壳承载结构判别 + 第二 agent regulator 承载可操作误差信号）。
• 落地收口走 [[workflow_landing_to_production]] 的四条件 + landing_gate；本 skill 的创建本身按它的 DL-02 分步协议走。
• 需要先冻结「做什么」和验收边界时，先走 [[workflow_requirement_decomposition_core]]，再用本 skill 入库入序。
• 根因（确定层有信号 / 语义层无信号 → satisfice 滑向表面）接 [[project_order_intake_insight_diagnosis]] [[project_open_loop_control_theory]] [[project_verifiable_checkpoint_experiment]]。