@xenonbyte/da-vinci-workflow 0.2.3 → 0.2.4

package/docs/dv-command-reference.md

@@ -43,10 +43,11 @@ These commands do not replace route selection, but they support design execution
   - useful when the command surface is harder to remember than the workflow itself
 - `da-vinci workflow-status --project <path> [--change <id>] [--json]`
   - derives the current workflow stage from artifact and checkpoint truth
-  - reports blockers, warnings, handoff-gate state, and one primary route recommendation
+  - reports blockers, warnings, handoff-gate state, discipline markers, execution profile hints, and verification-evidence freshness
   - keep this distinct from `audit`: route guidance is not completion truth
 - `da-vinci next-step --project <path> [--change <id>] [--json]`
   - provides a route-first continuation summary from the same derived workflow state
+  - JSON output includes `nextStep`, `executionProfile`, `worktreePreflight`, and discipline/freshness metadata for orchestration consumers
   - use this as the first continuation signal before free-form artifact scanning
 - `da-vinci lint-spec --project <path> [--change <id>] [--strict] [--json]`
   - validates Da Vinci runtime `spec.md` schema sections (`Behavior`, `States`, `Inputs`, `Outputs`, `Acceptance`, `Edge Cases`)
@@ -57,7 +58,7 @@ These commands do not replace route selection, but they support design execution
   - emits a machine-readable coverage matrix for pages and states
   - default behavior is advisory (`WARN` with zero exit); `--strict` upgrades findings to blocking
 - `da-vinci lint-tasks --project <path> [--change <id>] [--strict] [--json]`
-  - validates top-level task groups, ordering, verification actions, and behavior-to-task coverage hints
+  - validates top-level task groups, ordering, discipline markers, execution-mode hints, file targets, verification commands, and behavior-to-task coverage hints
   - default behavior is advisory (`WARN` with zero exit); `--strict` upgrades findings to blocking
 - `da-vinci lint-bindings --project <path> [--change <id>] [--strict] [--json]`
   - validates implementation-to-Pencil mappings for parseability, source shape, and implementation landings
@@ -68,6 +69,15 @@ These commands do not replace route selection, but they support design execution
 - `da-vinci verify-bindings|verify-implementation|verify-structure|verify-coverage --project <path> [--change <id>] [--strict] [--json]`
   - verifies code landings, planned-state implementation evidence, and structural consistency against bindings
   - `verify-structure` reports whether checks used markup-backed analysis or heuristic fallback and exposes confidence
+- `da-vinci task-execution --project <path> --change <id> --task-group <id> --status <DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED> --summary <text> [--changed-files <csv>] [--test-evidence <csv>] [--concerns <csv>] [--blockers <csv>] [--json]`
+  - persists normalized implementer-status envelopes into execution signals
+  - use this to keep resume routing machine-readable when implementation is blocked or concerns remain
+- `da-vinci task-review --project <path> --change <id> --task-group <id> --stage <spec|quality> --status <PASS|WARN|BLOCK> --summary <text> [--issues <csv>] [--reviewer <name>] [--write-verification] [--json]`
+  - persists ordered two-stage task review evidence (`spec` before `quality`)
+  - rejects out-of-order quality approval and can append evidence into `verification.md`
+- `da-vinci worktree-preflight --project <path> [--change <id>] [--json]`
+  - runs advisory worktree isolation checks (`.worktrees/` or `worktrees/` ignore safety, dirty workspace, baseline test heuristics)
+  - does not replace route truth; use it to decide whether bounded-parallel execution should downgrade to serial
 - `da-vinci diff-spec --project <path> [--change <id>] [--from <sidecars-dir>] [--json]`
   - compares normalized planning sidecars and reports added/removed/modified requirement planning items
   - includes normalized spec deltas plus broader planning summaries (tasks/page-map/bindings) under one surface
@@ -255,6 +265,10 @@ Build-stage self-check:
 - run `da-vinci scope-check --project <path> [--change <id>]`
 - if `tasks.md` exists, run `da-vinci lint-tasks --project <path> [--change <id>]`
 - if both `pencil-design.md` and `pencil-bindings.md` exist, run `da-vinci lint-bindings --project <path> [--change <id>]`
