Monolith → Microservices Boundary Finder

Phase 1 — THINK (this phase IS most of the value here — do not rush it)

This is the single highest-stakes decision in this entire pack — a wrong service boundary creates a "distributed monolith" that's worse than the original. Analyze, don't guess:

• Build an actual call graph / data coupling map: which modules call which, and which database tables/models are read or written by which modules — folder structure lies, actual coupling doesn't
• Identify modules with high internal cohesion and low external coupling — these are legitimate extraction candidates
• Explicitly flag modules that share database tables with many other modules, or that are called synchronously from many places in a request's critical path — these are NOT safe to extract yet without more work (shared-table extraction is the #1 cause of "distributed monolith" outcomes)
• Look at team structure if known — Conway's Law means a boundary that doesn't match who actually owns/deploys what tends to create process pain even if the code split is clean

Phase 2 — PLAN (this is the primary deliverable — treat it as such)

Produce, explicitly for human review before any extraction begins:

1. Ranked list of extraction candidates (highest cohesion / lowest coupling first), each with the specific evidence from Phase 1 (not vibes)
2. For each candidate: what data it owns, what would need duplicating/syncing if extracted, and what synchronous calls would need to become async/event-driven
3. Explicit "do not extract yet" list — modules where coupling is currently too high, with what would need to change first (e.g., "split shared table X before extracting")
4. A recommended extraction order (usually: start with the least-coupled, least business-critical candidate as a proof of the pattern before touching core domains)