connecting-orcalisted

# Connecting-Orca — from "harness vendored" to "autonomous delivery running" The harness being installed in a repo does **not** mean anything is delivering. Two more layers have to exist: an Orca runtime that dispatches, and a queue that tells it what to dispatch. This skill installs those, in order, and does not finish until a real issue has moved through them. **Orca dispatches; the repo's vendored `.claude/` executes.** Nothing here installs a second delivery engine — the pipeline is already in the repo. See `core/orca/README.md` in the harness repo. **Announce at start (pt-br):** "Ligando este projeto no Orca — vou do diagnóstico até uma issue canária entregue." All identifiers and commands stay in English; every message to the operator is **pt-br, product-language**. --- ## Mode **LOCAL/interactive.** Phases 1–5 pair runtimes, write config and change a crontab — an autonomous session must not do that on its own. In a **HEADLESS** session, run **Phase 0 only** and report the diagnosis; never mutate. --- ## Phase 0 — Can this session reach the VPS at all? (always first) Three failures read as *"I have no access"* and are not. Stacked, they produce a confident wrong conclusion, and an agent that reaches it stops and hands the work back to the operator — while another session on the same machine, in the same minute, operates the VPS fine. Run the deterministic diagnosis instead of concluding: ```bash node .claude/skills/connecting-orca/references/orca-doctor.mjs