Starlightdocs

Agent harness contract (operator)

Internal operator contract — how an agent harness claims a lane, verifies work, passes pr-gate, and records handovers.

LiveChecked against starlight-agent-config/core/doctrine/SYSTEM-SPINE.md, tools/pr-gate.mjs, tools/lib/harness-identity.mjs
MCP endpoint/api/mcp

Operator reference: This page covers the internal multi-harness contract enforced by starlight-agent-config and tools/pr-gate.mjs. For public CLI usage across coding agents, see Work from any harness.

The four invariants every harness inherits

  1. Isolated lane. A harness works on its own branch (agent/<harness>/<scope> or codex/<scope>) and worktree, never committing into another agent's live checkout.
  2. Managed-block config. Harness instructions (~/.claude/CLAUDE.md, ~/.codex/AGENTS.md, ~/.gemini/GEMINI.md, ~/.grok/AGENTS.md) are compiled from starlight-agent-config/core/doctrine/SYSTEM-SPINE.md using marker-bounded blocks.
  3. Maker ≠ checker (pr-gate.mjs). The harness that authored a branch cannot sign off on its own PR. A second harness (claude, codex, antigravity, gemini, grok, hermes) must verify the exact commit SHA (starlight-signoff: harness=<H> verdict=pass sha=<SHA>) before pr-gate.mjs merge will execute.
  4. Durable handover. Completed slices record their session summary and next prompt in frankxai/agentic-ops-hub (ops/sessions/YYYY-MM-DD.md and node scripts/handover.mjs index).

Human gates (fail closed)

Per Doctrine 0 in SYSTEM-SPINE.md, agents build, test, verify, and stage autonomously, but money, pricing, credentials, DNS records, repository visibility, and external customer sends always require explicit human execution.

The system map (operator)

Internal operator architecture — the machine, repo, and memory planes across the Starlight estate.

On this page

The four invariants every harness inheritsHuman gates (fail closed)