+- inspect `executionProfile` from `da-vinci next-step --project <path> [--change <id>] --json`
+- if profile mode is `bounded_parallel`, run `da-vinci worktree-preflight --project <path> [--change <id>]` and downgrade to serial unless isolation is ready or explicitly accepted
+- persist per-task implementer outcomes via `da-vinci task-execution ...` and keep unresolved concerns visible before closure
+- run task review in order: `da-vinci task-review ... --stage spec ...` then `da-vinci task-review ... --stage quality ...`
 - treat command output as the gate; do not downgrade `BLOCK` or non-zero results into soft guidance
 - treat any `BLOCK` or missing required planning/design artifact as a hard stop before broad implementation
 
@@ -286,6 +300,8 @@ Verify-stage self-check:
 - run `da-vinci verify-coverage --project <path> [--change <id>]`
 - treat command output as the gate; do not downgrade `BLOCK` or `FAIL` into soft guidance
 - if any verification surface is still `BLOCK` or `FAIL`, keep the workflow in verification and record the drift instead of claiming success
+- require fresh verification evidence in `verify-coverage` and `workflow-status` before terminal completion wording
+- if task-review evidence is being recorded, keep unresolved `WARN/BLOCK` review stages open instead of closing the task group
 - before terminal completion, require `da-vinci audit --mode completion --change <change-id> <project-path>` to pass
 
 ## State-Based Next-Step Rules

package/docs/execution-chain-migration.md

@@ -44,3 +44,26 @@ If any check fails, Da Vinci falls back to derived state from artifacts and reco
 - no multi-framework expansion in the MVP
 - scaffold boundaries come from `pencil-bindings.md` mappings
 - verify scaffold output with `verify-bindings`, `verify-implementation`, and `verify-structure` before acceptance
+
+## 5. Planned Next Upgrade: Discipline And Orchestration
+
+After execution-chain surfaces are enabled, the next planned upgrade is:
+
+- `openspec/changes/discipline-and-orchestration-upgrade/`
+
+This planned change adds:
+
+- stronger handoff discipline before implementation
+- stronger task-plan quality checks
+- bounded orchestration hints tied to workflow state
+- structured task execution and review evidence
+- completion wording discipline backed by fresh verification evidence
+- optional worktree preflight guidance
+
+Important boundary:
+
+- this does not replace artifact truth, checkpoint truth, or completion-audit authority
+
+See:
+
+- `docs/discipline-and-orchestration-upgrade.md`

package/docs/prompt-entrypoints.md

@@ -66,13 +66,17 @@ Continuation precedence:
 
 - when shell access is available, run `da-vinci workflow-status --project <path> [--change <id>] --json` before route selection
 - use `da-vinci next-step --project <path> [--change <id>]` as the first continuation routing signal
+- prefer reading `da-vinci next-step --project <path> [--change <id>] --json` when available so discipline marker state, execution-profile hints, and verification freshness are explicit
 - run `da-vinci lint-spec --project <path> [--change <id>]` when runtime spec quality is uncertain before routing into `build`
 - run `da-vinci scope-check --project <path> [--change <id>]` when page or state propagation across planning artifacts is uncertain
+- run `da-vinci lint-tasks --project <path> [--change <id>]` before routing into `build` when task metadata quality is uncertain
 - run `da-vinci verify-bindings --project <path> [--change <id>]` and `da-vinci verify-coverage --project <path> [--change <id>]` before terminal completion routing
 - run `da-vinci diff-spec --project <path> [--change <id>]` after planning edits when continuation must reason about changed requirement slices
 - determine routing from artifact and checkpoint truth first
 - use contextual checkpoint deltas only as auxiliary recovery context
 - if contextual deltas conflict with current artifacts, ignore them for routing and note the conflict
+- if design approval discipline markers are missing, malformed, or stale, keep routing in `design` or `tasks` and avoid direct promotion into `build`
+- if bounded-parallel execution is hinted, run `da-vinci worktree-preflight --project <path> [--change <id>]` before emitting a parallel build continuation prompt
 
 ## Default Flow
 
@@ -93,6 +97,7 @@ State rule:
 
 - if design is done but `tasks.md` does not exist yet, the next recommended route should usually be `tasks`, not `build`
 - only recommend `build` as the primary next step once tasks and implementation readiness are already clear
