CI routing costs

Routing from measured wall time

Use GitHub-hosted runners for independent checks that fit the workflow's remaining time. Retain Blacksmith where the measured job tail threatens completion. Qualify RunsOn by workload before assigning it a production tier. Requested Blacksmith 8/16/32 labels delivered 2/4/8 CPUs in the capacity check; labels are not worker counts.

The table compares eleven successful B1/R1 main runs with five later successful main runs: 35679872894, 35679457587, 35678156129, 35677164460, and 35675497006. These are longitudinal observations with different source revisions, not controlled provider comparisons. Values are median [maximum] complete job seconds; a dash means unmeasured. Existing trust, retry, and hosted assignment admission still apply.

Independent hosted checks reached at most 664 seconds in this sample. Artifact builds reached 898 seconds before the shared preflight and gate; they retain Blacksmith. Only the gate depends on build-artifacts: the workflow does not contain a serial build-to-test job dependency.

The package-boundary check now requests the existing Blacksmith 32-class when its route selects Blacksmith. In successful PR run 36248684656, its 16-class allocation delivered four CPUs and the existing two-CPU reservation admitted two compilers. The 527-second check comprised 257 seconds of declaration preparation and 268 seconds compiling all 125 plugins. The 32-class delivers eight CPUs, allowing four compilers under that same policy. It adds no jobs or registrations. At the observed 569-second job duration, doubling the class would add 151.7 class-vCPU-minutes, or 1.17% of that run's 12,921.2 total. The later complete green run 36269840991 measured 301 seconds and 160.5 class-vCPU-minutes with all 125 plugins checked. Upstream compiler optimization also contributed, so this is not an isolated runner speedup. Hosted, retry, trust, and cache policies remain unchanged.

Exact plugin envelopes and unsplit two-worker command envelopes now feed the existing timing owner using config, complete file inventory, and worker-bound identities. Plugin row ordinals never identify a workload. Static plugin rates remain the fallback for unmeasured selections, and the refitter still requires two independent runs before replacing a price. Conservative single-run floors are explicitly labeled in the committed timing provenance. An exact measured multi-file core child above 300 seconds can split again without repricing its siblings or combining unlike capacity samples into a parent. A single-file overrun remains visible.

Gateway methods prefer measurements for the current scope and worker policy, then the full owner at that policy. Until those exist, the matching older-worker scope and full-owner measurements remain admission floors. Changing both key qualifiers must not discard the existing owner measurement.

Process-bounded plugin owners also retain per-file invocation prices across envelope changes. These prices have distinct keys from whole-envelope walls; shared wrapper overhead is charged once. Only complete successful serial receipts with one declared file per process qualify. Other process owners and missing measurements keep their existing estimates.

Telegram process overlap

Source-only Telegram database-worker envelopes with at least two singleton processes can overlap two inner processes on current self-hosted Linux runners. Admission requires an explicit current target (FROZEN_TARGET=false), one unchanged Node invocation from the canonical runtime selector (including bun-compatible), two workers, one outer plan, scheduler-owned caches, at least two actual CPUs, and 7.5 GiB of effective memory. Effective memory is the smaller of physical memory and a positive finite process constraint. Other selections or insufficient capacity retain one inner process. Each test file keeps its own process, and focused CI still stops admitting new work after failure while joining admitted peers.

The executor reports actual inner concurrency, including serial fallback. Its value participates in the existing environment-bound timing identity. Parallel receipts supply only the complete envelope wall; overlapping file durations are never summed and subtracted to derive wrapper overhead. Until that exact policy has qualified measurements, placement retains the conservative serial estimate.

A 199-case envelope measured 184.40 seconds serially and 147.31 seconds with two processes on a Linux Testbox constrained to two CPUs and 7.65 GiB. Three further qualified replays took 147.46, 146.13 and 149.34 seconds. Peak aggregate memory stayed below 4.51 GiB, with no OOM events and the same cases. Whole-row budgets still need qualification from naturally occurring CI runs.

Storage balancing additionally uses 36 config-scoped module-work hints from an unchanged two-worker replay of the exact tested merge. Setup, collection, and suite elapsed time guide placement; the longest file is never divided by the worker count. A separate 20-second allowance covers compiler and wrapper work once per child. These conservative four-CPU Testbox hints are not eight-CPU native CI file walls. Existing whole-envelope observations remain authoritative floors, unknown files retain their prior estimates, and worker policies stay unchanged. Heavy storage children retain their measured 32-class allocation when splitting leaves them alone; isolation does not imply a smaller runner.

