Break one circular dependency between modules
Two modules that import each other, separated so the build order is deterministic.
The ticket
Break one import cycle between two modules.
Acceptance criteria
- The dependency graph has no cycle between the two modules
- Shared types or helpers move to a module both can depend on
- No behaviour changes, proven by the existing tests
- A rule blocks the cycle from returning
What lands as proof
A dependency graph before and after, plus a rule that fails if the cycle is reintroduced.
Why teams defer it
- Cycles work at runtime until they do not, and the failure is usually an obscure undefined at import time.
- Breaking one means deciding where shared code belongs, which is an architecture decision rather than a refactor.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: break one import cycle between two modules. 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 dependency graph acyclic, build order deterministic, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops once the plan is written. Somebody reads the approach and approves it before any code exists, which is the cheapest moment to redirect the work.