+- never include terminal completion wording unless fresh verification evidence is present and completion audit is explicitly required
 
 ## Platform Syntax
 

package/docs/skill-usage.md

@@ -85,6 +85,12 @@ When design is mostly ready and implementation is next, use these checks:
   - use this when runtime spec quality is still uncertain
 - `da-vinci scope-check`
   - use this when page/state propagation across planning artifacts looks ambiguous
+- `da-vinci lint-tasks`
+  - confirm task groups have discipline markers, exact ownership targets, execution intent, and verification commands
+- `da-vinci lint-bindings`
+  - run this when `pencil-design.md` and `pencil-bindings.md` both exist so implementation landing evidence stays parseable
+- `da-vinci worktree-preflight`
+  - run this before bounded-parallel execution to decide whether local worktree isolation is recommended
 
 If you are already inside the project root directory, `--project` is optional because the CLI falls back to `cwd`.
 
@@ -95,8 +101,17 @@ da-vinci workflow-status
 da-vinci next-step
 da-vinci lint-spec
 da-vinci scope-check
+da-vinci lint-tasks
 ```
 
+During implementation, persist machine-readable task evidence instead of relying on chat-only summaries:
+
+- `da-vinci task-execution --project <path> --change <id> --task-group <id> --status <DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED> --summary <text> ...`
+- `da-vinci task-review --project <path> --change <id> --task-group <id> --stage spec ...`
+- `da-vinci task-review --project <path> --change <id> --task-group <id> --stage quality ...`
+
+`quality` review is valid only after `spec` review has a `PASS` record for the same task group.
+
 ## After Pausing Midway
 
 The safest resume order is:
@@ -107,6 +122,7 @@ The safest resume order is:
 4. if planning propagation is unclear, run `da-vinci scope-check`
 5. if planning artifacts changed since the last stable snapshot, run `da-vinci generate-sidecars` and `da-vinci diff-spec`
 6. before terminal completion, run `da-vinci verify-bindings` and `da-vinci verify-coverage`
+7. if completion wording is needed, confirm `verify-coverage` freshness is current and run `da-vinci audit --mode completion --change <id> <project-path>`
 
 Resume should follow the artifacts, not old conversation state:
 

package/docs/workflow-overview.md

@@ -30,6 +30,12 @@ This means:
 - project-local `.pen` files remain the design source of truth
 - implementation must stay traceable to both
 
+Truth-versus-orchestration boundary:
+
+- route and completion truth comes from artifacts, checkpoints, execution signals, and `audit`
+- orchestration hints such as execution profiles and worktree preflight remain advisory guidance
+- orchestration hints must never override explicit `BLOCK` truth from artifacts, checkpoints, or completion audit
+
 ## Main Flow
 
 1. Choose the correct mode.
@@ -60,6 +66,12 @@ Use these command surfaces to inspect route readiness before selecting the next
   - explicitly generates deterministic planning sidecars used by diff and downstream tooling
 - `da-vinci verify-bindings|verify-implementation|verify-structure|verify-coverage --project <path> [--change <id>] [--strict] [--json]`
   - validates execution-chain evidence from bindings through implementation and structural coverage
+- `da-vinci task-execution --project <path> --change <id> --task-group <id> --status <DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED> --summary <text> ...`
+  - persists normalized implementer evidence per task group so pause/resume routing can read unresolved blockers and concerns
+- `da-vinci task-review --project <path> --change <id> --task-group <id> --stage <spec|quality> --status <PASS|WARN|BLOCK> --summary <text> ...`
+  - persists ordered two-stage review evidence (`spec` before `quality`) and can append review records into `verification.md`
+- `da-vinci worktree-preflight --project <path> [--change <id>] [--json]`
+  - runs advisory worktree isolation checks before bounded-parallel execution
 - `da-vinci diff-spec --project <path> [--change <id>] [--from <sidecars-dir>] [--json]`
   - reports normalized planning deltas for spec/tasks/page-map/bindings sidecars to support safe continuation
 
@@ -185,7 +197,11 @@ These checks verify that:
 After mapping passes:
 
 - generate `tasks.md`
+- keep task groups parseable with discipline markers plus explicit file targets, execution intent, review intent, and verification commands
 - implement from requirements plus Pencil data
+- inspect `executionProfile` from `workflow-status` or `next-step --json` before broad implementation
+- if bounded parallelism is suggested, run `da-vinci worktree-preflight --project <path> [--change <id>]` and downgrade to serial when isolation is not ready
+- persist per-task implementer and review evidence via `task-execution` and ordered `task-review` records
 - verify requirement drift and design drift
 
 ### 8. Terminal Completion
@@ -195,6 +211,7 @@ The workflow must not report `design complete`, `workflow complete`, or any equi
 - design checkpoint is no longer blocking
 - design-source checkpoint is at least `PASS`
 - MCP runtime gate is acceptable when Pencil MCP was used
+- fresh verification evidence is present for in-scope implementation and coverage claims
 - `da-vinci audit --mode completion --change <change-id> <project-path>` passes
 
 Notes:

package/docs/zh-CN/dv-command-reference.md

@@ -45,10 +45,11 @@ Da Vinci 期望它们遵循工作流状态。
   - 当真正难记的是命令面而不是流程本身时，优先用它
 - `da-vinci workflow-status --project <path> [--change <id>] [--json]`
   - 从工件和 checkpoint 真相推导当前 workflow 阶段
-  - 报告 blocker、warning、handoff gate 状态，以及主推荐路由
+  - 报告 blocker、warning、handoff gate、discipline marker、execution profile 提示与 verification freshness
   - 它和 `audit` 职责不同：它负责选路，不是终态审计真相
 - `da-vinci next-step --project <path> [--change <id>] [--json]`
   - 基于同一套 workflow-state 推导，给出 route-first 的续跑建议
+  - JSON 输出包含 `nextStep`、`executionProfile`、`worktreePreflight` 与 discipline/freshness 元数据
   - 在自由扫描工件之前，优先把它作为第一路由信号
 - `da-vinci lint-spec --project <path> [--change <id>] [--strict] [--json]`
   - 校验 Da Vinci 运行时 `spec.md` 的核心章节（`Behavior`、`States`、`Inputs`、`Outputs`、`Acceptance`、`Edge Cases`）
@@ -59,7 +60,7 @@ Da Vinci 期望它们遵循工作流状态。
   - 输出页面与状态两条线的机器可读覆盖矩阵
   - 默认 advisory（有发现给 `WARN` 且不阻断）；显式 `--strict` 才升级为阻断
 - `da-vinci lint-tasks --project <path> [--change <id>] [--strict] [--json]`
-  - 校验顶层 task groups、编号顺序、verification 动作和 behavior 覆盖提示
+  - 校验顶层 task groups、编号顺序、discipline markers、执行模式提示、文件目标、verification 命令与 behavior 覆盖提示
   - 默认 advisory（有发现给 `WARN` 且不阻断）；显式 `--strict` 才升级为阻断
 - `da-vinci lint-bindings --project <path> [--change <id>] [--strict] [--json]`
   - 校验实现到 Pencil 的映射是否可解析、source 形态是否合理、实现落点是否可定位
@@ -70,6 +71,12 @@ Da Vinci 期望它们遵循工作流状态。
 - `da-vinci verify-bindings|verify-implementation|verify-structure|verify-coverage --project <path> [--change <id>] [--strict] [--json]`
   - 校验代码落点、计划状态实现证据、以及绑定驱动的结构一致性
   - `verify-structure` 会明确报告是 markup-backed 还是 heuristic fallback，并给出置信度
+- `da-vinci task-execution --project <path> --change <id> --task-group <id> --status <DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED> --summary <text> [--changed-files <csv>] [--test-evidence <csv>] [--concerns <csv>] [--blockers <csv>] [--json]`
+  - 持久化结构化 implementer 执行结果包，作为 task 级执行证据
+- `da-vinci task-review --project <path> --change <id> --task-group <id> --stage <spec|quality> --status <PASS|WARN|BLOCK> --summary <text> [--issues <csv>] [--reviewer <name>] [--write-verification] [--json]`
+  - 持久化有序两阶段 task review 证据（`spec` 在前，`quality` 在后）
+- `da-vinci worktree-preflight --project <path> [--change <id>] [--json]`
+  - 运行 advisory worktree 隔离预检（目录 ignore 安全、工作区脏状态、baseline 检查启发）
 - `da-vinci diff-spec --project <path> [--change <id>] [--from <sidecars-dir>] [--json]`
   - 比较规范化 planning sidecars，报告新增/删除/修改的规划项
   - 在同一 surface 下提供 spec 差异以及 tasks/page-map/bindings 摘要差异
@@ -255,6 +262,10 @@ Da Vinci 期望它们遵循工作流状态。
 - 跑 `da-vinci scope-check --project <path> [--change <id>]`
 - 如果 `tasks.md` 已存在，跑 `da-vinci lint-tasks --project <path> [--change <id>]`
 - 如果 `pencil-design.md` 和 `pencil-bindings.md` 都存在，跑 `da-vinci lint-bindings --project <path> [--change <id>]`
+- 查看 `da-vinci next-step --project <path> [--change <id>] --json` 的 `executionProfile`
+- 若 profile 为 `bounded_parallel`，先跑 `da-vinci worktree-preflight --project <path> [--change <id>]`；隔离未就绪则降级串行
+- 用 `da-vinci task-execution ...` 持久化每个 task group 的 implementer 结果包，确保 concern/blocker 可追踪
+- 按顺序执行 task review：先 `da-vinci task-review ... --stage spec ...`，再 `da-vinci task-review ... --stage quality ...`
 - 把命令结果当成门禁，不要把 `BLOCK` 或非零退出码降级成软提示
 - 只要还有 `BLOCK` 或缺少必要 planning/design 工件，就不要进入大范围实现
 
@@ -262,6 +273,7 @@ Da Vinci 期望它们遵循工作流状态。
 
 - `BUILD SUCCESSFUL` 只代表可编译，不代表 workflow 完成
 - 只要 in-scope task groups 还没做完，就不能宣告 `design complete` 或 `workflow complete`
+- 终态 completion 表述前必须具备 fresh verification evidence
 - 任何终态声明前都要运行 `da-vinci audit --mode completion --change <change-id> <project-path>` 并通过
 
 ### `/dv:verify`
@@ -286,6 +298,8 @@ Da Vinci 期望它们遵循工作流状态。
 - 跑 `da-vinci verify-coverage --project <path> [--change <id>]`
 - 把命令结果当成门禁，不要把 `BLOCK` 或 `FAIL` 降级成软提示
 - 只要任何验证面仍然是 `BLOCK` 或 `FAIL`，就继续停留在验证阶段并记录 drift，而不是宣称成功
+- 终态表述前要求 `verify-coverage` 和 `workflow-status` 中的验证证据 freshness 为最新
+- 如果启用了 task-review 证据，存在未解决 `WARN/BLOCK` 评审阶段时不得关闭对应 task group
 - 如果要声称终态完成，先要求 `da-vinci audit --mode completion --change <change-id> <project-path>` 通过
 
 ## 基于状态的下一步规则

package/docs/zh-CN/execution-chain-migration.md

@@ -44,3 +44,26 @@ Audit 集成：
 - MVP 不做多框架扩展
 - scaffold 边界来自 `pencil-bindings.md` 映射
 - 接受前需跑 `verify-bindings`、`verify-implementation`、`verify-structure`
+
+## 5. 下一阶段规划升级：Discipline And Orchestration
+
+execution-chain 能力落地后，下一项规划中的升级是：
+
+- `openspec/changes/discipline-and-orchestration-upgrade/`
+
+该规划变更会补充：
+
+- 实施前交接纪律的强化
+- `tasks.md` 执行就绪质量检查强化
+- 与 workflow state 绑定的有边界编排提示
+- 结构化 task 执行与审查证据
+- 基于 fresh verification evidence 的 completion 表述约束
+- 可选 worktree preflight 隔离建议
+
+重要边界：
+
+- 该升级不会替代 artifact truth、checkpoint truth 或 completion-audit 权威
+
+参考：
+
+- `docs/discipline-and-orchestration-upgrade.md`

package/docs/zh-CN/prompt-entrypoints.md

@@ -67,13 +67,17 @@
 
 - 有 shell 能力时，先运行 `da-vinci workflow-status --project <path> [--change <id>] --json`
 - 再用 `da-vinci next-step --project <path> [--change <id>]` 作为第一续跑路由信号
+- 如可用，优先读取 `da-vinci next-step --project <path> [--change <id>] --json`，显式获取 discipline marker、execution-profile 与 verification freshness 信息
 - 如果运行时 spec 质量还不确定，进入 `build` 前先运行 `da-vinci lint-spec --project <path> [--change <id>]`
 - 如果页面或状态在规划工件中的传播关系不确定，进入 `build` 前先运行 `da-vinci scope-check --project <path> [--change <id>]`
+- 如果任务拆解质量不确定，进入 `build` 前先运行 `da-vinci lint-tasks --project <path> [--change <id>]`
 - 进入终态前先运行 `da-vinci verify-bindings --project <path> [--change <id>]` 与 `da-vinci verify-coverage --project <path> [--change <id>]`
 - 当规划切片有改动且需要恢复判断时，运行 `da-vinci diff-spec --project <path> [--change <id>]`
 - 先根据工件和 checkpoint 真相决定路由
 - Context Delta 只用于恢复和解释，不用于覆盖选路
 - 如果 Context Delta 与当前工件冲突，选路时忽略冲突内容并标记冲突
+- 如果 design approval discipline marker 缺失、格式错误或过期，路由应停留在 `design` 或 `tasks`，不能直接推进到 `build`
+- 如果提示了 bounded parallel 执行，先运行 `da-vinci worktree-preflight --project <path> [--change <id>]`，再决定是否输出并行 build continuation prompt
 
 ## 默认推荐流程
 
@@ -94,6 +98,7 @@
 
 - 如果设计已经完成，但 `tasks.md` 还不存在，下一步主推荐通常应该是 `tasks`，而不是 `build`
 - 只有任务和实现就绪度都已经明确时，才把 `build` 作为主推荐下一步
+- 在 fresh verification evidence 缺失时，不能输出终态 completion 表述；应明确要求 completion audit
 
 ## 平台语法
 

package/docs/zh-CN/skill-usage.md

@@ -85,6 +85,12 @@ $da-vinci use continue for <existing workflow state>
   - 当运行时 spec 质量还不够确定时使用
 - `da-vinci scope-check`
   - 当规划工件之间页面/状态传播关系还不清楚时使用
+- `da-vinci lint-tasks`
+  - 校验 task groups 是否包含 discipline markers、明确文件落点、执行意图与 verification 命令
+- `da-vinci lint-bindings`
+  - 当 `pencil-design.md` 与 `pencil-bindings.md` 同时存在时运行，确保实现落点证据可解析
+- `da-vinci worktree-preflight`
+  - 准备 bounded parallel 执行前先跑，用于判断是否建议启用本地 worktree 隔离
 
 如果你已经在项目根目录里，`--project` 通常可以省略，因为 CLI 默认会回退到当前目录。
 
@@ -95,8 +101,17 @@ da-vinci workflow-status
 da-vinci next-step
 da-vinci lint-spec
 da-vinci scope-check
+da-vinci lint-tasks
 ```
 
