Harness Engineering Capstone Project

By the Syncfusion DevTutorials team · Last updated October 22, 2026

Put the whole course into one harness. It must pass every part of the capstone check: single-session jobs, two five-session builds, the architecture test, the subagent and MCP server, and the harness lint. Then export it for Claude Code, Codex or Cursor and try it in your own repo.

The Capstone Harness

This is the last lesson of the course.

You will build one harness that passes every job you have seen.

Capstone harness = your v1 harness from Part 1, plus the pieces from Part 2 and Part 3, in one set of files.

For example, the same files must pass:

• A bug fix, a new feature and a date rule, on 3 versions each.
• Two builds of 5 features, over 5 sessions each.
• The architecture test, the subagent and the MCP server.
• The harness lint.

Then you export it for your own tool and try it in a real repo.

A Real-World Example

Think about a new restaurant kitchen.

In Part 1, you wrote the recipe card, the safety rules and the "taste before you serve" check. That is enough for one cook and one dish.

Now the kitchen is open all day. A new cook comes in every shift.

You also need:

1. A menu with every dish on it. (This is the feature list.)
2. A shift log for the next cook. (This is progress.md.)
3. A taster who did not cook the dish. (This is the end-to-end check and the evaluator.)
4. Walls between the stations. (This is the architecture test.)
5. A runner and a phone to the supplier. (These are the subagent and the MCP server.)

The capstone puts all of this in one kitchen.

Click the button and open the Sessions & App tab.

• Session 1: the v1 harness builds the first feature.
• Session 2: it does not know what was done.
• The App tab: the agent says done, but most features do not work.

Simple lesson: a harness for one session is not enough for a whole project.

What You Will Learn

In this lesson, you will learn:

1. What goes into the capstone harness, file by file.
2. How the capstone check tests every part.
3. How to join the v1 rules with the long-task lines and keep the file short.
4. How a team workflow matches the harness, from UI design to integration.
5. How to export the harness for your tool and try it in your own repo.

The Capstone Check

Every Part in One Pipeline

Capstone check = one grader that runs every job from the course on your harness.

It has 5 parts, in this order:

1. Single-session jobs: bug fix, feature and date rule, on 3 versions each. That is 9 runs.
2. 5-session builds: two builds of 5 features each.
3. Architecture test: the agent tries to break a layer. The test must catch it and say the fix.
4. Subagent + MCP: logs go to a helper, and API URLs come from a server.
5. Harness lint: no missing file, no broken hook, no rules file that is too long.

Watch the check run as you add one piece at a time:

Step through all five frames.

• Frame 2: the v1 harness passes the first part. It stops at the 5-session builds.
• Frames 3 and 4: each new piece turns one more part green.
• Frame 5: all five parts pass with one set of files.

Start From What Already Works

Do not start from an empty folder.

The v1 harness already passes the single-session jobs. Add new pieces on top of it.

A good order:

1. The long-task pack: init.sh, feature_list.json, progress.md and the rubric.
2. The architecture test.
3. The subagent and the MCP server.

When a check fails, you know which piece broke it.

Simple lesson: one piece at a time tells you what each piece fixed.

Every File, and Where It Came From

The File Tree

Here is the full list for Claude Code. The Export tab changes the names for Codex and Cursor.

