noCV
BMONO-103 · Build the planner

Handle cycles in the downstream impact graph

Practice briefBugAdvanced

Two shared packages depend on each other through development tooling, and recursive traversal never finishes.

Focused work estimate
3h 30m + prerequisites
Priority in the scenario
High
Engineering practice
Graph algorithms · Dependency analysis

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.

Your next step

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 internal tools team maintains eighteen packages. Engineers currently run everything because the affected-package script occasionally misses downstream consumers.

Setup prerequisites

  • Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes.

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

Acceptance criteria

  • Collapse or explicitly track cycles without dropping members.
  • Include transitive dependents once each.
  • Sort output stably regardless of manifest enumeration order.

Implementation constraints

  • Distinguish runtime and development edges in the plan explanation.

Verification to include

  • Resolve a diamond graph with one cycle.
  • Verify a disconnected package stays excluded and traversal terminates.

Deliverables

  • Cycle-safe graph traversal.

Rollout and recovery

Compare results with full package selection; disable selective mode if membership differs.

Value of the work

For the engineer: Practice graph analysis, reproducible commands, and safe developer-tool failure modes.

For the team: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers.

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.