Measure the faster loop against a full-check baseline
A timing screenshot says the cache is faster but omits cases where it skipped a required check. Produce a reproducible comparison covering clean, warm, leaf-change, and shared-change runs.
- Focused work estimate
- 2h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Benchmarking · Experimental design · Build correctness
Estimated field mix
- Performance engineering50%
- Developer tooling30%
- Quality engineering20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A product team waits for every package to rebuild after small changes. An experimental cache is faster but occasionally returns success after a shared type changed. Build a small, auditable task runner around fixture packages.
Setup prerequisites
- Prepare four fixture packages with one shared library and two applications.
- Use only trusted fixture commands in local tests.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- BUILD-101 · Reject invalid task configuration before starting a command
- BUILD-102 · Show why a task is selected after a file change
- BUILD-104 · Include tool versions and declared environment in the cache key
- BUILD-105 · Restore cached outputs without touching unrelated files
- BUILD-103 · Schedule independent checks without exceeding the worker limit
- BUILD-106 · Never cache failed or incompletely written task outputs
- BUILD-107 · Cancel running checks and report what did not run
- BUILD-108 · Keep parallel task output readable and bounded
- BUILD-109 · Explain a cache miss without exposing input contents
Acceptance criteria
- The report records machine context, fixture revision, task counts, cache hits, and wall-clock timings.
- Each incremental result is compared with the full-check result for the same input state.
- A deliberate shared-type error fails both workflows and is never reported as a valid cache hit.
Implementation constraints
- Present measured numbers with run count and variability.
- Avoid a hard speed claim based on one run.
Verification to include
- Run the documented matrix from an empty cache and reproduce task selection.
- Introduce a dependent type error and confirm the benchmark records failed correctness before reporting speed.
Deliverables
- Benchmark script and correctness-first comparison report
Rollout and recovery
Adopt skipped-task execution only after parity is demonstrated; retain a scheduled full-check path as a diagnostic baseline.
Value of the work
For the engineer: Practice incremental computation, dependency scheduling, cache correctness, and cancellation.
For the team: Inspect whether faster checks preserve the guarantees reviewers depend on.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.