Numbered compact bins change when membership changes. A matching suffix does not establish a matching workload. Full manual native qualification, including iOS and Android, is not proven within fifteen minutes by these Linux measurements.

Hosted assignment on the critical path

In main run 35810905247 (September 23, 2026), the gate completed 1,068 seconds after run_started_at; the run metadata finalized one second later. The jobs endpoint reports 105 rows, including skipped jobs, so the second page is required to observe the gate. Each creation interval below starts when the preceding required job completed, or at run_started_at for preflight.

This is 416 seconds of hosted queueing, 190 seconds of creation/admission, 460 seconds of execution, and two seconds of Blacksmith queueing. The initial 189 seconds end exactly when run 35809764899 releases the same even main parity slot. They are workflow admission, not planner execution. The planner is inside preflight's 60 seconds; downstream creation costs one second. The six extension-lint rows finish before the slowest Node job and remain hosted.

The newest green PR at the sampling cutoff, run 35811411598, completes the gate in 780 seconds (metadata finalizes at 781 seconds):

That chain spends 130 seconds in hosted queueing, two in creation, 632 executing, and 16 in Blacksmith queueing. No test depends on the artifact build in either chain. Changing matrix shape would not remove the gate's serial queue.

Trusted hybrid first attempts therefore request the 16-class for both packed core-lint rows and the 4-class for the gate. The logical lint partitions, single lint thread, extension-lint rows, main parity slots, workflow dependencies, and deadlines stay unchanged. Hosted remains the route for independent cheap work. RunsOn's cron evidence does not qualify lint or a Bash-only gate, so those workloads retain the measured Blacksmith route. The existing health owner also rejects optional check offloads after observed hosted waits reach sixty seconds, replacing its former three-minute threshold. This protects the central type and dependency rows when assignment consumes their execution slack without changing API deadlines or test coverage. The first native candidate used the 8-class for both lint rows. Its PR run 35813098351 passed in 785 seconds, but core lint 1 took 621 seconds (568 in lint itself), versus the 398-second hosted baseline (350 in lint). Core lint 2 took 353 seconds versus 323 hosted. That revision retained four actual CPUs only for the heavier row to avoid spending the queue saving on slower execution. At the historical list rates and old hosted runtimes held constant, the 16/8 split costs about $0.2984 instead of $0.1923 for two 8-class rows. These unrounded estimates exclude minimum billing and ancillary charges; native measurements, rather than that forecast, own the final cost and wall comparison.

The second packed row later exhausted its 15-minute limit in run 36422187813. A controlled four-CPU, 16-GiB-capped lease completed its unchanged stripes 3, 4, and 5 in 137.37 seconds with the existing larger-runner Go policy. Both rows now request the 16-class. The promotion adds no jobs or registrations; at the full 15-minute deadline, the second row adds at most 120 class-vCPU-minutes versus the 8-class. The lease measurement is not a native CI timing result.

The revised PR run 35814962786 measured core lint 1 at 275 seconds on the 16-class and core lint 2 at 385 seconds on the 8-class. The heavier row's reference compute was about $0.1467, versus $0.1469 for its 551-second 8-class main-shaped observation and $0.1656 for the earlier 621-second PR observation. These are unrounded complete-job costs across different CI contexts, excluding minimum billing and ancillary charges. The revised workflow still failed a UI test and had a 118-second hosted median wait; it is not a complete fifteen-minute qualification.

The change adds three actual Blacksmith registrations on ordinary hybrid main and same-repository PRs. Fork PRs keep the logical GitHub check profile, which emits five core-lint rows, so their increase can be six including the gate. A fresh current-source audit totals 71 potentially self-hosted non-Node rows across the supported automatic main/PR profiles. This conservative union includes five core-lint rows, five core-type rows, five Windows rows, and thirteen UI E2E rows; its profile maxima do not all coexist. The six extension-lint rows stay hosted.

Retain an 84-row non-Node allowance, leaving thirteen rows reserved above that union. With the unchanged 70/130 Node caps and four-main/21-PR arrival envelope, 4 × (70 + 84) + 21 × (130 + 84) = 5,110. That leaves 890 below the 6,000 operating target from the reported 10,000-per-five-minute registration limit. This replaces the stale historical 80 + 3 + 1 explanation without spending headroom or changing matrix caps. Manual/frozen release jobs and other workflows are outside this conditional arrival envelope; it does not establish complete organization-wide usage.

