Show why a task is selected after a file change
Changing packages/shared/types.ts reruns one app but not its sibling. Build a changed-file planner that includes affected dependents and prints the reason for each selected task.
- Focused work estimate
- 1h 45m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Dependency analysis · Incremental builds · Git changes
Estimated field mix
- Developer tooling100%
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.
Acceptance criteria
- Changes under a shared package select all configured downstream checks.
- A root configuration change selects the documented full validation set.
- Deleted files and renamed files are handled using both old and new affected paths.
Implementation constraints
- Sort explanation paths for reproducible output.
Verification to include
- Change shared types and inspect both application check reasons.
- Delete a file from one leaf package and confirm unrelated leaf tasks remain unselected.
Deliverables
- Affected-task planner and explanation output
Rollout and recovery
Compare selection with full checks in report-only mode before using it to skip work.
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.