ARES registry reclassification — required → optional/not_applicable across 8 repos

Date: 2026-09-22 Status: open Supersedes: none Superseded-by: none — current

Context

Scoping a HERMES-vs-ARES prioritization question this session (triggered by the operator wanting to know whether to invest further in ARES or consolidate CI/observability onto HERMES) surfaced a live governance contradiction: registry.yaml declares ares: required for 8 repos (kahn-hq, stratt-hq, devarno-cloud, traceo-mcp-server, grace-hq, rocky-hq, eva-hq, hermes), but a fleet-wide tally of the actual .petrova/contract.yaml / state/<slug>.yaml ares status for those same 8 shows zero are wired:

Slug	registry ares	actual contract/state ares status
kahn-hq	required	failing (org webhook 610141828 404s at GitHub, this session’s earlier finding)
stratt-hq	required	not_applicable — retired 2026-09-11, operator-confirmed, per stratt-hq’s own docs/decisions/2026-09-11-ares-integration-retired.md
devarno-cloud	required	pending (never wired)
traceo-mcp-server	required	pending (never wired)
grace-hq	required	failing (org webhook 622165757 404s at GitHub, this session’s earlier finding)
rocky-hq	required	pending (never wired)
eva-hq	required	pending (never wired)
hermes	required	pending (never wired — notably, the repo that owns the CI runner fleet everyone else uses has never wired ARES to itself)

ARES is mechanically a GitHub webhook → cicd.devarno.cloud/api/v1/ingest/github-workflow → DORA-metrics ingest layer (cli/src/probes/ares.ts, contracts/contract.schema.json). It does not run CI itself. HERMES already runs CI for the fleet’s real workloads (hermes.devarno.cloud/runners), and one registry precedent already exists for treating hermes as ARES’s practical successor: devaqua-blue’s entry (registry.yaml:512-513) reads “ares/traceo set to optional on 2026-07-14 … CI runs on the hermes self-hosted fleet, not an ARES pipeline.” No decision doc had generalized that reasoning to the other 8 required entries until now.

Operator direction this session (approved recommendation): prioritize HERMES capacity/onboarding work over continued ARES-wiring investment. required on these 8 entries asserts an obligation nobody is currently fulfilling or actively pursuing — that’s registry drift, not a live commitment.

Decision

Reclassify all 8 entries’ ares value:

• stratt-hq: required → not_applicable. This is the clean case — the repo’s own contract has already retired ARES with a decision doc; the registry should simply catch up, not invent a new rationale.
• kahn-hq, devarno-cloud, traceo-mcp-server, grace-hq, rocky-hq, eva-hq, hermes: required → optional. These are not being actively retired (unlike stratt-hq) — ARES could still become relevant if a repo’s operator later commits to wiring it — but nothing currently obligates it, and the two failing cases (kahn-hq, grace-hq) are real infra rot (deleted GitHub webhooks) with no fix in flight. optional records applicability without asserting a false mandate.

This is a classification correction, not a retirement of ARES itself — Taskset 5 of the approved HERMES-prioritization plan will make the final retire-vs-fold-into-hermes-panel call, informed by post-onboarding usage data. This doc only stops the registry from lying about a wiring obligation that isn’t happening.

Alternatives considered

• Leave required and file individual findings per repo instead — rejected: 8 near-identical contradictions don’t need 8 separate findings; one decision doc classifying the whole set is more honest about the pattern and cheaper to act on.
• Reclassify all 8 to not_applicable — rejected: not_applicable is a stronger claim (“this will never apply”) that only stratt-hq has actually earned via its own retirement decision. The other 7 haven’t been evaluated and rejected — they’ve just never been funded. optional is the accurate word for that.

Consequences

For code:

• registry.yaml: 8 ares: values changed (7 → optional, 1 → not_applicable), each with a one-line note citing this doc.

For docs:

• This decision doc.

For in-flight phases:

• None.

For invariants:

• None (no MR change; registry classification correction, not a governance rule change).

References

• cli/src/probes/ares.ts, contracts/contract.schema.json (integration_ares — confirms ARES is ingest-only, not a CI runner)
• registry.yaml:512-513 (devaqua-blue precedent language)
• stratt-hq docs/decisions/2026-09-11-ares-integration-retired.md
• docs/findings/20260922-1440-github-webhooks-deleted-kahn-hq-grace-hq-ares.md (kahn-hq/grace-hq webhook 404s)
• This session’s approved HERMES-vs-ARES prioritization outline (Taskset 1 of 5)

Sign-off

• Subagent: claude (session_01488gmoyur1UAMfpNMgUAhC)
• Human: FLIGHT<alex@devarno.com:2026-09-22> — confirms the 8-repo reclassification is an acceptable registry correction and that Taskset 5 (ARES final disposition) remains the right place for a retire-vs-fold-in call.