CLAUDE.md                          rules: map, done, never lines, long-task lines
.claude/skills/<name>/SKILL.md     the add-status (React) or add-field (.NET) skill
eslint.config.js                   React lint with a message that names the fix
Pricing.Api/BannedSymbols.txt      .NET banned API with a message that names the fix
.claude/settings.json              hooks and permissions
scripts/hooks/*.sh                 the hook scripts
init.sh                            starts the app the same way every session
feature_list.json                  every feature, "passes": false
progress.md                        the handoff between sessions
evaluator/rubric.md                what a separate checker looks at
src/architecture.test.ts           React layer rule (or Pricing.Tests/ArchitectureTests.cs)
.claude/agents/log-searcher.md     the subagent
.mcp.json                          the "orders" MCP server

Each file came from one lesson. Step through the map:

Step through all four frames.

• Frame 1: Part 1 files. A skill, a lint rule, hooks and permissions.
• Frame 2: Part 2 files. The plan, the start script, the handoff and the rubric.
• Frame 3: Part 3 files. The layer test, the subagent and the MCP server.
• Frame 4: the rules file. Each line is marked with the part it came from.

Simple lesson: every file solves one problem you met in the course.

Keep the Rules File a Map

The capstone rules file is the longest one in the course. It must still be short.

Each line must tell the agent what to do, or point to a file in docs/.

Here are the long-task lines you add to it:

## Long tasks
- At the start of every session, run `bash init.sh`, then read progress.md and run `git log --oneline -5`.
- Pick the next item from feature_list.json where "passes" is false. Work on one feature per session.
- Never change a feature's description in feature_list.json. Only flip "passes".
- Flip "passes" to true only after `pnpm test` and `pnpm e2e` both pass.
- Before you stop: run `pnpm test`, commit, and append what you did and what is next to progress.md.
- For any search through logs/, use the log-searcher subagent. Do not read the logs yourself.
- Look up orders API URLs with the orders MCP server. Never guess a URL.

For ASP.NET Core, the commands are dotnet test and dotnet test --filter Category=E2E.

Two lines can say nearly the same thing.

"Run pnpm test before you say you are done" and "Before you stop: run pnpm test" overlap.

The second one also says "commit" and "write progress.md". So both stay.

A vague line like "Write clean code" stays out. The agent cannot act on it.

Simple lesson: every line costs context, so keep only lines the agent can act on.

The Team Workflow

A real team moves through steps: design, plan, build the backend and frontend, test, then join the parts.

Every earlier lesson gave one step its harness part. The capstone puts them in one repo.

Each step is its own session, with one feature. It ends with passing checks and a commit.

Simple lesson: one harness, many small sessions, each one checked.

Lab Exercise: Pass Every Check

Start from the v1 harness. Add:

1. The long-task pack and its rules lines.
2. The e2e command in the "flip passes" line.
3. The architecture test.
4. The log-searcher subagent and the orders MCP server, and the two rules lines that name them.

Click the button, make the changes, then press Check my harness.

• The check: it runs all 5 parts in order.
• On a failure: the message names the part. Fix that part and check again.
• When it all passes: open the Export tab.

Simple lesson: the check tells you which part to fix next.

Export It and Try It for Real

What the Export Contains

Export = the same harness, written in the file layout of one tool.

The Export tab does this for you:

• The rules go into AGENTS.md. Claude Code gets a one-line CLAUDE.md that imports it.
• The hooks go into .claude/settings.json, .codex/hooks.json or .cursor/hooks.json.
• The skill, subagent and MCP files move to each tool's own folder.
• The long-task pack stays the same. Every tool reads plain files.

Then the lab checks that every file is where that tool looks, and that every JSON file is valid.

Here is where each part goes:

Step through all four frames.

• Frame 1: the same harness for Claude Code and Codex. Most files are the same.
• Frames 2 and 3: only the tool's own files move.
• Frame 4: one answer puts your real test command into the rules.

The Export tab gives you one zip per tool, with a README that lists every file.

The Questionnaire for an Existing Project

If you already have a project, the Export tab asks a few questions:

• testCommand: how your project runs its tests.
• lintCommand: how it runs the lint.
• protectedFiles: files the agent must never edit.

Your answers go into the rules, the hook scripts and the deny list.

Try It for Real: a Checklist

The lab is a simulator. A real repo will show you things the lab cannot.

Go through this list in your own project:

1. Copy the export into a branch. Do not put it on main yet.
2. Fix the commands. Run each test, lint and e2e command yourself first.
3. Trust the folders. Codex loads project hooks only after you trust .codex/. Run chmod +x scripts/hooks/*.sh.
4. Write your own feature list. Use real descriptions a test can check. Every item starts at "passes": false.
5. Run one small task. Use a bug fix with a failing test. Watch if the agent reads the rules and runs the checks.
6. Try to break a wall. Ask the agent to skip a test. The hook must stop it.
7. Run two sessions of a long task. Check that session 2 reads progress.md and does not repeat work.
8. Check the vendor docs. File paths and hook events change over time.
9. Start the improvement loop. For each new mistake, pick the layer, add a check, and remove what is no longer needed.

Simple lesson: export to a branch, fix the commands, then try one small task.

TL;DR

1. Capstone harness = the v1 harness plus the long-task pack, the architecture test, the subagent and the MCP server.
2. Capstone check = one grader with 5 parts. It stops at the first part that fails.
3. One piece at a time = add a piece, run the check, then add the next.
4. Rules map = one short file that names every other file.
5. Team workflow = each step from UI design to integration has its own harness part.
6. Export = the same harness in one tool's layout.
7. validateExport = checks every file is in the right place and parses.
8. Questionnaire = puts your real commands and protected files into the export.

Common mistakes

Check Your Understanding

Exercises

These exercises use the real capstone harness and the real export.

Press Check when you are ready. Use Show Hint if you get stuck.

What to Remember

• The capstone harness is the v1 harness plus the long-task pack, the architecture test, the subagent and the MCP server.
• The capstone check has 5 parts. It stops at the first one that fails.
• Add one piece at a time, and check again after each one.
• The rules file stays a short map. Remove duplicate and vague lines.
• Each workflow step has a harness part, from UI design to integration.
• Export for your tool, run validateExport, answer the questionnaire, and try it on a branch.

Further Reading

• Effective harnesses for long-running agents, by Anthropic: the initializer, the feature list, the progress file, and one feature per session.
• Harness engineering: leveraging Codex in an agent-first world, by OpenAI: rules as a map, custom lints, architecture rules and doc gardening.
• Agent Harness Engineering, by Addy Osmani: Agent = Model + Harness, and treating mistakes as permanent signals.
• awesome-harness-engineering, by walkinglabs: a map of the whole field, so you can keep learning.

Next: Cheat Sheet. One page with every file, format and checklist from the course.