openfeel 1.1.6 → 1.2.0

package/dist/core/template-loader.js

@@ -218,6 +218,47 @@ When a stage enters \`plan_passed\` and the project's \`auto_advance\` is set to
 3. **User declines**: Feel keeps \`auto_advance=disabled\` and requires user confirmation before each stage advance (manual execution mode).
 4. **No silent advancement**: When \`auto_advance=disabled\`, Feel must not advance the pipeline without asking the user.
 
+#### Workflow Mode (workflow_mode)
+
+Before dispatching, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`; when the field is absent, fall back per the cascade). Two modes:
+
+- **full (complete flow)**: planner → plan_review (reviewer) → schemer → executor → reviewer → tester → archiver.
+- **fast (Workflow Fast Line)**: planner (lightweight) → plan_review (**single mandatory plan review**) → executor → reviewer (single round) → archiver (lightweight); **does not dispatch openfeel-schemer / openfeel-feel-tester**.
+
+Fast-mode discipline:
+
+1. **The quality floor cannot be skipped**: under fast the reviewer **runs twice** — ① \`plan_review\` plan review (**mandatory single round**, on par with code review; pass → \`plan_passed\`, issues returned → \`plan_pending\`); ② code review after exec (single round); the \`review_failed\` loop allows re-review or returning to exec for fixes; failures are recorded as usual (REV entries unchanged).
+2. **Lightweight**: planner / archiver produce lightweight output (**must not** omit the task table / dependencies / acceptance points, or the state record / knowledge-staging decision).
+3. **Phase semantics**: under fast, reachable phases are the fast-line chain (\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`); the **legal phase enumeration remains at 15** (6 phases are unreachable under fast: \`scheme_*\` / \`test_*\`).
+4. **Full skeletons unchanged**: fast trims no on-disk structure; it only reduces agent relay steps.
+5. **Terminology disambiguation**: the flow mode is called the **Workflow Fast Line** (\`workflow_mode=fast\`); the review-depth downgrade is called **Fast Track (FAST-PASS)** — they are different mechanisms and must not be cross-referenced or conflated.
+
+#### Requirement Lifecycle
+
+The requirement layer is the second layer of the four-layer model "version → requirement REQ-NNN → plan stage → op": **a requirement is the scheduling layer**, answering "what to do and when"; **implementation still goes through the full pipeline** — a requirement is not a plan; after taking a requirement, delegate to openfeel-planner for plan.md per the "Threshold for Small Changes vs. Large-Scale Planning" as usual.
+
+A requirement has 7 statuses: \`draft\` → \`scheduled\` → \`in_progress\` → \`done\`, plus three side states \`blocked\` / \`cancelled\` / \`rejected\`. Requirement progress is aggregated from the linked stages' phases (single projection direction: stage phase → requirement status; the requirement is closed as done automatically once all linked stages are done — precondition: only \`scheduled\` / \`in_progress\`; \`draft\` / \`blocked\` / terminal states do not trigger).
+
+Requirement lifecycle actions (command group \`openfeel req\`, 10 subcommands):
+
+| Step | Action | Command |
+|------|--------|---------|
+| Take | Browse requirement views and pick the next takeable requirement | \`openfeel req board\` / \`openfeel req next\` / \`openfeel req list\` |
+| Claim | Claim the requirement (rejected if already claimed by another — guards concurrent overwrite; no TTL) | \`openfeel req claim <REQ-NNN>\` |
+| Link | Link the requirement to the stages implementing it | \`openfeel req link --stage <stageId> --requirement <REQ-NNN>\` |
+| Advance | Stage advancement drives aggregation; advance explicitly along legal targets | \`openfeel req advance <REQ-NNN> --to <status>\` |
+| Complete | Auto-done once all linked stages are done; overview and release | \`openfeel req board\` / \`openfeel req release <REQ-NNN>\` |
+
+> Orthogonality note: requirement flow is orthogonal to the workflow mode (\`full\` / \`fast\`) — the requirement discipline is identical in both modes.
+
+#### Archiving and History Reading
+
+Once a version is finalized (all its stages done), prompt the user that version archiving is available (\`openfeel flow archive <version>\` — after the criteria gate passes, the archive file is written first and the active entries removed afterwards): the archiving action is executed by the CLI; dispatch only prompts, never performs it.
+
+- Never read archive files proactively: regular dispatch must not read \`.openfeel/flow-archive/**\` (to prevent context pollution); the active set via \`openfeel flow status\` / \`openfeel flow overview\` is the full working view.
+- Query history on demand: when history is genuinely needed, use \`openfeel flow archive show <version>\` (single version, read-only) or \`openfeel flow archive list\` (enumerate versions); do not read the files directly.
+- Distinct from top-level \`openfeel archive\`: the top-level command is stage-summary archiving; \`flow archive\` is flow.json version-shard archiving — different responsibilities.
+
 ## Threshold for Small Changes vs. Large-Scale Planning
 
 Choose the appropriate process path based on the change scale:
@@ -285,7 +326,7 @@ A shared log entry (\`.openfeel/log/yyyy-mm-dd-feel-NNN.md\`) must be created wh
 
 ### Skeleton File Note
 
-During critical operations (advancing to exec_running / review_pending / test_pending / archiving), the pipeline automatically creates skeleton files with date prefixes in the private log directory. Feel does not need to manually create log files; simply fill in the content when you see a skeleton file.
+During critical operations (advancing to exec_running / review_pending / test_pending / archiving), the pipeline automatically creates skeleton files with date prefixes in the private log directory (under the fast Workflow Fast Line, \`test_pending\` remains a legal phase but is unreachable (no inbound edge), so its skeleton is no longer produced; all other skeleton rules are unchanged). Feel does not need to manually create log files; simply fill in the content when you see a skeleton file.
 
 ### Log Entry Format
 
@@ -547,6 +588,15 @@ After archiving is complete, the stage's pipeline phase must be set to one of th
 
 > ⚠️ Note: After archiving is complete, the stage status must be set to \`"done"\`, **do not** use non-standard values like \`"completed"\`. \`"completed"\` does not exist in \`VALID_TRANSITIONS\`.
 
+> **Under the fast Workflow Fast Line**: the 15-phase enumeration above is **unchanged** (reachable ≠ legal); reachable phases are the fast-line chain (\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`).
+
+## Workflow Mode Awareness (fast lightweight archiving)
+
+Before archiving, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`):
+
+- **full**: full archiving checklist (unchanged).
+- **fast (Workflow Fast Line)**: **lightweight archiving** — the state record and the knowledge-staging decision (including the dedup lookup) **must not be omitted**; checklist process narrative may be merged and condensed. (Lightweight scope: keep the state record / knowledge-staging decision / kb index quick overview / manual update decision / shared log summary; summary process narrative may be merged into bullet points.)
+
 ## Model Selection
 
 openfeel-archiver is driven by a **reasoning model** (such as DeepSeek V4 Pro), responsible for understanding context and extracting valuable experience.
@@ -556,7 +606,7 @@ description: openfeel-executor Agent, fast model, implements code according to o
 mode: subagent
 model: deepseek/deepseek-flash
 reasoning_effort: medium
-color: "#D94A4A"
+color: "#4CAF50"
 permission:
   bash: "allow"
   read: "allow"
@@ -622,9 +672,10 @@ Confirm that the following 6 required fields are present. If any is missing, ret
 
 ### Step 2: Phase Legitimacy Check
 
-1. Read \`.openfeel/flow.json\`, check if \`pipeline.phase\` is a valid enum value (\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`); refuse to execute if invalid.
+1. Read \`.openfeel/flow.json\`, check if \`pipeline.phase\` is a valid enum value (\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`); refuse to execute if invalid. (under the fast Workflow Fast Line, reachable phases are the fast-line chain; the legal phase enumeration remains at 15 — reachable ≠ legal)
 2. Confirm \`pipeline.current.op\` matches the current op-id; refuse to execute if mismatched.
 3. When the current phase is not \`exec_running\`: if Feel explicitly instructs execution, it may proceed but must note the phase deviation; otherwise, refuse to execute.
+4. **Fast-mode phase paths**: \`plan_pending → plan_review → plan_passed → exec_running\` (the plan review is a mandatory single round; the step is entered only after it passes); the \`review_failed → exec_running\` loop (review failure returns to exec for fixes; the \`review_failed → review_pending\` re-review exit is retained).
 
 ### Step 3: FlowManager Transition Legitimacy Check
 
@@ -765,7 +816,7 @@ Delegable targets: openfeel-vision (analyze screenshots), openfeel-reviewer (pre
 description: openfeel-feel-tester Agent, reasoning model, responsible for formal testing and acceptance in the pipeline.
 mode: subagent
 reasoning_effort: medium
-color: "#E8A838"
+color: "#22D3EE"
 permission:
   bash: "allow"
   read: "allow"
@@ -864,6 +915,7 @@ Write regression verification results into the Bug file's "Acceptance Record" ta
 - When issues are found, notify openfeel-schemer to formulate a revision
 - Re-test after fixes until passing
 - When tests pass, notify Feel to enter the archiving phase
+- **Workflow Mode Awareness**: under the fast Workflow Fast Line this agent is **not dispatched** (the formal test step is skipped per \`status.md\` "Workflow Mode"; the \`test_*\` phases are unreachable); the role definition is unchanged.
 
 ## Model Selection
 
@@ -978,6 +1030,22 @@ This step ensures openfeel-planner absorbs existing project knowledge before mak
 - Does not directly code or execute tests
 - openfeel-planner and openfeel-schemer responsibility boundary: openfeel-planner is responsible for "what" (what) and "when" (when), openfeel-schemer is responsible for "how" (how)
 
+## Workflow Mode Awareness (fast)
+
+Before planning, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`):
+
+- **full**: the output goes through openfeel-reviewer plan review (\`plan_review\`) before openfeel-schemer (unchanged).
+- **fast (Workflow Fast Line)**: **this agent's output must pass openfeel-reviewer's plan review (\`plan_review\`, single round; pass → \`plan_passed\`, issues returned → \`plan_pending\`; only then does it enter exec)**; produce a lightweight plan — the task table / dependencies / acceptance points **must not be omitted**; other process narrative may be trimmed. (Lightweight scope: keep goals / dependencies / task table / acceptance points / constraints / KB retrieval / change-point list / risks; background evidence details and revision history may be condensed.)
+
+## Requirement Awareness
+
+When a task originates from a requirement (\`REQ-NNN\`):
+
+- Read the requirement: first read the requirement details (title / status / owner / linked stages) via \`openfeel req show <REQ-NNN>\` as plan input.
+- Link the plan to the requirement: annotate the header of the produced \`plan.md\` with "Linked requirement: REQ-NNN"; omit the annotation when there is no requirement source.
+- Flow is not this agent's duty: requirement status transitions (claim / link / advance) are executed via the \`openfeel req\` CLI; this agent is read-only (no direct flow.json writes).
+- Orthogonal to "Workflow Mode Awareness": requirement awareness is identical under \`full\` / \`fast\`.
+
 ## Model Selection
 
 openfeel-planner is driven by a **reasoning model** (such as DeepSeek V4 Pro). In the Feel system design, openfeel-planner duties can be concurrently handled by Feel, but exist as an independent agent definition to support flexible scheduling strategies.
@@ -990,7 +1058,7 @@ description: openfeel-reviewer Agent, heterogenous reasoning model, responsible
 mode: subagent
 model: zhipuai/glm-5.3-flash
 reasoning_effort: medium
-color: "#D4A017"
+color: "#EC4899"
 permission:
   bash: "allow"
   read: "allow"
@@ -1057,6 +1125,15 @@ When **all three** of the following conditions are met, openfeel-reviewer enters
 
 If any condition is not met, skip fast track and execute full review process.
 
+## Workflow Mode Awareness (fast single round)
+
+Before reviewing, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`):
+
+- **full**: plan review + code review (multiple points, unchanged).
+- **fast (Workflow Fast Line)**: **single round ×2, both mandatory** — ① \`plan_review\` **plan review (mandatory under fast**, on par with code review; pass → \`plan_passed\`, issues returned → \`plan_pending\`); ② code review after exec (the \`review_failed\` loop allows re-review / returning to exec for fixes); the **quality floor is unchanged** (issues are still recorded and blockers still raised; REV entries as usual).
+
+> **Terminology disambiguation**: the **Workflow Fast Line** (\`workflow_mode=fast\`, the flow mode) and **Fast Track (FAST-PASS)** (the review-depth downgrade mechanism defined in this template) are **different mechanisms** with similar names — do not cross-reference or conflate them.
+
 ## REV Template Specification
 
 \`\`\`yaml
@@ -1098,7 +1175,7 @@ openfeel-reviewer must be driven by a **heterogenous reasoning model** (such as
 | Requires judgment (default blocking) | Serious coding convention violations / Cross-module consistency issues | \`true\` |
 | Non-blocking | Naming suggestions / Comment improvements / Style tweaks / Optimization suggestions | \`false\` |
 
-> When fast track is hit, REV defaults to \`blocking=false\` (except for security vulnerabilities).
+> When fast track is hit, REV defaults to \`blocking=false\` (except for security vulnerabilities). This mechanism is unrelated to the Workflow Fast Line — see "Workflow Mode Awareness".
 
 ## blocking and Pipeline Behavior
 
@@ -1218,6 +1295,7 @@ When third-party dependencies are involved:
 
 - Receives dispatch from Feel to start, outputs are reviewed by openfeel-reviewer before being handed to openfeel-executor
 - When review fails, re-formulate the scheme based on openfeel-reviewer feedback
+- **Workflow Mode Awareness**: under the fast Workflow Fast Line this agent is **not dispatched** (the scheme step is skipped per \`status.md\` "Workflow Mode"); the role definition is unchanged.
 
 ## Notes
 
@@ -1575,6 +1653,47 @@ Agent 模型需求对照：
 3. **用户拒绝**：Feel 保持 \`auto_advance=disabled\`，每次阶段推进前均需向用户确认（手动执行模式）。
 4. **禁止静默推进**：\`auto_advance=disabled\` 时禁止 Feel 不询问用户直接推进流水线。
 
+#### 工作流模式（workflow_mode）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询：\`openfeel flow mode [--stage <id>]\`；字段缺失时按级联口径回落）。两种模式：
+
+- **full（完整流程）**：planner → plan_review（reviewer）→ schemer → executor → reviewer → tester → archiver。
+- **fast（工作流快线）**：planner（轻量）→ plan_review（**计划审查单轮，必经**）→ executor → reviewer（单轮）→ archiver（轻量）；**不派发 schemer / tester**。
+
+fast 调度纪律：
+
+1. **质量底线不可跳**：reviewer 在 fast 下**必跑两处**——① \`plan_review\` 计划审查（**必经单轮**，与代码审查同级；通过 → \`plan_passed\`，问题退回 → \`plan_pending\`）；② exec 后代码审查（单轮）；\`review_failed\` 回环可重审或回执行修复；失败留痕照常（REV 条目照常）。
+2. **轻量化**：planner / archiver 轻量产出（**不得**省略任务表 / 依赖 / 验收要点与状态记录 / 知识暂存判定）。
+3. **相位口径**：fast 下可达相位为快线链（\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`）；**合法相位枚举 15 项不变**（fast 下 6 项不可达：\`scheme_*\` / \`test_*\`）。
+4. **骨架全量不变**：fast 不裁剪任何落盘结构，仅减少 Agent 接力环节。
+5. **术语消歧**：流程模式称「**工作流快线**」（\`workflow_mode=fast\`）；审查深度降级称「**快速通道 / fast track（FAST-PASS）**」——二者为不同机制，不得互相引用 / 混用。
+
+#### 需求流转（requirement lifecycle）
+
+需求层位于「版本 → 需求 REQ-NNN → 计划 stage → 方案 op」四层模型的第二层：**需求 = 排期与调度层**，回答「做什么、何时做」；**实现仍走完整流水线**——需求不等于计划，接取需求后按「小改 vs 大规模规划的阈值」照常委托 openfeel-planner 产出 plan.md。
+
+需求共 7 个状态：\`draft\` → \`scheduled\` → \`in_progress\` → \`done\`，另有 \`blocked\` / \`cancelled\` / \`rejected\` 三个旁路状态。需求进度由关联阶段的 phase 聚合（投影方向单一：阶段 phase → 需求状态；全部关联阶段 done 时需求自动收口 done——前置集限定：仅 \`scheduled\` / \`in_progress\`；\`draft\` / \`blocked\` / 终态不触发）。
+
+需求生命周期动作（命令组 \`openfeel req\`，共 10 个子命令）：
+
+| 步骤 | 动作 | 命令 |
+|------|------|------|
+| 接取 | 浏览需求视图，挑选下一个可接取需求 | \`openfeel req board\` / \`openfeel req next\` / \`openfeel req list\` |
+| 认领 | 占用需求（已被他人认领则拒绝——防并发覆盖，无 TTL） | \`openfeel req claim <REQ-NNN>\` |
+| 关联 | 把需求关联到实现它的阶段 | \`openfeel req link --stage <stageId> --requirement <REQ-NNN>\` |
+| 流转 | 阶段推进驱动聚合；显式流转按合法目标推进 | \`openfeel req advance <REQ-NNN> --to <status>\` |
+| 完成 | 全部关联阶段 done 后需求自动 done；总览与释放 | \`openfeel req board\` / \`openfeel req release <REQ-NNN>\` |
+
+> 正交注记：需求流转与工作流模式（\`full\` / \`fast\`）正交——两种模式下需求纪律一致。
+
+#### 归档与历史读取
+
+版本收官（该版本全部阶段 done）后，提示用户可执行版本归档（\`openfeel flow archive <version>\`——判据门校验后先写归档文件、再移除活跃条目）：归档动作由 CLI 执行，调度侧只提示不代劳。
+
+- 不主动读归档文件：常规调度不得读取 \`.openfeel/flow-archive/**\`（防上下文污染）；活跃集经 \`openfeel flow status\` / \`openfeel flow overview\` 即为全量工作视图。
+- 按需查询历史：确需历史版本时用 \`openfeel flow archive show <version>\`（单版本只读）或 \`openfeel flow archive list\`（列举版本），不直接读文件。
+- 与顶层 \`openfeel archive\` 区分：顶层命令是阶段摘要归档；\`flow archive\` 是 flow.json 版本分片归档，二者职责不同。
+
 ## 小改 vs 大规模规划的阈值
 
 根据变更规模选择适当的流程路径：
@@ -1642,7 +1761,7 @@ Agent 模型需求对照：
 
 ### 骨架文件提示
 
-关键操作（推进到 exec_running / review_pending / test_pending / archiving）时，流水线会自动在私域日志目录创建带日期前缀的骨架文件。Feel 无需手动创建日志文件，看到骨架文件时填充内容即可。
+关键操作（推进到 exec_running / review_pending / test_pending / archiving）时，流水线会自动在私域日志目录创建带日期前缀的骨架文件（fast 工作流快线下 \`test_pending\` 仍为合法相位、仅不可达（无入边），该相位骨架不再产生；其余骨架规则全量不变）。Feel 无需手动创建日志文件，看到骨架文件时填充内容即可。
 
 ### 日志条目格式
 
@@ -1903,6 +2022,15 @@ openfeel-feel-tester 通过 → Feel 触发归档 → openfeel-archiver 整理
 
 > ⚠️ 注意：归档完成后的阶段状态必须设为 \`"done"\`，**不得**使用 \`"completed"\` 等非标准值。\`VALID_TRANSITIONS\` 中不存在 \`"completed"\`。
 
+> **fast 工作流快线下**：上表 15 项相位枚举**不变**（可达 ≠ 合法）；可达相位为快线链（\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`）。
+
+## 工作流模式感知（fast 轻量归档）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询 \`openfeel flow mode [--stage <id>]\`）：
+
+- **full**：归档全量清单（现状不变）。
+- **fast（工作流快线）**：**轻量归档**——状态记录与知识暂存判定（含去重检索）**不得省略**；清单过程性叙述可合并精简。（轻量口径：保留 状态记录 / 知识暂存判定 / 知识库快速概览 / 模块手册判定 / 公共日志摘要；总结过程性叙述可合并为要点。）
+
 ## 模型选择
 
 openfeel-archiver 由**推理模型**（如 DeepSeek V4 Pro）驱动，负责理解上下文并提取有价值的经验。
