Skip to content
PETROVA

ARES disposition — formally deprecated, plumbing stays dormant

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

Context

Section titled “Context”

Taskset 5 of the approved HERMES-vs-ARES prioritization plan (this session): make the final retire-vs-fold-into-hermes-panel call on ARES, informed by the fleet data gathered across Tasksets 1–4.

Taskset 1 already fixed the acute governance problem: registry.yaml no longer claims ares: required against 0/8 real wiring (docs/decisions/2026-09-22-ares-registry-reclassification.md). What Taskset 5 was scoped to answer is what happens next — does ARES get actively retired (code removal), actively replaced (its DORA-metrics function rebuilt inside hermes-panel), or something else.

The original taskset outline offered two active-change options. Neither held up against what the data actually shows:

  • ARES imposes no ongoing cost. It is a passive ingest endpoint (cicd.devarno.cloud/api/v1/ingest/github-workflow) plus a schema and a probe check. No repo currently sends it traffic (0/8 previously-required repos wired), so it consumes no resources, blocks nothing, and generates no maintenance burden beyond the schema/probe code already sitting in contracts/contract.schema.json and cli/src/probes/ares.ts.
  • Full code removal is real, avoidable risk. Deleting the probe, schema entries, and the integrations_applicability.ares field across all 36 registry entries touches every consumer repo’s contract validation surface, cli/tests/registry.test.ts’s ares assertions, and any repo that has explicitly and correctly declared ares: not_applicable with a cited rationale (e.g. choco-hq, stratt-hq) — those records are legitimate governance history, not drift to be erased. Removing the field would delete that history for no operational gain, since the field costs nothing to leave in place now that it no longer lies.
  • Building DORA metrics into hermes-panel is real, out-of-proportion new feature work. hermes-panel is a different codebase/stack (SvelteKit operator UI) this session has only observed via its dashboard, not implemented against. Scoping and building a new metrics feature there — schema, queries against job history, a UI page — is a legitimate future idea, not something to force through as a side effect of a petrova-codes governance cleanup taskset.

Decision

Section titled “Decision”

Formally deprecate ARES. Leave its plumbing in place, dormant, undisturbed.

  • No further investment in wiring ARES for any repo. The optional/not_applicable reclassification from Taskset 1 stands as the honest final state — no repo should move back toward required without a fresh, specific decision doc justifying it.
  • cli/src/probes/ares.ts, contracts/contract.schema.json’s integration_ares block, and registry.yaml’s integrations_applicability.ares field are not removed. They cost nothing to keep and deleting them would erase legitimate governance history (the repos that correctly declared not_applicable with cited rationale) for no operational benefit.
  • DORA-metrics-via-hermes-panel is recorded here as a candidate idea, not commissioned work. If a hermes maintainer wants deployment-frequency/lead-time/MTTR/change-failure-rate surfaced from hermes-panel’s own job history (which already has the primitives — job success/failure/timestamps per repo), that is hermes-panel’s own feature to scope and build, on its own timeline, in its own repo. This decision does not authorize or schedule that work.
  • devarno-cloud/ares (the standalone ARES dashboard/service repo) is left as-is — not touched, not scheduled for retirement, not invested in further. It continues to exist and can still be pointed at manually if a repo operator ever wants to wire it for a specific reason.

Alternatives considered

Section titled “Alternatives considered”
  • Full code removal from petrova-codes — rejected: real risk (touches every consumer repo’s contract validation, deletes legitimate not_applicable governance history) for zero operational gain, since dormant plumbing costs nothing.
  • Build the hermes-panel DORA fold-in now — rejected: substantial new-feature engineering in a different repo/stack, out of proportion to what this taskset was scoped to decide. A future hermes-team decision, not a petrova-codes governance cleanup’s side effect.

Consequences

Section titled “Consequences”

For code:

  • None. No files changed by this decision — that is the decision.

For docs:

  • This decision doc closes the retire-vs-fold-in question the Taskset 1 reclassification doc deferred.

For in-flight phases:

  • None.

For invariants:

  • None (no MR change).

References

Section titled “References”
  • docs/decisions/2026-09-22-ares-registry-reclassification.md (Taskset 1 — fixed the registry lie this doc’s context section relies on)
  • docs/findings/20260922-2105-hermes-runner-cap-public-vs-paid.md (Taskset 2)
  • hermes/docs/decisions/2026-07-26-eu-1-cost-and-instrumentation.md (Taskset 3 — resolved, real capacity headroom confirmed)
  • This session’s approved HERMES-vs-ARES prioritization outline (Taskset 5 of 5, final)

Sign-off

Section titled “Sign-off”
  • Subagent: claude (session_01488gmoyur1UAMfpNMgUAhC)
  • Human: FLIGHT<alex@devarno.com:2026-09-22> — confirms ARES stays formally deprecated and dormant (not removed, not actively replaced), and that any future DORA-metrics work in hermes-panel is a separate, independently-scoped decision.