Open Dynamic Workflow

A plan → execute → audit harness for coding agents, shipped as a plugin for both Claude Code and Codex.

You give it a reviewed plan — a DAG of implement-and-audit tasks. Your agent implements each task, then a panel of blind auditors verifies the result against the task's acceptance criteria. If an audit fails, the implementer runs again with the findings until the task passes or runs out of attempts. The engine that tracks all this is pure, deterministic, and never calls an LLM.

How it works

The host agent is the orchestrator. It drives a deterministic engine through a verb CLI and spawns the implementer/auditor subagents itself — the engine holds the graph truth, the agent supplies the intelligence.

host agent (Claude Code / Codex)  ── the orchestrator: spawns subagents
      │  shell: validate │ init │ ready │ complete │ resolve │ fail │ report
      ▼
  engine-cli.ts   deterministic state machine, no LLM, state on disk (resumable)

Each task T is exploded into subnodes and run as a state machine:

T.impl ──▶ T.resolve ──▶ T.audit.0 … T.audit.n ──▶ settle
   ▲          (design a                              │
   │       blind MECE panel)                         │
   └──────── any FAIL, attempts remain ──────────────┘
             (re-implement with the findings)

All audits pass → the task is done and its dependents unblock. Any fail with attempts left → re-implement with the findings and re-resolve a fresh panel. Attempts exhausted → failed (non-halting; successors still run).

Install & use

Both plugins require Node ≥ 23.6 on the host (the engine is TypeScript run via native type-stripping — no build step).

Claude Code

/plugin marketplace add ./
/plugin install odw@open-dynamic-workflow

With a reviewed plan, the execute-plan skill drives the loop and spawns subagents; the bundled odw:audit-resolver agent designs each task's blind panel.

Codex (plugins are first-class since 2026)

codex plugin marketplace add ./
codex plugin add odw@open-dynamic-workflow

The Codex execute-plan skill drives the same engine, running each blind auditor as a fresh codex exec context so it can't see the implementer's reasoning.

The task graph

A plan compiles to a version: 1 graph of implement-and-audit tasks:

{ "version": 1, "nodes": [
  { "id": "greeting", "name": "Create a greeting module", "deps": [],
    "acceptanceCriteria": ["src/greeting.ts exports greet(name)"], "maxAttempts": 2 },
  { "id": "tests", "name": "Test it", "deps": ["greeting"],
    "acceptanceCriteria": ["the suite passes"], "maxAttempts": 2, "humanGate": true }
]}

The engine CLI

The shared backbone both plugins drive (state persists under --state-dir):

engine-cli.ts  validate | init | ready | complete | resolve | fail | show | report | status | done

Try it by hand:

cat > /tmp/plan.json <<'JSON'
{ "version": 1, "nodes": [
  { "id": "build", "name": "Build it", "deps": [], "acceptanceCriteria": ["it works"], "maxAttempts": 2 }
] }
JSON
node src/engine-cli.ts validate --graph /tmp/plan.json
GID=$(node src/engine-cli.ts init --graph /tmp/plan.json --state-dir .odw/state)
node src/engine-cli.ts ready --id "$GID" --state-dir .odw/state
node --test   # 16 engine tests

Layout

src/
  engine/        deterministic state machine (types · graph · core · store · Engine) — source of truth
  engine-cli.ts  the verb CLI the host agent drives
plugins/
  claude-code/   .claude-plugin/plugin.json · skills/execute-plan · agents/audit-resolver · scripts/(synced)
  codex/         .codex-plugin/plugin.json · skills/execute-plan · scripts/(synced)
scripts/build-plugins.mjs   sync the engine into both plugins
.claude-plugin/marketplace.json   ·   .agents/plugins/marketplace.json

src/ is the single source of truth; node scripts/build-plugins.mjs copies the engine into each plugin (plugins are copied to a cache on install, so each carries its own engine). The engine is dependency-free and covered by node --test.

Notes

• Non-halting failures — an exhausted task is logged failed, not fatal; the policy lives in one predicate (depsSettled).
• Fail-safe parsing — an implementer with no clear STATUS is treated as BLOCKED, an auditor with no clear VERDICT as FAIL; ambiguity never passes.
• Resumable — run state is keyed by a content hash of the graph; re-init of the same graph resumes it.

Status

Engine and verb CLI implemented and tested (16 tests; the CLI verified end-to-end across separate processes via FileStore). Both plugins are packaged — manifests parse and the engine runs unchanged from inside each plugin dir. The skills' host-side dispatch (subagent spawning / codex exec) is exercised live, not in the offline suite. Not yet built: exclusive-resource locking, a write-plan authoring skill, and a single-file .mjs engine build to drop the Node ≥ 23.6 host requirement.

Open Dynamic Workflow（中文）

一个面向编码智能体的 规划 → 执行 → 审计 框架，作为插件同时支持 Claude Code 与 Codex。

你向它提供一份已审阅的计划——一个由*「实现并审计」任务*构成的有向无环图（DAG）。 你的智能体逐个实现每个任务，随后由一组盲审审计员依据该任务的验收标准核验结果。 若审计未通过，实现者会带着审计发现重新执行，直到任务通过或耗尽尝试次数。 驱动这一切的引擎是纯粹、确定性的，且从不调用任何 LLM。

