ares wire rollout

ARES Wiring Rollout Runbook

Spec: docs/superpowers/specs/2026-05-01-petrova-ares-wire-spec.md Plan: docs/superpowers/plans/2026-05-01-petrova-ares-wire-plan.md Decision: docs/decisions/2026-05-01-ares-wire-adoption.md Prompt: core/playbook/prompts/06-ares-wire.md

After the sub-project B PR merges, the operator wires the 6 required repos in three waves. This runbook codifies the order, the gate between phases, and the per-repo decision-doc template.

Waves

Phase 1 — strictly serial (one at a time, observe between)

Wave	Repo	Why this slot
1	traceo-mcp-server	smallest blast radius; permissive profile; lowest CI traffic — catches procedure bugs cheaply
2	grace-hq	mid-traffic experimental; first cross-profile test (permissive → standard)

After wave 2, run a gate review:

• Did the procedure surface a missing rollback path, an unsafe sandbox interaction, a hard-coded value that needed to be a placeholder?
• If yes: fix core/playbook/prompts/06-ares-wire.md first (submodule PR + parent pointer bump), then proceed.
• If no: proceed to Phase 2.

Phase 2 — pipelined (all three may be in flight)

Wave	Repo
3a	choco-hq
3b	stratt-hq
3c	devarno-cloud
3d	kahn-hq

Pipelining rule: consumer-repo PRs (CI inline + decision doc + deployment doc) may be in flight in parallel. PRs against devarno-cloud/ares (ecosystem registry, allure registry) are serialised — only one open at a time, since they touch the same files and the rebase storm isn’t worth the parallelism.

Per-wave checklist

For each repo, in order:

1. Open Claude Code in the consumer repo.
2. Paste core/playbook/prompts/06-ares-wire.md (PETROVA submodule pointer captures the canonical version).
3. Run tasksets 0 (preflight) → 1–5 (audit through end-to-end smoke) → 8 (docs) → 9 (contract flip).
4. Skip taskset 6 unless the repo is airlock-handoff-gated AND on the operator’s Verification matrix.
5. Skip taskset 7 unless the repo emits KAHN-grammar transitions.
6. Confirm the dashboard row appears at cicd.devarno.cloud/history/.
7. Confirm petrova doctor --slug=<repo> reports ares: ok (run from petrova-codes worktree).
8. Merge the consumer-repo PR.

Per-repo decision-doc template

Copy this into the consumer repo as docs/decisions/YYYY-MM-DD-wire-ares-<repo>.md at taskset 8 of the prompt:

---
title: Wire <repo> to ARES
date: YYYY-MM-DD
status: ratified
mr_compliance: [MR-1, MR-7]
ranks_under: <repo's north-star intent doc>
---

## Context

Per `docs/runbooks/ares-wire-rollout.md` in petrova-codes, this repo is in wave <N>. Sub-project B's adoption decision (petrova-codes:`docs/decisions/2026-05-01-ares-wire-adoption.md`) ratified `integrations_applicability.ares: required` for this repo on 2026-05-01.

## Decision

Authorise the wiring per `core/playbook/prompts/06-ares-wire.md` (taskset-ladder 0 + 1–5 + 8 + 9). Skipping tasksets <list, with reasons>. Webhook scope: `<org|repo>`. Webhook id will be recorded in `.petrova/contract.yaml.integrations.ares.evidence.org_webhook_id`.

Rollback: `gh api -X DELETE <scope>/hooks/<id>`. Documented in `docs/deployment/ares-integration.md`.

## Consequences

- This repo's CI completions land on `cicd.devarno.cloud`.
- Secret rotation: `HUBBLE_EVENTS_INGEST_TOKEN` mirrors hubble's `EVENTS_INGEST_TOKEN`; webhook secret rotates whenever the Railway service rotates `GITHUB_WEBHOOK_SECRET` (operator-tracked, ≤90d).
- `.petrova/contract.yaml.integrations.ares.status` flips from `pending` to `wired` in this PR.
- petrova-codes's next `petrova doctor` sweep observes the wiring via the real probe and the dashboard updates accordingly.

Rollback (whole programme)

If a wave surfaces an unfixable issue, the rollback shape is:

1. Revert .petrova/contract.yaml.integrations.ares to status: pending in the affected consumer repo (PR).
2. Delete the webhook: gh api -X DELETE <scope>/hooks/<id>.
3. Open a new dated decision doc explaining what failed; link from petrova-codes sub-project B’s decision doc.
4. Continue the next wave only after the procedure is fixed.

The 6 required declarations in registry.yaml are NOT rolled back — governance intent survives transient wiring failures.

Validation between hops

After each wave:

• Consumer repo: petrova doctor --slug=<repo> reports ares: ok AND a real workflow_run delivery is visible at cicd.devarno.cloud/history/.
• petrova-codes: state file at state/<repo>.yaml shows current_status.ares: ok after the next sweep.

If current_status.ares == "degraded", inspect the latest probe_history entry — usually a stale delivery (>7d) on a low-traffic repo. Trigger a manual workflow_dispatch to refresh.

Cross-references

• Sub-project A integration-spine rollout: docs/runbooks/integration-spine-rollout.md (the spine that this wiring populates)
• Submodule update mechanics: docs/runbooks/submodule-bump.md (when the prompt itself is updated post-gate-review)
• Onboarding new repos: docs/runbooks/onboard-repo.md (each new repo onboarded should be assigned integrations_applicability.ares at onboard time, not retroactively)