1. Preface

AI Harness Enterprise Implementation Practice (1)

Harness Enterprise Implementation (2) - Let AI Understand the Project

Through the previous two articles, Harness can already be used normally and produce an engineering project profile.

This time, we want every task to have clear boundaries, be executed correctly, and finally leave reusable evidence.

The author integrated OpenSpec and omx (oh-my-codex's runtime orchestration) into cow-harness. Thus achieving Harness manages project boundaries, OpenSpec manages task decomposition and sorting, and omx manages the execution of approved tasks.

Making the AI operation process more robust!

Open Source Addresses: OpenSpec · omx · cow-harness

2. Background

AI being able to read a repository does not mean it can consistently implement requirements correctly. A new requirement brings another set of questions: why change it, where to change it, which behaviors must not be broken, and what constitutes completion?

If this information is scattered only in chat logs, previous judgments can easily disappear.

Therefore, Harness is not treated as just a folder for stuffing prompts, but more like the project's working order:

• Stable facts: Precipitated as project assets;
• Facts to be changed this time: Precipitated as change specifications;
• Execution and verification facts: Precipitated as traceable process evidence.

3. Division of Responsibilities

Layer	Location	Responsible For	Not Responsible For
Harness	.ai-harness/ and project entry	Project profile, module boundaries, task routing, verification gates	Does not save detailed plans for every requirement
OpenSpec	openspec/changes/	Motivation, behavioral specs, tasks, and acceptance for a single change	Does not duplicate project profiles, nor write code directly for you
omx	Runtime execution chain	Decomposes, executes, and reclaims results for approved tasks	Does not override specs to decide requirement scope
Runtime Evidence	.ai-runtime-artifacts/	Execution logs, independent decisions, reviews, and non-OpenSpec verification records	Does not re-save facts already existing within a change

• Harness first tells the AI "which project it is working in";
• OpenSpec tells the AI "what to change this time";
• omx finally handles "how to more reliably produce the already clarified tasks."

Project Profile .ai-harness/
        ↓ Identify stable facts and correct sub-projects
OpenSpec change
        ↓ Specs, tasks, human confirmation
omx or current Agent
        ↓ Execution, testing, verification
Change Archive + Runtime Evidence
        ↓ Reflow as project context readable for the next task

4. How OpenSpec Intervenes

What OpenSpec truly constrains is: Changes with behavioral boundaries

Task Situation	Which Path to Take
Documentation, spelling, pure configuration, mechanical modifications, local defects without contracts	Handle directly, run the closest verification
New capabilities, architecture, cross-module, external APIs, data models, security, complex UI behavior	Create or continue an OpenSpec change within the current business project
Follow-up work already within a change	Continue that change; cannot bypass it to start a private process

Note that once entering OpenSpec, the process compacts requirements layer by layer:

• First understand the problem, then decide if design is needed;
• Write verifiable behavioral specs;
• Decompose into executable tasks;
• Confirm with humans when necessary, and only then enter implementation and verification.

brainstorm
   → design (as needed)
   → specs (required)
   → tasks
   → human-review (as needed)
   → apply
   → verify
   → retrospective
   → archive

The current OpenSpec verification and archiving process requires at least one behavioral delta spec to judge whether a change is complete; this precisely gives "what to change, how to verify" a clear landing point.

5. How omx Intervenes

OpenSpec solves "what to do"; omx solves "how to execute already-approved things more reliably."

The handoff point between the two is very clear: Only after tasks have been decomposed and confirmed is execution allowed to begin.

In cow-harness's routing, the Agent first reads the dynamic instructions of the current change:

openspec instructions apply --change <change-name> --json

This step lets the executor obtain the tasks, specs, and verification requirements of the current change, and then decide which execution method to adopt:

• Single-objective, low-coupling tasks: Can be directly implemented by the current Agent with focused verification;
• Multi-task or high-coupling approved implementations: Hand over to omx for runtime orchestration, completing, reclaiming, and verifying separately;
• No available runtime: The current Agent truthfully falls back to execution and cannot pretend omx has already run it.

6. cow-harness Integration

In this modification of cow-harness, we actually did four things:

1. Fixed domain-init as a Git submodule of Harness. During initialization, AI no longer just looks at directories but identifies frontend, backend, client, testing, and other project rules according to the domain initialization process, and writes the results into the project's own .ai-harness/.
2. Added OpenSpec custom schemas, templates, and bootstrap runbooks into the Harness source code. These are general capabilities that evolve with cow-harness/.
3. Refactored the init call chain: first form the project profile, then run openspec init --tools none to initialize OpenSpec in the project root directory, merge schemas, and generate .ai-harness/openspec-context.md.
4. Changed task routing to first select the business sub-project, then create or continue that sub-project's change.

business-project/
├── cow-harness/                 # Git submodule: general framework and initialization process
├── .ai-harness/                 # Long-term profile of this project
│   ├── project.profile.md
│   ├── context-map.md
│   ├── verification.md
│   └── openspec-context.md
├── openspec/                    # This project's own specs and changes
│   ├── changes/
│   ├── specs/
│   └── schemas/cow-harness/
└── .ai-runtime-artifacts/       # Non-OpenSpec execution and verification evidence

7. Why It's Worth Using

In real projects, OpenSpec and omx solve a standard R&D process with higher reliability.

This is also why cow-harness was open-sourced; it is not just an example template, but a portable infrastructure that organizes full-stack project routing, domain initialization, project profiles, OpenSpec changes, and verification gates together.

They might not be difficult in themselves, but you can completely treat cow-harness as the engineering foundation when AI enters a real project.

Project Site	Relying Only on Conversational Promotion	After Integrating OpenSpec and omx
Requirement Change	Requirements, plans, and acceptance mixed in context; over time, only code results remain	Change motivation, behavioral specs, and tasks remain in the same change, reviewable and continuable
Code Review	Mainly looks at diffs; hard to confirm if the originally intended problem was covered	Can check implementation, specs, and verification together
Long Tasks or Multi-person Collaboration	Previous round judgments rely on memory; task handover easily loses focus	Project profile, change, and runtime evidence each have their place; the successor knows what to read first
Multi-task Implementation	Easy to mix parallelizable and strongly dependent tasks; execution results are also hard to reclaim	First clarify dependencies via tasks, then omx advances and reclaims verification according to suitable execution methods

• The most direct value of OpenSpec is turning "I thought we should do this" into "we agreed to achieve this."

  • Much rework is not due to insufficient coding ability, but because requirements, interfaces, data, and UI behaviors were not decomposed to a verifiable granularity before development.
  • Delta specs isolate the change itself, preventing it from being washed away by new conversations.
  • The next time a dispute arises, you can directly return to the change to see the agreed-upon behavior at that time.

• It turns review from result-oriented to closed-loop oriented.

  • With specs and verification records, you can continue to judge: Are there omissions in this requirement? Are boundary scenarios covered?
  • This is especially important for AI development, because models are very good at writing a complete piece of code but do not inherently know which behavior the product truly cares about.

• The value of omx is making the "task list" no longer just a few lines at the end of a document.

  • When a change has been decomposed into multiple tasks, omx can handle task order, parallelization opportunities, and result reclamation within the allowed rules, and pull execution back into the verification loop.

• Putting both together avoids two extremes.

  • Without OpenSpec, omx might execute the wrong direction faster;
  • With only OpenSpec and no execution orchestration, specs easily remain stuck in documents.
  • Harness connects the former to project boundaries and the latter to verification gates, forming a closed loop where "requirements have a source, execution has a basis, and results have evidence."

What is truly worth precipitating is not the file format of a specific framework, but this way of working.

8. Final Words

Harness is not meant to restrict AI, but to allow AI to truly participate in software production.

Admittedly, as large model capabilities grow stronger, constraints like Harness seem less "essential." Today's new generation models can already complete planning, development, modification, and error correction within long contexts; we certainly shouldn't process for the sake of process.

But the value of Harness has never been just about constraining models, but about forcing us to turn experience into methodological processes: how to decompose requirements, how to verify specs, how tests correspond, and who should guard instrumentation, canary releases, deployment, and rollbacks.

Models will indeed become more powerful, but these judgment points will not spontaneously grow. Therefore, we should participate more actively and teach these methods to AI for execution.

Next, the author will continue based on Harness, anchoring a scenario. For example: gradually stringing a product's one-sentence requirement into a verifiable plan, design draft, development tasks, and automated tests; then letting AI continuously observe similar software, extract external requirements, and feed them back into the next iteration.

This is a relatively idealized process, but not fantasy. First let AI understand the project, then ensure every change has specs and every execution has evidence; we are running it from concept into reality.

Follow me to stay tuned; we will continue to run this path through. Open source address: cow-harness