工作原理

宿主智能体即编排者（orchestrator）。它通过一个动词式 CLI 驱动确定性引擎， 并亲自派生实现者/审计员子智能体——引擎持有图的事实真相，智能体提供智能。

宿主智能体 (Claude Code / Codex)  ── 编排者：派生子智能体
      │  shell: validate │ init │ ready │ complete │ resolve │ fail │ report
      ▼
  engine-cli.ts   确定性状态机，无 LLM，状态落盘（可恢复）

每个任务 T 会被展开为若干子节点，并作为状态机运行：

T.impl ──▶ T.resolve ──▶ T.audit.0 … T.audit.n ──▶ settle
   ▲       （设计一组盲审                            │
   │        MECE 审计面板）                          │
   └──────── 任一 FAIL 且仍有尝试次数 ────────────────┘
             （带着审计发现重新实现）

所有审计通过 → 任务标记为 done，其下游依赖随之解锁。任一失败且仍有尝试次数 → 带着审计发现重新实现，并重新组建一组全新的盲审面板。尝试次数耗尽 → failed （非中断式；后继任务仍会继续运行）。

安装与使用

两个插件都要求宿主环境具备 Node ≥ 23.6（引擎是通过原生类型剥离运行的 TypeScript——无需构建步骤）。

Claude Code

/plugin marketplace add ./
/plugin install odw@open-dynamic-workflow

有了已审阅的计划后，execute-plan 技能会驱动整个循环并派生子智能体； 随附的 odw:audit-resolver 智能体负责为每个任务设计其盲审面板。

Codex（自 2026 年起，插件已是一等公民）

codex plugin marketplace add ./
codex plugin add odw@open-dynamic-workflow

Codex 的 execute-plan 技能驱动同一引擎，将每个盲审审计员作为一个全新的 codex exec 上下文运行，使其无法看到实现者的推理过程。

任务图

一份计划会编译为一个 version: 1 的*「实现并审计」任务*图：

{ "version": 1, "nodes": [
  { "id": "greeting", "name": "Create a greeting module", "deps": [],
    "acceptanceCriteria": ["src/greeting.ts exports greet(name)"], "maxAttempts": 2 },
  { "id": "tests", "name": "Test it", "deps": ["greeting"],
    "acceptanceCriteria": ["the suite passes"], "maxAttempts": 2, "humanGate": true }
]}

引擎 CLI

两个插件共同驱动的底层骨干（状态持久化于 --state-dir 下）：

engine-cli.ts  validate | init | ready | complete | resolve | fail | show | report | status | done

手动试用：

cat > /tmp/plan.json <<'JSON'
{ "version": 1, "nodes": [
  { "id": "build", "name": "Build it", "deps": [], "acceptanceCriteria": ["it works"], "maxAttempts": 2 }
] }
JSON
node src/engine-cli.ts validate --graph /tmp/plan.json
GID=$(node src/engine-cli.ts init --graph /tmp/plan.json --state-dir .odw/state)
node src/engine-cli.ts ready --id "$GID" --state-dir .odw/state
node --test   # 16 个引擎测试

目录结构

src/
  engine/        确定性状态机 (types · graph · core · store · Engine) —— 事实真相之源
  engine-cli.ts  宿主智能体驱动的动词式 CLI
plugins/
  claude-code/   .claude-plugin/plugin.json · skills/execute-plan · agents/audit-resolver · scripts/(已同步)
  codex/         .codex-plugin/plugin.json · skills/execute-plan · scripts/(已同步)
scripts/build-plugins.mjs   将引擎同步进两个插件
.claude-plugin/marketplace.json   ·   .agents/plugins/marketplace.json

src/ 是唯一的事实真相之源；node scripts/build-plugins.mjs 会把引擎复制进每个插件 （插件在安装时会被复制到缓存，因此各自携带自己的引擎）。引擎零依赖，并由 node --test 覆盖。

说明

• 非中断式失败 —— 耗尽尝试次数的任务会被记为 failed，而非致命错误； 该策略集中于单个谓词（depsSettled）中。
• 故障安全解析 —— 没有明确 STATUS 的实现者会被视作 BLOCKED， 没有明确 VERDICT 的审计员会被视作 FAIL；含糊其辞绝不会被判为通过。
• 可恢复 —— 运行状态以图的内容哈希为键；对同一张图重新 init 即可恢复。

状态

引擎与动词式 CLI 已实现并通过测试（16 个测试；CLI 已通过 FileStore 在多个独立进程间 端到端验证）。两个插件均已打包——清单文件可正常解析，且引擎在每个插件目录内可原样运行。 技能的宿主侧分发（子智能体派生 / codex exec）是在真实环境中实测的，而非离线测试套件覆盖。 尚未构建：独占资源锁、用于撰写计划的 write-plan 技能，以及一个单文件 .mjs 引擎构建 （以摆脱 Node ≥ 23.6 的宿主要求）。