+实现阶段不要只靠聊天总结，建议同步写入机器可读证据：
+
+- `da-vinci task-execution --project <path> --change <id> --task-group <id> --status <DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED> --summary <text> ...`
+- `da-vinci task-review --project <path> --change <id> --task-group <id> --stage spec ...`
+- `da-vinci task-review --project <path> --change <id> --task-group <id> --stage quality ...`
+
+同一 task group 只有在 `spec` review 已是 `PASS` 时，`quality` review 才允许通过。
+
 ## 中途退出后，下次怎么恢复
 
 最稳妥的恢复顺序是：
@@ -107,6 +122,7 @@ da-vinci scope-check
 4. 如果规划传播关系不确定，跑 `da-vinci scope-check`
 5. 如果 planning 工件相对上次稳定状态有变化，跑 `da-vinci generate-sidecars` 和 `da-vinci diff-spec`
 6. 在终态前，跑 `da-vinci verify-bindings` 和 `da-vinci verify-coverage`
+7. 如果要做 completion 表述，确认 `verify-coverage` 的 freshness 仍然有效，并运行 `da-vinci audit --mode completion --change <id> <project-path>`
 
 恢复时应该遵循工件，而不是旧聊天上下文：
 

package/docs/zh-CN/workflow-overview.md

@@ -32,6 +32,12 @@ Da Vinci 围绕一个固定契约工作：
 - 项目内 `.pen` 是设计真相源
 - 实现必须能追溯到这两层
 
