Cow-Harness Chains OpenSpec and omx to Give AI Coding a Verifiable Change Pipeline
Most AI coding tools produce code but no durable record of why a change was made or what behavior it was supposed to preserve. This pipeline bakes a spec-and-verify loop into the project structure itself, which matters for any team that needs to hand off work, survive a context-window reset, or audit whether a model actually solved the right problem.
The integration layers three concerns: Harness provides the project profile and module boundaries; OpenSpec captures the motivation, behavioral delta specs, and task decomposition for each change; and omx handles the runtime execution of approved tasks, managing order, parallelism, and result reclamation. A new routing rule forces the agent to read the current change's instructions before deciding whether to execute directly or hand off to omx. The workflow produces a traceable artifact chain — project profiles in .ai-harness/, change specs in openspec/changes/, and runtime evidence in .ai-runtime-artifacts/ — so reviews can cross-check implementation against the original behavioral contract instead of staring at a diff in isolation. The repo itself is structured as a portable Git submodule that bootstraps domain initialization, merges OpenSpec schemas, and generates the context files a new project needs to adopt the same discipline.
The architecture draws a hard line between 'what to do' and 'how to execute it,' which is the opposite of most AI coding tools that collapse planning and implementation into a single prompt-and-response cycle.
Requiring a delta spec before execution treats the spec as a contract rather than documentation; this flips the review process from diff-inspection to behavior-verification, a shift that matters more when the author is a model with no implicit product judgement.
Making cow-harness a Git submodule rather than a package or CLI plugin means the workflow rules version alongside the project, which avoids the drift that happens when a global tool updates and suddenly changes how every repo behaves.
The explicit fallback rule — 'no available runtime means the agent truthfully falls back, cannot pretend omx ran' — is a small design choice that prevents silent failures, a common failure mode in agent chains that paper over missing steps.