Workflow Execution

The evaluation loop

Context does not run a fixed script. Every time the Agent asks what to do, the CLI observes the Context knowledge workspace, turns what it sees into Facts, and asks the workflow Provider for the current Route.

flowchart LR
  facts["Knowledge workspace facts"] --> evaluate["Agent Graph evaluates"]
  evaluate --> route["Current Route"]
  route --> act["Agent runs one action"]
  act -->|"knowledge workspace changes"| facts

A Route carries the selected step, a reason code, the resources the Agent must read before acting, any unresolved Gate and the exact commands to run. Only workflow.current chooses the next lifecycle step; a command that finishes returns control to a fresh evaluation instead of choosing the next step itself.

Two graphs

The Provider in packages/context-cli/context-workflow/ contains two static graphs:

Graph	Covers
workspace	The top-level lifecycle: repair, source boundary, capture, Indexer lifecycle, review, close, package output, translation, version recording, build and completion, plus rollback
indexer	Requirements, planning, the work-start report, stage writing, gap handling, source updates and approved-page revisions

The top-level order is fixed by the graph's edges: source boundary → capture → run-indexer-lifecycle → review → close → package output → version → build. Nodes describe stable task categories such as "a capture target remains"; source names, dates and modules are runtime facts and never become graph nodes. That is why one graph serves every knowledge workspace.

Gates

Some nodes are Gates: they wait for a decision. Examples are choosing the source boundary, authorizing document capture, approving the work-start report, reviewing the current batch and choosing the package output.

Each Gate declares whether it is delegatable. In ordinary mode a person decides. When you explicitly authorize fully managed operation for the current conversation, the Agent may resolve delegatable Gates — for example applying a review it has checked — but never those marked non-delegatable, such as the work-start report when a scope decision is required. Managed authority is scoped to the conversation and cannot authorize new source boundaries, failed validation or failed verification.

Revisions and stale commands

Every write command is bound to the revision of the observation that produced it. If the knowledge workspace changed since then — another action ran, a file was edited — the command is rejected instead of being applied to newer state. Required resources are acknowledged by digest; dynamic views are tied to the revision that selected them. A receipt proves the Agent received a resource; it does not claim the task is done.

Resuming

With the same Provider, the same observed Facts and the same recorded outcomes, Agent Graph selects the same Route. Work already satisfied by knowledge workspace facts is skipped or advances. So an interruption, a retry or a new conversation converges from observable state, not from conversation memory. The CLI keeps each filesystem effect atomic, guarded or a proven no-op; Agent Graph keeps evaluation repeatable.

How the workflow improves

Route selection is tested without a model: context-workflow/tests/ holds fact-to-Route scenarios. With debug mode on, Context records CLI invocations and graph evaluations; a replay shows which Route was chosen at each fact change, where a loop advanced and where a Gate paused. Inefficient loops, repeated reads or misleading priorities found in traces become new route tests and graph changes. Long procedures live in separate resources, so they can be improved without touching the entry skill.

工作流运行

评估循环

Context 不执行固定脚本。每当 Agent 询问下一步做什么，CLI 都会观测 Context 知识工作区，把观测结果转换为 Facts，再向工作流 Provider 请求当前的 Route。

flowchart LR
  facts["知识工作区事实"] --> evaluate["Agent Graph 评估"]
  evaluate --> route["当前 Route"]
  route --> act["Agent 执行一个动作"]
  act -->|"知识工作区变化"| facts

Route 包含选中的步骤、原因码、Agent 动手前必须阅读的资源、尚未解决的 Gate，以及要执行的确切命令。只有 workflow.current 能选择下一个生命周期步骤；命令执行完后会把控制权交还给一次新的评估，而不是自己决定下一步。

两张图

packages/context-cli/context-workflow/ 中的 Provider 包含两张静态图：

图	覆盖范围
workspace	顶层生命周期：修复、来源边界、采集、Indexer 生命周期、审核、close、知识包输出、翻译、版本记录、构建和完成，以及回滚
indexer	需求、计划、开工报告、分阶段写作、缺口处理、来源更新和已批准页面的修订

顶层顺序由图的边固定：来源边界 → 采集 → run-indexer-lifecycle → 审核 → close → 知识包输出 → 版本 → 构建。节点描述的是稳定的任务类别，例如“还有采集目标未完成”；来源名称、日期和模块都是运行时事实，永远不会成为图节点。所以一张图就能服务所有知识工作区。

Gate

有些节点是 Gate：它们等待一个决定。例如选择来源边界、授权文档采集、批准开工报告、审核当前批次以及选择知识包输出。

每个 Gate 都声明自己是否可委托。普通模式下由人来决定。当你在当前对话中明确授权全托管运行时，Agent 可以处理可委托的 Gate，例如应用一份它已检查过的审核结果；但标记为不可委托的 Gate 不行，比如需要做范围决策时的开工报告。托管授权仅限当前对话，不能授权新的来源边界，也不能放行失败的校验或验证。

修订号与过期命令

每条写命令都绑定到产生它的那次观测的修订号。如果知识工作区此后发生了变化（另一个动作执行了，或者某个文件被编辑了），这条命令会被拒绝，而不是被应用到更新后的状态上。必读资源通过摘要确认；动态视图与选中它们的修订号绑定。回执只证明 Agent 收到了某个资源，并不表示任务已完成。

恢复

只要 Provider 相同、观测到的 Facts 相同、记录的结果相同，Agent Graph 就会选出相同的 Route。知识工作区事实已经满足的工作会被跳过或直接推进。因此，无论是中断、重试还是新开对话，都会从可观测的状态收敛，而不是依赖对话记忆。CLI 保证每个文件系统操作要么是原子的，要么有保护，要么可证明是空操作；Agent Graph 则保证评估可重复。

工作流如何改进

Route 的选择无需模型即可测试：context-workflow/tests/ 中存放从事实到 Route 的场景。开启调试模式后，Context 会记录 CLI 调用和图评估；回放可以看到每次事实变化时选中了哪个 Route、循环在哪里推进、Gate 在哪里暂停。从轨迹中发现的低效循环、重复读取或误导性优先级，会转化为新的 Route 测试和图改动。较长的操作流程放在独立的资源中，因此改进它们不必改动入口技能。