+真相与编排边界：
+
+- 选路和 completion 真相来自工件、checkpoint、execution signals 与 `audit`
+- execution profile、worktree preflight 等编排信息始终是 advisory 指导，不替代真相面
+- 编排提示不能覆盖来自工件、checkpoint 或 completion audit 的明确 `BLOCK`
+
 ## 主流程
 
 1. 选择正确的 mode。
@@ -62,6 +68,12 @@ Da Vinci 围绕一个固定契约工作：
   - 显式生成确定性的 planning sidecars，供 diff 和下游工具消费
 - `da-vinci verify-bindings|verify-implementation|verify-structure|verify-coverage --project <path> [--change <id>] [--strict] [--json]`
   - 校验从 bindings 到实现与结构覆盖的执行链证据
+- `da-vinci task-execution --project <path> --change <id> --task-group <id> --status <DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED> --summary <text> ...`
+  - 按 task group 持久化 implementer 结果包，便于恢复时读取未解决 blocker/concern
+- `da-vinci task-review --project <path> --change <id> --task-group <id> --stage <spec|quality> --status <PASS|WARN|BLOCK> --summary <text> ...`
+  - 持久化有序两阶段 review 证据（先 `spec` 再 `quality`），并可写回 `verification.md`
+- `da-vinci worktree-preflight --project <path> [--change <id>] [--json]`
+  - 在准备 bounded-parallel 执行前提供 advisory 隔离预检
 - `da-vinci diff-spec --project <path> [--change <id>] [--from <sidecars-dir>] [--json]`
   - 报告 spec/tasks/page-map/bindings sidecars 的规范化差异，支持安全续跑
 
