autonomy-init

Bootstrap the autonomy loop for this repository.

1. Config. If autonomy.config.json ALREADY exists, you are upgrading, not initializing: run node ${CLAUDE_PLUGIN_ROOT}/hooks/migrate-config.mjs to top up any missing knobs (idempotent, never overwrites a value you set), report what it added, and SKIP to step 2. Do NOT overwrite an existing config. Otherwise, if autonomy.config.json does not exist at the repo root, copy it from the plugin's autonomy.config.example.json and fill the knobs by inspecting the repo: detect the package manager + exact test/build/lint commands; ask me (or infer + confirm) the workBranch, prodBranch, the frozen invariant (what must stay byte-identical: golden fixtures? snapshot tests? an API contract?), and the protectedPaths. Coverage drift gate (offer it, do not assume): check whether a coverage tool is available (c8, nyc, jest, vitest, or node --test --experimental-test-coverage); if one is, ask me whether to turn on drift protection, and on a yes set gate.coverage to a command that emits an Istanbul coverage-summary.json (for example c8 --reporter=json-summary --reporter=json <the test command>), then run node ${CLAUDE_PLUGIN_ROOT}/hooks/coverage-ratchet.mjs once to seed .autonomy-coverage.json at the current coverage. If no coverage tool is present, leave gate.coverage empty and tell me why. Then, if a coverage tool IS present, ask about the FOURTH gate, patch coverage: off, 80 (standard), or 100 (every changed line of a wave must be tested). On 80 or 100 set gate.patchTarget to that number and make sure the coverage command emits coverage-final.json (the --reporter=json above); on off leave gate.patchTarget at 0. Explain that patch coverage scores ONLY the lines a wave changes, so it works regardless of the repo's overall coverage level, even a low-coverage repo can require every new line to be tested. Leave models and loopIntervalSec at their defaults unless I say otherwise. Roles (v0.8 presence-to-trigger): the example config already ships the à la carte roles shape (builder: auto, reviewer: required, planner: auto, researcher: auto), so do NOT ask me to flip flags. Tell me the loop is presence-driven: builder+reviewer are the always-on core, and I add the Planner simply by opening a /autonomy-loop:planner terminal (the recommended 3-terminal shape), and the Researcher by also opening /autonomy-loop:researcher (the 4-terminal power mode). The only reason to edit roles is to set one to off (a veto). Leave the à la carte shape as copied.
2. Server-side prod protection (v0.8 provision-or-refuse: PROVISION the no-bypass ruleset). The gate-guard hook is a local tripwire, not a sandbox; the real backstop is server-side branch protection on prodBranch, and it is the only unattended-grade independence (the SessionStart preflight hooks/preflight.mjs decidePreflight REFUSES the auto-promotion path while gate.requireProdProtection is true and prod is unprotected). If gh is missing, you are not authenticated (gh auth status fails), or origin is not a github.com remote, SKIP the automated path: print a clear warning that prod protection could NOT be provisioned, show the manual steps, and continue. Otherwise check effective protection (ruleset-aware, no admin needed): gh api "repos/{owner}/{repo}/rules/branches/{prodBranch}" --jq 'length'. If greater than 0, report it is already protected and move on. If 0, tell me plainly that prod is unprotected and the gate is only a local tripwire, then ASK whether to provision the no-bypass ruleset. On yes, provision it from the plugin template ${CLAUDE_PLUGIN_ROOT}/prod-ruleset.json: substitute {prodBranch} with the configured prodBranch and STRIP every _comment* key (GitHub schema-validates the rule and parameter objects, so comment keys must not be POSTed), write the result to a temp prod-ruleset.json, then gh api --method POST -H "X-GitHub-Api-Version: 2022-11-28" "repos/{owner}/{repo}/rulesets" --input <that file>. The template is enforcement:"active" with an EMPTY bypass_actors:[] (so it binds EVERYONE including repo admins, and the agent token is not on it, so the agent credential cannot reach prodBranch directly) and rules pull_request (required_approving_review_count >= 1, require_last_push_approval true) + non_fast_forward + deletion. CRITICAL: this uses the pull_request rule, NOT "Restrict updates" (the update rule). Restrict-updates would block the PR-merge fast-forward for non-bypass actors and break the promote-by-PR flow; pull_request gates the merge behind a required review without blocking the merge itself. This is the exact shape the preflight probeProdProtected checks for (it requires BOTH pull_request and non_fast_forward), so once provisioned the preflight's prodUnprotected refusal clears. Provisioning needs repo ADMIN; on any failure (403 / not admin / error) do NOT abort: print the exact command plus a warning and continue. This step NEVER stops setup.