conductor-dev

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Conductor Dev

Conductor owns orchestration. It delegates ArkUI implementation to

hmos-arkui-develop-skill

, architecture to

hmos-arkui-mvvm-pattern

, grounded ArkTS/API evidence to

hmos-arkts-knowledge-retriever

, and build/device work to

ohos-app-dev

Conductor 负责编排工作。它将 ArkUI 实现委托给

hmos-arkui-develop-skill

，将架构设计委托给

hmos-arkui-mvvm-pattern

，将基于实际依据的 ArkTS/API 证据收集委托给

hmos-arkts-knowledge-retriever

，并将构建和设备工作委托给

ohos-app-dev

。

Read Efficiently

高效读取

Read this file once per session. Load only the phase-specific files listed in

references/context-policy.md

. Read

references/execution-policy.md

when selecting a profile or verification set. Do not reread all workflow files at phase boundaries. On a continuing project, read

conductor/bootstrap.md

before the full state or history. Do not run

--help

for a known script unless its invocation fails. Use the fixed script signatures documented in this skill during normal execution.

每个会话仅读取本文件一次。只加载

references/context-policy.md

中列出的阶段专属文件。选择 profile 或验证集时，读取

references/execution-policy.md

。不要在阶段边界重新读取所有工作流文件。对于正在继续的项目，在读取完整状态或历史记录之前，先读取

conductor/bootstrap.md

。除非脚本调用失败，否则不要为已知脚本运行

--help

。正常执行期间，使用此 skill 中记录的固定脚本签名。

User-visible Output

用户可见输出

Keep Conductor orchestration details internal. Do not narrate or paste full PowerShell chains for directory creation, state initialization, question gates, workflow planning, skill recording, context caching, or phase synchronization. Run these steps quietly and report one concise status line. Always surface user decisions, actionable failures, blockers, and build/lint/install/launch results. Do not suppress errors or verification evidence. For the approved execution transition, use

scripts/confirm_execution.py

with a brief JSON file instead of a long

state_update.py

command with many

--set

flags.

Conductor 的编排细节应保持内部状态。不要描述或粘贴用于目录创建、状态初始化、问题门、工作流规划、skill 记录、上下文缓存或阶段同步的完整 PowerShell 命令链。静默执行这些步骤，并仅报告一行简明状态。务必向用户呈现其决策、可操作的失败、阻塞项以及构建、lint、安装和启动结果。不要隐藏错误或验证证据。对于已批准的执行转换，使用

scripts/confirm_execution.py

配合简短的 JSON 文件，而不是使用带有许多

--set

标志的长

state_update.py

命令。

Required State

必需状态

Before implementation, record these fields in

SESSION_STATE.json

and the Track plan:

text

risk_level: low | medium | high
execution_profile: lean | strict
risk_signals: persistence | device | network | security | architecture
product_status: unconfirmed | confirmed | assumptions_accepted
product_brief: problem, primary_user, desired_outcome, core_flow, mvp,
  non_goals, target_device, data_behavior, visual_direction, acceptance_criteria
product_confirmation: explicit user decision and assumptions
work_plan_status: pending | approved | changes_requested
track_kind: ui | logic | infrastructure
ui_impact: none | visual | interaction | runtime
required_skills, context_fingerprint, loaded_context, api_evidence_cache
loaded_skills, api_evidence_sources
ui_checkpoint, ai_workflow
current_phase, phase_status, track_status
last_completed_phase, next_phase
phase_requires_boundary_pass, verification_boundary
recovery, synchronization_record, verification_gate
execution_authorization
acceptance_results, runtime_evidence, scope_change

SESSION_STATE.json

is the operational source of truth.

TASKS.md

is only the backlog and acceptance list. The Track plan contains scope and decisions.

conductor/learning.md

contains only consequential lessons and reusable tool limitations. Use

sync_phase.py

to generate the phase summary.

lean

is valid only with

risk_level: low

; medium/high-risk Tracks must use

strict