Ratchet admission and Node tests

Selected baseline ratchets and Node rows start independently after preflight. The final gate still requires every selected ratchet to pass. This preserves the landed parallel admission path and avoids moving ratchet setup into preflight.

The five newest broad green PR runs at the September 26 sampling cutoff (36208949888, 36208857347, 36208617238, 36208552952, and 36208291831) spent 148–173 seconds in hosted checks-fast-baseline-ratchets. Checkout took 31–33 seconds, dependency setup 27–52 seconds, and the ratchets 73–111 seconds. Those historical Node rows waited for this job. Current Node rows start alongside it. Preflight took 89–120 seconds, including 48–83 seconds of manifest planning; these hybrid runs already skipped preflight's exact dependency restore.

Same-repository hybrid PR first attempts, automatic main runs, and admitted qualification dispatches now request the existing Blacksmith 4-class for the ratchet job. Nearby default-Blacksmith runs 36208877388 and 36209067188 measured complete ratchet jobs of 85 and 91 seconds. Their setup took 12–15 seconds and ratchets 39–40 seconds. These different-head observations project 57–88 seconds less ratchet wall; they do not prove current whole-workflow savings.

Using the slower 91-second observation, the route adds at most a modeled 4 × 91 / 60 = 6.07 Blacksmith vCPU-minutes per eligible run. It adds no jobs and one actual hybrid Blacksmith registration. The job already belonged to the potentially self-hosted non-Node union under the default backend, so the existing 84-row allowance and 5,110-registration envelope stay unchanged. Hosted routing remains for the GitHub override, hybrid retries, ordinary manual or frozen targets, and noncanonical repositories. Ratchet checks, merge-tree validation, parallel Node admission, dependency reconciliation, and deadlines are unchanged.

The same five runs spent 165–209 seconds in the separate check-plan prerequisite. Its compiler inventory queries took most of the 93–154-second materialization step; every narrowed type/lint row waits for that result. Those runs' central test-type checks finished 629–667 seconds after workflow start, so advancing only Node admission cannot meet the ten-minute PR objective.

check-plan therefore uses the existing 4-class under the same hybrid admission, restoring exact dependencies only for eligible same-repository jobs on an actual self-hosted runner. The route adds one Blacksmith registration within the existing non-Node reserve. Keeping the full observed 209-second hosted wall as its conservative cost estimate adds 13.93 vCPU-minutes, or 20 vCPU-minutes with the ratchet estimate. No planner speedup is assumed in this cost bound. Native proof must establish the materialization and whole-workflow wall; compiler coverage, selected graphs, and all hosted fallbacks remain intact.

The broad fallback PR qualification does not select check-plan. Its observed wall can validate the broad Node path, but cannot establish the new narrowed type/lint critical-path improvement. That claim needs a separate native run whose changed-file plan selects this prerequisite.

These two control-job changes apply only to the hybrid backend. RunsOn retains hosted ratchets and check planning, including qualification dispatches.

RunsOn remains unqualified

The on-demand pilot measured the two critical compact jobs at 561/816 seconds on Blacksmith versus 755/1259 seconds on c8i.4xlarge: 35%/54% slower. Full Gateway-core failed on AWS at every tested worker count. Cron scaled from 156 to 138 seconds on c8i.8xlarge and 126 to 110 seconds on c8a.8xlarge at 8 versus 16 workers, but lacks a matching Blacksmith control. Checks, artifact builds, extensions, and UI have no pilot comparison.

The opt-in runson profile derives from hybrid and extracts the three core-runtime-cron-parallel-* children into one serial job on c8i.8xlarge: 32 vCPUs, 64 GiB RAM, ubuntu24-full-x64, and an 80 GB gp3 root. On the retained cron comparison inventory, all 258 files kept their two-worker job and group ceilings, and the source Blacksmith jobs retained their other children. RunsOn inherits hybrid's current splitting and packing before adding its cron row. Current inventory counts and pricing are recorded in measured compact packing; the earlier fixed nine-to-four projection is not a universal result. The pilot's eight-worker, 156-second cron wall remains historical context, while the complete two-worker comparison below owns the available provider evidence.

