Archie Orchestrator

Can a plugin give a coding agent durable task state - queue tracking, manual-testing gates, usage summaries - that actually holds up under unattended real-world software engineering?

The plugin provides eight tools: task init, read, transition, start, finish, update, queue status, and usage report. It maintains state integrity via cryptographic signatures on status.json - detecting when agents fabricate state instead of using tools.

Bundled skills cover work orchestration, issue design, and repository investigation. The config supports concurrency limits, worker command routing, CI verification, and manual testing requirements.

End-to-end testing drove real fixes:

• review.requireManualTesting was declared in config but never enforced - fixed with an explicit requireManualTesting parameter on archie_task_finish
• Concurrency enforcement added to prevent more than N workers running simultaneously
• resolvedConfig return value added to archie_task_start so agents can see whether config was actually delivered
• 73 unit tests, every new behavior also verified live

The plugin’s own logic held up under testing. The task lifecycle, manual-testing gate, concurrency enforcement, and integrity signature all worked correctly (73 tests pass).

But the overall workflow did not work reliably:

1. Platform-level config gap: OpenClaw’s CLI one-shot and embedded agent runtime paths do not reliably deliver plugin config to tool executors - meaning every config default this plugin declares is silently ignored in those environments. This was traced through OpenClaw’s own minified source to a discovery-mode registration pass that skips full activation.

2. Agent autonomy/trust finding: When the plugin’s tools were unavailable through the Codex harness, an agent chose to fabricate status.json by hand rather than stop and report the blocker. The integrity signature was added specifically to catch this.

3. Real bug detection: Testing with a real Pomodoro timer build (using a prompt from my Model Prompt Tests library) found a real user-facing bug the agent’s own tests couldn’t catch - the agent was building mode-toggles via querySelectorAll('[data-mode]') which also matched the <main> element. A fresh agent session correctly diagnosed and fixed it from the review notes alone.

The fix for the config gap wasn’t in the plugin - it was changing the plugin to not depend on config at all, using explicit per-call parameters instead. The real lesson: agent tooling needs to be tested against the environments it actually runs in, not just unit-tested against documented API contracts.

• Test against real runtimes, not docs. The SDK contract says execute(params, config, context) delivers config - but the actual CLI runtime doesn’t under agent --local.
• Integrity checking beats prompting. Don’t ask agents nicely not to fabricate state - make it detectable.
• Explicit beats implicit. When config injection is unreliable, pass critical parameters explicitly.