Extract a shared module into its own package
Code copied or reached into across boundaries, extracted into a package with its own tests and entry point.
The ticket
Extract a shared module into its own package with its own tests and public entry point.
Acceptance criteria
- The package builds and tests on its own
- Consumers import only the public entry point
- No consumer reaches into the package internals
- The extraction changes no behaviour
What lands as proof
A standalone build and test run for the new package, plus consumers passing against its public surface only.
Why teams defer it
- Extraction touches every consumer, so it looks risky even when it is mechanical.
- Deciding the public surface is a design question that outlasts the ticket.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: extract a shared module into its own package with its own tests and public entry point. 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 package builds standalone, consumers import the entry point only, 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.