The compatible CLI observations retain 558 and 703-second forecasts including one 60-second setup allowance. Separating their serial pair does not establish a 600-second maximum for each indivisible child. Eligible serial tooling pairs now split above a 600-second complete-wall estimate; packing separate short jobs uses a 720-second admission limit. These are placement estimates, not raised test deadlines or guarantees about the fifteen-minute workflow wall.

Qualification run 35702772380, attempt 1 at 84733d1a17a9a7321ac74099e421889099e411b4, ran the same cron descriptors on all three providers. All three cron jobs passed with two workers and one serial child plan. The RunsOn allocation reported instance-life-cycle=spot; no interruption occurred. Wait below is job creation to start, including matrix admission, not pure provider boot time.

RunsOn's job duration was 36 seconds shorter than the Blacksmith control's, an 8.3% reduction in this single same-run comparison. It does not establish a repeated distribution or qualify the complete workflow. The fresh Blacksmith child measurement is 393.71 seconds, or 6.56 minutes of candidate serial work removed from the existing source jobs, approximately $0.4200 at the historical $0.064/minute list rate. The control's complete 7.2-minute job is an added qualification job, not the amount removed from production. The source jobs retain other children and setup. Each additional Blacksmith 8-class split adds an estimated 45–60 seconds of setup; the current inventory accounting appears below. Runtime interactions, those added steps, and AWS allocation cost must be included before claiming net whole-run savings.

The earlier baseline run 35688659765 measured the same cron descriptors at 252.63 combined child seconds. The newer 393.71-second control replaces that 4.21-minute costing assumption; the variation is another reason not to equate a child-duration forecast with realized savings.

Selection uses the runson backend on a canonical same-repository PR's first attempt, or the maintainer qualification dispatch with an exact current PR head. The repository variable remains unchanged. The existing RunsOn GitHub App supplies runners from workflow labels; no interactive AWS login is part of dispatch. The latest operator identity check failed because the AWS SSO session was expired, so administrative state, teardown, and selected-AZ prices remain unverified. The public regional price feed is available without those credentials.

Jobs request spot=true/retry=false. Spot has native on-demand fallback when capacity is unavailable; the provider's fallback documentation describes an additional 2–3 seconds, not a complete assignment SLA. retry=false opts out of automatic interruption reruns because the full-workflow recovery delay has not been shown to fit the original 900-second wall. An interruption can therefore fail this qualification. This is a Spot placement experiment, not an interruption-safe fifteen-minute tier.

The selected c8i.8xlarge has no local instance-store NVMe. No sticky disk, warm pool, custom image, or storage change is enabled. RunsOn automatically configures local NVMe on compatible instance-store types such as c8id; the pilot's corrected overlay verifier has not supplied a live performance comparison for that storage route. See RunsOn local NVMe.

The public AWS Spot price feed reported c8i.8xlarge Linux in us-east-1 at $0.6586/hour when fetched on September 22, 2026, at 06:02:13 UTC; its HTTP last-modified timestamp was 06:01:21 UTC. This is a regional reference with no availability-zone identity or assumed averaging method, not the selected runner's billing rate. The observed Spot instance launched at 08:06:00 UTC and its job completed at 08:12:57 UTC: 417 seconds from launch through job completion, giving $0.076286 estimated compute at that reference rate. This replaces the earlier 156/187-second illustrative costing.

Final instance termination was not independently verified, so 417 seconds is not the complete billable lifecycle. Add teardown, storage, networking, and control-plane charges. The $1.49936/hour on-demand reference remains the historical September 17 quote; no on-demand fallback was observed in this qualification. No expected blended rate is claimed without fallback and interruption frequencies. The earlier approximately $0.09 sample is not a flat job price.

Native interruption recovery remains a future option requiring measured slack. RunsOn v3.3 permits two automatic reruns with retry=when-interrupted: it waits for the entire workflow attempt to finish, then reruns failed jobs and dependents. Newly launched recovery capacity is on-demand, but GitHub can assign an existing matching Spot runner. Admission must therefore account for first-attempt completion + retry delays + both failed/dependent replays <= 900s; merely placing a job off the critical path is insufficient. A 720-second first attempt leaves 180 seconds, already less than the measured 396-second cron job before recovery dispatch, assignment, and the gate.

