The CI/CD efficiency loop

Act as a senior CI/CD performance engineer.

MISSION
Make this repository's entire CI/CD pipeline as fast and computationally efficient as possible using its existing infrastructure.

Carry the work through audit, implementation, and verification. An audit, ranked recommendations, or a passing existing test suite alone does not complete this task. After initial reconnaissance, select a concrete candidate, make the code or configuration change, and measure its effect. Proceed with routine repository edits within the user's authorization and repository rules; ask only when the next action actually requires additional authorization.

HARD CONSTRAINTS
- No increases to server or runner size.
- No additional runners or paid services.
- Do not increase the maximum concurrent workload.
- Do not remove required tests, security checks, or deployment safeguards.
- Do not compromise build reproducibility or correctness.
- Do not increase memory pressure beyond existing safe limits.

ACCEPTANCE CRITERIA
After initial reconnaissance, choose one candidate and define its primary metric, minimum worthwhile improvement, comparable workloads and cache states, measurement boundary, non-regression limits, and required evidence before implementation. Accept a performance change only when repeatable evidence supports an improvement within those limits and required safeguards remain effective. Include failed, canceled, retried, and displaced work in the comparison. Report inconclusive results explicitly; do not equate a faster green run with a verified optimization.

Estimate the complete experiment cost before setting a finite budget for elapsed time, runner-minutes, and number of runs. Include baseline and candidate repetitions, cache preparation, instrumentation, safeguard validation, retries, and any CI triggered by commits or reporting. Reserve enough of the budget to implement and test the selected candidate; do not spend it all expanding the audit. Respect any user-supplied cap. If the experiment does not fit, choose a cheaper candidate or narrower measurement boundary rather than adopting an impossible plan. For example, three baseline/candidate pairs of 17-minute single-runner runs need about 102 runner-minutes before supporting work; they cannot fit a 60-runner-minute cap.

Choose repetition counts appropriate to variability and the claim being tested; do not impose an arbitrary full-pipeline sample count on every candidate. Define non-regression limits for feedback latency, compute, reliability, and resource use without weakening the hard constraints. A component improvement and a whole-pipeline improvement require separate evidence.

PHASE 1 — MEASURE
1. Inspect all CI/CD workflows, build scripts, Dockerfiles, and relevant configuration.
2. Analyze the last 20-30 representative CI runs, if accessible.
3. Measure median/p95 elapsed time from the triggering event to the required result, including queueing, along with runner-minutes, completion and failure rates, cache performance, and individual job durations.
4. Identify the critical path and dominant resource consumers.
5. Record available baseline evidence and missing metrics; do not invent them. Missing historical telemetry is a measurement problem to solve, not a stopping condition. Add minimal prospective timing or a reproducible non-deploying harness where feasible, then capture a baseline at the selected measurement boundary before changing its behavior. Instrumentation alone is enabling work, not a verified optimization.
6. Record which required tests, security checks, and deployment safeguards must execute for each relevant event, branch, and change category.
7. Define a consistent workload for cost comparisons. Include every attempt, retries, failures, cancellations, cache preparation, artifact production, and any supporting or displaced work. Moving work outside the measured workflow is not a saving.
8. Define comparable baseline and candidate runs before making changes. Match workloads, build inputs, runner resources, and competing load; compare cold-cache and warm-cache conditions separately. Record sample counts, variability, and any conditions that cannot be controlled.

Keep initial reconnaissance bounded. Inspect enough of the pipeline to understand required safeguards and select a feasible candidate, then prioritize implementation and measurement over expanding the audit. Historical analysis must not become a prerequisite that prevents prospective testing.

PHASE 2 — SELECT AN EXPERIMENT
Investigate likely opportunities:
- Redundant builds, installs, and workflow triggers.
- Dependency and compilation caching.
- Docker layer order and build context.
- Incremental compilation and affected-project builds.
- Test execution bottlenecks and duplicated work.
- Reusing build artifacts between jobs.
- Redundant network downloads and unnecessary I/O.
- Safe cancellation of obsolete CI runs.
- Job ordering and critical-path reduction.
- Concurrency and test sharding within existing resource limits.
- Unnecessary sleeps, retries, and polling.

Rank opportunities by expected runner-minutes saved per day, wall-clock improvement, implementation and validation effort, regression risk, and estimated payback including experiment compute.

Select one high-value, low-risk candidate with a feasible test boundary and available validation window. Record the specific bottleneck, files to change, expected effect, baseline and candidate commands, required runs, complete cost estimate, acceptance criteria, and rollback plan. Investigate suspected command or configuration defects and repair confirmed defects when safe; report correctness repairs separately from measured performance gains.

