Harness Engineering Lifecycle

Evolve a proven repo-local contract into a generalized, high-performance, declarative harness system, then safely dogfood those changes across a producer-consumer repository boundary. Start here only after the target repo has a steward.yaml contract and at least an H2 smoke proof; use mcp-harness-repo-maintainer before that.

When to use

• Evolving custom validation scripts into a central linter engine.
• Extending steward CLI features for large polyrepos.
• Testing a local CLI/harness build against a sibling repository to catch path-resolution crashes or integration friction.
• Turning repeated local benchmark/probe findings into a reusable harness feature.

When not to use

• Initial steward.yaml adoption or first quick probe in one repo — use mcp-harness-repo-maintainer.
• Skill creation, registry updates, or marketplace packaging — use skill-authoring-lifecycle or plugin-marketplace-setup.
• Product-specific diagnostics before a cold-start contract exists — first add a bounded action, probe, and scenario in the target repo.

Part 1: The Cascading Agent Surface (Architecture & Generalization)