Report observed interruptions and retry attempts separately from this documented provider behavior. No-capacity fallback or a manually requested rerun is not interruption-recovery proof. Until a complete recovery fits the original wall, the opt-in profile keeps automatic interruption retry disabled and makes no interruption-safe 900-second claim.

Packing and cost arithmetic

The 300-second changed-extension budget combines the same 119 child envelopes into 40 jobs instead of 47 on the September 22 counting inventory. Estimated work remains 10,140 seconds. At 45–60 seconds of fixed setup per job, the extension slice changes from 204.25–216 to 199–209 machine-minutes: a 5.25–7 minute saving. At the historical 8-class list rate of $0.016/minute, that is $0.084–0.112 per broad PR. Public hosted execution has no metered Linux runner charge; this saving is capacity there, not a cash saving.

The following historical replay uses the capacity-pricing candidate's committed 47b18faa725 inventory with only the extension budget changed. These conditional counts describe that earlier experiment, not the final rebased inventory or qualification of the combined branch.

Each profile also has two dist descriptors outside the Node matrix. Main does not append these extension envelopes. Compact/PR/push/plugin caps stay 90/130/70/50. Worker counts, assertions, test deadlines, runtime-build ownership, and native-worker file ceilings remain unchanged. The workflow no longer promotes extension bundle numbers 16 and 25 to the 16-class: those positions now contain different work and follow their planner-owned 8-class route. Native proof must measure this capacity change too.

Predictions can be wrong. The old 982-second extension job included database-worker, Codex, and Matrix children taking 351/354/125 seconds; the candidate places their corresponding envelopes in separate bundles. Only the Matrix selector is identical. Its 27-second estimate substantially understates the observed 125 seconds. Applying that observation conservatively to all four Matrix children in their candidate bundle gives about 725 seconds including 60 seconds of setup, with uncertainty in the other children still requiring native proof.

Measured compact packing

Hybrid placement reuses the canonical tooling estimator from the capacity-pricing work. It reads committed Blacksmith file measurements through readToolingFileTimings and passes them through the existing estimator's optional file-map argument. Only this hybrid placement pass consumes that additional map; RunsOn inherits the hybrid plan. The broader timing payload and global pricing coefficients are unchanged, so this route does not create a competing file-price table.

The canonical collector accepts a complete singleton invocation duration when one declared tooling file, one passing file summary, one duration, matching reporter identity and successful exit agree. Native file summaries retain precedence. Six singleton file prices were refitted from successful jobs and children in three failed workflows; a seventh stayed within the owner's 15% threshold. Seven scoped native Testbox file updates fill missing eligible prices and correct the provision estimate. Failed workflows and cancelled lease cleanup never supply complete-inventory or pruning evidence.

Packing admits serial Blacksmith 8-class jobs with the existing two-worker ceiling, numbered tooling children and no runtime-build prerequisite. Every child needs complete per-file measurements or an exact complete-child native observation before its job can acquire additional packed work. Default two-second hints for unknown files do not satisfy that requirement. An incompletely measured job keeps its original membership and receives its conservative quoted cost and setup allowance.

The complete packed estimate is 60 seconds of setup plus the greater of the existing owner job price and summed canonical group prices, retaining compatible native child observations as lower bounds. Native wall floors are not discounted by a worker ratio; the canonical file estimator keeps its normal worker-aware calculation. Each packed job must fit 720 seconds including setup, preserve complete children and their order, respect sibling-family separation and retain its deadline. Higher owner prices cannot be replaced by faster historical samples.

Four new main tooling tests changed the earlier selectors. The same estimator now prices the changed inventory instead of disabling packing wholesale. Only affected jobs lacking complete file or native evidence are excluded from merging. Native observations bind to the executed config, environment, ordered selectors, child name and build mode; a parent timing key remains provenance, not admission authority. An unchanged child can therefore retain its observation when a sibling changes, while a changed executed contract expires the old observation safely.

Eligible serial tooling jobs with multiple children split above a 600-second complete-wall estimate. Complete native child totals drive this decision when available, while the existing job prediction remains a floor; otherwise canonical estimates supply the child costs. Packing still retains any higher canonical price. Exact observed critical pairs also split. Runtime preparation stays only on the requiring child, and newly split critical rows cannot be repacked or charged another setup by that pass. The 703-second CLI forecast remains an unresolved indivisible tail.

Native calibration