unless the user explicitly records an approved exception.

Choose

workflow_profile=quick

for a low-risk local change,

standard

for a normal UI Track, and

strict

for device, persistence, network, signing, or submission work. The profile controls ceremony and output budgets; it never weakens product confirmation or claims unrun verification as success.

When

workflow_plan.py

returns

required_architecture_skills

, load every listed skill before implementation. A Standard UI Track with multiple stateful interactions therefore receives an MVVM review; a one-state Quick Track does not.

Use

initialize_state.py

to write risk/profile/kind/UI impact; do not hand-write an invalid combination. A required recovery must be cleared by

record_failure.py --state-file

before the phase can continue.

在实现之前，在

SESSION_STATE.json

和 Track 计划中记录以下字段：

text

risk_level: low | medium | high
execution_profile: lean | strict
risk_signals: persistence | device | network | security | architecture
product_status: unconfirmed | confirmed | assumptions_accepted
product_brief: problem, primary_user, desired_outcome, core_flow, mvp,
  non_goals, target_device, data_behavior, visual_direction, acceptance_criteria
product_confirmation: explicit user decision and assumptions
work_plan_status: pending | approved | changes_requested
track_kind: ui | logic | infrastructure
ui_impact: none | visual | interaction | runtime
required_skills, context_fingerprint, loaded_context, api_evidence_cache
loaded_skills, api_evidence_sources
ui_checkpoint, ai_workflow
current_phase, phase_status, track_status
last_completed_phase, next_phase
phase_requires_boundary_pass, verification_boundary
recovery, synchronization_record, verification_gate
execution_authorization
acceptance_results, runtime_evidence, scope_change

SESSION_STATE.json

是运行时的唯一事实来源。

TASKS.md

仅用于待办事项和验收列表。Track 计划包含范围和决策。

conductor/learning.md

仅包含影响重大的经验和可复用的工具限制。使用

sync_phase.py

生成阶段摘要。

仅当

risk_level: low

时，

lean

才有效；medium/high-risk Track 必须使用

strict

，除非用户明确记录并批准例外。

低风险本地变更应选择

workflow_profile=quick

，普通 UI Track 应选择

standard

，设备、持久化、网络、签名或提交工作应选择

strict

。profile 控制流程步骤和输出预算；它绝不会削弱产品确认要求，也不会将未执行的验证声称为成功。

当

workflow_plan.py

required_architecture_skills

时，必须加载列出的每个 skill 后再开始实现。因此，包含多个有状态交互的 Standard UI Track 会获得 MVVM 审查；只有一个状态的 Quick Track 则不会。

使用

initialize_state.py

写入风险、profile、kind 和 UI impact；不要手动写入无效组合。如阶段存在 required recovery，必须先通过

record_failure.py --state-file

清除该恢复项，阶段才能继续。

Entry and Product Gate

入口与产品门

Load the current state and active Track using the context policy.
A direction is clear only when the user has supplied a problem or opportunity, primary user, and intended outcome. An app name, category, or feature fragment alone is vague.
If the direction is vague, offer bounded options or focused questions and wait for the user's explicit choice or custom definition. For discrete choices, call the interactive
```
question
```
tool so the client renders an option bar. Only if that tool is unavailable or dismissed, use a Markdown table with stable option IDs, short trade-offs, and an explicit request for the user's selection. Never invent the audience, problem, MVP, visual direction, non-goals, or platform capability.
Ask until the brief covers the problem, primary user, desired outcome, smallest successful flow, MVP, non-goals, target device, data behavior, visual direction, and acceptance criteria. Do not compress these into one guessed answer; group missing fields into a small number of user questions.
Set
```
product_status: confirmed
```
only after the user confirms the brief, or
```
assumptions_accepted
```
only when the user explicitly asks to proceed with stated assumptions. Do not create an implementation Track before that state.
If no Figma input exists, record
```
designInput: unavailable
```
and continue only after the product direction is confirmed.

Interactive question requirement: when the

question

