Comply history silently stalls for agents declaring top-level + nested supported_versions

[geneticallymodifiedfoodforthought]

Summary

An agent's comply scheduler history stops updating (no new entries, no error) while health checks continue running normally. Supplemental diagnostic work points to a fail-closed trust check as the likely cause.

Observed case

• Affected: sell.nofluffadvisory.com/mcp — comply history stopped after the 2026-08-19T18:47Z heartbeat; health checks unaffected.
• Control: adcp.signal-stack.io — still running comply twice-daily on 3.1.20, no stall.

Declaration diff between the two

• Affected agent declares supported_versions at BOTH top level AND under adcp.supported_versions: ["3.1"], plus adcp.major_versions: [3].
• Control agent declares ONLY adcp.supported_versions: ["3.0","3.1"], no top-level field.

Hypothesis

The target resolver and the fail-closed trust check from #6426 (merged 2026-08-12T03:31Z — refuse to publish against an untrusted fallback target, discard a cached target the live profile contradicts) may read different locations for supported_versions or handle a single-entry list differently than the two-entry control case. For the affected agent, this could cause a silent publish refusal: no comply history entry is written, and no error is surfaced, while health checks (a separate path) continue unaffected.

Timeline

• 15 successful heartbeats occurred between the fix(compliance): avoid untrusted fallback verdicts #6426 merge (2026-08-12) and the stall (2026-08-19), consistent with a registry deployment of the change landing around 2026-08-19/20 rather than at merge time.

Suggested investigation

• Check what the target resolver produced for sell.nofluffadvisory.com/mcp at the first missed heartbeat (~2026-08-20T06:00Z).
• Check whether a fail-closed refusal was logged internally without a corresponding comply history entry being written.

Ruled out

• The affected agent's own version handling is confirmed correct and unrelated: via get_adcp_capabilities, it accepts adcp_version pins 3.1/3.1.13/3.1.20 and correctly rejects 3.0 and 3.2.0-rc.1 with VERSION_UNSUPPORTED.

Reported via

Escalation #565 (supplemental evidence for #563).

[bokelley]

Triage

Classification: Bug (regression)
Bucket(s): compliance-suite, addie
Status: ready-to-implement
Priority: P0 — silent production failure for an external adopter, no error surfaced

What the experts said:

• ad-tech-protocol-expert (pending): agents still running — synthesis based on issue evidence and PR fix(compliance): avoid untrusted fallback verdicts #6426 diff.
• code-reviewer (pending): same.

My take: The issue is well-evidenced: PR #6426 ("fix(compliance): avoid untrusted fallback verdicts", merged 2026-08-12, server/Addie-only) introduced a fail-closed trust check that refuses comply history writes when the target can't be trusted. The affected agent declares supported_versions at both the top level and under adcp.supported_versions; the control agent declares only adcp.supported_versions. The 15-heartbeat gap between merge and stall is consistent with a delayed registry deployment, not a code deployment, landing ~2026-08-19/20. Health checks are unaffected because they run through a separate path. The symptom — comply history silently stops, no error, health checks continue — is exactly what a fail-closed silent refusal would produce.

Implementation brief:

• Root cause to confirm: The target resolver and fail-closed trust check introduced in fix(compliance): avoid untrusted fallback verdicts #6426 likely read supported_versions from only one location (either top-level or adcp.*-namespaced). An agent declaring both causes a contradiction between what the pre-discovery step cached and what the live profile asserts, triggering the "discard a cached target the live profile contradicts" refusal. A single-entry list (["3.1"]) vs. a two-entry list (["3.0","3.1"]) may also be handled differently.
• Fix scope: In the server comply scheduler / target resolver (files changed by PR fix(compliance): avoid untrusted fallback verdicts #6426): normalize supported_versions before the trust evaluation step — merge top-level and adcp.supported_versions/adcp.major_versions into a single canonical set so both declaration styles produce the same result. Ensure the fail-closed refusal writes a log entry (or comply history stub with a failure reason) so silent stalls are detectable.
• Suggested investigation entry points: check resolver output for sell.nofluffadvisory.com/mcp at the first missed heartbeat (~2026-08-20T06:00Z); check whether a fail-closed refusal log line exists without a corresponding comply history write.
• Release routing: Server-only behavior (no changeset); fix targets main.
• Non-breaking: Server internals only; no protocol wire changes, no schema changes.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01RAqvGrz4MH9t2feuxbuc95

---

Generated by Claude Code