The Operating Harness for AI Coding Agents
Context, boundaries, verification, and promotion for Claude Code, Codex, Cursor, Cline, OpenCode, and more.
Tags: agent-runtime context-pack judge-loop release-gates worktrees mcp
AI coding agents are already strong at generating code. What they still lack is execution discipline:
- what context to load
- what files they are allowed to touch
- how the outcome is verified
- when a patch should actually be promoted
Salacia turns those concerns into runtime primitives.
It sits between your repository and your agent run, compiles a machine-readable program for the task, builds a bounded ContextPack, executes inside an isolated workspace, verifies the result, and emits an auditable accept / reject / blocked decision.
This is not just “better prompting.” It is a governable way to run coding agents inside real repositories.
npx salacia init
salacia design
salacia runInspect the result:
salacia judge
salacia trace
Every run gets a repository-aware ContextPack:
- ranked repo map
- working set and snippets
- recent run history
- explicit guardrails
Instead of forcing the agent to rediscover your codebase from scratch, Salacia gives it a bounded, high-signal map.
Every run ends in a hard outcome:
acceptrejectblocked
Verification, patch surface, and policy all feed into the final decision.
Runtime, eval, and release policy share the same evidence shape:
- inputs
- context evidence
- verification results
- judge decision
- promotion decision
- evidence refs
That means product runs, benchmarks, and release gates finally speak the same language.
Salacia is not another coding agent.
It is the harness/runtime layer that makes coding agents usable inside real engineering workflows:
program.mddeclares the goal, mutable surface, verification, and promotion policy.designcompiles that into a machine-readable blueprint.runbuilds aContextPack, dispatches the agent in a bounded workspace, and collects the candidate patch.judgedecides whether the result should be accepted, rejected, or blocked.traceexposes the event log, artifacts, and evidence behind that decision.
Drop Salacia in front of the agent you already use and stop letting every run start from zero.
Use Salacia as the execution layer beneath your coding agent, IDE bridge, or internal developer workflow.
Reuse the same runtime evidence model for experiments, quality gates, and production policy.
program.md
-> blueprint
-> context pack
-> isolated run
-> verification
-> judge
-> promote / reject / block
Artifacts produced by a run:
program.md.salacia/blueprint.json.salacia/context/<run-id>.json.salacia/runs/<run-id>/events.ndjson.salacia/runs/<run-id>/summary.json.salacia/runs/<run-id>/judge.json
Salacia does not compete with Claude Code, Codex, Cursor, or other agent products. It makes them more governable inside a real repository.
IDE bridges are supported, but the core abstraction is the harness:
- control plane
- context plane
- judge loop
- evidence model
Benchmarks and superiority audits are first-class, but they reuse the same runtime evidence model instead of living in a separate reporting universe.
salacia init
salacia design
salacia run [--adapter <name>]
salacia judge [--run <id>]
salacia trace [--run <id>]
salacia eval <action>Legacy v0.1 commands such as plan, execute, and validate remain available only as transitional surfaces.
- Claude Code
- Codex
- OpenCode
- Cursor
- Cline
- VS Code bridges
- Antigravity
Salacia v0.2 is organized around four planes:
control plane:program.md-> blueprintcontext plane: repo map, working set, history, guardrailsharness plane: run session, verification, judge, promotioneval plane: benchmark, superiority, release gate consumption
Apache-2.0