tool is available, you MUST call it for every bounded user choice. Do not render a Markdown

# Questions

section, numbered text choices, or a prose question instead. Use Markdown choices only after the question tool is unavailable or dismissed.

After loading each selected Skill, record it with

record_skill_usage.py

. Before execution,

loaded_skills

must contain every

required_skills

entry. If the Track requires

hmos-arkts-knowledge-retriever

, record at least one cited API or language evidence source in

api_evidence_sources

. For ArkTS retriever Tracks,

verification_gate --execution

also requires a recorded

evidence_cache.py

result.

依据 context policy 加载当前状态和活跃 Track。
只有当用户提供了问题或机会、主要用户和预期结果时，方向才算明确。仅有应用名称、类别或某个功能片段仍然过于模糊。
如果方向模糊，应提供有限选项或聚焦问题，并等待用户明确选择或提供自定义定义。对于离散选项，调用交互式
```
question
```
工具，让客户端呈现选项栏。仅当该工具不可用或被忽略时，才使用带有稳定选项 ID 和简短利弊说明的 Markdown 表格，并明确请求用户选择。绝不臆造受众、问题、MVP、视觉方向、非目标或平台能力。
持续询问，直到简报涵盖问题、主要用户、预期结果、最小成功流程、MVP、非目标、目标设备、数据行为、视觉方向和验收标准。不要将这些内容压缩成一个猜测答案；应将缺失字段归并为少量用户问题。
只有在用户确认简报后，才能设置
```
product_status: confirmed
```
；只有当用户明确要求按所述假设继续时，才能设置
```
assumptions_accepted
```
。在达到该状态之前，不要创建实现 Track。
如果不存在 Figma 输入，记录
```
designInput: unavailable
```
，并且仅在产品方向已确认后继续。

**交互式问题要求：**当

question

工具可用时，对于每个有限的用户选择，都必须调用该工具。不要渲染 Markdown

# Questions

章节、编号文本选项或直接以文字提问。只有在

question

工具不可用或被忽略后，才使用 Markdown 选项。

加载每个选定的 skill 后，使用

record_skill_usage.py

记录。执行之前，

loaded_skills

必须包含

required_skills

中的每一项。如果 Track 要求使用

hmos-arkts-knowledge-retriever

，则

api_evidence_sources

中至少要记录一条带引用的 API 或语言证据来源。对于 ArkTS retriever Track，

verification_gate --execution

还要求已记录

evidence_cache.py

的结果。

Cycle

周期

initialization -> design_analysis -> strategy -> work_plan_approval -> execution -> ui_approval (UI only) -> self_review_verification -> synchronization -> handover

Read

assets/conductor-template/workflows/cycle.md

for the short phase checklist. Read

references/execution-policy.md

for risk, profile, UI impact, verification, command-output budgets, and approval gates.

For low-risk

lean

work, recommendations may be concise, but Work Plan Approval remains a separate explicit confirmation after the product brief. Keep the recommendation and Work Plan decisions separate for strict or medium/high-risk work. Do not edit application source before Work Plan Approval.

initialization -> design_analysis -> strategy -> work_plan_approval -> execution -> ui_approval (UI only) -> self_review_verification -> synchronization -> handover

读取

assets/conductor-template/workflows/cycle.md

以获取简明阶段检查清单。读取

references/execution-policy.md

以了解风险、profile、UI impact、验证、命令输出预算和审批门。

对于低风险

lean

工作，建议可以保持简洁，但 Work Plan Approval 仍是产品简报之后单独且明确的确认。对于 strict 或 medium/high-risk 工作，应将建议与 Work Plan 决策分开。未获得 Work Plan Approval 之前，不要编辑应用源码。

Verification

验证