Linux Testbox run 35722202780 used source 2fd7485b450e12ef5574645d7b648d61ee5ce8a2 on the Blacksmith 8-class, with two observed CPUs, two workers and one child at a time. All eight selected children and the runtime preparation completed successfully. The enclosing workflow was cancelled during lifecycle cleanup, so it is not a green workflow or fifteen-minute qualification. Source correspondence retains the recorded runner-label fixture difference.

Rounded native components plus one 60-second setup yield 235/466-second floors for the first pair and 388/698-second floors for the second. Preparation is charged only to 9-hosted-1. The new complete 9-hosted-2 sample replaces no failure outcome: the earlier failed 631-second observation remains censored. The four packing-child measurements update only their new exact fingerprints; final packing also retains the higher canonical prices. These are child/build receipts and forecasts, not complete Actions job walls with queueing.

Current inventory

Main now includes the separately owned runtime release tier; its coverage movement is not an R3 saving. On the candidate rebased onto 0a5b5381a26b, hybrid's broad-PR plan separates two critical pairs and packs seven eligible jobs into three. Four removed setups save 3–4 minutes; the two splits add 1.5–2 minutes, leaving a conditional 1.5–2 Blacksmith 8-class minutes /$0.024–$0.032 before runtime interactions. Main adds one split and its setup. Extension packing retains its separate controlled 47→40-job comparison.

The immutable nine-job calibration cohort fits four jobs with canonical forecasts of 629, 539, 662 and 672 seconds. That cohort checks the policy; it does not define the current inventory's job count. Current packed compact-small-20 forecasts 617 seconds, and tooling compact-small-32 forecasts 576.5 seconds. The longest known forecast remains the 703-second CLI child.

Compact counts include dist descriptors; broad-PR Node counts include 40 extension rows. RunsOn adds one cron job to the hybrid plan. All counts stay inside the unchanged 70/130/90 caps. Together, current Node and extension packing remove a net nine setups from a broad PR: an estimated 6.75–9 Blacksmith 8-class minutes, or $0.108–$0.144 before runtime interactions. Main adds one setup, approximately 0.75–1 minute or $0.012–$0.016. These counts and costs are planner arithmetic, not native performance acceptance. Final measurements are recorded in PR #155403.

Ordinary main still does not select AWS. The admitted main-shaped qualification can select RunsOn and excludes comparison controls. Its initial preflight stays hosted until authorization. Qualifications retain their coverage shape on reruns while using hosted routing, resource policies and deadlines; raw GitHub context continues to own authentication, concurrency and cache publication.

Whole-run acceptance

Baseline run 35679872894 took 21m18s: 5m20s before preflight creation and 15m58s from preflight creation through the gate. Blacksmith class median assignment was 8/8/3 seconds for 32/16/8-class. Workflow admission and runner assignment are different waits; include both in whole-run latency.

The baseline allocated 29/2/10 active Blacksmith 32/16/8-class jobs and 25 hosted Ubuntu jobs. Skipped placeholders consumed no runners. That is 258.15 Blacksmith machine-minutes; historical label rates imply $13.84, while the campaign's supplied estimate was $18–20. These are pricing assumptions, not an invoice. Moving artifact builds back adds one Blacksmith job and approximately 4.67 Blacksmith minutes using the older build median; extension compaction applies to PRs only.

Completion requires measured main-shaped and broad-fallback PR-shaped runs for each changed profile at or below 900 seconds, with every Blacksmith class median assignment at most 60 seconds. Record actual job and step walls, total workflow wall, class counts, and cost against the same baseline. Planner estimates, reduced rows, and a successful test result alone do not establish this performance gate. The routing and packing changes remain unqualified until those exact-head observations exist.

The two native runs at 84733d1a17a9a7321ac74099e421889099e411b4 both failed and exceeded the wall target:

Qualification additionally used 6.6 job minutes on Spot, with the $0.076286 launch-to-completion estimate above. It includes the two extra cron controls and different dispatch admission, so subtracting these total costs would not isolate the production routing change. Blacksmith Linux class median waits were 12 seconds in the PR and 9–10 seconds in qualification. Windows medians were 48 and 61 seconds, respectively; qualification therefore also missed the under-60-second class wait target. The successful job tails were 950 seconds in the PR and 907 seconds in qualification. Passing cron controls do not turn either failed workflow into a green or fifteen-minute result. These runs predate the current calibrated packing candidate and do not qualify it. Current main-shaped and broad-PR receipts are recorded in PR #155403.