docs(triage): record the escalation branch's new output for the diagram
The chart draws the human path as a dead end for the automation. It now has a second output - a remediation Hermes proposes but cannot request - and the arrow has to terminate at a person rather than at the action registry, or the drawing would imply the model can grow its own capabilities. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
df41cde9f8
commit
292999118b
@ -132,3 +132,35 @@ Smaller corrections to the same nodes:
|
||||
once the `junit` plugin is live. Note the plugin was never blocked on a core
|
||||
upgrade as previously recorded: `junit 1369.v15da_00283f06` runs on core
|
||||
2.528.3, only the latest release requires 2.533.
|
||||
|
||||
## Third pass: the escalation branch now has an output
|
||||
|
||||
The chart shows the human path as a dead end for the automation: no action
|
||||
fits, an issue is filed, and Ariadne learns nothing. That is no longer the
|
||||
whole story.
|
||||
|
||||
**A diagnosis may now propose a remediation Ariadne cannot perform.** When no
|
||||
allowlisted action fits, Hermes may return `suggested_remediation` naming the
|
||||
action it believes would work and the evidence that should be required before
|
||||
running it. So the human path forks: an escalation always files an issue, and
|
||||
some escalations also carry a proposal. The chart should show that second
|
||||
output leaving the escalation node, labelled as a proposal for a maintainer
|
||||
rather than as anything executable.
|
||||
|
||||
**The proposal must be drawn outside the trust boundary.** It is prose in an
|
||||
issue and a field in an audit event. No gate reads it; an id that is not
|
||||
already in the allowlist still fails `action_not_allowlisted`. If the boundary
|
||||
is drawn as "Hermes advises, Ariadne acts", the proposal sits firmly on the
|
||||
advisory side, and the arrow from it should terminate at a person, not at the
|
||||
Action registry. The registry only grows when a human deploys a new action.
|
||||
|
||||
**The three allowlisted actions are now four.** `action_registry` should list
|
||||
`repair_demo_fixture`, `retry_transient_infra`, `reclaim_workspace_storage`
|
||||
and `clear_stuck_agent_pods`, each reachable only from its own classification.
|
||||
|
||||
Two of those are worth calling out on the chart as separate paths rather than
|
||||
folding them into a generic retry, because the distinction is the point:
|
||||
`workspace_storage_exhausted` reclaims stale workspace storage *before*
|
||||
rebuilding, since a plain rebuild lands on the same full volume; and
|
||||
`jenkins_agent_provisioning_failure` clears finished agent pods first, since a
|
||||
retry otherwise queues behind the same stuck pool.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user