Run focused compile/checks during implementation.
At an application-changing phase boundary, ensure one complete build/sign/device pass exists.
Immediately after install/launch and the initial UI screenshot, use the interactive
```
question
```
tool to ask whether automated device interaction tests are approved. Record consent before lint or any interaction. Run clicks/input only after
```
record_test_consent.py --decision approved
```
; a declined decision blocks runtime completion rather than silently skipping evidence.
Record runtime/source match with
```
record_runtime_evidence.py
```
; a mismatch blocks interaction tests and handover.
Reuse a successful unchanged UI approval checkpoint; otherwise run the boundary pass.
Repeat only after source, packaging, signing, runtime, or device-impacting changes, or after failure.
Use
```
lint_cache.py
```
before lint. Its unchanged zero-file result is reusable until the tool version, configuration fingerprint, or target fingerprint changes.
At execution start, run
```
context_cache.py
```
, reload/record context when it returns
```
RELOAD_CONTEXT
```
, then run
```
verification_gate.py --execution
```
.
Only after
```
GATE_PASS
```
, run
```
authorize_execution.py
```
with the current source revision. Do not edit application source before
```
EXECUTION_AUTHORIZED
```
.
Run
```
verification_gate.py --phase-boundary
```
before boundary validation and
```
verification_gate.py --post-verification
```
after the actual lint/build/device results are recorded. Run
```
verification_gate.py --handover
```
before handover. The gate is a compact preflight decision; it does not replace build, lint, or device commands.
Record the actual boundary result with
```
record_boundary.py
```
; do not hand-edit
```
verification_boundary.status
```
to
```
passed
```
.
The phase-boundary gate records
```
verification_boundary.status: gate_passed
```
; only actual build/sign/device evidence may change it to
```
passed
```
.
A verification phase must actually call
```
context_cache.py
```
,
```
evidence_cache.py
```
when API evidence is relevant, and
```
lint_cache.py
```
before lint. A documented cache rule without the command result is not verification evidence.
Use
```
context_cache.py
```
before rereading phase context and
```
evidence_cache.py
```
before repeating an API search. Reuse only when phase, files, SDK, and query fingerprints are unchanged.
A missing device or required signing configuration is a blocker or an explicit
```
signing: not_configured
```
result, never a false success.
Do not scan a repository with
```
Glob "**/*"
```
by default. Scope discovery to the target module, changed file types, and root configuration files.
Do not dump full device logs into the conversation. Filter for the first actionable error and retain complete output in an artifact log.
Always use
```
scripts/devecocli_docs_bridge.py
```
for both
```
devecocli docs search
```
and
```
devecocli docs read
```
; never call raw
```
devecocli docs read
```
in a normal workflow. Treat bridge output with
```
context_status=translation_required
```
as an internal queue, never as final context. Translate each queued snippet locally, preserve its
```
document_id
```
, and use only translated English
```
ready_context
```
for later reasoning.

Use

devecocli

through

ohos-app-dev

for build, lint, deployment, and device/UI operations. Require a zero

devecocli

build exit code and successful build output. Do not invoke Hvigor directly unless the user requests lower-level diagnostics.