@@ -1912,7 +2040,7 @@ description: openfeel-executor 执行官 Agent，快速模型，按操作方案
 mode: subagent
 model: deepseek/deepseek-flash
 reasoning_effort: medium
-color: "#D94A4A"
+color: "#4CAF50"
 permission:
   bash: "allow"
   read: "allow"
@@ -1978,9 +2106,10 @@ permission:
 
 ### 步骤 2：Phase 合法性校验
 
-1. 读取 \`.openfeel/flow.json\`，检查 \`pipeline.phase\` 是否为合法枚举值（\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`），非法则拒绝执行。
+1. 读取 \`.openfeel/flow.json\`，检查 \`pipeline.phase\` 是否为合法枚举值（\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`），非法则拒绝执行。（fast 工作流快线下可达相位为快线链；合法相位枚举 15 项不变——可达 ≠ 合法）
 2. 确认 \`pipeline.current.op\` 与当前 op-id 匹配，不匹配则拒绝执行。
 3. 当前 phase 不是 \`exec_running\` 时：若 Feel 已明确指示执行可继续但需注明 phase 偏差；否则拒绝执行。
+4. **fast 工作流快线下相位路径**：\`plan_pending → plan_review → plan_passed → exec_running\`（计划审查为必经单轮：通过后进入本环节）；\`review_failed → exec_running\` 回环（审查不通过时回执行修复；\`review_failed → review_pending\` 重审出口保留）。
 
 ### 步骤 3：FlowManager 流转合法性校验
 
@@ -2121,7 +2250,7 @@ openfeel-executor 由**快速模型**（如 DeepSeek V4 Flash）驱动，编码
 description: openfeel-feel-tester 测试官 Agent，推理模型驱动，负责流水线中的正式测试验收。
 mode: subagent
 reasoning_effort: medium
-color: "#E8A838"
+color: "#22D3EE"
 permission:
   bash: "allow"
   read: "allow"
@@ -2220,6 +2349,7 @@ high 优先级 Bug 修复后，推荐执行全量测试套件。
 - 发现问题后通知 openfeel-schemer 制定修复方案
 - 修复后重新测试直到通过
 - 测试通过后通知 Feel 进入归档阶段
+- **工作流模式感知**：fast 工作流快线下本 Agent **不被调度**（依据 \`status.md「工作流模式」\` 跳过正式测试环节，\`test_*\` 相位不可达）；职责定义不变。
 
 ## 模型选择
 
@@ -2334,6 +2464,22 @@ openfeel-planner 作为独立子 Agent 由 Feel 按需唤起。Feel 根据规划
 - 不直接编码，不执行测试
 - openfeel-planner 与 openfeel-schemer 的职责边界：openfeel-planner 负责"做什么"（what）和"何时做"（when），openfeel-schemer 负责"怎么做"（how）
 
+## 工作流模式感知（fast 快线）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询 \`openfeel flow mode [--stage <id>]\`）：
+
+- **full**：产出经 openfeel-reviewer 计划审查（\`plan_review\`）后进入 openfeel-schemer（现状不变）。
+- **fast（工作流快线）**：**本 Agent 产出后必经 openfeel-reviewer 的计划审查（\`plan_review\` 单轮；通过 → \`plan_passed\`，问题退回 → \`plan_pending\`；此后进入 exec）**；产出为轻量计划——任务表 / 依赖声明 / 验收要点**不得省略**，其余过程性描述可精简。（轻量口径：保留 目标 / 依赖 / 任务表 / 验收要点 / 约束 / KB 检索 / 变更点清单 / 风险；背景实测证据明细与修订记录过程可收敛为结论。）
+
+## 需求感知
+
+当任务源自需求（\`REQ-NNN\`）时：
+
+- 读取需求：先以 \`openfeel req show <REQ-NNN>\` 读取需求详情（标题 / 状态 / 认领人 / 关联阶段），作为计划输入。
+- 计划关联需求：产出的 \`plan.md\` 头部标注「关联需求：REQ-NNN」；无需求来源时省略该标注。
+- 流转不在本 Agent 职责内：需求状态流转（认领 / 关联 / 推进）经 \`openfeel req\` CLI 执行；本 Agent 只读不写（不直写 flow.json）。
+- 与「工作流模式感知」正交：\`full\` / \`fast\` 下需求感知口径一致。
+
 ## 模型选择
 
 openfeel-planner 由**推理模型**（如 DeepSeek V4 Pro）驱动。在 Feel 体系设计中，openfeel-planner 职责可由 Feel 兼任，但作为独立 Agent 定义存在以支持灵活的调度策略。
@@ -2346,7 +2492,7 @@ description: openfeel-reviewer 审查官 Agent，异种推理模型，负责交
 mode: subagent
 model: zhipuai/glm-5.3-flash
 reasoning_effort: medium
-color: "#D4A017"
+color: "#EC4899"
 permission:
   bash: "allow"
   read: "allow"
@@ -2413,6 +2559,15 @@ permission:
 
 若任一条件不满足，跳过快速通道，执行完整审查流程。
 
+## 工作流模式感知（fast 单轮）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询 \`openfeel flow mode [--stage <id>]\`）：
+
+- **full**：计划审查 + 代码审查（多轮位点，现状不变）。
+- **fast（工作流快线）**：**单轮 ×2，两处均必跑**——① \`plan_review\` **计划审查（fast 下必经**，与代码审查同级；通过 → \`plan_passed\`，问题退回 → \`plan_pending\`）；② exec 后代码审查（\`review_failed\` 回环可重审 / 回执行修复）；**质量底线不变**（问题照记、阻断照留，REV 条目照常）。
+
+> **术语消歧**：本节的「**工作流快线**」（\`workflow_mode=fast\`，流程模式）与本模板「**快速通道 / fast track（FAST-PASS）**」（审查深度降级机制）为**不同机制**、同名异义——不得互相引用 / 混用。
+
 ## REV 模板规范
 
 \`\`\`yaml
@@ -2454,7 +2609,7 @@ openfeel-reviewer 必须由**异种推理模型**（如 GLM / Qwen）驱动，
 | 需判定（默认阻塞） | 编码规范严重违反 / 跨模块一致性问题 | \`true\` |
 | 非阻塞 | 命名建议 / 注释完善 / 风格微调 / 优化建议 | \`false\` |
 
-> 快速通道命中时，REV 默认 \`blocking=false\`（安全漏洞除外）。
+> 快速通道命中时，REV 默认 \`blocking=false\`（安全漏洞除外）。该机制与「工作流快线」无关——见「工作流模式感知」节。
 
 ## blocking 与流水线行为
 
@@ -2574,6 +2729,7 @@ permission:
 
 - 接收 Feel 调度启动，产出方案经 openfeel-reviewer 审查后交 openfeel-executor 执行
 - 审查不通过时，根据 openfeel-reviewer 反馈重新制定方案
+- **工作流模式感知**：fast 工作流快线下本 Agent **不被调度**（依据 \`status.md「工作流模式」\` 跳过方案环节）；职责定义不变。
 
 ## 注意事项
 
@@ -2740,7 +2896,7 @@ Not all tasks must go through the full pipeline. Non-coding tasks and coding tas
 | Task Type | Handling Path | Notes |
 |-----------|---------------|-------|
 | Research/exploration (reading code, consulting references, locating issues) | Feel → research (general / explore Agent) | Read-only exploration, no source code changes; flow.json need not spin up for this |
-| Coding implementation (adding/modifying source code) | Full pipeline (openfeel-planner → openfeel-schemer → openfeel-executor → openfeel-reviewer → openfeel-feel-tester) | Involves source changes, must go through the full audit chain |
+| Coding implementation (adding/modifying source code) | Full pipeline (openfeel-planner → openfeel-schemer → openfeel-executor → openfeel-reviewer → openfeel-feel-tester) (full); in fast mode: planner → plan review (reviewer, single mandatory round) → executor → code review (reviewer) → archiver (see status.md "Workflow Mode" / openfeel flow mode) | Involves source changes, must go through the full audit chain (fast-line audit chain in fast mode) |
 | Selection discussion (settling a technical approach / design trade-off) | Feel + \`question\` tool | Conversational decision, produces a conclusion, no plan.md |
 
 > Non-coding tasks (research, selection discussion) do not require creating a plan or advancing the pipeline; the pipeline is engaged only when source changes or a formal plan document is produced.
@@ -2803,7 +2959,7 @@ When encountering technical issues, **the first action MUST be to consult the kn
    - openfeel-utility Agent performs mechanical file operations, does not participate in design decisions
    - openfeel-archiver archives and distills knowledge, does not modify source code; does not write flow.json directly (written via Feel)
 
-3. **Feel orchestration constraint**: Feel, as the overall commander, uniformly orchestrates downstream Agents (openfeel-planner / openfeel-schemer / openfeel-executor / openfeel-reviewer / openfeel-feel-tester / openfeel-utility Agent / openfeel-vision / openfeel-archiver), advancing serially via the \`task\` tool according to pipeline phases (plan → scheme → execute → review → test → archive). Each Agent operates only within its own responsibility boundary and must not start other Agents beyond its scope or modify flow.json state on its own.
+3. **Feel orchestration constraint**: Feel, as the overall commander, uniformly orchestrates downstream Agents (openfeel-planner / openfeel-schemer / openfeel-executor / openfeel-reviewer / openfeel-feel-tester / openfeel-utility Agent / openfeel-vision / openfeel-archiver), advancing serially via the \`task\` tool according to pipeline phases (plan → scheme → execute → review → test → archive) (full); in fast mode: plan → plan review → execute → code review → archive (see status.md "Workflow Mode" / openfeel flow mode). Each Agent operates only within its own responsibility boundary and must not start other Agents beyond its scope or modify flow.json state on its own.
 
 4. **Lightweight decision boundary**: Conversational selections (Feel and the user settle a technical direction or design trade-off via the \`question\` tool, producing a conclusion but no plan.md) are handled by Feel directly, without delegating to openfeel-planner; only when a **formal plan document** (plan.md, including stage division, task table, constraint table) is needed, or the planning scale threshold is reached, should openfeel-planner be delegated. Avoid the extremes of "handle everything personally" or "delegate everything".
 
@@ -2856,7 +3012,7 @@ Version progression must be prudent, using the four-level X.Y.Z.W version number
 | Level 4 (W) | Feature detail | Independently committed feature or submodule |
 
 When Feel starts a new version, it defaults to incrementing the fourth level (W+1), unless the user explicitly specifies otherwise.
-The OpenFeel framework has released the official v1.0.x (currently v1.1.6). After deploying the global constraints via openfeel setup, new projects set their own starting version number as needed.
+The OpenFeel framework has released the official v1.0.x (currently v1.2.0). After deploying the global constraints via openfeel setup, new projects set their own starting version number as needed.
 
 ### Module Manuals
 
@@ -3249,7 +3405,7 @@ AI Agent 行为约束与编码规范。本文件为永久性约束，适用于
 | 任务类型 | 处理路径 | 说明 |
 |----------|----------|------|
 | 调研/探索（读代码、查资料、定位问题） | Feel → research（general / explore Agent） | 只读探索，不产出源码变更，flow.json 不必为此空转 |
-| 编码实现（新增/修改源码） | 完整流水线（openfeel-planner → openfeel-schemer → openfeel-executor → openfeel-reviewer → openfeel-feel-tester） | 有源码变更，须走完整审计链 |
+| 编码实现（新增/修改源码） | 完整流水线（openfeel-planner → openfeel-schemer → openfeel-executor → openfeel-reviewer → openfeel-feel-tester）（full）；fast 工作流快线（workflow_mode=fast）下为 planner → 计划审查（reviewer，单轮必经）→ executor → 代码审查（reviewer）→ archiver——见 status.md「工作流模式」 / openfeel flow mode | 有源码变更，须走完整审计链（fast 走快线审计链） |
 | 选型讨论（敲定技术方案/设计取舍） | Feel + \`question\` 工具 | 对话式决策，产出结论，不产出 plan.md |
 
 > 非编码任务（调研、选型讨论）不强制创建计划或推进流水线；仅当产生源码变更或正式计划文档时才接入流水线。
@@ -3312,7 +3468,7 @@ AI Agent 行为约束与编码规范。本文件为永久性约束，适用于
    - 事务官 执行文件机械操作，不参与设计决策
    - openfeel-archiver 归档和沉淀知识，不修改源码；不直写 flow.json（通过 Feel 写入）
 
-3. **Feel 调度约束**：Feel 总统领统一调度下游 Agent（openfeel-planner / openfeel-schemer / openfeel-executor / openfeel-reviewer / openfeel-feel-tester / 事务官 / openfeel-vision / openfeel-archiver），通过 \`task\` 工具按流水线阶段（计划→方案→执行→审查→测试→归档）串行推进。各 Agent 仅在自己的职责边界内操作，不得越界启动其他 Agent 或自行修改 flow.json 状态。
+3. **Feel 调度约束**：Feel 总统领统一调度下游 Agent（openfeel-planner / openfeel-schemer / openfeel-executor / openfeel-reviewer / openfeel-feel-tester / 事务官 / openfeel-vision / openfeel-archiver），通过 \`task\` 工具按流水线阶段（计划→方案→执行→审查→测试→归档）串行推进（full）；fast 工作流快线下为 计划 → 计划审查 → 执行 → 代码审查 → 归档（见 status.md「工作流模式」 / openfeel flow mode）。各 Agent 仅在自己的职责边界内操作，不得越界启动其他 Agent 或自行修改 flow.json 状态。
 
 4. **轻量决策边界**：对话式选型（Feel 与用户通过 \`question\` 工具敲定技术方向/设计取舍，产出结论不产出 plan.md）由 Feel 直接处理，不委托 openfeel-planner；仅当需要**产出正式计划文档**（plan.md，含阶段划分、任务表、约束表）或达到规划规模阈值时，才委托 openfeel-planner。避免"要么全亲为、要么全委托"的极端。
 
@@ -3365,7 +3521,7 @@ AI Agent 行为约束与编码规范。本文件为永久性约束，适用于
 | 四级（W） | 功能细节 | 独立提交的功能或子模块 |
 
 Feel 启动新版本时默认使用四级版本递增（W+1），除非用户明确指定。
-OpenFeel 框架已发布正式版 v1.0.x（当前 v1.1.6）。新项目经 openfeel setup 部署全局约束后，按自身需求设定起始版本号。
+OpenFeel 框架已发布正式版 v1.0.x（当前 v1.2.0）。新项目经 openfeel setup 部署全局约束后，按自身需求设定起始版本号。
 
 ### 模块手册
 
@@ -3986,6 +4142,47 @@ When a stage enters \`plan_passed\` and the project's \`auto_advance\` is set to
 3. **User declines**: Feel keeps \`auto_advance=disabled\` and requires user confirmation before each stage advance (manual execution mode).
 4. **No silent advancement**: When \`auto_advance=disabled\`, Feel must not advance the pipeline without asking the user.
 
+#### Workflow Mode (workflow_mode)
+
+Before dispatching, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`; when the field is absent, fall back per the cascade). Two modes:
+
+- **full (complete flow)**: planner → plan_review (reviewer) → schemer → executor → reviewer → tester → archiver.
+- **fast (Workflow Fast Line)**: planner (lightweight) → plan_review (**single mandatory plan review**) → executor → reviewer (single round) → archiver (lightweight); **does not dispatch openfeel-schemer / openfeel-feel-tester**.
+
+Fast-mode discipline:
+
+1. **The quality floor cannot be skipped**: under fast the reviewer **runs twice** — ① \`plan_review\` plan review (**mandatory single round**, on par with code review; pass → \`plan_passed\`, issues returned → \`plan_pending\`); ② code review after exec (single round); the \`review_failed\` loop allows re-review or returning to exec for fixes; failures are recorded as usual (REV entries unchanged).
+2. **Lightweight**: planner / archiver produce lightweight output (**must not** omit the task table / dependencies / acceptance points, or the state record / knowledge-staging decision).
+3. **Phase semantics**: under fast, reachable phases are the fast-line chain (\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`); the **legal phase enumeration remains at 15** (6 phases are unreachable under fast: \`scheme_*\` / \`test_*\`).
+4. **Full skeletons unchanged**: fast trims no on-disk structure; it only reduces agent relay steps.
+5. **Terminology disambiguation**: the flow mode is called the **Workflow Fast Line** (\`workflow_mode=fast\`); the review-depth downgrade is called **Fast Track (FAST-PASS)** — they are different mechanisms and must not be cross-referenced or conflated.
+
+#### Requirement Lifecycle
+
+The requirement layer is the second layer of the four-layer model "version → requirement REQ-NNN → plan stage → op": **a requirement is the scheduling layer**, answering "what to do and when"; **implementation still goes through the full pipeline** — a requirement is not a plan; after taking a requirement, delegate to openfeel-planner for plan.md per the "Threshold for Small Changes vs. Large-Scale Planning" as usual.
+
+A requirement has 7 statuses: \`draft\` → \`scheduled\` → \`in_progress\` → \`done\`, plus three side states \`blocked\` / \`cancelled\` / \`rejected\`. Requirement progress is aggregated from the linked stages' phases (single projection direction: stage phase → requirement status; the requirement is closed as done automatically once all linked stages are done — precondition: only \`scheduled\` / \`in_progress\`; \`draft\` / \`blocked\` / terminal states do not trigger).
+
+Requirement lifecycle actions (command group \`openfeel req\`, 10 subcommands):
+
+| Step | Action | Command |
+|------|--------|---------|
+| Take | Browse requirement views and pick the next takeable requirement | \`openfeel req board\` / \`openfeel req next\` / \`openfeel req list\` |
+| Claim | Claim the requirement (rejected if already claimed by another — guards concurrent overwrite; no TTL) | \`openfeel req claim <REQ-NNN>\` |
+| Link | Link the requirement to the stages implementing it | \`openfeel req link --stage <stageId> --requirement <REQ-NNN>\` |
+| Advance | Stage advancement drives aggregation; advance explicitly along legal targets | \`openfeel req advance <REQ-NNN> --to <status>\` |
+| Complete | Auto-done once all linked stages are done; overview and release | \`openfeel req board\` / \`openfeel req release <REQ-NNN>\` |
+
+> Orthogonality note: requirement flow is orthogonal to the workflow mode (\`full\` / \`fast\`) — the requirement discipline is identical in both modes.
+
+#### Archiving and History Reading
+
+Once a version is finalized (all its stages done), prompt the user that version archiving is available (\`openfeel flow archive <version>\` — after the criteria gate passes, the archive file is written first and the active entries removed afterwards): the archiving action is executed by the CLI; dispatch only prompts, never performs it.
+
+- Never read archive files proactively: regular dispatch must not read \`.openfeel/flow-archive/**\` (to prevent context pollution); the active set via \`openfeel flow status\` / \`openfeel flow overview\` is the full working view.
+- Query history on demand: when history is genuinely needed, use \`openfeel flow archive show <version>\` (single version, read-only) or \`openfeel flow archive list\` (enumerate versions); do not read the files directly.
+- Distinct from top-level \`openfeel archive\`: the top-level command is stage-summary archiving; \`flow archive\` is flow.json version-shard archiving — different responsibilities.
+
 ## Threshold for Small Changes vs. Large-Scale Planning
 
 Choose the appropriate process path based on the change scale:
@@ -4053,7 +4250,7 @@ A shared log entry (\`.openfeel/log/yyyy-mm-dd-feel-NNN.md\`) must be created wh
 
 ### Skeleton File Note
 
-During critical operations (advancing to exec_running / review_pending / test_pending / archiving), the pipeline automatically creates skeleton files with date prefixes in the private log directory. Feel does not need to manually create log files; simply fill in the content when you see a skeleton file.
+During critical operations (advancing to exec_running / review_pending / test_pending / archiving), the pipeline automatically creates skeleton files with date prefixes in the private log directory (under the fast Workflow Fast Line, \`test_pending\` remains a legal phase but is unreachable (no inbound edge), so its skeleton is no longer produced; all other skeleton rules are unchanged). Feel does not need to manually create log files; simply fill in the content when you see a skeleton file.
 
 ### Log Entry Format
 
@@ -4315,6 +4512,15 @@ After archiving is complete, the stage's pipeline phase must be set to one of th
 
 > ⚠️ Note: After archiving is complete, the stage status must be set to \`"done"\`, **do not** use non-standard values like \`"completed"\`. \`"completed"\` does not exist in \`VALID_TRANSITIONS\`.
 
+> **Under the fast Workflow Fast Line**: the 15-phase enumeration above is **unchanged** (reachable ≠ legal); reachable phases are the fast-line chain (\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`).
+
+## Workflow Mode Awareness (fast lightweight archiving)
+
+Before archiving, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`):
+
+- **full**: full archiving checklist (unchanged).
+- **fast (Workflow Fast Line)**: **lightweight archiving** — the state record and the knowledge-staging decision (including the dedup lookup) **must not be omitted**; checklist process narrative may be merged and condensed. (Lightweight scope: keep the state record / knowledge-staging decision / kb index quick overview / manual update decision / shared log summary; summary process narrative may be merged into bullet points.)
+
 ## Model Selection
 
 openfeel-archiver is driven by a **reasoning model** (such as DeepSeek V4 Pro), responsible for understanding context and extracting valuable experience.
@@ -4324,7 +4530,7 @@ description: openfeel-executor Agent, fast model, implements code according to o
 mode: subagent
 model: deepseek/deepseek-flash
 reasoning_effort: medium
-color: "#D94A4A"
+color: "#4CAF50"
 permission:
   bash: "allow"
   read: "allow"
@@ -4390,9 +4596,10 @@ Confirm that the following 6 required fields are present. If any is missing, ret
 
 ### Step 2: Phase Legitimacy Check
 
-1. Read \`.openfeel/flow.json\`, check if \`pipeline.phase\` is a valid enum value (\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`); refuse to execute if invalid.
+1. Read \`.openfeel/flow.json\`, check if \`pipeline.phase\` is a valid enum value (\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`); refuse to execute if invalid. (under the fast Workflow Fast Line, reachable phases are the fast-line chain; the legal phase enumeration remains at 15 — reachable ≠ legal)
 2. Confirm \`pipeline.current.op\` matches the current op-id; refuse to execute if mismatched.
 3. When the current phase is not \`exec_running\`: if Feel explicitly instructs execution, it may proceed but must note the phase deviation; otherwise, refuse to execute.
+4. **Fast-mode phase paths**: \`plan_pending → plan_review → plan_passed → exec_running\` (the plan review is a mandatory single round; the step is entered only after it passes); the \`review_failed → exec_running\` loop (review failure returns to exec for fixes; the \`review_failed → review_pending\` re-review exit is retained).
 
 ### Step 3: FlowManager Transition Legitimacy Check
 
@@ -4533,7 +4740,7 @@ Delegable targets: openfeel-vision (analyze screenshots), openfeel-reviewer (pre
 description: openfeel-feel-tester Agent, reasoning model, responsible for formal testing and acceptance in the pipeline.
 mode: subagent
 reasoning_effort: medium
-color: "#E8A838"
+color: "#22D3EE"
 permission:
   bash: "allow"
   read: "allow"
@@ -4632,6 +4839,7 @@ Write regression verification results into the Bug file's "Acceptance Record" ta
 - When issues are found, notify openfeel-schemer to formulate a revision
 - Re-test after fixes until passing
 - When tests pass, notify Feel to enter the archiving phase
+- **Workflow Mode Awareness**: under the fast Workflow Fast Line this agent is **not dispatched** (the formal test step is skipped per \`status.md\` "Workflow Mode"; the \`test_*\` phases are unreachable); the role definition is unchanged.
 
 ## Model Selection
 
@@ -4746,6 +4954,22 @@ This step ensures openfeel-planner absorbs existing project knowledge before mak
 - Does not directly code or execute tests
 - openfeel-planner and openfeel-schemer responsibility boundary: openfeel-planner is responsible for "what" (what) and "when" (when), openfeel-schemer is responsible for "how" (how)
 
+## Workflow Mode Awareness (fast)
+
+Before planning, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`):
+
+- **full**: the output goes through openfeel-reviewer plan review (\`plan_review\`) before openfeel-schemer (unchanged).
+- **fast (Workflow Fast Line)**: **this agent's output must pass openfeel-reviewer's plan review (\`plan_review\`, single round; pass → \`plan_passed\`, issues returned → \`plan_pending\`; only then does it enter exec)**; produce a lightweight plan — the task table / dependencies / acceptance points **must not be omitted**; other process narrative may be trimmed. (Lightweight scope: keep goals / dependencies / task table / acceptance points / constraints / KB retrieval / change-point list / risks; background evidence details and revision history may be condensed.)
+
+## Requirement Awareness
+
+When a task originates from a requirement (\`REQ-NNN\`):
+
+- Read the requirement: first read the requirement details (title / status / owner / linked stages) via \`openfeel req show <REQ-NNN>\` as plan input.
+- Link the plan to the requirement: annotate the header of the produced \`plan.md\` with "Linked requirement: REQ-NNN"; omit the annotation when there is no requirement source.
+- Flow is not this agent's duty: requirement status transitions (claim / link / advance) are executed via the \`openfeel req\` CLI; this agent is read-only (no direct flow.json writes).
+- Orthogonal to "Workflow Mode Awareness": requirement awareness is identical under \`full\` / \`fast\`.
+
 ## Model Selection
 
 openfeel-planner is driven by a **reasoning model** (such as DeepSeek V4 Pro). In the Feel system design, openfeel-planner duties can be concurrently handled by Feel, but exist as an independent agent definition to support flexible scheduling strategies.
@@ -4758,7 +4982,7 @@ description: openfeel-reviewer Agent, heterogenous reasoning model, responsible
 mode: subagent
 model: zhipuai/glm-5.3-flash
 reasoning_effort: medium
-color: "#D4A017"
+color: "#EC4899"
 permission:
   bash: "allow"
   read: "allow"
@@ -4825,6 +5049,15 @@ When **all three** of the following conditions are met, openfeel-reviewer enters
 
 If any condition is not met, skip fast track and execute full review process.
 
+## Workflow Mode Awareness (fast single round)
+
+Before reviewing, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`):
+
+- **full**: plan review + code review (multiple points, unchanged).
+- **fast (Workflow Fast Line)**: **single round ×2, both mandatory** — ① \`plan_review\` **plan review (mandatory under fast**, on par with code review; pass → \`plan_passed\`, issues returned → \`plan_pending\`); ② code review after exec (the \`review_failed\` loop allows re-review / returning to exec for fixes); the **quality floor is unchanged** (issues are still recorded and blockers still raised; REV entries as usual).
+
+> **Terminology disambiguation**: the **Workflow Fast Line** (\`workflow_mode=fast\`, the flow mode) and **Fast Track (FAST-PASS)** (the review-depth downgrade mechanism defined in this template) are **different mechanisms** with similar names — do not cross-reference or conflate them.
+
 ## REV Template Specification
 
 \`\`\`yaml
@@ -4866,7 +5099,7 @@ openfeel-reviewer must be driven by a **heterogenous reasoning model** (such as
 | Requires judgment (default blocking) | Serious coding convention violations / Cross-module consistency issues | \`true\` |
 | Non-blocking | Naming suggestions / Comment improvements / Style tweaks / Optimization suggestions | \`false\` |
 
-> When fast track is hit, REV defaults to \`blocking=false\` (except for security vulnerabilities).
+> When fast track is hit, REV defaults to \`blocking=false\` (except for security vulnerabilities). This mechanism is unrelated to the Workflow Fast Line — see "Workflow Mode Awareness".
 
 ## blocking and Pipeline Behavior
 
@@ -4986,6 +5219,7 @@ When third-party dependencies are involved:
 
 - Receives dispatch from Feel to start, outputs are reviewed by openfeel-reviewer before being handed to openfeel-executor
 - When review fails, re-formulate the scheme based on openfeel-reviewer feedback
+- **Workflow Mode Awareness**: under the fast Workflow Fast Line this agent is **not dispatched** (the scheme step is skipped per \`status.md\` "Workflow Mode"); the role definition is unchanged.
 
 ## Notes
 
@@ -5343,6 +5577,47 @@ Agent 模型需求对照：
 3. **用户拒绝**：Feel 保持 \`auto_advance=disabled\`，每次阶段推进前均需向用户确认（手动执行模式）。
 4. **禁止静默推进**：\`auto_advance=disabled\` 时禁止 Feel 不询问用户直接推进流水线。
 
+#### 工作流模式（workflow_mode）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询：\`openfeel flow mode [--stage <id>]\`；字段缺失时按级联口径回落）。两种模式：
+
+- **full（完整流程）**：planner → plan_review（reviewer）→ schemer → executor → reviewer → tester → archiver。
+- **fast（工作流快线）**：planner（轻量）→ plan_review（**计划审查单轮，必经**）→ executor → reviewer（单轮）→ archiver（轻量）；**不派发 schemer / tester**。
+
+fast 调度纪律：
+
+1. **质量底线不可跳**：reviewer 在 fast 下**必跑两处**——① \`plan_review\` 计划审查（**必经单轮**，与代码审查同级；通过 → \`plan_passed\`，问题退回 → \`plan_pending\`）；② exec 后代码审查（单轮）；\`review_failed\` 回环可重审或回执行修复；失败留痕照常（REV 条目照常）。
+2. **轻量化**：planner / archiver 轻量产出（**不得**省略任务表 / 依赖 / 验收要点与状态记录 / 知识暂存判定）。
+3. **相位口径**：fast 下可达相位为快线链（\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`）；**合法相位枚举 15 项不变**（fast 下 6 项不可达：\`scheme_*\` / \`test_*\`）。
+4. **骨架全量不变**：fast 不裁剪任何落盘结构，仅减少 Agent 接力环节。
+5. **术语消歧**：流程模式称「**工作流快线**」（\`workflow_mode=fast\`）；审查深度降级称「**快速通道 / fast track（FAST-PASS）**」——二者为不同机制，不得互相引用 / 混用。
+
+#### 需求流转（requirement lifecycle）
+
+需求层位于「版本 → 需求 REQ-NNN → 计划 stage → 方案 op」四层模型的第二层：**需求 = 排期与调度层**，回答「做什么、何时做」；**实现仍走完整流水线**——需求不等于计划，接取需求后按「小改 vs 大规模规划的阈值」照常委托 openfeel-planner 产出 plan.md。
+
+需求共 7 个状态：\`draft\` → \`scheduled\` → \`in_progress\` → \`done\`，另有 \`blocked\` / \`cancelled\` / \`rejected\` 三个旁路状态。需求进度由关联阶段的 phase 聚合（投影方向单一：阶段 phase → 需求状态；全部关联阶段 done 时需求自动收口 done——前置集限定：仅 \`scheduled\` / \`in_progress\`；\`draft\` / \`blocked\` / 终态不触发）。
+
+需求生命周期动作（命令组 \`openfeel req\`，共 10 个子命令）：
+
+| 步骤 | 动作 | 命令 |
+|------|------|------|
+| 接取 | 浏览需求视图，挑选下一个可接取需求 | \`openfeel req board\` / \`openfeel req next\` / \`openfeel req list\` |
+| 认领 | 占用需求（已被他人认领则拒绝——防并发覆盖，无 TTL） | \`openfeel req claim <REQ-NNN>\` |
+| 关联 | 把需求关联到实现它的阶段 | \`openfeel req link --stage <stageId> --requirement <REQ-NNN>\` |
+| 流转 | 阶段推进驱动聚合；显式流转按合法目标推进 | \`openfeel req advance <REQ-NNN> --to <status>\` |
+| 完成 | 全部关联阶段 done 后需求自动 done；总览与释放 | \`openfeel req board\` / \`openfeel req release <REQ-NNN>\` |
+
+> 正交注记：需求流转与工作流模式（\`full\` / \`fast\`）正交——两种模式下需求纪律一致。
+
+#### 归档与历史读取
+
+版本收官（该版本全部阶段 done）后，提示用户可执行版本归档（\`openfeel flow archive <version>\`——判据门校验后先写归档文件、再移除活跃条目）：归档动作由 CLI 执行，调度侧只提示不代劳。
+
+- 不主动读归档文件：常规调度不得读取 \`.openfeel/flow-archive/**\`（防上下文污染）；活跃集经 \`openfeel flow status\` / \`openfeel flow overview\` 即为全量工作视图。
+- 按需查询历史：确需历史版本时用 \`openfeel flow archive show <version>\`（单版本只读）或 \`openfeel flow archive list\`（列举版本），不直接读文件。
+- 与顶层 \`openfeel archive\` 区分：顶层命令是阶段摘要归档；\`flow archive\` 是 flow.json 版本分片归档，二者职责不同。
+
 ## 小改 vs 大规模规划的阈值
 
 根据变更规模选择适当的流程路径：
@@ -5410,7 +5685,7 @@ Agent 模型需求对照：
 
 ### 骨架文件提示
 
-关键操作（推进到 exec_running / review_pending / test_pending / archiving）时，流水线会自动在私域日志目录创建带日期前缀的骨架文件。Feel 无需手动创建日志文件，看到骨架文件时填充内容即可。
+关键操作（推进到 exec_running / review_pending / test_pending / archiving）时，流水线会自动在私域日志目录创建带日期前缀的骨架文件（fast 工作流快线下 \`test_pending\` 仍为合法相位、仅不可达（无入边），该相位骨架不再产生；其余骨架规则全量不变）。Feel 无需手动创建日志文件，看到骨架文件时填充内容即可。
 
 ### 日志条目格式
 
@@ -5671,6 +5946,15 @@ openfeel-feel-tester 通过 → Feel 触发归档 → openfeel-archiver 整理
 
 > ⚠️ 注意：归档完成后的阶段状态必须设为 \`"done"\`，**不得**使用 \`"completed"\` 等非标准值。\`VALID_TRANSITIONS\` 中不存在 \`"completed"\`。
 
+> **fast 工作流快线下**：上表 15 项相位枚举**不变**（可达 ≠ 合法）；可达相位为快线链（\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`）。
+
+## 工作流模式感知（fast 轻量归档）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询 \`openfeel flow mode [--stage <id>]\`）：
+
+- **full**：归档全量清单（现状不变）。
+- **fast（工作流快线）**：**轻量归档**——状态记录与知识暂存判定（含去重检索）**不得省略**；清单过程性叙述可合并精简。（轻量口径：保留 状态记录 / 知识暂存判定 / 知识库快速概览 / 模块手册判定 / 公共日志摘要；总结过程性叙述可合并为要点。）
+
 ## 模型选择
 
 openfeel-archiver 由**推理模型**（如 DeepSeek V4 Pro）驱动，负责理解上下文并提取有价值的经验。