@@ -187,7 +199,11 @@ anchor 通过后，再抽 shared primitives，然后再扩更多页面。
 mapping 通过后：
 
 - 生成 `tasks.md`
+- 保持 task group 可解析：包含 discipline markers、文件目标、执行意图、review 意图和 verification 命令
 - 基于 requirements 和 Pencil 数据实现
+- 在大范围实现前，从 `workflow-status` 或 `next-step --json` 查看 `executionProfile`
+- 如果建议 bounded parallel，先跑 `da-vinci worktree-preflight --project <path> [--change <id>]`；隔离未就绪时降级为串行
+- 通过 `task-execution` 与有序 `task-review` 记录每个 task group 的执行与审查证据
 - 验证需求漂移和设计漂移
 
 ### 8. 终态完成
@@ -197,6 +213,7 @@ mapping 通过后：
 - design checkpoint 不再阻塞
 - design-source checkpoint 至少 `PASS`
 - 如果用了 Pencil MCP，runtime gate 结果可接受
+- in-scope 的实现和覆盖结论具备 fresh verification evidence
 - `da-vinci audit --mode completion --change <change-id> <project-path>` 通过
 
 补充说明：

package/lib/audit-parsers.js

@@ -760,6 +760,149 @@ function inspectDesignSupervisorReview(pencilDesignText) {
   };
 }
 