在实现期间运行有针对性的编译和检查。
在会改变应用状态的阶段边界，确保至少存在一次完整的构建、签名和设备验证流程。
安装、启动并获取初始 UI 截图后，立即使用交互式
```
question
```
工具询问是否批准自动化设备交互测试。在 lint 或任何交互之前记录同意。只有在
```
record_test_consent.py --decision approved
```
之后才能执行点击和输入；拒绝决定会阻止运行时完成，而不是静默跳过证据。
使用
```
record_runtime_evidence.py
```
记录运行时与源码的匹配情况；不匹配会阻止交互测试和 handover。
如果 UI 审批检查点此前成功且相关状态未发生变化，则复用该检查点；否则执行边界流程。
仅在源码、打包、签名、运行时或设备相关影响发生变化后，或在失败后，才重复验证。
在 lint 前使用
```
lint_cache.py
```
。只要工具版本、配置指纹和目标指纹未发生变化，其未变更文件的零结果就可复用。
执行开始时，运行
```
context_cache.py
```
；当它返回
```
RELOAD_CONTEXT
```
时，重新加载并记录上下文，然后运行
```
verification_gate.py --execution
```
。
只有在
```
GATE_PASS
```
之后，才能使用当前源码修订运行
```
authorize_execution.py
```
。在出现
```
EXECUTION_AUTHORIZED
```
之前，不要编辑应用源码。
在边界验证之前运行
```
verification_gate.py --phase-boundary
```
，在实际 lint、构建和设备结果记录之后运行
```
verification_gate.py --post-verification
```
，在 handover 之前运行
```
verification_gate.py --handover
```
。
该门是紧凑的预检决策，不能替代构建、lint 或设备命令。
使用
```
record_boundary.py
```
记录实际边界结果；不要手动将
```
verification_boundary.status
```
编辑为
```
passed
```
。
phase-boundary 门会记录
```
verification_boundary.status: gate_passed
```
；只有实际的构建、签名和设备证据才能将其改为
```
passed
```
。
验证阶段必须实际调用
```
context_cache.py
```
，在 API 证据相关时调用
```
evidence_cache.py
```
，并在 lint 前调用
```
lint_cache.py
```
。仅记录缓存规则而没有命令结果，不属于验证证据。
重新读取阶段上下文前使用
```
context_cache.py
```
，重复 API 搜索前使用
```
evidence_cache.py
```
。仅当阶段、文件、SDK 和查询指纹均未发生变化时才复用结果。
缺少设备或必需的签名配置时，应将其视为阻塞项或明确记录
```
signing: not_configured
```
结果，绝不能报告虚假成功。
默认不要使用
```
Glob "**/*"
```
扫描整个仓库。应将发现范围限定为目标模块、变更文件类型和根配置文件。
不要将完整的设备日志转储到对话中。筛选首个可操作的错误，并将完整输出保留在 artifact 日志中。
对
```
devecocli docs search
```
和
```
devecocli docs read
```
始终使用
```
scripts/devecocli_docs_bridge.py
```
；正常工作流中绝不直接调用原始的
```
devecocli docs read
```
。将带有
```
context_status=translation_required
```
的桥接输出视为内部队列，而不是最终上下文。在本地翻译队列中的每个片段，保留其
```
document_id
```
，并且后续推理仅使用已翻译为英文的
```
ready_context
```
。

通过

ohos-app-dev

使用

devecocli

完成构建、lint、部署和设备/UI 操作。要求

devecocli

构建退出码为 0，且构建输出成功。除非用户要求进行底层诊断，否则不要直接调用 Hvigor。

Fixed Script Invocations

固定脚本调用方式

Use these known signatures without running

-h

--help

powershell

python record_acceptance.py --path <add|complete|filter|delete|persistence> --result <passed|blocked|not_attempted|out_of_scope> SESSION_STATE.json
python lint_cache.py --tool-version <version> --config-fingerprint <config> --target-fingerprint <target> [--record passed|failed|zero_files] SESSION_STATE.json
python context_cache.py SESSION_STATE.json --phase <phase> --files <file>... [--record]
python verification_gate.py SESSION_STATE.json --phase-boundary --context-phase <phase> --context-files <file>...
python record_boundary.py --status <passed|blocked> --source-revision <revision> --packaging-revision <revision> --signing <not_configured|skipped|passed|failed> --reason <reason> SESSION_STATE.json
python evidence_cache.py SESSION_STATE.json --topic <topic> --sdk <sdk> --query-fingerprint <query> --scope <components|state|signatures> --record --document-id <id> --section <section> --source-kind <kind> --summary <summary>
python verification_gate.py SESSION_STATE.json --execution --context-phase <phase> --context-files <file>... --evidence-topic <topic> --evidence-sdk <sdk> --evidence-query-fingerprint <query> --evidence-scope <components|state|signatures>...
python verification_gate.py SESSION_STATE.json --post-verification --lint-tool-version <version> --lint-config-fingerprint <config> --lint-target-fingerprint <target>
python state_update.py --required-skill <skill> --assumption "<assumption>" --next-action "<next action>" SESSION_STATE.json
python sync_phase.py SESSION_STATE.json --task-id <task-id> [--tasks-file TASKS.md]
python validate_state.py SESSION_STATE.json
python bootstrap_summary.py SESSION_STATE.json
python clean_ai_workflow.py AI_WORKFLOW.md
python verification_gate.py SESSION_STATE.json --handover

