9f24f8d999
All checks were successful
Tests / Declarative: Post Actions passed: 1275
Every action in the allowlist got there because someone hit the failure by hand, recognised the pattern, and wired a job for it. That loop only closes if a person happens to read enough issues to notice the same failure recurring, so a failure nobody reviews twice never earns an action. Until now a diagnosis that fit nothing could only say a human was needed; it could not say what the human should build. An optional suggested_remediation field closes the other half of the loop. When nothing in the allowlist fits, Hermes may name the remediation it believes would work and the evidence that should be required before running it is safe. It lands in the incident issue under a heading that states plainly the remediation does not exist and was not performed, and in the audit event, where the same proposal recurring across unrelated incidents is the evidence that building it is worth the effort. The field is inert by construction. No gate reads it, and an id that is not already allowlisted still fails action_not_allowlisted exactly as before - naming a remediation and being granted one stay different things, and only the second needs a human to change a deployment. It is rejected outright alongside a requested action: the field reports that nothing fit, so something fitting contradicts it, and allowing both would invite a rationale to be attached to a request the gates must judge on evidence alone. The key is optional rather than required so a response written before today still validates unchanged, and unknown keys are still refused. Also names reclaim_workspace_storage, clear_stuck_agent_pods and abort_hung_build in KNOWN_ACTION_LABELS. They were reporting as "unknown" in metrics on any deployment that had not enabled them, which is the one case where you most want to see the real name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>