@@ -5680,7 +5964,7 @@ description: openfeel-executor 执行官 Agent，快速模型，按操作方案
 mode: subagent
 model: deepseek/deepseek-flash
 reasoning_effort: medium
-color: "#D94A4A"
+color: "#4CAF50"
 permission:
   bash: "allow"
   read: "allow"
@@ -5746,9 +6030,10 @@ permission:
 
 ### 步骤 2：Phase 合法性校验
 
-1. 读取 \`.openfeel/flow.json\`，检查 \`pipeline.phase\` 是否为合法枚举值（\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`），非法则拒绝执行。
+1. 读取 \`.openfeel/flow.json\`，检查 \`pipeline.phase\` 是否为合法枚举值（\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`），非法则拒绝执行。（fast 工作流快线下可达相位为快线链；合法相位枚举 15 项不变——可达 ≠ 合法）
 2. 确认 \`pipeline.current.op\` 与当前 op-id 匹配，不匹配则拒绝执行。
 3. 当前 phase 不是 \`exec_running\` 时：若 Feel 已明确指示执行可继续但需注明 phase 偏差；否则拒绝执行。
+4. **fast 工作流快线下相位路径**：\`plan_pending → plan_review → plan_passed → exec_running\`（计划审查为必经单轮：通过后进入本环节）；\`review_failed → exec_running\` 回环（审查不通过时回执行修复；\`review_failed → review_pending\` 重审出口保留）。
 
 ### 步骤 3：FlowManager 流转合法性校验
 
@@ -5889,7 +6174,7 @@ openfeel-executor 由**快速模型**（如 DeepSeek V4 Flash）驱动，编码
 description: openfeel-feel-tester 测试官 Agent，推理模型驱动，负责流水线中的正式测试验收。
 mode: subagent
 reasoning_effort: medium
-color: "#E8A838"
+color: "#22D3EE"
 permission:
   bash: "allow"
   read: "allow"
@@ -5988,6 +6273,7 @@ high 优先级 Bug 修复后，推荐执行全量测试套件。
 - 发现问题后通知 openfeel-schemer 制定修复方案
 - 修复后重新测试直到通过
 - 测试通过后通知 Feel 进入归档阶段
+- **工作流模式感知**：fast 工作流快线下本 Agent **不被调度**（依据 \`status.md「工作流模式」\` 跳过正式测试环节，\`test_*\` 相位不可达）；职责定义不变。
 
 ## 模型选择
 
@@ -6102,6 +6388,22 @@ openfeel-planner 作为独立子 Agent 由 Feel 按需唤起。Feel 根据规划
 - 不直接编码，不执行测试
 - openfeel-planner 与 openfeel-schemer 的职责边界：openfeel-planner 负责"做什么"（what）和"何时做"（when），openfeel-schemer 负责"怎么做"（how）
 
+## 工作流模式感知（fast 快线）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询 \`openfeel flow mode [--stage <id>]\`）：
+
+- **full**：产出经 openfeel-reviewer 计划审查（\`plan_review\`）后进入 openfeel-schemer（现状不变）。
+- **fast（工作流快线）**：**本 Agent 产出后必经 openfeel-reviewer 的计划审查（\`plan_review\` 单轮；通过 → \`plan_passed\`，问题退回 → \`plan_pending\`；此后进入 exec）**；产出为轻量计划——任务表 / 依赖声明 / 验收要点**不得省略**，其余过程性描述可精简。（轻量口径：保留 目标 / 依赖 / 任务表 / 验收要点 / 约束 / KB 检索 / 变更点清单 / 风险；背景实测证据明细与修订记录过程可收敛为结论。）
+
+## 需求感知
+
+当任务源自需求（\`REQ-NNN\`）时：
+
+- 读取需求：先以 \`openfeel req show <REQ-NNN>\` 读取需求详情（标题 / 状态 / 认领人 / 关联阶段），作为计划输入。
+- 计划关联需求：产出的 \`plan.md\` 头部标注「关联需求：REQ-NNN」；无需求来源时省略该标注。
+- 流转不在本 Agent 职责内：需求状态流转（认领 / 关联 / 推进）经 \`openfeel req\` CLI 执行；本 Agent 只读不写（不直写 flow.json）。
+- 与「工作流模式感知」正交：\`full\` / \`fast\` 下需求感知口径一致。
+
 ## 模型选择
 
 openfeel-planner 由**推理模型**（如 DeepSeek V4 Pro）驱动。在 Feel 体系设计中，openfeel-planner 职责可由 Feel 兼任，但作为独立 Agent 定义存在以支持灵活的调度策略。
@@ -6114,7 +6416,7 @@ description: openfeel-reviewer 审查官 Agent，异种推理模型，负责交
 mode: subagent
 model: zhipuai/glm-5.3-flash
 reasoning_effort: medium
-color: "#D4A017"
+color: "#EC4899"
 permission:
   bash: "allow"
   read: "allow"
@@ -6181,6 +6483,15 @@ permission:
 
 若任一条件不满足，跳过快速通道，执行完整审查流程。
 
+## 工作流模式感知（fast 单轮）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询 \`openfeel flow mode [--stage <id>]\`）：
+
+- **full**：计划审查 + 代码审查（多轮位点，现状不变）。
+- **fast（工作流快线）**：**单轮 ×2，两处均必跑**——① \`plan_review\` **计划审查（fast 下必经**，与代码审查同级；通过 → \`plan_passed\`，问题退回 → \`plan_pending\`）；② exec 后代码审查（\`review_failed\` 回环可重审 / 回执行修复）；**质量底线不变**（问题照记、阻断照留，REV 条目照常）。
+
+> **术语消歧**：本节的「**工作流快线**」（\`workflow_mode=fast\`，流程模式）与本模板「**快速通道 / fast track（FAST-PASS）**」（审查深度降级机制）为**不同机制**、同名异义——不得互相引用 / 混用。
+
 ## REV 模板规范
 
 \`\`\`yaml
@@ -6222,7 +6533,7 @@ openfeel-reviewer 必须由**异种推理模型**（如 GLM / Qwen）驱动，
 | 需判定（默认阻塞） | 编码规范严重违反 / 跨模块一致性问题 | \`true\` |
 | 非阻塞 | 命名建议 / 注释完善 / 风格微调 / 优化建议 | \`false\` |
 
-> 快速通道命中时，REV 默认 \`blocking=false\`（安全漏洞除外）。
+> 快速通道命中时，REV 默认 \`blocking=false\`（安全漏洞除外）。该机制与「工作流快线」无关——见「工作流模式感知」节。
 
 ## blocking 与流水线行为
 
@@ -6342,6 +6653,7 @@ permission:
 
 - 接收 Feel 调度启动，产出方案经 openfeel-reviewer 审查后交 openfeel-executor 执行
 - 审查不通过时，根据 openfeel-reviewer 反馈重新制定方案
+- **工作流模式感知**：fast 工作流快线下本 Agent **不被调度**（依据 \`status.md「工作流模式」\` 跳过方案环节）；职责定义不变。
 
 ## 注意事项
 
@@ -6784,7 +7096,7 @@ Skill 加载后，根据步骤 3 的匹配结果决定是否追加提示：
 `,
     'openfeel-cli-usage': `---
 name: openfeel-cli-usage
-description: OpenFeel CLI 命令用法参考：命令清单与关键参数、15 个 phase 枚举与转移表、stageId 命名与目录映射约定、v1.1.2 新增能力（自描述/可纠错、--json 结构化输出、health --fix、scheme draft、knowledge dedup、纠正清理侧命令面）、v1.1.4 新增能力（checkpoint 选择性恢复 --stage/--dry-run、flow stage reset 精准复位、故障恢复路径）、v1.1.5 新增能力（setup --check [--json] 诊断 / 被动部署提示）、v1.1.6 新增能力（Claude Code 适配器 \`--tools claude\` / settings 注入）。当需要查询 CLI 命令、参数、phase、stageId、阶段命名时加载。
+description: OpenFeel CLI 命令用法参考：命令清单与关键参数、15 个 phase 枚举与转移表、stageId 命名与目录映射约定、v1.1.2 新增能力（自描述/可纠错、--json 结构化输出、health --fix、scheme draft、knowledge dedup、纠正清理侧命令面）、v1.1.4 新增能力（checkpoint 选择性恢复 --stage/--dry-run、flow stage reset 精准复位、故障恢复路径）、v1.1.5 新增能力（setup --check [--json] 诊断 / 被动部署提示）、v1.1.6 新增能力（Claude Code 适配器 \`--tools claude\` / settings 注入）、v1.1.7 新增能力（双模式工作流 workflow_mode：flow mode 只读查询 / flow phases --mode 模式分节 / plan stage add --workflow-mode / stage set --workflow-mode / config set --sync-stages --stage）、v1.2.0 新增能力（需求流转命令组 \`openfeel req\`：需求 7 状态与 10 子命令 / 认领协议；flow.json 版本分片归档 \`flow archive\`：\`<version>\` / \`list\` / \`show\`）。当需要查询 CLI 命令、参数、phase、stageId、阶段命名时加载。
 ---
 
 # OpenFeel CLI 用法参考
@@ -6796,7 +7108,7 @@ description: OpenFeel CLI 命令用法参考：命令清单与关键参数、15
 - 与 \`openfeel-tool-usage\` 协同：工具选择规范见该 skill；本 skill 补充 CLI 命令细节。
 - 正文以**能力名**叙述；平台差异见 \`### opencode 适配器\` / \`### Claude Code 适配器\` 两小节。
 
-> 本文档为 v1.1.6 快照；命令/参数细节以 \`openfeel <cmd> --help\`（本仓执行）实时输出为准（CLI 演进后本文档可能滞后）。
+> 本文档为 v1.2.0 快照；命令/参数细节以 \`openfeel <cmd> --help\`（本仓执行）实时输出为准（CLI 演进后本文档可能滞后）。
 >
 > ⚠️ **本仓自举**：本仓（openfeel 源码仓库）开发/执行时请用 \`node bin/openfeel.js <cmd>\`；安装后使用 \`openfeel <cmd>\`。
 
@@ -6811,29 +7123,42 @@ description: OpenFeel CLI 命令用法参考：命令清单与关键参数、15
 | \`openfeel flow ...\` | 流水线状态管理 | 见下「flow 子命令」 |
 | \`openfeel flow checkpoint restore\` | Checkpoint 恢复（全量 / 选择性 / 预览） | \`<file> [--force] [--stage <id>] [--dry-run]\`（无 \`--stage\`=全量覆盖，最后手段；\`--stage\`=按阶段回退；\`--dry-run\`=零写盘预览） |
 | \`openfeel flow stage reset\` | 精准复位阶段 phase（\`flow advance\` 的对称复位，允许回退） | \`<stageId> --to <phase> [--dry-run]\`（受合法值域 + \`to=done\` 阻塞 REV 约束） |
-| \`openfeel plan stage add\\|list\` | 工作阶段管理 | \`add <name> --deps <ids...> --tasks <items...> --exec-mode <manual\\|auto> --auto-advance <enabled\\|disabled>\`（初值取 \`config.yaml.defaults\`；显式选项优先） |
+| \`openfeel plan stage add\\|list\` | 工作阶段管理 | \`add <name> --deps <ids...> --tasks <items...> --exec-mode <manual\\|auto> --auto-advance <enabled\\|disabled> --workflow-mode <full\\|fast>\`（初值取 \`config.yaml.defaults\`；显式选项优先；\`--workflow-mode\` 覆盖 config 默认） |
 | \`openfeel plan scheme create\\|publish\\|rename\\|list\\|remove\\|register\` | 操作方案管理 | \`create <stage> <title> [--draft]\`、\`publish <stage> <opId>\`、\`rename <stage> <opId> --title <text>\`、\`remove <stage> <opId> [--force] [--dry-run]\`、\`register <stage> [opId] [--dry-run]\`（补注册 fileOrphans） |
-| \`openfeel stage status\\|set\\|task\` | \`status.md\` 原子操作 | \`set <id> --status/--exec-mode/--auto-advance/--review-agent\`、\`task <id> [no] --add/--done/--undone\`（\`stage create\` 已弃用） |
-| \`openfeel config ...\` | 配置管理 | \`get\\|set <key> <value> [--global]\`（支持全量 \`defaults.*\`，且 \`defaults.X ≡ X\`）、\`set ... --sync-stages\`（批量写入所有已注册阶段 \`status.md\` 的 \`自动推进\`/\`执行模式\`）、\`get-lang\\|set-lang\`、\`list-projects\`、\`effective [key]\` |
+| \`openfeel stage status\\|set\\|task\` | \`status.md\` 原子操作 | \`set <id> --status/--exec-mode/--auto-advance/--review-agent/--workflow-mode\`、\`task <id> [no] --add/--done/--undone\`（\`stage create\` 已弃用） |
+| \`openfeel config ...\` | 配置管理 | \`get\\|set <key> <value> [--global]\`（支持全量 \`defaults.*\`，且 \`defaults.X ≡ X\`）、\`set ... --sync-stages [--stage <ids...>]\`（批量写入已注册阶段 \`status.md\` 的 \`自动推进\`/\`执行模式\`/\`工作流模式\`；\`--stage\` 限定作用域，单独使用 / 与 \`--global\` 组合 → exit 1）、\`get-lang\\|set-lang\`、\`list-projects\`、\`effective [key]\` |
 | \`openfeel model set\\|get\\|list\` | 模型三层级配置 | \`set <agent> <model>\` |
 | \`openfeel lint i18n\\|kb\` | 健康检查（i18n 键一致性 / kb 过期引用） | 发现问题**非 0 退出** |
 | \`openfeel knowledge ...\` | 知识库管理 | \`list\` / \`add\` / \`search\` / \`index\` / \`dedup\` |
 | \`openfeel archive <stage>\` | 归档指定阶段（汇总产出、生成摘要、提取知识） | \`<stage>\` |
+| \`openfeel req ...\` | 需求流转（需求管理命令组） | 见「v1.2.0 新增能力（stage-78~84）」节 |
 | \`openfeel view list\\|accept\` | 审查条目验收（\`add\` 已移除，改用 \`flow review add\`） | — |
 | \`openfeel project overview\` | 项目结构概览 | \`overview\`（无 \`list\`/\`info\` 子命令） |
 | \`openfeel roadmap create\\|show\` | 分期大纲管理 | \`create <version>\`、\`show [version]\` |
 | \`openfeel instructions <artifactId>\` | 为指定 artifact 生成结构化指令 | \`--change <name>\`、\`--schema <name>\`、\`--json\` |
 
-**flow 子命令**：\`status\` / \`current\` / \`overview\` / \`phases\` / \`stage\`（\`add\` / \`remove\` / \`set --deps\` / **\`reset <id> --to <phase> [--dry-run]\`**）/ \`metrics\` / \`advance\`（\`--stage <id> --to <phase>\`、\`--op\`、\`--force\`、\`--dry-run\`、\`--quiet\`）/ \`attempt\` / \`log\` / \`review\` / \`retry\` / \`repair\` / \`ops\` / \`migrate\` / \`checkpoint\`（\`list\` / **\`restore <file> [--force] [--stage <id>] [--dry-run]\`**）/ \`health\` / \`recover\` / \`wizard\`。
+**flow 子命令**：\`status\` / \`current\` / \`overview\` / \`phases\` / \`mode\`（\`[--stage <id>] [--json]\`，只读） / \`stage\`（\`add\` / \`remove\` / \`set --deps\` / **\`reset <id> --to <phase> [--dry-run]\`**）/ \`metrics\` / \`advance\`（\`--stage <id> --to <phase>\`、\`--op\`、\`--force\`、\`--dry-run\`、\`--quiet\`）/ \`attempt\` / \`log\` / \`review\` / \`retry\` / \`repair\` / \`ops\` / \`migrate\` / \`checkpoint\`（\`list\` / **\`restore <file> [--force] [--stage <id>] [--dry-run]\`**）/ \`health\` / \`recover\` / \`wizard\` / \`archive\`（\`<version>\` / \`list\` / \`show\`）。
 
 **纠错/清理侧补充**：\`flow review add|resolve|update|remove\`；\`flow ops list [--stage <id>] [--json]\`（操作方案视图，draft 分组展示）；\`flow repair [--prune-orphans]\`（默认只报告，\`--prune-orphans\` 仅清键孤儿，单向不删文件）；\`plan scheme register\`（补注册**文件孤儿**：有 op 文件无注册键 → 写入 flow.json，\`--dry-run\` 零写盘；与 \`flow repair --prune-orphans\`（仅清键孤儿）对称）；**\`flow stage reset <id> --to <phase>\`**（\`advance\` 的**对称复位**：允许回退，受合法 phase 值域 + \`to=done\` 阻塞 REV 约束，\`--dry-run\` 零写盘）；**\`flow checkpoint restore <file> --stage <id> [--dry-run]\`**（按阶段选择性回退；\`--dry-run\` 差异预览零写盘）。
 
 > 命令职责分层：\`plan stage add\`（完整，推荐）> \`flow stage add\`（仅注册 \`flow.json\`，不建目录）> \`stage create\`（已弃用）。
 
+## v1.2.0 新增能力（stage-78~84）
+
+- **flow.json 版本分片归档（\`flow archive\`）**：按版本号归档已收官历史（判据门：该版本全部阶段 done + 无 blocking open REV；归档文件落 \`.openfeel/flow-archive/{version}.json\`）。三个入口：\`openfeel flow archive <version>\`（执行归档；\`--dry-run\` 预览零写盘、\`--json\` 结构化输出）、\`openfeel flow archive list\`（列举已归档版本，只读）、\`openfeel flow archive show <version>\`（查看指定归档版本，只读）。**与顶层 \`openfeel archive <stage>\` 区分**：顶层命令是**阶段摘要归档**，\`flow archive\` 是 **flow.json 版本分片归档**，二者职责不同；常规命令不读 \`.openfeel/flow-archive/**\`（\`flow health\` 仅目录清单级对账）。
+- **需求流转（\`openfeel req\`）**：需求层命令组（10 子命令：\`add\` / \`list\` / \`show\` / \`claim\` / \`release\` / \`set\` / \`link\` / \`advance\` / \`board\` / \`next\`）。需求 7 状态（\`draft\` / \`scheduled\` / \`in_progress\` / \`done\` / \`blocked\` / \`cancelled\` / \`rejected\`）；**需求进度由关联阶段 phase 聚合**（全部关联阶段 done → 需求自动 done）；认领协议 = \`owner\` + \`claimed_at\` 占用校验（无 TTL）。需求正文 \`.openfeel/requirements/REQ-NNN.md\` 为人读副本，**机读权威恒为 flow.json**。用法权威源见 \`openfeel-req\` skill；**v1.2.0 起提供**。
+
+## v1.1.7 新增能力（stage-74~76）
+
+- **双模式工作流（\`workflow_mode\`）**：值域 \`full | fast\`（默认 \`fast\`）。三层载体：\`config.yaml defaults.workflow_mode\`（项目默认 / 记忆）→ \`status.md「工作流模式」\`（阶段覆盖，**读取权威**）→ \`flow.json\` 冗余字段（可选、**不参与级联**）；级联优先序 \`status.md > config.yaml > builtin\`（\`profile.yaml\` 不承载）。只读查询：\`openfeel flow mode [--stage <id>] [--json]\`（当前模式 + 四源 \`source\`）。
+- **fast 快线转移表（并列）**：\`transitions\` 共 **9 条目**（8 条流转键 + \`done\` 终止项）：\`plan_pending → plan_review\`（**计划审查必经**）、\`plan_review → plan_passed / plan_pending\`、\`plan_passed → exec_running\`、\`exec_running → review_pending\`、\`review_pending → review_failed / review_passed\`、\`review_failed → review_pending / exec_running\`（回环）、\`review_passed → archiving\`、\`archiving → done\`、\`done\`（终态）。**\`phases\` / \`advanceAccepted\` 恒 15 项、模式无关**；fast 下 6 个相位不可达（\`scheme_*\` / \`test_*\`）。
+- **模式命令面**：\`plan stage add --workflow-mode <full|fast>\`（值域派生、非法 exit 1 不建阶段）、\`stage set <id> --workflow-mode <full|fast>\`（缺失字段插入）、\`flow phases [--mode <full|fast>] [--stage <id>]\`（模式分节；\`--json\` 追加 \`workflowMode\`）、\`config set ... --sync-stages [--stage <ids...>]\`（同步字段含「工作流模式」）。
+- **\`config effective\` 四键**：\`auto_advance\` / \`execution_mode\` / \`merge_mode\` / \`workflow_mode\`。
+
 ## v1.1.6 新增能力（stage-68~73）
 
 - **多 harness 并存**：\`openfeel setup\` / \`openfeel update\` 新增 \`--tools <逗号列表>\`（如 \`opencode,claude\`）；非法值 **exit 1** 前置校验零写盘；默认仅 \`opencode\`。
-- **Claude Code 适配器资产**：\`--tools claude\` 部署 \`~/.claude/\`——\`CLAUDE.md\`（全局约束，用户已有内容 append 不覆盖）、\`agents/\`（**9 个**，含 \`feel\`）、\`skills/\`（**17 个**共享源）、\`settings.json\`（注入 \`"agent":"feel"\` + \`"permissions":{"defaultMode":"auto"}\`，用户既有键逐字保留）；默认零触（不带 \`--tools\` 时 \`~/.claude/\` 零变化）。
+- **Claude Code 适配器资产**：\`--tools claude\` 部署 \`~/.claude/\`——\`CLAUDE.md\`（全局约束，用户已有内容 append 不覆盖）、\`agents/\`（**9 个**，含 \`feel\`）、\`skills/\`（**18 个**共享源）、\`settings.json\`（注入 \`"agent":"feel"\` + \`"permissions":{"defaultMode":"auto"}\`，用户既有键逐字保留）；默认零触（不带 \`--tools\` 时 \`~/.claude/\` 零变化）。
 
 ## v1.1.5 新增能力（stage-67）
 
@@ -6867,7 +7192,7 @@ openfeel setup --tools claude  # 2. 重跑部署（claude 目标）
 
 > 以下为 v1.1.2 相对上版的增量能力（分组摘要，细节以 \`<cmd> --help\` 为准）。
 
-- **A. 自描述与可纠错（stage-41）**：\`flow phases [--json]\`（**5 键**：\`schemaVersion\`/\`phases\`/\`transitions\`/\`advanceAccepted\`/\`transitionsDiff\`）、\`flow stage remove [--force] [--dry-run] [--purge]\`、stageId 校验/冲突检测（\`validateStageId\` / \`suggestStageId\` / \`findStageDirConflict\`）、\`plan stage add --deps\`。
+- **A. 自描述与可纠错（stage-41）**：\`flow phases [--json] [--mode <full|fast>] [--stage <id>]\`（**6 键**：\`schemaVersion\`/\`phases\`/\`transitions\`/\`advanceAccepted\`/\`transitionsDiff\`/\`workflowMode\`（v1.1.7 追加）；既有五键语义逐字不变）、\`flow stage remove [--force] [--dry-run] [--purge]\`、stageId 校验/冲突检测（\`validateStageId\` / \`suggestStageId\` / \`findStageDirConflict\`）、\`plan stage add --deps\`。
 - **B. 状态与口径（stage-42）**：\`config effective [key]\`（有效值 + 生效来源 \`status.md > config.yaml > profile.yaml > builtin\`）、\`pipeline.phase\` 全量 done 判定、审计日志 \`register_stage\` / \`register_op\`。
 - **C. 部署与备份（stage-46）**：覆盖写前自动备份 \`~/.openfeel/backup/{ts}/\` + \`update_infos.md\`「备份」类条目（Agent 按 \`feel.md\` 检查规则核对）。
 - **D. 纠正/清理侧命令面（stage-51/52，v1.1.4-stage-64 补 register）**：\`plan scheme remove\`（仅删 \`flow.json\` 注册键，不删 op 文件；done/checkpoint 保护）、\`plan scheme register <stage> [opId] [--dry-run]\`（对称补全：补注册 fileOrphans，\`--dry-run\` 零写盘；**\`create\` 序号基于「ops/ 文件 ∪ flow.json 注册」的最小未用正整数（空位回填），创建后对目标阶段未注册文件输出 stderr 告警并提示 \`plan scheme register\`**）、\`plan scheme rename --title\`（必填，空标题报错）、\`plan scheme publish\` + \`create --draft\`（draft→pending，空模板拒绝）、\`flow stage set --deps\`（覆盖写入；**不带 \`--deps\` 视为清空**）、\`flow review update|remove\`、\`stage set\`（**幂等**：同值 no-op + 同值不生成 \`.bak\`；\`--exec-mode <manual\\|auto>\` / \`--auto-advance <enabled\\|disabled>\` / \`--review-agent <agent>\`）、\`stage task --add|--done|--undone\`、\`plan stage add --tasks\`/\`--exec-mode\`/\`--auto-advance\`（显式覆盖 config 默认）、\`flow repair --prune-orphans\`、\`flow health --fix [--dry-run]\`（默认只报告；\`--fix\` **仅回写 status.md「状态」字段**；\`--dry-run\` 预览零写盘）、\`flow ops list\`、\`flow advance --quiet\` + \`--to <远距 phase>\`（存在唯一路径时自动逐步；\`--dry-run\` 展示完整路径）、\`knowledge dedup\`（检索相似条目，**只读建议，不修改 kb**）。\`flow attempt\` 对 **draft op 拒绝**。
@@ -6901,7 +7226,23 @@ plan_pending → plan_review → plan_passed → scheme_pending → scheme_revie
 | \`archiving\` | \`done\` |
 | \`done\` | （终态） |
 
-- 转移表以**运行时** \`.openfeel/pipeline.yaml\` 为准；\`openfeel flow phases\` 查看当前生效值。
+**fast 快线转移表（\`workflow_mode=fast\`）** —— \`transitions\` 共 **9 条目**（8 条流转键 + \`done\` 终止项），快线链（可达相位序列）为 \`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`：
+
+| phase | 合法目标 |
+|-------|----------|
+| \`plan_pending\` | \`plan_review\` |
+| \`plan_review\` | \`plan_passed\`, \`plan_pending\` |
+| \`plan_passed\` | \`exec_running\` |
+| \`exec_running\` | \`review_pending\` |
+| \`review_pending\` | \`review_failed\`, \`review_passed\` |
+| \`review_failed\` | \`review_pending\`, \`exec_running\` |
+| \`review_passed\` | \`archiving\` |
+| \`archiving\` | \`done\` |
+| \`done\` | （终态） |
+
+> \`phases\` / \`advanceAccepted\` 恒 15 项（模式无关）；fast 下 \`scheme_pending\` / \`scheme_review\` / \`scheme_passed\` / \`test_pending\` / \`test_failed\` / \`test_passed\` 共 **6 项**不可达（无入边）。
+
+- 转移表以**运行时** \`.openfeel/pipeline.yaml\` 为准；\`openfeel flow phases\` 查看当前生效值。（\`--mode <full|fast>\` 显式指定 / \`--stage <id>\` 按阶段派生；\`--json\` 追加 \`workflowMode\`）
 - 推进：\`openfeel flow advance --stage <id> --to <phase>\`。**\`advanceAccepted\` = 内置 15 个 phase 的「推进白名单」**（\`flow advance\` 只接受这 15 个值），**不是**组合式条件键的替代品（旧文案曾误述，此处已更正）。**组合式条件差异**（如内置默认含 \`review_passed|test_passed\`，本仓 \`pipeline.yaml\` 未列）经 \`--json.transitionsDiff.missing\` **显式可见**（stage-50 裁定：**不补组合键**，改以 \`transitionsDiff\` 显式化）。
 - 参考：\`.openfeel/manual/**\`（CLI/flow 模块文档）。
 
@@ -7013,7 +7354,7 @@ description: 读取 .openfeel/plan/{series}/{stage}/status.md，判断当前子
 
 ### 0. 读取全局配置
 
-读取 \`.openfeel/config.yaml\`，解析 \`defaults\` 中的 \`execution_mode\`、\`auto_advance\`、\`merge_mode\`。
+读取 \`.openfeel/config.yaml\`，解析 \`defaults\` 中的 \`execution_mode\`、\`auto_advance\`、\`merge_mode\`、\`workflow_mode\`。
 
 ### 1. 定位状态文件
 
@@ -7029,6 +7370,7 @@ description: 读取 .openfeel/plan/{series}/{stage}/status.md，判断当前子
 
 - \`执行模式\`
 - \`自动推进\`
+- \`工作流模式\`
 - \`状态\`
 - \`当前责任 Agent\`
 - \`上一责任 Agent\`
@@ -7089,6 +7431,7 @@ description: 读取 .openfeel/plan/{series}/{stage}/status.md，判断当前子
 - 阶段：{stage}
 - 执行模式：manual | auto
 - 自动推进：disabled | enabled
+- 工作流模式：full | fast
 - 状态：{status}
 - 当前责任 Agent：{agent}
 - 前置依赖：{依赖列表 或 无}
@@ -7103,6 +7446,8 @@ description: 读取 .openfeel/plan/{series}/{stage}/status.md，判断当前子
 {根据状态给出下一步，例如：启动 Code、等待用户、启动 openfeel-feel-tester、停止流程；若存在并行候选则建议批量启动}
 \`\`\`
 
+> **模式感知（fast）**：\`工作流模式\` 为 \`fast\` 时，「下一步建议」不指向方案 / 测试环节（快线链为 计划 → 计划审查 → 执行 → 代码审查 → 归档）；\`plan_pending\` 阶段下一步建议 = \`plan_review\`（必经，勿建议直接 \`plan_passed\`）；相位口径为「**可达 ≠ 合法**」——合法枚举仍 15 项（fast 下仅 6 项不可达），**不得**表述为相位缩减。
+
 ## 状态到下一步映射
 
 | 状态 | 下一步建议 |
@@ -7335,7 +7680,7 @@ models:
 
 ### opencode 适配器
 
-平台配置文件：
+读取 \`opencode.jsonc\`（或对应平台的配置文件），确定当前适配器平台：
 
 | 配置文件 | 平台 |
 |----------|------|
@@ -7344,7 +7689,8 @@ models:
 
 若无平台配置文件，提示用户当前不在支持的平台中。
 
-- agents 目录：\`.opencode/agents/\`（或对应平台的 agents/ 目录）下所有 \`.md\` 文件。
+扫描 \`.opencode/agents/\`（或对应平台的 agents/ 目录）下所有 \`.md\` 文件，提取每个 Agent 的模型需求。
+
 - 报告/模板中的平台标签：\`**平台**：OpenCode（当前适配器）\`（原文标签，正文已改为中性表述「当前 harness（opencode 适配器 / Claude Code 适配器）」）。
 - 向用户提问使用 \`question\` 工具。
 
@@ -7480,11 +7826,90 @@ description: 跨会话上下文恢复，供 Agent 在会话启动时重建流水
 2. 读取**索引** \`.openfeel/users/{username}/dev_last.md\`（「用户偏好」「主题索引」「公共交接区」）→ **按需**再读主题文件（**文件名英文，如 \`decisions.md\`/\`pending.md\`**）恢复详情；**旧格式**（无 \`## 主题索引\` 节）→ 触发惰性迁移（按英文命名映射拆分生成 \`dev_last/\` + 索引，原文保留）
 3. 将两者合并为当前会话起点
 
+> **模式感知**：恢复后按当前阶段 \`status.md「工作流模式」\` 确认流程模式（\`flow recover\` 输出不含模式字段；fast 工作流快线下按快线链继续）。
+
 > **加锁提示（A9）**：恢复流程为**只读**，无需加锁；仅**会话末尾写入**走 \`withFileLock\` 临界区（见 agents-md「并发写加锁协议」）。
 
 ## 输出
 
 恢复摘要：流水线状态 + 阻塞项 + 待处理任务列表
+`,
+    'openfeel-req': `---
+name: openfeel-req
+description: OpenFeel 需求流转用法参考：需求（requirement）四层模型与 7 状态生命周期、req 命令组 10 个子命令（add/list/show/claim/release/set/link/advance/board/next）与参数、认领协议、REQ-NNN 正文与人读副本语义（机读权威恒为 flow.json）、与计划（plan.md）的关系、与 workflow_mode 正交。当需要创建/查询/认领/关联/推进需求，或要理解 REQ-NNN 状态与阶段聚合关系时加载。
+---
+
+# OpenFeel 需求流转（openfeel req）用法参考
+
+## 说明
+
+- 定位：**查询型参考手册**（只读，不自执行）。回答「需求是什么、状态怎么流转、\`req\` 命令怎么用」。
+- 提供版本：**v1.2.0 起提供**（\`openfeel req\` 命令组）；命令/参数细节以 \`openfeel req --help\`（本仓执行）实时输出为准（CLI 演进后本文档可能滞后）。
+- 本仓自举：本仓（openfeel 源码仓库）开发/执行时请用 \`node bin/openfeel.js req <cmd>\`；安装后使用 \`openfeel req <cmd>\`。
+- 相关 skill：\`openfeel-cli-usage\`（全量命令速查）；本 skill 只承载需求流转专项。
+
+## 四层模型与需求定位
+
+需求层位于**「版本 → 需求 REQ-NNN → 计划 stage → 方案 op」**四层模型的第二层：**需求 = 排期与调度层**（回答「做什么、何时做」）；**计划 = 对某项明确需求的具体实现**。需求不等于计划——接取需求后仍按既有规划阈值走流水线（\`plan.md\` 头部标注「关联需求：REQ-NNN」）。
+
+## 需求生命周期（7 状态）
+
+\`\`\`
+draft ─→ scheduled ─→ in_progress ─→ done
+  │          │            │
+  └──────────┴────────────┴──→ blocked / cancelled / rejected
+\`\`\`
+
+| 状态 | 语义 |
+|------|------|
+| \`draft\` | 草稿（\`req add\` 新建初值） |
+| \`scheduled\` | 已排期（可被 \`req next\` 推荐接取） |
+| \`in_progress\` | 进行中（认领后推进；**内部进度由关联阶段的 15-phase 聚合**） |
+| \`done\` | 完成（**全部关联阶段 done 时自动收口**——前置集限定 \`scheduled\` / \`in_progress\`；\`req advance --to done\` 亦须此门） |
+| \`blocked\` | 阻塞（可回到 \`scheduled\` / \`in_progress\`） |
+| \`cancelled\` | 已取消（终态） |
+| \`rejected\` | 已拒绝（终态） |
+
+- **投影方向单一**：需求状态是关联阶段 phase 的聚合投影（方向：阶段 phase → 需求状态）；不得由需求状态前推阶段 phase。
+- 合法显式流转由引擎流转表判定（\`req advance --to <status>\` / \`req set --status <status>\`）；终态（\`done\` / \`cancelled\` / \`rejected\`）不可再流转。
+
+## 子命令（10 个）
+
+| 子命令 | 用途 | 关键参数 |
+|--------|------|----------|
+| \`req add <title>\` | 创建需求（ID 自动分配 REQ-NNN，max+1 不回收；正文骨架铺到 \`.openfeel/requirements/REQ-NNN.md\`） | \`--target-version <version>\`、\`--priority <P0\\|P1\\|P2>\` |
+| \`req list\` | 列出需求（可按状态 / 版本 / 认领人过滤） | \`--status <status>\`、\`--target-version <version>\`、\`--owner <owner>\`、\`--json\` |
+| \`req show <id>\` | 查看需求详情（关联阶段为原始只读枚举） | \`--json\` |
+| \`req claim <id>\` | 认领需求（占用校验；已被他人认领则拒绝） | \`--owner <owner>\`（缺省 \`.openfeel/.info.json\` user → git config user.name） |
+| \`req release <id>\` | 释放认领（未认领为 no-op 成功） | — |
+| \`req set <id>\` | 更新需求字段（白名单；状态流转合法性由引擎判定） | \`--status\`、\`--title\`、\`--target-version\`、\`--priority\` |
+| \`req link\` | 关联需求到阶段 / 解绑 | \`--stage <stageId>\`、\`--requirement <id>\`、\`--unlink\`（与 \`--requirement\` 二选一） |
+| \`req advance <id>\` | 显式推进需求状态（合法目标由引擎流转表判定；done 须全部关联阶段 done） | \`--to <status>\` |
+| \`req board\` | 需求看板（按状态分组；7 组固定顺序） | \`--target-version <version>\`、\`--json\` |
+| \`req next\` | 推荐下一个可接取需求（\`scheduled\` 且未认领；按预估版本升序） | \`--owner <owner>\`（含该认领人已认领的 scheduled 需求）、\`--json\` |
+
+> \`--json\` 输出为纯 JSON 单文档（含 \`schemaVersion\`，脚本消费口径）；命令细节以 \`openfeel req <sub> --help\` 为准。
+
+## 认领协议
+
+- **轻量原子**：\`owner\` + \`claimed_at\` 两字段；\`req claim\` 做**占用校验**（已被他人认领 → 拒绝，exit 非 0 零写盘）；**无 TTL / 无心跳**（单机场景足够）。
+- 认领人缺省解析：\`.openfeel/.info.json\` 的 \`user\` → \`git config user.name\`。
+- 释放：\`req release <id>\`（未认领为 no-op 成功）；终态需求不可认领。
+
+## REQ-NNN 正文与权威源
+
+- 正文文件：\`.openfeel/requirements/REQ-NNN.md\`（\`req add\` 机械铺骨架，**人读副本**）。
+- **机读权威恒为 \`.openfeel/flow.json\` 的 \`requirements\` 条目**；正文与 flow.json 不一致时**以 flow.json 为准**（正文内状态为创建时快照，不追写）。
+- \`stages[*].requirement_id\` 记录需求↔阶段关联（单值可空；存量阶段缺省 = \`null\`）；关联关系以 flow.json 为准。
+
+## 与计划（plan.md）的关系
+
+- 需求 = 排期与调度层；**具体实现仍由计划承载**——阶段 \`plan.md\` 头部标注「关联需求：REQ-NNN」。
+- 需求状态流转（认领 / 关联 / 推进）经 \`openfeel req\` CLI 执行；planner 只读不写（不直写 flow.json）。
+
+## 与 workflow_mode 正交
+
+需求层与工作流模式（\`full\` / \`fast\`）**正交**：需求可分别由 full / fast 阶段实现；两种模式下需求纪律一致，\`workflow_mode\` 不影响需求状态机与命令行为。
 `,
     'openfeel-roadmap': `---
 name: openfeel-roadmap
@@ -7776,7 +8201,7 @@ description: 标准化更新 .openfeel/plan/{series}/{stage}/status.md 的子计
 
 ### 0. 读取全局配置
 
-读取 \`.openfeel/config.yaml\`，获取 \`defaults\` 中的 \`execution_mode\`、\`auto_advance\`、\`merge_mode\`。
+读取 \`.openfeel/config.yaml\`，获取 \`defaults\` 中的 \`execution_mode\`、\`auto_advance\`、\`merge_mode\`、\`workflow_mode\`。
 
 ### 1. 读取状态文件
 
@@ -7821,6 +8246,7 @@ planned | ready_for_code | coding | ready_for_review | review_failed | review_pa
 
 - \`执行模式\`
 - \`自动推进\`
+- \`工作流模式\`（模式字段**不由**状态更新覆盖）
 - \`前置依赖\`（由 Architect 在 Phase 3.5 中声明，运行时不应修改）
 
 ### 4. 追加状态记录
@@ -7882,6 +8308,8 @@ description: 交互式流水线向导，供 Agent 在终端中逐步推进流水
 2. 按提示选择要推进的阶段和下一步 phase（基于当前阶段的可达 transitions）
 3. 确认后执行推进，循环直至阶段 done 或退出
 
+> **模式选型**：首次运行时向导会询问工作流模式（\`full\` / \`fast\`），写入 \`config.yaml defaults.workflow_mode\`（项目级记忆）；非 TTY 环境沿用既有守卫、不询问。
+
 ## 输出
 
 向导推进结果：阶段 phase 变化（from → to），结束/退出提示
@@ -7930,10 +8358,10 @@ description: 会话启动时检查并补齐 .openfeel/ 工作区目录结构与
 // AUTO-GENERATED-BEGIN: OPENCODE_CONFIG_TEMPLATES
 const OPENCODE_CONFIG_TEMPLATES = {
     'zh-CN': {
-        adapter: 'IyBPcGVuQ29kZSDlubPlj7DpgILphY3lmagKCui/meaYryBPcGVuQ29kZSDlubPlj7DpgILphY3lmajvvIzljIXlkKsgOSDkuKogQWdlbnQg5a6a5LmJ5ZKMIDE3IOS4qiBTa2lsbOOAggoK6YOo572y5ZCO5bCG5Zyo55uu5qCH6aG555uu5Lit55Sf5oiQ77yaCgotIGBvcGVuY29kZS5qc29uY2Ag4oCUIE9wZW5Db2RlIOW5s+WPsOmFjee9ru+8iEFnZW50IOaooeWei+OAgVNraWxscyDliJfooajnrYnvvIkKLSBgLm9wZW5jb2RlL2FnZW50cy9gIOKAlCA5IOS4qiBBZ2VudCDlrprkuYnvvIhmZWVs44CBb3BlbmZlZWwtcGxhbm5lcuOAgW9wZW5mZWVsLXNjaGVtZXLjgIFvcGVuZmVlbC1leGVjdXRvcuOAgW9wZW5mZWVsLXJldmlld2Vy44CBb3BlbmZlZWwtZmVlbC10ZXN0ZXLjgIFvcGVuZmVlbC12aXNpb27jgIFvcGVuZmVlbC1hcmNoaXZlcuOAgW9wZW5mZWVsLXV0aWxpdHnvvIkKLSBgLm9wZW5jb2RlL3NraWxscy9gIOKAlCAxNyDkuKogU2tpbGwg5a6a5LmJ77yIb3BlbmZlZWwtYWdlbnQtbW9kZWwtY2hlY2vjgIFvcGVuZmVlbC1idWctYWNjZXB0YW5jZeOAgW9wZW5mZWVsLWNoZWNrLWti44CBb3BlbmZlZWwtY2xpLXVzYWdl44CBb3BlbmZlZWwtZ2V0LWJ1Z3PjgIFvcGVuZmVlbC1nZXQtc3RhZ2Utc3RhdHVz44CBb3BlbmZlZWwtaGVhbHRo44CBb3BlbmZlZWwtbW9kZWwtY2hlY2vjgIFvcGVuZmVlbC1tb2RlbC1jb25maWfjgIFvcGVuZmVlbC1yZWNvdmVy44CBb3BlbmZlZWwtcm9hZG1hcOOAgW9wZW5mZWVsLXNlYXJjaC1rYuOAgW9wZW5mZWVsLXN5bmMtc3RhdHVz44CBb3BlbmZlZWwtdG9vbC11c2FnZeOAgW9wZW5mZWVsLXVwZGF0ZS1zdGFnZS1zdGF0dXPjgIFvcGVuZmVlbC13aXphcmTjgIFvcGVuZmVlbC13b3Jrc3BhY2XvvIkKLSBgLm9wZW5jb2RlL0FEQVBURVIubWRgIOKAlCDmnKzpgILphY3lmajor7TmmI4KLSBgLm9wZW5jb2RlLy5naXRpZ25vcmVgIOKAlCDlv73nlaXop4TliJkKCj4g5rOo77ya5pys6aG555uu5LiN6YOo572yIGBwYWNrYWdlLmpzb25g77yI55Sx55So5oi36aG555uu6Ieq6KGM566h55CG77yJ44CCCg==',
+        adapter: 'IyBPcGVuQ29kZSDlubPlj7DpgILphY3lmagKCui/meaYryBPcGVuQ29kZSDlubPlj7DpgILphY3lmajvvIzljIXlkKsgOSDkuKogQWdlbnQg5a6a5LmJ5ZKMIDE4IOS4qiBTa2lsbOOAggoK6YOo572y5ZCO5bCG5Zyo55uu5qCH6aG555uu5Lit55Sf5oiQ77yaCgotIGBvcGVuY29kZS5qc29uY2Ag4oCUIE9wZW5Db2RlIOW5s+WPsOmFjee9ru+8iEFnZW50IOaooeWei+OAgVNraWxscyDliJfooajnrYnvvIkKLSBgLm9wZW5jb2RlL2FnZW50cy9gIOKAlCA5IOS4qiBBZ2VudCDlrprkuYnvvIhmZWVs44CBb3BlbmZlZWwtcGxhbm5lcuOAgW9wZW5mZWVsLXNjaGVtZXLjgIFvcGVuZmVlbC1leGVjdXRvcuOAgW9wZW5mZWVsLXJldmlld2Vy44CBb3BlbmZlZWwtZmVlbC10ZXN0ZXLjgIFvcGVuZmVlbC12aXNpb27jgIFvcGVuZmVlbC1hcmNoaXZlcuOAgW9wZW5mZWVsLXV0aWxpdHnvvIkKLSBgLm9wZW5jb2RlL3NraWxscy9gIOKAlCAxOCDkuKogU2tpbGwg5a6a5LmJ77yIb3BlbmZlZWwtYWdlbnQtbW9kZWwtY2hlY2vjgIFvcGVuZmVlbC1idWctYWNjZXB0YW5jZeOAgW9wZW5mZWVsLWNoZWNrLWti44CBb3BlbmZlZWwtY2xpLXVzYWdl44CBb3BlbmZlZWwtZ2V0LWJ1Z3PjgIFvcGVuZmVlbC1nZXQtc3RhZ2Utc3RhdHVz44CBb3BlbmZlZWwtaGVhbHRo44CBb3BlbmZlZWwtbW9kZWwtY2hlY2vjgIFvcGVuZmVlbC1tb2RlbC1jb25maWfjgIFvcGVuZmVlbC1yZWNvdmVy44CBb3BlbmZlZWwtcmVx44CBb3BlbmZlZWwtcm9hZG1hcOOAgW9wZW5mZWVsLXNlYXJjaC1rYuOAgW9wZW5mZWVsLXN5bmMtc3RhdHVz44CBb3BlbmZlZWwtdG9vbC11c2FnZeOAgW9wZW5mZWVsLXVwZGF0ZS1zdGFnZS1zdGF0dXPjgIFvcGVuZmVlbC13aXphcmTjgIFvcGVuZmVlbC13b3Jrc3BhY2XvvIkKLSBgLm9wZW5jb2RlL0FEQVBURVIubWRgIOKAlCDmnKzpgILphY3lmajor7TmmI4KLSBgLm9wZW5jb2RlLy5naXRpZ25vcmVgIOKAlCDlv73nlaXop4TliJkKCj4g5rOo77ya5pys6aG555uu5LiN6YOo572yIGBwYWNrYWdlLmpzb25g77yI55Sx55So5oi36aG555uu6Ieq6KGM566h55CG77yJ44CCCg==',
     },
     en: {
-        adapter: 'IyBPcGVuQ29kZSBQbGF0Zm9ybSBBZGFwdGVyCgpUaGlzIGlzIHRoZSBPcGVuQ29kZSBwbGF0Zm9ybSBhZGFwdGVyLCBjb250YWluaW5nIDkgQWdlbnQgZGVmaW5pdGlvbnMgYW5kIDE3IFNraWxscy4KCkFmdGVyIGRlcGxveW1lbnQsIHRoZSBmb2xsb3dpbmcgZmlsZXMgd2lsbCBiZSBnZW5lcmF0ZWQgaW4gdGhlIHRhcmdldCBwcm9qZWN0OgoKLSBgb3BlbmNvZGUuanNvbmNgIOKAlCBPcGVuQ29kZSBwbGF0Zm9ybSBjb25maWd1cmF0aW9uIChBZ2VudCBtb2RlbHMsIFNraWxscyBsaXN0LCBldGMuKQotIGAub3BlbmNvZGUvYWdlbnRzL2Ag4oCUIDkgQWdlbnQgZGVmaW5pdGlvbnMgKGZlZWwsIG9wZW5mZWVsLXBsYW5uZXIsIG9wZW5mZWVsLXNjaGVtZXIsIG9wZW5mZWVsLWV4ZWN1dG9yLCBvcGVuZmVlbC1yZXZpZXdlciwgb3BlbmZlZWwtZmVlbC10ZXN0ZXIsIG9wZW5mZWVsLXZpc2lvbiwgb3BlbmZlZWwtYXJjaGl2ZXIsIG9wZW5mZWVsLXV0aWxpdHkpCi0gYC5vcGVuY29kZS9za2lsbHMvYCDigJQgMTcgU2tpbGwgZGVmaW5pdGlvbnMgKG9wZW5mZWVsLWFnZW50LW1vZGVsLWNoZWNrLCBvcGVuZmVlbC1idWctYWNjZXB0YW5jZSwgb3BlbmZlZWwtY2hlY2sta2IsIG9wZW5mZWVsLWNsaS11c2FnZSwgb3BlbmZlZWwtZ2V0LWJ1Z3MsIG9wZW5mZWVsLWdldC1zdGFnZS1zdGF0dXMsIG9wZW5mZWVsLWhlYWx0aCwgb3BlbmZlZWwtbW9kZWwtY2hlY2ssIG9wZW5mZWVsLW1vZGVsLWNvbmZpZywgb3BlbmZlZWwtcmVjb3Zlciwgb3BlbmZlZWwtcm9hZG1hcCwgb3BlbmZlZWwtc2VhcmNoLWtiLCBvcGVuZmVlbC1zeW5jLXN0YXR1cywgb3BlbmZlZWwtdG9vbC11c2FnZSwgb3BlbmZlZWwtdXBkYXRlLXN0YWdlLXN0YXR1cywgb3BlbmZlZWwtd2l6YXJkLCBvcGVuZmVlbC13b3Jrc3BhY2UpCi0gYC5vcGVuY29kZS9BREFQVEVSLm1kYCDigJQgVGhpcyBhZGFwdGVyIGRvY3VtZW50YXRpb24KLSBgLm9wZW5jb2RlLy5naXRpZ25vcmVgIOKAlCBJZ25vcmUgcnVsZXMKCj4gTm90ZTogVGhpcyBwcm9qZWN0IGRvZXMgbm90IGRlcGxveSBgcGFja2FnZS5qc29uYCAobWFuYWdlZCBieSB0aGUgdXNlcidzIHByb2plY3QgaXRzZWxmKS4K',
+        adapter: 'IyBPcGVuQ29kZSBQbGF0Zm9ybSBBZGFwdGVyCgpUaGlzIGlzIHRoZSBPcGVuQ29kZSBwbGF0Zm9ybSBhZGFwdGVyLCBjb250YWluaW5nIDkgQWdlbnQgZGVmaW5pdGlvbnMgYW5kIDE4IFNraWxscy4KCkFmdGVyIGRlcGxveW1lbnQsIHRoZSBmb2xsb3dpbmcgZmlsZXMgd2lsbCBiZSBnZW5lcmF0ZWQgaW4gdGhlIHRhcmdldCBwcm9qZWN0OgoKLSBgb3BlbmNvZGUuanNvbmNgIOKAlCBPcGVuQ29kZSBwbGF0Zm9ybSBjb25maWd1cmF0aW9uIChBZ2VudCBtb2RlbHMsIFNraWxscyBsaXN0LCBldGMuKQotIGAub3BlbmNvZGUvYWdlbnRzL2Ag4oCUIDkgQWdlbnQgZGVmaW5pdGlvbnMgKGZlZWwsIG9wZW5mZWVsLXBsYW5uZXIsIG9wZW5mZWVsLXNjaGVtZXIsIG9wZW5mZWVsLWV4ZWN1dG9yLCBvcGVuZmVlbC1yZXZpZXdlciwgb3BlbmZlZWwtZmVlbC10ZXN0ZXIsIG9wZW5mZWVsLXZpc2lvbiwgb3BlbmZlZWwtYXJjaGl2ZXIsIG9wZW5mZWVsLXV0aWxpdHkpCi0gYC5vcGVuY29kZS9za2lsbHMvYCDigJQgMTggU2tpbGwgZGVmaW5pdGlvbnMgKG9wZW5mZWVsLWFnZW50LW1vZGVsLWNoZWNrLCBvcGVuZmVlbC1idWctYWNjZXB0YW5jZSwgb3BlbmZlZWwtY2hlY2sta2IsIG9wZW5mZWVsLWNsaS11c2FnZSwgb3BlbmZlZWwtZ2V0LWJ1Z3MsIG9wZW5mZWVsLWdldC1zdGFnZS1zdGF0dXMsIG9wZW5mZWVsLWhlYWx0aCwgb3BlbmZlZWwtbW9kZWwtY2hlY2ssIG9wZW5mZWVsLW1vZGVsLWNvbmZpZywgb3BlbmZlZWwtcmVjb3Zlciwgb3BlbmZlZWwtcmVxLCBvcGVuZmVlbC1yb2FkbWFwLCBvcGVuZmVlbC1zZWFyY2gta2IsIG9wZW5mZWVsLXN5bmMtc3RhdHVzLCBvcGVuZmVlbC10b29sLXVzYWdlLCBvcGVuZmVlbC11cGRhdGUtc3RhZ2Utc3RhdHVzLCBvcGVuZmVlbC13aXphcmQsIG9wZW5mZWVsLXdvcmtzcGFjZSkKLSBgLm9wZW5jb2RlL0FEQVBURVIubWRgIOKAlCBUaGlzIGFkYXB0ZXIgZG9jdW1lbnRhdGlvbgotIGAub3BlbmNvZGUvLmdpdGlnbm9yZWAg4oCUIElnbm9yZSBydWxlcwoKPiBOb3RlOiBUaGlzIHByb2plY3QgZG9lcyBub3QgZGVwbG95IGBwYWNrYWdlLmpzb25gIChtYW5hZ2VkIGJ5IHRoZSB1c2VyJ3MgcHJvamVjdCBpdHNlbGYpLgo=',
     }
 };
 // AUTO-GENERATED-END: OPENCODE_CONFIG_TEMPLATES
@@ -8125,6 +8553,47 @@ When a stage enters \`plan_passed\` and the project's \`auto_advance\` is set to
 3. **User declines**: The main session keeps \`auto_advance=disabled\` and requires user confirmation before each stage advance (manual execution mode).
 4. **No silent advancement**: When \`auto_advance=disabled\`, the main session must not advance the pipeline without asking the user.
 
+#### Workflow Mode (workflow_mode)
+
+Before dispatching, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`; when the field is absent, fall back per the cascade). Two modes:
+
+- **full (complete flow)**: planner → plan_review (reviewer) → schemer → executor → reviewer → tester → archiver.
+- **fast (Workflow Fast Line)**: planner (lightweight) → plan_review (**single mandatory plan review**) → executor → reviewer (single round) → archiver (lightweight); **does not dispatch openfeel-schemer / openfeel-feel-tester**.
+
+Fast-mode discipline:
+
+1. **The quality floor cannot be skipped**: under fast the reviewer **runs twice** — ① \`plan_review\` plan review (**mandatory single round**, on par with code review; pass → \`plan_passed\`, issues returned → \`plan_pending\`); ② code review after exec (single round); the \`review_failed\` loop allows re-review or returning to exec for fixes; failures are recorded as usual (REV entries unchanged).
+2. **Lightweight**: planner / archiver produce lightweight output (**must not** omit the task table / dependencies / acceptance points, or the state record / knowledge-staging decision).
+3. **Phase semantics**: under fast, reachable phases are the fast-line chain (\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`); the **legal phase enumeration remains at 15** (6 phases are unreachable under fast: \`scheme_*\` / \`test_*\`).
+4. **Full skeletons unchanged**: fast trims no on-disk structure; it only reduces agent relay steps.
+5. **Terminology disambiguation**: the flow mode is called the **Workflow Fast Line** (\`workflow_mode=fast\`); the review-depth downgrade is called **Fast Track (FAST-PASS)** — they are different mechanisms and must not be cross-referenced or conflated.
+
+#### Requirement Lifecycle
+
+The requirement layer is the second layer of the four-layer model "version → requirement REQ-NNN → plan stage → op": **a requirement is the scheduling layer**, answering "what to do and when"; **implementation still goes through the full pipeline** — a requirement is not a plan; after taking a requirement, delegate to openfeel-planner for plan.md per the "Threshold for Small Changes vs. Large-Scale Planning" as usual.
+
+A requirement has 7 statuses: \`draft\` → \`scheduled\` → \`in_progress\` → \`done\`, plus three side states \`blocked\` / \`cancelled\` / \`rejected\`. Requirement progress is aggregated from the linked stages' phases (single projection direction: stage phase → requirement status; the requirement is closed as done automatically once all linked stages are done — precondition: only \`scheduled\` / \`in_progress\`; \`draft\` / \`blocked\` / terminal states do not trigger).
+
+Requirement lifecycle actions (command group \`openfeel req\`, 10 subcommands):
+
+| Step | Action | Command |
+|------|--------|---------|
+| Take | Browse requirement views and pick the next takeable requirement | \`openfeel req board\` / \`openfeel req next\` / \`openfeel req list\` |
+| Claim | Claim the requirement (rejected if already claimed by another — guards concurrent overwrite; no TTL) | \`openfeel req claim <REQ-NNN>\` |
+| Link | Link the requirement to the stages implementing it | \`openfeel req link --stage <stageId> --requirement <REQ-NNN>\` |
+| Advance | Stage advancement drives aggregation; advance explicitly along legal targets | \`openfeel req advance <REQ-NNN> --to <status>\` |
+| Complete | Auto-done once all linked stages are done; overview and release | \`openfeel req board\` / \`openfeel req release <REQ-NNN>\` |
+
+> Orthogonality note: requirement flow is orthogonal to the workflow mode (\`full\` / \`fast\`) — the requirement discipline is identical in both modes.
+
+#### Archiving and History Reading
+
+Once a version is finalized (all its stages done), prompt the user that version archiving is available (\`openfeel flow archive <version>\` — after the criteria gate passes, the archive file is written first and the active entries removed afterwards): the archiving action is executed by the CLI; dispatch only prompts, never performs it.
+
+- Never read archive files proactively: regular dispatch must not read \`.openfeel/flow-archive/**\` (to prevent context pollution); the active set via \`openfeel flow status\` / \`openfeel flow overview\` is the full working view.
+- Query history on demand: when history is genuinely needed, use \`openfeel flow archive show <version>\` (single version, read-only) or \`openfeel flow archive list\` (enumerate versions); do not read the files directly.
+- Distinct from top-level \`openfeel archive\`: the top-level command is stage-summary archiving; \`flow archive\` is flow.json version-shard archiving — different responsibilities.
+
 ## Threshold for Small Changes vs. Large-Scale Planning
 
 Choose the appropriate process path based on the change scale:
@@ -8192,7 +8661,7 @@ A shared log entry (\`.openfeel/log/yyyy-mm-dd-feel-NNN.md\`) must be created wh
 
 ### Skeleton File Note
 
-During critical operations (advancing to exec_running / review_pending / test_pending / archiving), the pipeline automatically creates skeleton files with date prefixes in the private log directory. The main session does not need to manually create log files; simply fill in the content when you see a skeleton file.
+During critical operations (advancing to exec_running / review_pending / test_pending / archiving), the pipeline automatically creates skeleton files with date prefixes in the private log directory (under the fast Workflow Fast Line, \`test_pending\` remains a legal phase but is unreachable (no inbound edge), so its skeleton is no longer produced; all other skeleton rules are unchanged). The main session does not need to manually create log files; simply fill in the content when you see a skeleton file.
 
 ### Log Entry Format
 
@@ -8450,6 +8919,15 @@ After archiving is complete, the stage's pipeline phase must be set to one of th
 
 > ⚠️ Note: After archiving is complete, the stage status must be set to \`"done"\`, **do not** use non-standard values like \`"completed"\`. \`"completed"\` does not exist in \`VALID_TRANSITIONS\`.
 
+> **Under the fast Workflow Fast Line**: the 15-phase enumeration above is **unchanged** (reachable ≠ legal); reachable phases are the fast-line chain (\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`).
+
+## Workflow Mode Awareness (fast lightweight archiving)
+
+Before archiving, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`):
+
+- **full**: full archiving checklist (unchanged).
+- **fast (Workflow Fast Line)**: **lightweight archiving** — the state record and the knowledge-staging decision (including the dedup lookup) **must not be omitted**; checklist process narrative may be merged and condensed. (Lightweight scope: keep the state record / knowledge-staging decision / kb index quick overview / manual update decision / shared log summary; summary process narrative may be merged into bullet points.)
+
 ## Model Selection
 
 openfeel-archiver is decided by the **Claude-side model** (default \`model: inherit\`); archiving and knowledge extraction require understanding of context, and the framework does not hard-code vendor model IDs in templates.
@@ -8461,7 +8939,7 @@ name: openfeel-executor
 description: "Executor: implements code strictly per the op scheme and self-tests (Edit/Write/TodoWrite); does not expand scope."
 tools: Bash, Read, Glob, Grep, Edit, Write, TodoWrite
 effort: medium
-color: red
+color: green
 model: inherit
 ---
 
@@ -8521,9 +8999,10 @@ Confirm that the following 6 required fields are present. If any is missing, ret
 
 ### Step 2: Phase Legitimacy Check
 
-1. Read \`.openfeel/flow.json\`, check if \`pipeline.phase\` is a valid enum value (\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`); refuse to execute if invalid.
+1. Read \`.openfeel/flow.json\`, check if \`pipeline.phase\` is a valid enum value (\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`); refuse to execute if invalid. (under the fast Workflow Fast Line, reachable phases are the fast-line chain; the legal phase enumeration remains at 15 — reachable ≠ legal)
 2. Confirm \`pipeline.current.op\` matches the current op-id; refuse to execute if mismatched.
 3. When the current phase is not \`exec_running\`: if the **main session** explicitly instructs execution, it may proceed but must note the phase deviation; otherwise, refuse to execute.
+4. **Fast-mode phase paths**: \`plan_pending → plan_review → plan_passed → exec_running\` (the plan review is a mandatory single round; the step is entered only after it passes); the \`review_failed → exec_running\` loop (review failure returns to exec for fixes; the \`review_failed → review_pending\` re-review exit is retained).
 
 ### Step 3: FlowManager Transition Legitimacy Check
 
@@ -8667,7 +9146,7 @@ name: openfeel-feel-tester
 description: "Tester: performs formal test acceptance of pipeline outputs and files BUG entries (Edit/Write/Skill)."
 tools: Bash, Read, Glob, Grep, Edit, Write, Skill
 effort: medium
-color: orange
+color: cyan
 model: inherit
 ---
 
@@ -8758,6 +9237,7 @@ Write regression verification results into the Bug file's "Acceptance Record" ta
 - When issues are found, **return to the main session**, which dispatches openfeel-schemer to formulate a revision
 - Re-test after fixes until passing
 - When tests pass, notify the **main session** to enter the archiving phase
+- **Workflow Mode Awareness**: under the fast Workflow Fast Line this agent is **not dispatched** (the formal test step is skipped per \`status.md\` "Workflow Mode"; the \`test_*\` phases are unreachable); the role definition is unchanged.
 
 ## Model Selection
 
@@ -8776,7 +9256,7 @@ name: openfeel-planner
 description: "Planning officer: transforms user requirements into structured development plans, authoring roadmap/plan.md/deps.yaml; read-only, does not edit source."
 tools: Bash, Read, Glob, Grep, Skill
 effort: max
-color: purple
+color: blue
 model: inherit
 ---
 
@@ -8870,6 +9350,22 @@ This step ensures openfeel-planner absorbs existing project knowledge before mak
 - Does not directly code or execute tests
 - openfeel-planner and openfeel-schemer responsibility boundary: openfeel-planner is responsible for "what" (what) and "when" (when), openfeel-schemer is responsible for "how" (how)
 
+## Workflow Mode Awareness (fast)
+
+Before planning, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`):
+
+- **full**: the output goes through openfeel-reviewer plan review (\`plan_review\`) before openfeel-schemer (unchanged).
+- **fast (Workflow Fast Line)**: **this agent's output must pass openfeel-reviewer's plan review (\`plan_review\`, single round; pass → \`plan_passed\`, issues returned → \`plan_pending\`; only then does it enter exec)**; produce a lightweight plan — the task table / dependencies / acceptance points **must not be omitted**; other process narrative may be trimmed. (Lightweight scope: keep goals / dependencies / task table / acceptance points / constraints / KB retrieval / change-point list / risks; background evidence details and revision history may be condensed.)
+
+## Requirement Awareness
+
+When a task originates from a requirement (\`REQ-NNN\`):
+
+- Read the requirement: first read the requirement details (title / status / owner / linked stages) via \`openfeel req show <REQ-NNN>\` as plan input.
+- Link the plan to the requirement: annotate the header of the produced \`plan.md\` with "Linked requirement: REQ-NNN"; omit the annotation when there is no requirement source.
+- Flow is not this agent's duty: requirement status transitions (claim / link / advance) are executed via the \`openfeel req\` CLI; this agent is read-only (no direct flow.json writes).
+- Orthogonal to "Workflow Mode Awareness": requirement awareness is identical under \`full\` / \`fast\`.
+
 ## Model Selection
 
 openfeel-planner is decided by the **Claude-side model** (default \`model: inherit\`); plan formulation requires strong reasoning capability, and the framework does not hard-code vendor model IDs in templates.
@@ -8884,7 +9380,7 @@ name: openfeel-reviewer
 description: "Reviewer: cross-reviews plans/schemes/code and files REV entries; reviews only, does not modify."
 tools: Bash, Read, Glob, Grep
 effort: medium
-color: yellow
+color: pink
 model: inherit
 ---
 
@@ -8946,6 +9442,15 @@ When **all three** of the following conditions are met, openfeel-reviewer enters
 
 If any condition is not met, skip fast track and execute full review process.
 
+## Workflow Mode Awareness (fast single round)
+
+Before reviewing, read the current stage's \`status.md\` "Workflow Mode" field (authoritative query: \`openfeel flow mode [--stage <id>]\`):
+
+- **full**: plan review + code review (multiple points, unchanged).
+- **fast (Workflow Fast Line)**: **single round ×2, both mandatory** — ① \`plan_review\` **plan review (mandatory under fast**, on par with code review; pass → \`plan_passed\`, issues returned → \`plan_pending\`); ② code review after exec (the \`review_failed\` loop allows re-review / returning to exec for fixes); the **quality floor is unchanged** (issues are still recorded and blockers still raised; REV entries as usual).
+
+> **Terminology disambiguation**: the **Workflow Fast Line** (\`workflow_mode=fast\`, the flow mode) and **Fast Track (FAST-PASS)** (the review-depth downgrade mechanism defined in this template) are **different mechanisms** with similar names — do not cross-reference or conflate them.
+
 ## REV Template Specification
 
 \`\`\`yaml
@@ -8989,7 +9494,7 @@ openfeel-reviewer is decided by the **Claude-side model** (default \`model: inhe
 | Requires judgment (default blocking) | Serious coding convention violations / Cross-module consistency issues | \`true\` |
 | Non-blocking | Naming suggestions / Comment improvements / Style tweaks / Optimization suggestions | \`false\` |
 
-> When fast track is hit, REV defaults to \`blocking=false\` (except for security vulnerabilities).
+> When fast track is hit, REV defaults to \`blocking=false\` (except for security vulnerabilities). This mechanism is unrelated to the Workflow Fast Line — see "Workflow Mode Awareness".
 
 ## blocking and Pipeline Behavior
 
@@ -9105,6 +9610,7 @@ When third-party dependencies are involved:
 
 - Receives dispatch from the **main session** to start; outputs are reviewed by openfeel-reviewer before being handed to openfeel-executor
 - When review fails, re-formulate the scheme based on openfeel-reviewer feedback
+- **Workflow Mode Awareness**: under the fast Workflow Fast Line this agent is **not dispatched** (the scheme step is skipped per \`status.md\` "Workflow Mode"); the role definition is unchanged.
 
 ## Notes
 
@@ -9432,6 +9938,47 @@ openfeel-reviewer 审查发现的 REV，**即使是白名单操作（如文档
 3. **用户拒绝**：主会话保持 \`auto_advance=disabled\`，每次阶段推进前均需向用户确认（手动执行模式）。
 4. **禁止静默推进**：\`auto_advance=disabled\` 时禁止主会话不询问用户直接推进流水线。
 
+#### 工作流模式（workflow_mode）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询：\`openfeel flow mode [--stage <id>]\`；字段缺失时按级联口径回落）。两种模式：
+
+- **full（完整流程）**：planner → plan_review（reviewer）→ schemer → executor → reviewer → tester → archiver。
+- **fast（工作流快线）**：planner（轻量）→ plan_review（**计划审查单轮，必经**）→ executor → reviewer（单轮）→ archiver（轻量）；**不派发 schemer / tester**。
+
+fast 调度纪律：
+
+1. **质量底线不可跳**：reviewer 在 fast 下**必跑两处**——① \`plan_review\` 计划审查（**必经单轮**，与代码审查同级；通过 → \`plan_passed\`，问题退回 → \`plan_pending\`）；② exec 后代码审查（单轮）；\`review_failed\` 回环可重审或回执行修复；失败留痕照常（REV 条目照常）。
+2. **轻量化**：planner / archiver 轻量产出（**不得**省略任务表 / 依赖 / 验收要点与状态记录 / 知识暂存判定）。
+3. **相位口径**：fast 下可达相位为快线链（\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`）；**合法相位枚举 15 项不变**（fast 下 6 项不可达：\`scheme_*\` / \`test_*\`）。
+4. **骨架全量不变**：fast 不裁剪任何落盘结构，仅减少 Agent 接力环节。
+5. **术语消歧**：流程模式称「**工作流快线**」（\`workflow_mode=fast\`）；审查深度降级称「**快速通道 / fast track（FAST-PASS）**」——二者为不同机制，不得互相引用 / 混用。
+
+#### 需求流转（requirement lifecycle）
+
+需求层位于「版本 → 需求 REQ-NNN → 计划 stage → 方案 op」四层模型的第二层：**需求 = 排期与调度层**，回答「做什么、何时做」；**实现仍走完整流水线**——需求不等于计划，接取需求后按「小改 vs 大规模规划的阈值」照常委托 openfeel-planner 产出 plan.md。
+
+需求共 7 个状态：\`draft\` → \`scheduled\` → \`in_progress\` → \`done\`，另有 \`blocked\` / \`cancelled\` / \`rejected\` 三个旁路状态。需求进度由关联阶段的 phase 聚合（投影方向单一：阶段 phase → 需求状态；全部关联阶段 done 时需求自动收口 done——前置集限定：仅 \`scheduled\` / \`in_progress\`；\`draft\` / \`blocked\` / 终态不触发）。
+
+需求生命周期动作（命令组 \`openfeel req\`，共 10 个子命令）：
+
+| 步骤 | 动作 | 命令 |
+|------|------|------|
+| 接取 | 浏览需求视图，挑选下一个可接取需求 | \`openfeel req board\` / \`openfeel req next\` / \`openfeel req list\` |
+| 认领 | 占用需求（已被他人认领则拒绝——防并发覆盖，无 TTL） | \`openfeel req claim <REQ-NNN>\` |
+| 关联 | 把需求关联到实现它的阶段 | \`openfeel req link --stage <stageId> --requirement <REQ-NNN>\` |
+| 流转 | 阶段推进驱动聚合；显式流转按合法目标推进 | \`openfeel req advance <REQ-NNN> --to <status>\` |
+| 完成 | 全部关联阶段 done 后需求自动 done；总览与释放 | \`openfeel req board\` / \`openfeel req release <REQ-NNN>\` |
+
+> 正交注记：需求流转与工作流模式（\`full\` / \`fast\`）正交——两种模式下需求纪律一致。
+
+#### 归档与历史读取
+
+版本收官（该版本全部阶段 done）后，提示用户可执行版本归档（\`openfeel flow archive <version>\`——判据门校验后先写归档文件、再移除活跃条目）：归档动作由 CLI 执行，调度侧只提示不代劳。
+
+- 不主动读归档文件：常规调度不得读取 \`.openfeel/flow-archive/**\`（防上下文污染）；活跃集经 \`openfeel flow status\` / \`openfeel flow overview\` 即为全量工作视图。
+- 按需查询历史：确需历史版本时用 \`openfeel flow archive show <version>\`（单版本只读）或 \`openfeel flow archive list\`（列举版本），不直接读文件。
+- 与顶层 \`openfeel archive\` 区分：顶层命令是阶段摘要归档；\`flow archive\` 是 flow.json 版本分片归档，二者职责不同。
+
 ## 小改 vs 大规模规划的阈值
 
 根据变更规模选择适当的流程路径：
@@ -9499,7 +10046,7 @@ openfeel-reviewer 审查发现的 REV，**即使是白名单操作（如文档
 
 ### 骨架文件提示
 
-关键操作（推进到 exec_running / review_pending / test_pending / archiving）时，流水线会自动在私域日志目录创建带日期前缀的骨架文件。主会话无需手动创建日志文件，看到骨架文件时填充内容即可。
+关键操作（推进到 exec_running / review_pending / test_pending / archiving）时，流水线会自动在私域日志目录创建带日期前缀的骨架文件（fast 工作流快线下 \`test_pending\` 仍为合法相位、仅不可达（无入边），该相位骨架不再产生；其余骨架规则全量不变）。主会话无需手动创建日志文件，看到骨架文件时填充内容即可。
 
 ### 日志条目格式
 
@@ -9756,6 +10303,15 @@ openfeel-feel-tester 通过 → 主会话触发归档 → openfeel-archiver 整
 
 > ⚠️ 注意：归档完成后的阶段状态必须设为 \`"done"\`，**不得**使用 \`"completed"\` 等非标准值。\`VALID_TRANSITIONS\` 中不存在 \`"completed"\`。
 
+> **fast 工作流快线下**：上表 15 项相位枚举**不变**（可达 ≠ 合法）；可达相位为快线链（\`plan_pending → plan_review → plan_passed → exec_running → review_pending → review_failed → review_passed → archiving → done\`）。
+
+## 工作流模式感知（fast 轻量归档）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询 \`openfeel flow mode [--stage <id>]\`）：
+
+- **full**：归档全量清单（现状不变）。
+- **fast（工作流快线）**：**轻量归档**——状态记录与知识暂存判定（含去重检索）**不得省略**；清单过程性叙述可合并精简。（轻量口径：保留 状态记录 / 知识暂存判定 / 知识库快速概览 / 模块手册判定 / 公共日志摘要；总结过程性叙述可合并为要点。）
+
 ## 模型选择
 
 openfeel-archiver 由 **Claude 侧模型**决定（默认 \`model: inherit\`）；归档与知识提取需要理解上下文，框架不在模板内硬编码厂商模型 ID。
@@ -9767,7 +10323,7 @@ name: openfeel-executor
 description: 执行官：严格按 op 操作方案编码实现并自测（Edit/Write/TodoWrite）；不擅自扩大范围。
 tools: Bash, Read, Glob, Grep, Edit, Write, TodoWrite
 effort: medium
-color: red
+color: green
 model: inherit
 ---
 
@@ -9827,9 +10383,10 @@ model: inherit
 
 ### 步骤 2：Phase 合法性校验
 
-1. 读取 \`.openfeel/flow.json\`，检查 \`pipeline.phase\` 是否为合法枚举值（\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`），非法则拒绝执行。
+1. 读取 \`.openfeel/flow.json\`，检查 \`pipeline.phase\` 是否为合法枚举值（\`plan_pending | plan_review | plan_passed | scheme_pending | scheme_review | scheme_passed | exec_running | review_pending | review_failed | review_passed | test_pending | test_failed | test_passed | archiving | done\`），非法则拒绝执行。（fast 工作流快线下可达相位为快线链；合法相位枚举 15 项不变——可达 ≠ 合法）
 2. 确认 \`pipeline.current.op\` 与当前 op-id 匹配，不匹配则拒绝执行。
 3. 当前 phase 不是 \`exec_running\` 时：若**主会话**已明确指示执行可继续但需注明 phase 偏差；否则拒绝执行。
+4. **fast 工作流快线下相位路径**：\`plan_pending → plan_review → plan_passed → exec_running\`（计划审查为必经单轮：通过后进入本环节）；\`review_failed → exec_running\` 回环（审查不通过时回执行修复；\`review_failed → review_pending\` 重审出口保留）。
 
 ### 步骤 3：FlowManager 流转合法性校验
 
@@ -9973,7 +10530,7 @@ name: openfeel-feel-tester
 description: 测试官：对流水线产出做正式测试验收，记录 BUG 条目（Edit/Write/Skill）。
 tools: Bash, Read, Glob, Grep, Edit, Write, Skill
 effort: medium
-color: orange
+color: cyan
 model: inherit
 ---
 
@@ -10064,6 +10621,7 @@ high 优先级 Bug 修复后，推荐执行全量测试套件。
 - 发现问题后**返回主会话**，由主会话调度 openfeel-schemer 制定修复方案
 - 修复后重新测试直到通过
 - 测试通过后通知**主会话**进入归档阶段
+- **工作流模式感知**：fast 工作流快线下本 Agent **不被调度**（依据 \`status.md「工作流模式」\` 跳过正式测试环节，\`test_*\` 相位不可达）；职责定义不变。
 
 ## 模型选择
 
@@ -10082,7 +10640,7 @@ name: openfeel-planner
 description: 计划官：将用户需求转化为结构化开发计划，制定 roadmap/plan.md/deps.yaml；只读，不写源码。
 tools: Bash, Read, Glob, Grep, Skill
 effort: max
-color: purple
+color: blue
 model: inherit
 ---
 
@@ -10176,6 +10734,22 @@ openfeel-planner 作为独立 subagent，由**主会话（Feel 角色）**经 **
 - 不直接编码，不执行测试
 - openfeel-planner 与 openfeel-schemer 的职责边界：openfeel-planner 负责"做什么"（what）和"何时做"（when），openfeel-schemer 负责"怎么做"（how）
 
+## 工作流模式感知（fast 快线）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询 \`openfeel flow mode [--stage <id>]\`）：
+
+- **full**：产出经 openfeel-reviewer 计划审查（\`plan_review\`）后进入 openfeel-schemer（现状不变）。
+- **fast（工作流快线）**：**本 Agent 产出后必经 openfeel-reviewer 的计划审查（\`plan_review\` 单轮；通过 → \`plan_passed\`，问题退回 → \`plan_pending\`；此后进入 exec）**；产出为轻量计划——任务表 / 依赖声明 / 验收要点**不得省略**，其余过程性描述可精简。（轻量口径：保留 目标 / 依赖 / 任务表 / 验收要点 / 约束 / KB 检索 / 变更点清单 / 风险；背景实测证据明细与修订记录过程可收敛为结论。）
+
+## 需求感知
+
+当任务源自需求（\`REQ-NNN\`）时：
+
+- 读取需求：先以 \`openfeel req show <REQ-NNN>\` 读取需求详情（标题 / 状态 / 认领人 / 关联阶段），作为计划输入。
+- 计划关联需求：产出的 \`plan.md\` 头部标注「关联需求：REQ-NNN」；无需求来源时省略该标注。
+- 流转不在本 Agent 职责内：需求状态流转（认领 / 关联 / 推进）经 \`openfeel req\` CLI 执行；本 Agent 只读不写（不直写 flow.json）。
+- 与「工作流模式感知」正交：\`full\` / \`fast\` 下需求感知口径一致。
+
 ## 模型选择
 
 openfeel-planner 由 **Claude 侧模型**决定（默认 \`model: inherit\`）；计划制定需要较强推理能力，框架不在模板内硬编码厂商模型 ID。
@@ -10190,7 +10764,7 @@ name: openfeel-reviewer
 description: 审查官：交叉审查计划/方案/代码并提交 REV 条目；只审不改。
 tools: Bash, Read, Glob, Grep
 effort: medium
-color: yellow
+color: pink
 model: inherit
 ---
 
@@ -10252,6 +10826,15 @@ model: inherit
 
 若任一条件不满足，跳过快速通道，执行完整审查流程。
 
+## 工作流模式感知（fast 单轮）
+
+调度前读取当前阶段 \`status.md「工作流模式」\`（权威查询 \`openfeel flow mode [--stage <id>]\`）：
+
+- **full**：计划审查 + 代码审查（多轮位点，现状不变）。
+- **fast（工作流快线）**：**单轮 ×2，两处均必跑**——① \`plan_review\` **计划审查（fast 下必经**，与代码审查同级；通过 → \`plan_passed\`，问题退回 → \`plan_pending\`）；② exec 后代码审查（\`review_failed\` 回环可重审 / 回执行修复）；**质量底线不变**（问题照记、阻断照留，REV 条目照常）。
+
+> **术语消歧**：本节的「**工作流快线**」（\`workflow_mode=fast\`，流程模式）与本模板「**快速通道 / fast track（FAST-PASS）**」（审查深度降级机制）为**不同机制**、同名异义——不得互相引用 / 混用。
+
 ## REV 模板规范
 
 \`\`\`yaml
@@ -10295,7 +10878,7 @@ openfeel-reviewer 由 **Claude 侧模型**决定（默认 \`model: inherit\`）
 | 需判定（默认阻塞） | 编码规范严重违反 / 跨模块一致性问题 | \`true\` |
 | 非阻塞 | 命名建议 / 注释完善 / 风格微调 / 优化建议 | \`false\` |
 
-> 快速通道命中时，REV 默认 \`blocking=false\`（安全漏洞除外）。
+> 快速通道命中时，REV 默认 \`blocking=false\`（安全漏洞除外）。该机制与「工作流快线」无关——见「工作流模式感知」节。
 
 ## blocking 与流水线行为
 
@@ -10411,6 +10994,7 @@ model: inherit
 
 - 接收**主会话**调度启动，产出方案经 openfeel-reviewer 审查后交 openfeel-executor 执行
 - 审查不通过时，根据 openfeel-reviewer 反馈重新制定方案
+- **工作流模式感知**：fast 工作流快线下本 Agent **不被调度**（依据 \`status.md「工作流模式」\` 跳过方案环节）；职责定义不变。
 
 ## 注意事项
 
@@ -10573,7 +11157,7 @@ Not all tasks must go through the full pipeline. Non-coding tasks and coding tas
 | Task Type | Handling Path | Notes |
 |-----------|---------------|-------|
 | Research/exploration (reading code, consulting references, locating issues) | The main session (Feel role) → research (\`general\` / \`Explore\` subagent) | Read-only exploration, no source code changes; flow.json need not spin up for this |
-| Coding implementation (adding/modifying source code) | Full pipeline (openfeel-planner → openfeel-schemer → openfeel-executor → openfeel-reviewer → openfeel-feel-tester) | Involves source changes, must go through the full audit chain |
+| Coding implementation (adding/modifying source code) | Full pipeline (openfeel-planner → openfeel-schemer → openfeel-executor → openfeel-reviewer → openfeel-feel-tester) (full); in fast mode: planner → plan review (reviewer, single mandatory round) → executor → code review (reviewer) → archiver (see status.md "Workflow Mode" / openfeel flow mode) | Involves source changes, must go through the full audit chain (fast-line audit chain in fast mode) |
 | Selection discussion (settling a technical approach / design trade-off) | The main session (Feel role) and the user + the \`AskUserQuestion\` tool | Conversational decision, produces a conclusion, no plan.md |
 
 > Non-coding tasks (research, selection discussion) do not require creating a plan or advancing the pipeline; the pipeline is engaged only when source changes or a formal plan document is produced.
@@ -10636,7 +11220,7 @@ When encountering technical issues, **the first action MUST be to consult the kn
    - openfeel-utility Agent performs mechanical file operations, does not participate in design decisions
    - openfeel-archiver archives and distills knowledge, does not modify source code; does not write flow.json directly (written via the **main session**)
 
-3. **Main session orchestration constraint**: The **main session (Feel role)**, as the overall commander, uniformly orchestrates downstream subagents (openfeel-planner / openfeel-schemer / openfeel-executor / openfeel-reviewer / openfeel-feel-tester / openfeel-utility Agent / openfeel-vision / openfeel-archiver), advancing serially via the **Task** tool according to pipeline phases (plan → scheme → execute → review → test → archive). Each Agent operates only within its own responsibility boundary and must not start other Agents beyond its scope or modify flow.json state on its own.
+3. **Main session orchestration constraint**: The **main session (Feel role)**, as the overall commander, uniformly orchestrates downstream subagents (openfeel-planner / openfeel-schemer / openfeel-executor / openfeel-reviewer / openfeel-feel-tester / openfeel-utility Agent / openfeel-vision / openfeel-archiver), advancing serially via the **Task** tool according to pipeline phases (plan → scheme → execute → review → test → archive) (full); in fast mode: plan → plan review → execute → code review → archive (see status.md "Workflow Mode" / openfeel flow mode). Each Agent operates only within its own responsibility boundary and must not start other Agents beyond its scope or modify flow.json state on its own.
 
 4. **Lightweight decision boundary**: Conversational selections (the **main session** and the user settle a technical direction or design trade-off via the \`AskUserQuestion\` tool, producing a conclusion but no plan.md) are handled by the **main session** directly, without delegating to openfeel-planner; only when a **formal plan document** (plan.md, including stage division, task table, constraint table) is needed, or the planning scale threshold is reached, should openfeel-planner be delegated. Avoid the extremes of "handle everything personally" or "delegate everything".
 
@@ -10692,7 +11276,7 @@ Version progression must be prudent, using the four-level X.Y.Z.W version number
 | Level 4 (W) | Feature detail | Independently committed feature or submodule |
 
 When Feel starts a new version, it defaults to incrementing the fourth level (W+1), unless the user explicitly specifies otherwise.
-The OpenFeel framework has released the official v1.0.x (currently v1.1.6). After deploying the global constraints via openfeel setup, new projects set their own starting version number as needed.
+The OpenFeel framework has released the official v1.0.x (currently v1.2.0). After deploying the global constraints via openfeel setup, new projects set their own starting version number as needed.
 
 ### Module Manuals
 
@@ -11085,7 +11669,7 @@ AI Agent 行为约束与编码规范。本文件为永久性约束，适用于
 | 任务类型 | 处理路径 | 说明 |
 |----------|----------|------|
 | 调研/探索（读代码、查资料、定位问题） | 主会话（Feel 角色）→ research（\`general\` / \`Explore\` subagent） | 只读探索，不产出源码变更，flow.json 不必为此空转 |
-| 编码实现（新增/修改源码） | 完整流水线（openfeel-planner → openfeel-schemer → openfeel-executor → openfeel-reviewer → openfeel-feel-tester） | 有源码变更，须走完整审计链 |
+| 编码实现（新增/修改源码） | 完整流水线（openfeel-planner → openfeel-schemer → openfeel-executor → openfeel-reviewer → openfeel-feel-tester）（full）；fast 工作流快线（workflow_mode=fast）下为 planner → 计划审查（reviewer，单轮必经）→ executor → 代码审查（reviewer）→ archiver——见 status.md「工作流模式」 / openfeel flow mode | 有源码变更，须走完整审计链（fast 走快线审计链） |
 | 选型讨论（敲定技术方案/设计取舍） | 主会话（Feel 角色）与用户 + \`AskUserQuestion\` 工具 | 对话式决策，产出结论，不产出 plan.md |
 
 > 非编码任务（调研、选型讨论）不强制创建计划或推进流水线；仅当产生源码变更或正式计划文档时才接入流水线。
@@ -11148,7 +11732,7 @@ AI Agent 行为约束与编码规范。本文件为永久性约束，适用于
    - 事务官 执行文件机械操作，不参与设计决策
    - openfeel-archiver 归档和沉淀知识，不修改源码；不直写 flow.json（通过**主会话**写入）
 
-3. **主会话调度约束**：**主会话（Feel 角色）**统一调度下游 subagent（openfeel-planner / openfeel-schemer / openfeel-executor / openfeel-reviewer / openfeel-feel-tester / 事务官 / openfeel-vision / openfeel-archiver），通过 **Task** 工具按流水线阶段（计划→方案→执行→审查→测试→归档）串行推进。各 Agent 仅在自己的职责边界内操作，不得越界启动其他 Agent 或自行修改 flow.json 状态。
+3. **主会话调度约束**：**主会话（Feel 角色）**统一调度下游 subagent（openfeel-planner / openfeel-schemer / openfeel-executor / openfeel-reviewer / openfeel-feel-tester / 事务官 / openfeel-vision / openfeel-archiver），通过 **Task** 工具按流水线阶段（计划→方案→执行→审查→测试→归档）串行推进（full）；fast 工作流快线下为 计划 → 计划审查 → 执行 → 代码审查 → 归档（见 status.md「工作流模式」 / openfeel flow mode）。各 Agent 仅在自己的职责边界内操作，不得越界启动其他 Agent 或自行修改 flow.json 状态。
 
 4. **轻量决策边界**：对话式选型（**主会话**与用户通过 \`AskUserQuestion\` 工具敲定技术方向/设计取舍，产出结论不产出 plan.md）由**主会话**直接处理，不委托 openfeel-planner；仅当需要**产出正式计划文档**（plan.md，含阶段划分、任务表、约束表）或达到规划规模阈值时，才委托 openfeel-planner。避免"要么全亲为、要么全委托"的极端。
 
@@ -11204,7 +11788,7 @@ Claude Code 的权限与工具可用性由 subagent 的 \`tools\` 白名单与 \
 | 四级（W） | 功能细节 | 独立提交的功能或子模块 |
 
 Feel 启动新版本时默认使用四级版本递增（W+1），除非用户明确指定。
-OpenFeel 框架已发布正式版 v1.0.x（当前 v1.1.6）。新项目经 openfeel setup 部署全局约束后，按自身需求设定起始版本号。
+OpenFeel 框架已发布正式版 v1.0.x（当前 v1.2.0）。新项目经 openfeel setup 部署全局约束后，按自身需求设定起始版本号。
 
 ### 模块手册