The finalization order is fixed: record acceptance and lint results, record context, pass the phase-boundary gate, record the actual boundary, pass the post-verification gate, set

next_action

, synchronize, validate, clean the AI workflow, enter handover, pass the handover gate, then complete handover.

使用以下已知签名时，不要运行

-h

或

--help

：

powershell

python record_acceptance.py --path <add|complete|filter|delete|persistence> --result <passed|blocked|not_attempted|out_of_scope> SESSION_STATE.json
python lint_cache.py --tool-version <version> --config-fingerprint <config> --target-fingerprint <target> [--record passed|failed|zero_files] SESSION_STATE.json
python context_cache.py SESSION_STATE.json --phase <phase> --files <file>... [--record]
python verification_gate.py SESSION_STATE.json --phase-boundary --context-phase <phase> --context-files <file>...
python record_boundary.py --status <passed|blocked> --source-revision <revision> --packaging-revision <revision> --signing <not_configured|skipped|passed|failed> --reason <reason> SESSION_STATE.json
python evidence_cache.py SESSION_STATE.json --topic <topic> --sdk <sdk> --query-fingerprint <query> --scope <components|state|signatures> --record --document-id <id> --section <section> --source-kind <kind> --summary <summary>
python verification_gate.py SESSION_STATE.json --execution --context-phase <phase> --context-files <file>... --evidence-topic <topic> --evidence-sdk <sdk> --evidence-query-fingerprint <query> --evidence-scope <components|state|signatures>...
python verification_gate.py SESSION_STATE.json --post-verification --lint-tool-version <version> --lint-config-fingerprint <config> --lint-target-fingerprint <target>
python state_update.py --required-skill <skill> --assumption "<assumption>" --next-action "<next action>" SESSION_STATE.json
python sync_phase.py SESSION_STATE.json --task-id <task-id> [--tasks-file TASKS.md]
python validate_state.py SESSION_STATE.json
python bootstrap_summary.py SESSION_STATE.json
python clean_ai_workflow.py AI_WORKFLOW.md
python verification_gate.py SESSION_STATE.json --handover

最终处理顺序固定如下：记录验收和 lint 结果、记录上下文、通过 phase-boundary 门、记录实际边界、通过 post-verification 门、设置

next_action

、同步、验证、清理 AI 工作流、进入 handover、通过 handover 门，最后完成 handover。

Learning and Status

学习与状态

Record only failures that change an implementation decision, expose a reusable lesson, affect reproducibility, require a fix/retry, or create a blocker. Keep repeatable limitations under

## Known Tool Limitations

with command, symptom, workaround, and scope. Show only the new lesson, not the entire log. Keep

learning.md

as an index and current summary; put reusable limitations in

learning/limitations.md

and consequential incidents in

learning/incidents.md

Use command levels from the execution policy. Send status at implementation, compile, device validation, phase transition, synchronization, and around L2/L3 commands. Batch L0/L1 operations into the nearest milestone.

If a build or verification command times out, record

BUILD_WRAPPER_TIMEOUT

wrapper-exit-unconfirmed

and stop that verification step. Before any retry, run

record_failure.py

for the first consequential cause and announce the separately authorized recovery command. Do not infer success from a later

run

command's internal build.

只记录会改变实现决策、暴露可复用经验、影响可复现性、需要修复或重试，或造成阻塞的失败。将可重复出现的限制放在

## Known Tool Limitations

下，并记录命令、症状、变通方案和适用范围。只展示新经验，不要展示完整日志。保持

learning.md

作为索引和当前摘要；将可复用的限制放在

