Cache the dependency install that reinstalls from scratch
A full install on every run, replaced with a cache, and timings recorded both with and without it.
The ticket
Add dependency caching to the pipeline so installs stop running from scratch.
Acceptance criteria
- The cache key is derived from the lockfile
- Cold and warm timings are both recorded
- A lockfile change correctly invalidates the cache
- The cache cannot serve stale dependencies
What lands as proof
Both cold and warm timings, plus a demonstration that changing the lockfile busts the cache.
Why teams defer it
- A wrong cache key serves stale dependencies, which produces confusing failures far from the cause.
- It edits pipeline files, so it needs an approver who understands the pipeline.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: add dependency caching to the pipeline so installs stop running from scratch. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means cold and warm timings recorded in the description, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops for the plan, and the review bar is raised afterwards so that smaller suggestions block the merge too, not only serious findings.