Delivery Workflow Engine & Memory Relay (DWEMR)

DWEMR is an OpenClaw plugin that installs and operates a Claude-native delivery workflow.

It is intentionally split into two layers:

• OpenClaw public layer: short deterministic slash commands
• Claude internal layer: the bundled /delivery-* workflow plus /delivery-driver onboarding procedure inside the target project

OpenClaw is the operator. Claude Code remains the delivery engine.

High-Level Shape

                              ┌──────┐
                              │ User │
                              └──┬───┘
                                 │
                          /dwemr <action>
                                 │
              ┌──────────────────┴──────────────────┐
              │      OpenClaw + DWEMR Plugin         │
              │                                      │
              │  local ops        routed ops          │
              │  help / doctor    start / continue    │
              │  init / mode      plan / implement    │
              │  projects / use   release / pr / stop  │
              │  model / effort   status / what-now   │
              └──────────────────┬───────────────────┘
                                 │
                        Managed ACPX session
                    (per model/effort combo)
                                 │
  ┌─────────────────────────────┴─────────────────────────────────┐
  │                       Target Project                           │
  │                                                                │
  │  CLAUDE.md  ·  .claude/commands  ·  .claude/agents             │
  │  .dwemr/state/*  ·  .dwemr/project-config.yaml                │
  │                                                                │
  │  ┌──────────────────────────────────────────────────────────┐  │
  │  │  Main Agent  (state-first dispatcher)                    │  │
  │  │  reads state → picks owner → dispatches one subagent     │  │
  │  └────┬────────────────────┬────────────────────────────────┘  │
  │       │                    │                                   │
  │       │ [onboarding gate]  │ [if needs_product_framing]        │
  │       ▼                    ▼                                   │
  │   interviewer        product-manager                           │
  │   prompt-enhancer    (standard_app only)                       │
  │       │                    │                                   │
  │       └────────┬───────────┘                                   │
  │                ▼                                               │
  │  ┌──────────────────────────────────────────────────────────┐  │
  │  │  delivery-manager                                        │  │
  │  │  stage routing: planning → implementation [→ release]    │  │
  │  └────┬─────────────────┬─────────────────────┬─────────────┘  │
  │       │                 │                     │                │
  │       ▼                 ▼                     ▼                │
  │  ┌──────────┐   ┌───────────────┐    ┌──────────────┐         │
  │  │ planning │   │implementation │    │   release    │         │
  │  │ manager  │   │   manager     │    │   manager    │         │
  │  └────┬─────┘   └──────┬────────┘    └──────┬───────┘         │
  │       │                │                    │                  │
  │       ▼                ▼                    ▼                  │
  │  MINIMAL_TOOL:    one task per cycle:   git commit / push      │
  │   guide-creator    implementer          PR create / update     │
  │                    reviewer (phase      merge (if enabled)     │
  │  STANDARD_APP:       boundary only)                            │
  │   [architect]      fixer                                       │
  │   epic             e2e-tester                                  │
  │   tech-spec        wave-creator                                │
  │   guide-creator    wave-manager                                │
  │                    wave-planner                                 │
  │                                                                │
  │  orchestrator  (user-proxy, callable by any manager)           │
  │                                                                │
  │  ── Canonical State (read priority) ────────────────────────   │
  │  1. onboarding-state.md    gate: profile, packs, install       │
  │  2. project-config.yaml    config: exec mode, SCM, approval   │
  │  3. pipeline-state.md      routing ledger: owner, stage        │
  │  4. execution-state.md     freshest checkpoint overlay         │
  │  5. implementation-state   task / worker loop detail           │
  │  6. release-state.md       optional git traceability           │
  │  7. pipeline-policy.md     gates, loop limits, severity        │
  │  +  waves/*/wave-state.md  standard_app wave-local state       │
  │  +  memory/global/*        narrative context only              │
  └────────────────────────────────────────────────────────────────┘

Requirements

• Node.js 22 or newer
• OpenClaw 2026.4.2 or newer
• OpenClaw's ACPX runtime available on the machine
• Claude Code installed and authenticated on the host machine

DWEMR relies on OpenClaw's ACPX runtime for Claude execution. On healthy OpenClaw installs this is usually available automatically.

Quick install

openclaw plugins install dwemr
openclaw gateway restart

For local development:

openclaw plugins install -l ./plugins/dwemr
openclaw gateway restart

Then configure plugins.entries.dwemr.config in your OpenClaw config only if you need optional runtime overrides such as a default project path or model override.

ACPX Troubleshooting

DWEMR ACP-native runs are more reliable with a larger ACPX host timeout budget. We recommend setting this before use:

openclaw config set plugins.entries.acpx.config.timeoutSeconds 7200
openclaw gateway restart

7200 means a 2-hour per-turn timeout. For especially long-running DWEMR sessions, you may need a higher value.

You can check the current value with:

openclaw config get plugins.entries.acpx.config.timeoutSeconds

Reference values in current OpenClaw installs:

• default: 120 seconds
• minimum: 1 second
• maximum: 86400 seconds

Many environments work without extra ACPX permission tuning, so permissionMode is still conditional troubleshooting rather than a universal requirement.

If you do hit ACPX-specific failures, these host-level settings are the first things to check:

openclaw config get plugins.entries.acpx.config.permissionMode

If you are getting ACPX permission errors in non-interactive DWEMR runs:

openclaw config set plugins.entries.acpx.config.permissionMode approve-all
openclaw gateway restart

If ACPX sessions fail during longer DWEMR turns or die around a repeatable time boundary:

openclaw config set plugins.entries.acpx.config.timeoutSeconds 7200
openclaw gateway restart

Why these help in some environments:

• permissionMode=approve-all lets ACPX execute shell, edit, and write actions without interactive approval prompts
• timeoutSeconds=7200 gives longer ACPX turns enough host-level time budget and avoids time-bound failures we have observed in some environments

These are ACPX host settings. Project-local .claude/settings.json does not replace them for ACP-native runs.

Important Safety Note

DWEMR installs a project-local .claude/settings.json into initialized projects.

• Claude Code is put into bypassPermissions mode for that project
• Bash, Edit, and Write are allowed
• this is intentional so the bundled workflow can run unattended inside Claude-managed project contexts
• ACP-native runs still depend on ACPX host policy for the actual shell and file-write harness permissions

Use DWEMR only in projects where that permission model is acceptable. Running it in an isolated environment is recommended.

Important Cost Note

DWEMR is not optimized for minimal token usage.

• token usage can be high, especially in standard_app mode
• long autonomous runs can accumulate significant model cost through repeated planning, review, e2e, and release loops
• use DWEMR with care if you are sensitive to model spend

For leaner runs, explicitly steer onboarding toward a minimal workflow in your request, for example:

/dwemr start Build this as a minimal tool. Keep the workflow lightweight and avoid standard_app unless clearly necessary.

Support

• Repository: https://github.com/quareth/Dwemr
• Issues: https://github.com/quareth/Dwemr/issues
• Local development: openclaw plugins install -l ./plugins/dwemr

Public commands

DWEMR exposes one public OpenClaw command surface:

• /dwemr <action> ...

Supported /dwemr actions:

• help
• doctor [path] [--fix]
• init [path] [--overwrite] [--confirm-overwrite]
• mode <auto|checkpointed>
• sessions [clear]
• projects
• use <path>
• model [number|unset]
• subagents [number|unset]
• effort [number|unset]
• what-now [path if no active project]
• status [path if no active project]
• continue [path if no active project]
• stop [path if no active project]
• start [path if no active project] <request>
• plan [path if no active project] <request>
• implement [path if no active project]
• release [path if no active project] (requires git enabled)
• pr [path if no active project] (requires git enabled)
• git disable

If the path contains spaces, quote it.

Deterministic dispatch

The public commands dispatch directly to plugin tools with raw command arguments:

• /dwemr -> dwemr_command

/dwemr help is answered directly by the plugin.

/dwemr init is handled directly by the plugin and installs the DWEMR bootstrap kit into the target project.

/dwemr mode <auto|checkpointed> is also handled directly by the plugin. It updates .dwemr/project-config.yaml for the active DWEMR project; CLI auto selects the canonical mode autonomous.

/dwemr stop is handled directly by the plugin. It stops the active OpenClaw-managed DWEMR runtime owner for the selected project and leaves the Claude-owned workflow state files untouched so work can resume from the last saved checkpoint.

/dwemr what-now maps to the internal Claude command /delivery-what-now, which is guidance-only. It reads authoritative DWEMR state first, uses memory only as optional narrative context, summarizes what happened most recently, and points the user to the safest next public /dwemr command. If onboarding is incomplete, DWEMR surfaces the saved onboarding clarification when one exists; otherwise it points the user back to a request-bearing onboarding command.

At runtime DWEMR executes one Claude entrypoint per routed command through the ACP-native runtime backend (OpenClaw-managed ACP session + turn control). The legacy spawn-based shell execution path was retired in 0.2.0 and ACP-native is now the only supported runtime.

DWEMR does not emulate Claude’s internal agents. It maps the requested action to one Claude entrypoint and returns only the final assistant response on success.

Runtime behavior

DWEMR keeps /dwemr available even before setup is healthy.

ACP-native run model:

• each routed /dwemr command executes as a one-shot ACP run
• DWEMR continuity remains state-first via .dwemr/state/*, not by reusing one long-lived ACP session id

ACP-native runtime seam compatibility:

When ACP-native prerequisites are missing at runtime, /dwemr doctor reports the missing seams. There is no longer a fallback execution path; /dwemr help and /dwemr doctor remain reachable on broken installs so the user can diagnose the missing prerequisites.

DWEMR also remembers multiple project paths in its own state storage while keeping exactly one active project at a time.

Recommended workflow

1. Install or link the plugin.
2. Run /dwemr help or /dwemr doctor <path>.
3. If DWEMR reports missing runtime state or ACPX permission issues, run /dwemr doctor <path> --fix.
4. Make sure Claude Code is authenticated on the machine with claude auth status.
5. Run /dwemr init <path>.
6. Run /dwemr start <request> to complete onboarding and let DWEMR provision the selected workflow profile.
7. If onboarding returns one clarification batch, answer it with another /dwemr start <response> run.
8. Continue normal delivery with the same public /dwemr commands.

Freshly initialized bootstrap-only projects are not meant to continue through standalone Claude alone. If you run onboarding directly inside Claude and it selects a profile, return to /dwemr continue or another /dwemr start or /dwemr plan run so the DWEMR plugin runtime can provision the selected packs before downstream delivery commands continue.

If you are unsure what to do after onboarding has started, run /dwemr what-now to review the current guidance or any saved clarification batch. It does not begin first-pass onboarding by itself.

After init, DWEMR remembers that project and makes it the active project automatically without rewriting the live gateway config.

/dwemr init creates only the final project folder. Parent directories must already exist, which helps catch typos like Documnets before DWEMR creates the wrong tree.

Use /dwemr projects to list remembered projects and /dwemr use <path> to switch the active one.

Use /dwemr mode checkpointed when you want DWEMR to stop at major milestones and report before waiting for /dwemr continue. Use /dwemr mode auto when you want the canonical autonomous behavior: the bundled team keeps routing itself through planning, implementation, feature completion, and git/release progression until the run is done, blocked, approval-limited, or stopped by the current command's scope.

In autonomous mode, long-running DWEMR execution commands are allowed to keep running without the old delivery timeout. If you need to interrupt a run manually, use /dwemr stop.

Usage examples

1. Initialize a project

/dwemr init /absolute/path/to/my-project

/dwemr init creates the target project folder and installs the DWEMR bootstrap kit into it. In practice that means:

• CLAUDE.md
• .claude/ command and agent assets
• .dwemr/ state, memory, reference, guide, and runbook files

The initialized project becomes the active DWEMR project automatically.

2. Work with one active project at a time

DWEMR can remember multiple projects, but only one project is active at a time. When you run a /dwemr command without a path, DWEMR uses the active project.

/dwemr projects
/dwemr use /absolute/path/to/project-a
/dwemr status
/dwemr use /absolute/path/to/project-b
/dwemr what-now

In that sequence, /dwemr status runs against project-a, and after switching, /dwemr what-now runs against project-b.

3. Start work and continue onboarding

/dwemr start Build me a simple calculator app
/dwemr start 1: personal calculator 2A 3A 4B 5A 6A 7A

The first /dwemr start begins onboarding or delivery. If DWEMR returns one clarification batch, answer it with another /dwemr start <response>.

4. Ask DWEMR what to do next

/dwemr what-now

/dwemr what-now is guidance-only. It does not start a new run by itself. It reads DWEMR state, summarizes the current situation, and points you to the safest next public command. If onboarding is waiting on clarification, it repeats the saved clarification instead of starting over.

5. Tune model, subagent model, and effort

/dwemr model
/dwemr model 2
/dwemr subagents
/dwemr subagents 1
/dwemr effort
/dwemr effort 3
/dwemr effort unset

These commands are project-scoped. Running /dwemr model, /dwemr subagents, or /dwemr effort with no value shows the numbered choices for the active project. Then you can select by number or clear the override with unset.

6. Check live progress and stop a run

/dwemr status
/dwemr stop

/dwemr status shows the current delivery state for the active project without changing it. If a long-running DWEMR execution is in flight, /dwemr stop cancels the active OpenClaw-managed runtime owner and keeps the saved workflow state so you can resume later.

7. Inspect or clear tracked DWEMR ACP sessions

/dwemr sessions
/dwemr sessions clear

Use /dwemr sessions to list only the ACP sessions DWEMR currently tracks for DWEMR-owned runs. This is especially useful when checking for stale or hung ACP-native DWEMR activity. Use /dwemr sessions clear to close only those tracked DWEMR sessions. It does not close unrelated ACP or ACPX sessions owned by other tools. Session listing and clearing are available only with the ACP-native runtime backend.

8. Change execution mode

/dwemr mode checkpointed
/dwemr mode auto

/dwemr mode controls whether DWEMR keeps going until blocked (auto) or pauses at major milestones (checkpointed).

Doctor and self-heal

/dwemr doctor [path] reports:

• whether the ACP-native runtime backend is ready
• ACP-native seam availability (tasks.flows required, taskFlow compatibility)
• whether ACPX host timeout and permission config look healthy for DWEMR's ACP-native automation path
• whether the target project exists
• whether the project is missing DWEMR assets, bootstrap-only, or fully profile-installed
• whether onboarding is pending, waiting on clarification, or complete
• whether the configured runtime can execute a DWEMR health-check prompt

/dwemr doctor [path] --fix now previews ACPX host repair when ACP-native automation is blocked. It explains the root cause and prints exactly two follow-up commands:

• /dwemr doctor [path] --fix --restart
• /dwemr doctor [path] --fix --no-restart

/dwemr doctor [path] --fix --restart and /dwemr doctor [path] --fix --no-restart will try to:

• bootstrap or repair the configured runtime backend path
• reuse the bundled ACPX source shipped with OpenClaw when available
• repair plugins.entries.acpx.config.permissionMode to approve-all
• repair plugins.entries.acpx.config.nonInteractivePermissions to fail
• install missing DWEMR bootstrap assets without requiring a separate shell setup step
• finish profile provisioning only when onboarding has already selected a profile

Doctor also reports ACPX timeout guidance when it detects repeatable time-bound turn failures, but timeout changes remain host-level troubleshooting rather than an automatic --fix mutation.

For ACP-native runs, ACPX owns shell and file-write permissions. .claude/settings.json and Claude CLI bypass flags do not override ACPX harness policy. When doctor repairs ACPX permission config with --restart, it inspects gateway.reload.mode and tells you whether OpenClaw should apply the restart path automatically or whether a manual restart is still required.

Verification checklist

After shipping or installing a new DWEMR build, verify these flows:

• missing runtime: /dwemr help still works before any bootstrap
• missing runtime: /dwemr doctor <path> reports the runtime as not ready
• ACPX preview: /dwemr doctor <path> --fix prints the two repair choices without mutating host ACPX permission config
• ACPX repair only: /dwemr doctor <path> --fix --no-restart repairs ACPX permission config and preserves unrelated OpenClaw config
• ACPX restart-aware repair: /dwemr doctor <path> --fix --restart explains whether OpenClaw should restart/apply automatically based on gateway.reload.mode
• self-heal: /dwemr doctor <path> --fix --restart or --no-restart creates a usable managed runtime when ACPX permission config was the blocker
• repaired runtime: /dwemr doctor <path> reports a ready execution runtime afterward
• repaired runtime: /dwemr status succeeds after self-heal
• bootstrap-only project: /dwemr doctor <path> reports onboarding as pending instead of corruption
• onboarding entry gating: /dwemr continue does not start first-pass onboarding on a brand-new bootstrap-only project
• execution mode control: /dwemr mode checkpointed updates the active project's .dwemr/project-config.yaml
• operator stop control: /dwemr stop cancels a long-running OpenClaw-managed DWEMR runtime owner and keeps the last saved workflow checkpoint
• pending clarification: /dwemr what-now repeats the saved clarification batch instead of starting a new interview
• clarification follow-up: /dwemr start <response> resumes onboarding with the saved request context
• missing project assets: /dwemr doctor <path> reports the project as missing DWEMR assets
• repaired project assets: /dwemr init <path> or /dwemr doctor <path> --fix installs the missing bootstrap assets
• onboarding flow: /dwemr start <request> can run onboarding, provision the selected profile, and continue the original command
• release gating: /dwemr release and /dwemr pr return an explicit unavailable message when git is not enabled for the project
• healthy Claude runtime: /dwemr doctor <path> confirms auth, session ensure, and a quiet prompt
• agent policy guardrail: doctor diagnoses claude ACP allowlist/default-agent policy issues without auto-editing acp.allowedAgents or acp.defaultAgent
• clean response surface: /dwemr status returns only the final assistant message on success

Bundled workflow assets

The package is self-contained. init now installs a bootstrap pack instead of the full workflow. The bootstrap includes:

• CLAUDE.md
• .claude/settings.json
• the stable .claude/commands/ surface
• interviewer and bootstrap-safe reference agents
• .dwemr/guides/README.md
• .dwemr/project-config.yaml
• .dwemr/reference/
• .dwemr/memory/README.md
• .dwemr/reference/PLAN_TEMPLATE.md
• .dwemr/state/pipeline-policy.md
• .dwemr/state/implementation-state.example.md

The bootstrap also seeds fresh runtime files instead of copying live runtime state:

• .dwemr/state/pipeline-state.md
• .dwemr/state/execution-state.md
• .dwemr/state/implementation-state.md
• .dwemr/state/onboarding-state.md
• .dwemr/memory/global/*.md

Post-onboarding runtime truth is authoritative only in:

• .dwemr/state/pipeline-state.md
• .dwemr/state/execution-state.md
• .dwemr/state/implementation-state.md

.dwemr/memory/** remains human-friendly narrative context and must never override those files when they disagree.

On the first request-bearing onboarding command, DWEMR selects a workflow profile. After onboarding completes, DWEMR provisions only the required profile packs:

• profile-minimal-tool
• profile-standard-app
• optional packs such as standard-app-focused-planning

Until that provisioning step happens, a bootstrap-only project is still pending profile installation. Standalone Claude should stop after onboarding and hand control back to /dwemr for provisioning rather than trying to route into managers whose packs are not installed yet.

If git is not enabled in .dwemr/project-config.yaml, /dwemr release and /dwemr pr stop with an explicit unavailable message instead of attempting to enter the release lane.

Quality is enforced through the active quality runbook, implementation guides, implementer verification, and the implementation-reviewer loop rather than a separate routed QA command.

templates/CLAUDE.md is the single shipped main-agent guide source. During init, DWEMR copies that file into the target project root as CLAUDE.md.

Do not remove CLAUDE.md from a DWEMR-managed project or casually replace it with repo-specific guidance. DWEMR installs that file during provisioning because it explains the agentic workflow, routing rules, and state model the main agent relies on to run the system correctly.

.claude/ is reserved for Claude-native control files only. DWEMR-owned config, state, memory, reference material, and generated guides live under .dwemr/.

This runtime model is intentionally breaking for older initialized projects. Re-run /dwemr init <path> --overwrite --confirm-overwrite only when you intentionally want to destroy the existing target folder contents and recreate a brand-new DWEMR bootstrap install there.

Shared config

The installed .dwemr/project-config.yaml is the shared control-plane file for project-level decisions, such as:

• onboarding-resolved project size
• execution/approval defaults
• whether git, GitHub, PR, CI, and merge capabilities are available

Bootstrap installs now seed unresolved onboarding-owned fields as unset. Onboarding must rewrite those to concrete values before normal delivery continues.

Example:

project:
  size: unset

delivery:
  execution_mode: unset
  approval_mode: auto

scm:
  git_mode: unset
  github: unset
  remote_push: unset
  pull_requests: unset
  ci: unset
  merge: unset

project.size in .dwemr/project-config.yaml is now the canonical source for provisioning/profile loading. .dwemr/state/onboarding-state.md still carries onboarding state and must keep selected_profile aligned with that interviewer decision.

Optional plugin config

DWEMR can read a plugin config entry at plugins.entries.dwemr.

Supported key:

{
  "acpAgent": "claude",
  "acpBackend": "acpx",
  "activeProjectPath": "/absolute/path/to/project",
  "defaultProjectPath": "/absolute/path/to/project",
  "model": "sonnet",
  "subagentModel": "claude-sonnet-4-6",
  "effortLevel": "medium",
  "projects": [
    {
      "path": "/absolute/path/to/project",
      "addedAt": "2026-03-31T00:00:00.000Z",
      "lastUsedAt": "2026-03-31T00:00:00.000Z",
      "initialized": true
    }
  ]
}

acpAgent optionally overrides the ACP harness agent id used by ACP-native runs. If unset, DWEMR follows OpenClaw ACP defaults and ultimately falls back to claude.

acpBackend optionally overrides the ACP backend id for ACP-native runs.

model optionally selects the Claude model for DWEMR runs. Claude Code supports aliases such as sonnet, opus, haiku, and opusplan, as well as full model names.

subagentModel optionally overrides the Claude model used for subagents. Use a full model name when possible.

effortLevel optionally overrides Claude effort for DWEMR runs. Supported Claude values include low, medium, high, max, and auto.

activeProjectPath is a legacy compatibility fallback for the currently selected project path.

projects is a legacy compatibility fallback for remembered project metadata.

When activeProjectPath or defaultProjectPath is set, /dwemr init and /dwemr may omit the path argument.

Current DWEMR builds persist remembered projects under the OpenClaw state directory instead of writing them into openclaw.json during normal command execution.

Runtime option notes:

• model and cwd are mapped through to ACP-native session runtime options.
• DWEMR does not currently push timeoutSeconds through ACP-native session runtime options. Configure longer ACPX turn limits at the host level instead, for example: openclaw config set plugins.entries.acpx.config.timeoutSeconds 7200
• subagentModel and effortLevel mapping under ACP-native is backend-dependent and currently best-effort with caveats.

Internal implementation surfaces

These remain internal implementation surfaces and are not the recommended public interface:

• plugin id dwemr
• tool dwemr_init

Plugin layout

• openclaw.plugin.json - native OpenClaw manifest
• package.json - package metadata
• index.ts - plugin entry and deterministic command tools
• skills/ - public OpenClaw slash commands
• templates/ - bundled Claude workflow assets