learning/limitations.md

中，将影响重大的事故放在

learning/incidents.md

中。

使用执行策略中定义的命令级别。在实现、编译、设备验证、阶段转换、同步以及 L2/L3 命令前后报告状态。将 L0/L1 操作批量合并到最近的里程碑。

如果构建或验证命令超时，记录

BUILD_WRAPPER_TIMEOUT

wrapper-exit-unconfirmed

，并停止该验证步骤。在任何重试之前，针对首个重要原因运行

record_failure.py

，并宣布单独获得授权的恢复命令。不要根据后续

run

命令内部执行的构建来推断成功。

State Safety

状态安全

When a phase completes, keep

current_phase

on that phase, set

last_completed_phase

to it, and set

next_phase

only as an intention. Start the next phase with a separate update that sets

current_phase = next_phase

and

phase_status = in_progress

Run the installed validator at synchronization and before handover:

powershell

python "<resolved-conductor-dev-root>\scripts\validate_state.py" SESSION_STATE.json

An invalid state blocks the transition. A Track is

handed_over

only after verification, synchronization, and the handover report.

阶段完成时，让

current_phase

保持在该阶段，将

last_completed_phase

设置为该阶段，并仅将

next_phase

作为下一步意图设置。通过一次独立更新启动下一阶段，将

current_phase = next_phase

，并设置

phase_status = in_progress

。

在同步时和 handover 前运行已安装的验证器：

powershell

python "<resolved-conductor-dev-root>\scripts\validate_state.py" SESSION_STATE.json

无效状态会阻止阶段转换。只有在完成验证、同步和 handover 报告之后，Track 才能标记为

handed_over

。

Handover

Use the phase summary and state to produce a concise handover containing status, boundary result, UI decision, blockers, deferred work, and artifact paths. Do not repeat the full command transcript or learning history. Ask what to do next only after the handover state is recorded.

使用阶段摘要和状态生成简明的 handover，其中应包含状态、边界结果、UI 决策、阻塞项、延期工作和产物路径。不要重复完整的命令记录或学习历史。只有在 handover 状态记录完成后，才询问用户接下来要做什么。

Resources

资源

assets/conductor-template/workflows/cycle.md

: phase checklist.

```
assets/conductor-template/workflow.md
```
: project-facing workflow.

assets/conductor-template/setup_state.json

: initial state.

```
references/context-policy.md
```
: context and specialist loading.
```
references/execution-policy.md
```
: risk, profiles, verification, and output budgets.
```
references/agency-workflow.md
```
: state and synchronization model.
```
scripts/validate_state.py
```
: state transition validation.
```
scripts/lint_cache.py
```
: reusable lint result cache.
```
scripts/sync_phase.py
```
: phase summary and optional task synchronization.
```
scripts/context_cache.py
```
: phase context reuse check.
```
scripts/workflow_plan.py
```
: selects the smallest phase set for quick, standard, or strict work.
```
scripts/record_question_gate.py
```
: records decisions made through the interactive question bar.
```
scripts/quick_complete.py
```
: closes a Quick Track after focused verification without UI approval, device pass, synchronization, or handover.
```
scripts/change_impact.py
```
: classifies changed files and affected modules.
```
scripts/incremental_verify.py
```
: runs module-scoped incremental build and deploys with
```
devecocli run --skip-build
```
.
```
scripts/devecocli_docs_bridge.py
```
: calls
```
devecocli docs search --format json --limit 3
```
or
```
devecocli docs read <document-id>
```
, keeps short relevant snippets, and marks non-English text for local model translation instead of passing raw full documents into context.
```
scripts/evidence_cache.py
```
: API evidence reuse check.
```
scripts/ai_workflow.py
```
: incremental AI workflow recording.
```
scripts/prepare_artifacts.py
```
: creates screenshot and log directories.
```
scripts/record_skill_usage.py
```
: records loaded Skills and evidence sources.
```
scripts/record_failure.py
```
: records a consequential incident before retry.
```
scripts/clean_ai_workflow.py
```
: removes unfinished AI workflow placeholders.
```
scripts/verification_gate.py
```
: compact phase-boundary and handover preflight.
```
scripts/initialize_state.py
```
: writes only valid risk/profile initialization.
```
scripts/compact_command.py
```
: captures long command output and returns one-line results.
```
scripts/state_update.py
```
: validates and atomically updates session state.
```
scripts/bootstrap_summary.py
```
: creates a short session bootstrap summary.
```
scripts/authorize_execution.py
```
: creates the execution authorization token.
```
scripts/record_boundary.py
```
: records actual build/sign/device evidence.
```
scripts/record_test_consent.py
```
: records user consent for device automation.
```
scripts/record_acceptance.py
```
: records CRUD and in-scope or out-of-scope persistence path results.
```
scripts/record_runtime_evidence.py
```
: records foreground/source match.
```
scripts/record_scope_change.py
```
: records approval for out-of-plan files.

