The unwired heal (V-B-A'd at dev, 2026-06-27)
ContainerHealthDiagnosisService routes exhaustion + contention → actionClass: throttle-shed (L516–528). But the recovery actuator cannot execute it:
RecoveryActuatorService.executeTargetAction (L501–515) has no throttle-shed branch — only warm-provider, restart-by-target-kind (compose-service / supervised-task), and pageDeployTarget as the fall-through.'throttle-shed' is not in DEFAULT_ACTIONS (L17: ['restart','redeploy','page','warm-provider']).
Net: contention + exhaustion diagnoses do not heal — they are rejected or fall through to the wrong action. This is the burning-deployment core (a model CPU-saturates its cap and a co-scheduled embedder starves), and per ADR-0025/0026 §2.4 the Rung-0 shed-load is the most-needed AND least-privileged heal: shed the orchestrator's own REM/sync/golden-path load to free slots without touching siblings (the demand-first insight — recovery is demand-first, not supply-first). The shed-load primitive exists (MaintenanceBackpressureService, Rung-0) but is unrouted into the actuator.
The Fix
- Allow
'throttle-shed' in the actuator's executable action set.
executeTargetAction throttle-shed branch → MaintenanceBackpressureService (shed the orchestrator's own load); record-when-insufficient (a pure external-load contention can't be fully relieved by self-shedding → records the residual).- Inject
MaintenanceBackpressureService into RecoveryActuatorService; specs assert load is shed (the heal fires), not rejected/restarted.
Priority
HIGH — this is the operatorless-cloud contention heal, the privilege-free Rung-0. v13.1 self-healing is materially incomplete without it: today the burning-deployment class is detected and then not healed.
Related
Sibling to #14201 (config-drift→warm-provider heal, PR #14229). Epic #14039 / #14132 act-half. Primitive: MaintenanceBackpressureService. The diagnose→recover policy map (contention→Rung0-shed) is already designed.
Authored by Grace (Claude Opus 4.8). Origin session 090a68e6-1a28-4b20-a5fd-842ebac3e729.
The unwired heal (V-B-A'd at dev, 2026-06-27)
ContainerHealthDiagnosisServiceroutesexhaustion+contention→actionClass: throttle-shed(L516–528). But the recovery actuator cannot execute it:RecoveryActuatorService.executeTargetAction(L501–515) has nothrottle-shedbranch — onlywarm-provider, restart-by-target-kind (compose-service / supervised-task), andpageDeployTargetas the fall-through.'throttle-shed'is not inDEFAULT_ACTIONS(L17:['restart','redeploy','page','warm-provider']).Net:
contention+exhaustiondiagnoses do not heal — they are rejected or fall through to the wrong action. This is the burning-deployment core (a model CPU-saturates its cap and a co-scheduled embedder starves), and per ADR-0025/0026 §2.4 the Rung-0 shed-load is the most-needed AND least-privileged heal: shed the orchestrator's own REM/sync/golden-path load to free slots without touching siblings (the demand-first insight — recovery is demand-first, not supply-first). The shed-load primitive exists (MaintenanceBackpressureService, Rung-0) but is unrouted into the actuator.The Fix
'throttle-shed'in the actuator's executable action set.executeTargetActionthrottle-shedbranch →MaintenanceBackpressureService(shed the orchestrator's own load); record-when-insufficient (a pure external-load contention can't be fully relieved by self-shedding → records the residual).MaintenanceBackpressureServiceintoRecoveryActuatorService; specs assert load is shed (the heal fires), not rejected/restarted.Priority
HIGH — this is the operatorless-cloud contention heal, the privilege-free Rung-0. v13.1 self-healing is materially incomplete without it: today the burning-deployment class is detected and then not healed.
Related
Sibling to #14201 (config-drift→warm-provider heal, PR #14229). Epic #14039 / #14132 act-half. Primitive:
MaintenanceBackpressureService. The diagnose→recover policy map (contention→Rung0-shed) is already designed.Authored by Grace (Claude Opus 4.8). Origin session 090a68e6-1a28-4b20-a5fd-842ebac3e729.