At 2026-10-10 01:34 UTC, the selected MaaS assessment worker was Pending because the worker node had only 125m unreserved CPU. Existing general CI deployments each reserve 610m CPU; no capacity expansion was performed.
Temporarily changed only spec.replicas from 1 to 0 on gitea/gitea-act-runner-2 (UID fd4e6fe3-9cdc-4689-9a16-e4652080baba) and gitea/gitea-act-runner-3 (UID 27441177-77df-4a13-943d-d8dd16a812fa). Immediately before each change, Gitea runners 21 and 22 were online and busy=false, and their Docker daemons had no running containers. JSON patch tested the deployment UID, resource version and previous replica count. General1 and both Rust deployments were preserved.
The owning manifest is AutoCoder-Engine/documentation/configs/autocoder-engine/gitea-migration/gitea-act-runner-k8s.yaml, which retains the normal baseline of one replica each. The storage guard restores only deployments carrying its drained annotation; neither selected deployment carried it. No runtime environment flags, permissions, registrations or persistent data were changed.
Rollback: restore these same deployment UIDs from replica 0 to 1 after campaign assessment-recovery-20261010 finishes or fails; verify restored readiness and report CPU contention if scheduling prevents readiness. Assessment activation and behavioral acceptance are still pending.
Restricted task receipt: /home/ax_julian/temp/maas-assessment-evidence-20261010/runner-parking.json. This record will be updated with assessment and restoration evidence.
The campaign started01:35:14 UTC with34 frozen members. Three valid assessments were applied. The fourth request (EmailAssistant issue681, member195) failed provider HTTP504 at01:51:59 UTC after about11 minutes. Its uncertain $1.50 hold remains reserved; no automatic retry occurred.
At02:03:17/18 UTC both temporary runner changes were rolled back to their repository baseline of one replica. Each patch tested the original deployment UID, current resource version and current zero replicas. Restricted receipt: runner-restoration.json next to the parking receipt. Restored runner readiness must still be checked; reactivation of assessment remains blocked by its uncertain-charge gate.
At02:05–02:11 UTC gitea-act-runner-2 was restored and Ready. gitea-act-runner-3 has desired replicas1 but remains Pending because available CPU does not satisfy its request. Rollback state is restored; scheduling capacity remains constrained. No physical expansion or active job interruption occurred.
At 04:00 UTC, candidate 30069b7cd341b2ffb1017cd7559e2ae2308f5497-4478-1 was Ready in production. Its exact-digest worker publication selected sha256:2ee88fb1b4e6393260d7adca3c44162b5ec2a983cc296ee61cd873dafeb81cdd, built from main d422e6419b33e106b6628d4ae2415abccb5e2a7c with the same source tree. The categorization pod remained Pending for insufficient CPU.
A second bounded recovery parks only gitea/gitea-act-runner-3, exact original UID 27441177-77df-4a13-943d-d8dd16a812fa, from one replica to zero. Immediately before the guarded patch, runner 22 was online, busy=false, and the exact worker-node pod had zero running Docker containers. The patch tests UID, resource version and replica count. This frees its existing 610m CPU reservation; general runners 1/2 and both Rust lanes remain available. No physical expansion, runtime flag change, permission change or persistent-data deletion is involved.
Restore this same deployment UID to one replica when assessment-recovery-20261010 finishes or needs intervention, and verify readiness. Restricted receipt: runner-parking-recovery-0400.json under the existing task evidence directory. The campaign still has three applied, thirty untouched and one retained HTTP504 failure; its USD1.50 unknown-charge hold and USD100 aggregate ceiling remain intact. Deployed receipt-import inspection passed without executing a live import. Worker readiness, live campaign recovery and restoration remain to be recorded.
At 04:02–04:04 UTC the categorization worker was Ready on drg-k8s-worker-01.auth.home.lan, running the exact selected immutable worker digest. The supported terminal receipt import for retained member195 executed once (duplicate=false, financial_hold_preserved=true). Its original failed task, finish time, error and USD1.50 uncertain charge hold were preserved. The campaign resumed untouched members: four classifications were applied by 04:04 UTC, with one queued, twenty-eight pending and one failed request eligible for a separately charged second attempt under existing guards. These are estimates/reservations, not provider-billed spend. Runner3 remains temporarily parked while the campaign progresses; restoration and full board acceptance remain outstanding.
At 04:11 UTC worker reconciliation had admitted seven ordinary account workers, consuming the temporary CPU headroom; the replacement categorization pod was Pending again. At 04:12:45 UTC only gitea/gitea-act-runner-2 was additionally parked (same original UID fd4e6fe3-9cdc-4689-9a16-e4652080baba, one replica to zero). Immediately before the UID/resource-version/replica guarded patch, runner21 was online and not busy, with no running Docker containers. General runner1 and both Rust lanes remain. Restricted receipt runner2-parking-recovery-0414.json records the change. Restore both original runner2/3 UIDs to one replica after campaign completion or intervention, then verify readiness. No physical capacity expansion occurred.
At 04:14:57 UTC campaign admission was paused through its supported operator command after native member164 failed before provider dispatch. The enrolled issue and current issue differed only in mirrored_at; deployment reconciliation had refreshed that observation timestamp. No provider charge was incurred for that attempt, and the original failed task remains retained with released_before_dispatch evidence. Four assessments remain applied; this comparator defect requires source repair before resumption.
At 04:15:29 UTC the original runner2/3 deployment UIDs were both restored from zero to one replica with UID, current resource-version and previous replica tests. Restricted restoration receipt: runner-restoration-recovery-0415.json. Both desired replicas match their repository baseline; Ready replicas remain pending under worker-node CPU contention. No active campaign task was running at rollback. The supervising agent owns readiness verification and source repair; the campaign is not silently monitoring or retrying.
At 06:04 UTC production candidate 68261f00b6d46e01546c7f731ad72a6222048499-4500-1 was externally verified: backend /healthz returned HTTP200 and the same exact source revision as frontend pkg/build-revision.txt. Promotion4502 and worker publication4503 succeeded. The selected full worker is sha256:0b9367978bf4735e6adb550fd51628f41bdb093fbb88478e83b11d739c806b87, from main165d1ceca2643b07bb45e8ab76a3983ce9d63024 with the reviewed identical tree. PostgreSQL remains Ready with its repository-managed2Gi limit. The campaign remains paused at4/34 applied; three failures are now eligible for the existing bounded second-attempt guard, not rewritten.
At06:05:30 UTC only runner3, original UID27441177-77df-4a13-943d-d8dd16a812fa, was again temporarily parked from1 to0 to resolve the matching categorization pod's verified insufficient-CPU scheduling failure. Fresh checks confirmed runner22 online and not busy, zero running Docker containers, exact context/cluster, deployment name/UID/resource version/replicas. No active CI job was interrupted. Restricted receipt runner3-parking-recovery-0610.json records the change; filename is a task label, timestamp is authoritative. Restore the same UID to1 when assessment finishes or requires intervention, then verify readiness. Categorization worker readiness and assessment resumption remain pending. No new capacity, permissions or runtime flags were added.
At06:06 UTC parking runner3 left only235m unreserved CPU, below the categorization worker's250m request. At06:07:02 UTC runner2 (same original UIDfd4e6fe3-9cdc-4689-9a16-e4652080baba) was additionally parked from1 to0 after runner21 was freshly online/not busy and its exact pod had no Docker containers. UID/resource-version/replica tests guarded the change. Receipt runner2-parking-recovery-0610.json. General runner1 and Rust lanes remain available. Both runner2/3 must be restored to1 at campaign completion/intervention and readiness verified.