assets/conductor-template/workflows/cycle.md

：阶段检查清单。

```
assets/conductor-template/workflow.md
```
：面向项目的工作流。

assets/conductor-template/setup_state.json

：初始状态。

```
references/context-policy.md
```
：上下文和专项 skill 加载策略。
```
references/execution-policy.md
```
：风险、profile、验证和输出预算。
```
references/agency-workflow.md
```
：状态和同步模型。
```
scripts/validate_state.py
```
：状态转换验证。
```
scripts/lint_cache.py
```
：可复用的 lint 结果缓存。
```
scripts/sync_phase.py
```
：阶段摘要和可选的任务同步。
```
scripts/context_cache.py
```
：阶段上下文复用检查。
```
scripts/workflow_plan.py
```
：为 quick、standard 或 strict 工作选择最小阶段集合。
```
scripts/record_question_gate.py
```
：记录通过交互式问题栏所作的决策。
```
scripts/quick_complete.py
```
：在完成针对性验证后关闭 Quick Track，无需 UI 审批、设备流程、同步或 handover。
```
scripts/change_impact.py
```
：对变更文件和受影响模块进行分类。

scripts/incremental_verify.py

：使用

devecocli run --skip-build

执行模块范围的增量构建和部署。

```
scripts/devecocli_docs_bridge.py
```
：调用
```
devecocli docs search --format json --limit 3
```
或
```
devecocli docs read <document-id>
```
，保留简短的相关片段，并将非英文文本标记为需要本地模型翻译，而不是把原始完整文档传入上下文。
```
scripts/evidence_cache.py
```
：API 证据复用检查。
```
scripts/ai_workflow.py
```
：增量式 AI 工作流记录。
```
scripts/prepare_artifacts.py
```
：创建截图和日志目录。
```
scripts/record_skill_usage.py
```
：记录已加载的 skill 和证据来源。
```
scripts/record_failure.py
```
：在重试前记录影响重大的事故。
```
scripts/clean_ai_workflow.py
```
：移除未完成的 AI 工作流占位内容。
```
scripts/verification_gate.py
```
：紧凑的 phase-boundary 和 handover 预检。
```
scripts/initialize_state.py
```
：只写入有效的风险和 profile 初始化信息。
```
scripts/compact_command.py
```
：捕获冗长的命令输出并返回单行结果。
```
scripts/state_update.py
```
：验证并原子更新会话状态。
```
scripts/bootstrap_summary.py
```
：创建简短的会话启动摘要。
```
scripts/authorize_execution.py
```
：创建执行授权令牌。
```
scripts/record_boundary.py
```
：记录实际的构建、签名和设备证据。
```
scripts/record_test_consent.py
```
：记录用户对设备自动化的同意。
```
scripts/record_acceptance.py
```
：记录 CRUD 以及范围内或范围外的持久化路径结果。
```
scripts/record_runtime_evidence.py
```
：记录前台与源码的匹配情况。
```
scripts/record_scope_change.py
```
：记录对计划外文件的批准。