backend-launcher

Backend Launcher

"Same syringe, different supes. The dispatcher doesn't care who's holding it — it cares what comes back."

A reusable sub-skill (a sibling directory under skills/, pulled in by prose "read this file and apply"). It exposes one contract. The orchestrator hands a job_spec to whichever adapter the manifest's backend names, and gets back a canonical job_result — identical shape across every backend. Enforcement is uniform because it lives in the caller's scope gate, not in the backend.

There is no skill-import API: an adapter is a sibling doc (adapter-codex.md, adapter-claude.md, adapter-antigravity.md) that says "read the contract in this file, then do the backend-specific steps." Adapters are built by downstream tasks; this file is the contract they implement.

---

The contract

INPUT — job_spec

{
  "backend": "codex",                  // claude | codex | antigravity | cursor | devin | opencode
  "prompt": "…",                       // the worker prompt (opens with the planner/executor lock, below)
  "tier": "standard",                  // deep | standard | light — the routing INTENT (stable across model churn)
  "effort": "medium",                  // low | medium | high | xhigh — orthogonal reasoning-effort hint (optional; xhigh is codex-only)
  "model": "gpt-5.6-sol",                  // OPTIONAL explicit override; when present it skips resolution.
                                       //   execution-layer data — NEVER appears in any frontmatter
  "cwd": "/repo",                      // absolute repo root
  "write_allowed": ["src/features/sequences/components/**"],
  "read_only": false,                  // true ⇒ sandbox read-only, no merge
  "timeout_sec": 900,
  "network": false,                    // maps to sandbox_workspace_write.network_access
  "output_schema": "/abs/schemas/job_result.schema.json"  // optional
}

tier + effort + model — intent over hardcoded strings. A job_spec carries the routing intent (tier, and optional effort), not a hardcoded model. The concrete model is resolved before dispatch by scripts/compound-v-resolve-model.py from (backend, tier, effort, config) — so the plugin survives model churn (refresh the config models map via /v:models, never the call sites). A job MUST carry model OR tier; an explicit model override skips resolution and always wins. effort is passed through to the worker: for codex it becomes -c model_reasoning_effort=<effort>; for claude it is advisory (the Task path has no separate effort flag). xhigh is valid iff backend: codex; every other backend rejects it with a clear error naming the rule (use high instead) — the resolver and the manifest validator both enforce this. tier/effort/model are execution-layer values and never appear in any frontmatter. See skills/compound-v/execution-manifest.md for the tier vocabulary, the config models map shape, and the reviewer ⇒ deep rule.