Compute affected packages from both dependency directions
Changing a shared type package runs its own tests but skips three consumers that compile against the changed contract.
- Focused work estimate
- 2h 30m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Dependency graphs · Change analysis
Estimated field mix
- DevOps60%
- Developer tooling40%
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 fictional TypeScript monorepo has twelve packages and a local CI simulator. Pull requests wait for redundant work, stale caches occasionally pass broken changes, and superseded runs continue consuming executors. Create synthetic package graphs and fake check APIs; no hosted CI credentials or production repositories are supplied.
Setup prerequisites
- Dependency graphs
- Process exit codes
- Test isolation
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Changed packages and transitive consumers enter the affected set
- Deleted and renamed files map to their owning package
- Global configuration changes select the declared full set
Implementation constraints
- Use the synthetic graph and explicit ownership rules; filename substring guesses are insufficient.
Verification to include
- Change a leaf, shared library, and root configuration and compare selected packages.
- Create a dependency cycle fixture and fail analysis without silently dropping nodes.
Deliverables
- Affected-graph selector and graph fixtures
Rollout and recovery
Run selection in report-only mode beside the current full pipeline.
Value of the work
For the engineer: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints.
For the team: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes.
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.