+const DISCIPLINE_MARKER_NAMES = Object.freeze({
+  designApproval: "design_approval",
+  planSelfReview: "plan_self_review",
+  operatorReviewAck: "operator_review_ack"
+});
+
+const DISCIPLINE_MARKER_ALIASES = Object.freeze({
+  [DISCIPLINE_MARKER_NAMES.designApproval]: [
+    "design approval",
+    "design-approved",
+    "design approved",
+    "design_approval",
+    "design-approval"
+  ],
+  [DISCIPLINE_MARKER_NAMES.planSelfReview]: [
+    "plan self review",
+    "plan_self_review",
+    "plan-self-review",
+    "plan review",
+    "plan-review"
+  ],
+  [DISCIPLINE_MARKER_NAMES.operatorReviewAck]: [
+    "operator review ack",
+    "operator review acknowledgement",
+    "operator review acknowledgment",
+    "operator_ack",
+    "operator-review-ack",
+    "operator-review-acknowledgement",
+    "operator-review-acknowledgment"
+  ]
+});
+
+const DISCIPLINE_MARKER_KEYWORDS = Object.freeze(
+  Object.values(DISCIPLINE_MARKER_ALIASES)
+    .flat()
+    .map((token) => String(token).replace(/[_-]+/g, " ").toLowerCase())
+);
+
+function normalizeDisciplineMarkerName(value) {
+  const normalized = String(value || "")
+    .toLowerCase()
+    .replace(/[`*_~]/g, "")
+    .replace(/[_-]+/g, " ")
+    .replace(/\s+/g, " ")
+    .trim();
+  if (!normalized) {
+    return "";
+  }
+  for (const [canonicalName, aliases] of Object.entries(DISCIPLINE_MARKER_ALIASES)) {
+    if (aliases.some((alias) => normalized === String(alias).replace(/[_-]+/g, " ").toLowerCase())) {
+      return canonicalName;
+    }
+  }
+  return "";
+}
+
+function normalizeDisciplineMarkerStatus(value) {
+  return String(value || "")
+    .toUpperCase()
+    .replace(/[`*_~]/g, "")
+    .replace(/[()]/g, "")
+    .replace(/\s+/g, "_")
+    .replace(/[^A-Z0-9_]+/g, "_")
+    .replace(/^_+|_+$/g, "");
+}
+
+function parseDisciplineMarkers(markdownText) {
+  const markers = {};
+  const ordered = [];
+  const malformed = [];
+  const lines = String(markdownText || "").replace(/\r\n?/g, "\n").split("\n");
+  const markerPattern =
+    /^\s*-\s*`?([A-Za-z][A-Za-z0-9 _-]{1,80})`?\s*:\s*`?([A-Za-z0-9 _-]{1,80})`?(?:\s*@\s*`?([^`]+?)`?)?\s*$/;
+
+  for (let index = 0; index < lines.length; index += 1) {
+    const rawLine = lines[index];
+    const match = rawLine.match(markerPattern);
+    if (!match) {
+      const normalizedLine = String(rawLine || "")
+        .toLowerCase()
+        .replace(/[_-]+/g, " ")
+        .replace(/\s+/g, " ")
+        .trim();
+      if (!normalizedLine.startsWith("-")) {
+        continue;
+      }
+      if (DISCIPLINE_MARKER_KEYWORDS.some((keyword) => normalizedLine.includes(keyword))) {
+        malformed.push({
+          line: index + 1,
+          reason: "Malformed discipline marker syntax.",
+          raw: rawLine
+        });
+      }
+      continue;
+    }
+
+    const markerName = normalizeDisciplineMarkerName(match[1]);
+    if (!markerName) {
+      continue;
+    }
+
+    const status = normalizeDisciplineMarkerStatus(match[2]);
+    if (!status) {
+      malformed.push({
+        line: index + 1,
+        reason: "Missing marker status token.",
+        raw: rawLine
+      });
+      continue;
+    }
+
+    const rawTime = String(match[3] || "").trim();
+    let time = "";
+    if (rawTime) {
+      time = normalizeTimeToken(rawTime);
+      if (!time) {
+        malformed.push({
+          line: index + 1,
+          reason: "Invalid marker timestamp.",
+          raw: rawLine
+        });
+      }
+    }
+
+    const record = {
+      name: markerName,
+      status,
+      time,
+      rawTime,
+      line: index + 1,
+      raw: rawLine
+    };
+    ordered.push(record);
+    markers[markerName] = record;
+  }
+
+  return {
+    markers,
+    ordered,
+    malformed
+  };
+}
+
 module.exports = {
   hasMarkdownHeading,
   getMarkdownSection,
@@ -775,5 +918,9 @@ module.exports = {
   getConfiguredDesignSupervisorReviewers,
   hasConfiguredDesignSupervisorReview,
   isDesignSupervisorReviewRequired,
-  inspectDesignSupervisorReview
+  inspectDesignSupervisorReview,
+  DISCIPLINE_MARKER_NAMES,
+  normalizeDisciplineMarkerName,
+  normalizeDisciplineMarkerStatus,
+  parseDisciplineMarkers
 };