Service Agent Manifest

Status: machine-readable dispatch manifest for service-owner agents.

The canonical service-agent rows live in service-agent-manifest.json. The manifest is intentionally compact and is used by scripts/test/agent-dispatch-readiness-coverage.sh to verify that the human-facing roster, wave board, workflow matrix, spawn packets, task packs, runtime manifest, and service responsibility matrix stay aligned.

Completion/proof state lives separately in service-agent-proof-ledger.json and Service Agent Proof Ledger. The manifest answers which worker should be spawned; the proof ledger records what evidence is still required before a worker slice can be called complete.

What It Covers

• SVC-001 through SVC-023 canonical service-owner packets.
• Wave number, canonical service name, implementation owner, deployable runtime service when applicable, task pack, dispatch type, and first verification command.
• Runtime-adapter handling for formula-docx-service.
• Retirement and alias notes for user-service, auth-service, and entitlement-service.

Rules

• Do not add auth-service to the manifest; identity/access work belongs to iam-service.
• Do not add entitlement-service as a service row; entitlement work belongs to usage-service unless an ADR renames the canonical service.
• Do not add services/formula-docx-service; the current packet points to the external Go Formula runtime behind docx-import-service.
• If a new canonical service is approved later, update the manifest, service responsibility matrix, dispatch roster, wave board, workflow matrix, task pack, VitePress links, runtime manifests, and coverage scripts in the same orchestrator slice.