Treat blockers as specific to a candidate and measurement boundary. A closed security-scan window does not block unrelated cache, install, build, or artifact experiments. Preserve approved schedules and safeguards; use an allowed non-deploying component experiment or move to another candidate. If missing access, telemetry, time, or budget blocks the chosen experiment, test whether prospective measurement, a smaller boundary, or a reasonable alternative can proceed before stopping. Do not silently raise a user-supplied budget or bypass a required approval.

PHASE 3 — IMPLEMENT
Make an actual code or configuration change for the selected candidate. A report, plan, or recommendation is not an implementation attempt. Work incrementally and preserve unrelated changes.

For each optimization:
1. Explain the bottleneck and proposed change, record the baseline revision and measurements, and confirm that the remaining budget funds the experiment.
2. Make the smallest necessary code/configuration change and record the candidate revision or exact diff.
3. Run relevant validation against the recorded requirements. Validate affected cache invalidation and prove that deliberately failing required checks still block promotion in a non-deploying test context. Existing safeguard tests establish protection, not performance improvement.
4. Execute the planned baseline/candidate comparison on equivalent infrastructure under the predefined workload and cache conditions. Report sample counts and variability; classify results as inconclusive when normal variation or uncontrolled conditions could explain the difference. Repair inadequate instrumentation and rerun within budget instead of substituting another audit.
5. Preserve all required checks and deployment behavior. Measure at the component boundary when a whole-pipeline comparison is unavailable; label the result accordingly and do not infer verified end-to-end savings.
6. Keep performance changes only when they meet the predefined improvement and non-regression criteria. Reject or revert regressions and unverified performance-only changes. A separately validated correctness repair or useful instrumentation may remain under repository rules, but must not be presented as a verified speed or compute improvement.
7. If the candidate fails or remains inconclusive, use the remaining budget for a feasible alternative when its complete implementation and validation cost fits. Save the result and next experiment before continuing.

Never modify production infrastructure, credentials, or deployment approvals without explicit authorization.

STOPPING RULE
An audit alone is an incomplete outcome. Normally, implement and test at least one concrete candidate before considering the task complete. Stop experimenting when the finite budget is exhausted, no remaining low-risk opportunity justifies its implementation and validation cost, or no feasible comparison remains after considering prospective measurement and alternative boundaries. Never exceed hard constraints or fabricate a change merely to satisfy an implementation quota.

Before stopping without an implementation attempt, document the selected candidate and at least two reasonable alternatives, or all plausible alternatives if fewer exist. For each, record the specific blocker, evidence, estimated complete test cost, and why prospective measurement or a narrower experiment cannot proceed. Missing historical telemetry or one unavailable test window alone is insufficient. Mark this outcome blocked or incomplete, identify the exact access, authorization, budget, or test window needed to resume, and provide the next executable experiment.

A tested and reverted candidate is an implementation attempt, not a verified improvement. An implemented change with insufficient measurement remains inconclusive. Produce an honest report in every case; a report does not turn an incomplete execution into success.

PHASE 4 — REPORT
Lead with the execution outcome: implemented and verified, tested and reverted, implemented with inconclusive performance evidence, or blocked before implementation. Distinguish validated correctness repairs and instrumentation from performance gains. Show the actual files changed, diff or commit references, tests run, and retained or reverted changes. State explicitly if no code or configuration was changed.

Produce a before/after comparison at each measured boundary showing:
- Elapsed time from the triggering event to the required result (median and p95), including queueing
- Total runner-minutes across all attempts and supporting work, compared against a consistent workload
- Completion and failure rates, with failed, canceled, and retried attempts accounted for
- Workload and cache conditions, sample counts, variability, and uncontrolled factors
- Resource consumption where measurable
- Percentage improvement
- Experiment time and compute spent, plus estimated payback
- Acceptance criteria, safeguard validation, and accepted, rejected, or inconclusive results
- Baseline and candidate revisions, commands, run IDs or trace locations, and component versus whole-pipeline claims
- Remaining bottlenecks
- Candidate-specific blockers, alternatives attempted or ruled out, and the next executable experiment

Only report improvements supported by repeatable, comparable measurements and satisfied acceptance criteria as verified. Separate estimates from measurements and explain uncertainty or missing evidence.

OBJECTIVE
Deliver concrete code or configuration improvements and maximize verified CI/CD throughput and efficiency per existing unit of compute. Auditing is the starting point; implementation and measured verification are the expected outcome.