Monolith to Microservices

List my CoreStory projects. I need the project for [SystemName].
Then list all conversations — I need the decomposition thread
and the architecture decision thread.

Retrieve the conversation history from our decomposition planning
(conversation [conversation_id]). I need the details for
work package [WP-XXX]:
1. Components included in this extraction
2. Dependencies on other work packages
3. Hard blockers (what must complete first)
4. The Transform/Coexist/Eliminate plan
5. Acceptance criteria

Create a CoreStory conversation titled
"[Extraction] SystemName - ServiceName (WP-XXX)".
Store the conversation_id for all subsequent queries.

send_message: "For the [ComponentName] extraction (WP-XXX),
identify the precise domain boundary within the monolith:

1. Which modules, packages, or namespaces contain the logic
   for this domain?
2. Which classes/functions are entirely within this domain?
3. Which classes/functions are shared with other domains
   (used by this component AND other components)?
4. Which database tables are owned by this domain (only
   accessed by this component)?
5. Which database tables are shared (accessed by this component
   AND other components)?

Distinguish between:
- MOVE: code that belongs entirely to the new service
- SHARE: code currently shared that needs to be duplicated or
  extracted into a shared library
- LEAVE: code that stays in the monolith"

send_message: "What hidden coupling exists between [ComponentName]
and the rest of the monolith?

1. Direct function/method calls from other modules INTO this
   component — who depends on us?
2. Direct function/method calls FROM this component into other
   modules — who do we depend on?
3. Shared in-memory state (singletons, caches, thread-local storage)
4. Shared configuration values that this component reads
5. Implicit coupling through database triggers, stored procedures,
   or materialized views
6. Event/callback registrations where this component listens
   to events from other components or vice versa

For each coupling point, classify:
- Can be replaced with an API call (synchronous)
- Can be replaced with an event/message (asynchronous)
- Must be resolved before extraction (hard coupling)"

send_message: "Given the domain boundary and coupling analysis,
is this service extraction feasible as defined?

1. Can the extracted service function independently (with API
   calls replacing direct coupling)?
2. Can the monolith function correctly after this code is removed
   (with API calls to the new service replacing internal calls)?
3. Are there any circular dependencies between this component
   and the monolith that would prevent clean extraction?
4. Is the boundary a clean domain boundary (aligned with a
   bounded context) or does it cut across domain logic?

If the boundary needs adjustment, what's the recommended change?"

send_message: "Map all database interactions for [ComponentName]:

1. Tables OWNED by this component (only this component writes to them)
2. Tables READ by this component but OWNED by others (read-only access)
3. Tables WRITTEN by this component AND other components (shared writes)
4. Foreign key relationships between owned tables and other tables
5. Stored procedures, views, or triggers that cross the component boundary
6. Any direct SQL queries that join across component boundaries

For tables with shared writes (#3), this is the critical challenge.
Identify which component should own each shared table in the target
architecture."

send_message: "For each shared data dependency, recommend a
decomposition strategy:

Option A: Database-per-service (full separation)
- Each service gets its own database/schema
- Data that was joined becomes API calls
- Best for: cleanly separable data with clear ownership

Option B: Shared database with schema ownership
- One database, but each service owns specific schemas/tables
- Access control enforces ownership boundaries
- Best for: transitional state during migration, complex joins

Option C: Event-driven synchronization
- Services maintain their own copies of shared data
- Changes propagate via events (CDC, outbox pattern, domain events)
- Best for: read-heavy shared data where eventual consistency is acceptable

Option D: API-mediated access
- The owning service exposes the data via API
- Consuming services call the API instead of querying directly
- Best for: shared data with clear ownership and low-frequency access

For each shared table, which strategy applies? Consider:
- Query frequency (how often is this data accessed?)
- Consistency requirements (must reads see latest writes?)
- Join complexity (is this data joined with other service's data?)
- Volume (how much data, how fast does it change?)"

send_message: "For the selected data decomposition strategy,
plan the migration:

1. What data needs to move? (tables, rows, schemas)
2. Migration sequence — can data be migrated incrementally
   or must it be a bulk migration?
3. During the Coexist phase, how is data kept in sync between
   the monolith's database and the new service's database?
4. What happens to foreign keys that cross the service boundary?
5. What's the rollback plan if the data migration fails?
6. Are there any data consistency windows where the system
   is in an inconsistent state? How long, and is it acceptable?"

send_message: "Identify all entry points into [ComponentName]
within the monolith:

1. HTTP endpoints (routes, controllers) — what URLs currently
   route to this component's logic?
2. Internal method calls from other modules — what functions
   does the monolith call into this component?
3. Background jobs or scheduled tasks — what jobs execute
   this component's logic?
4. Event handlers — what events trigger this component?
5. CLI commands or admin interfaces

For each entry point:
- Can it be routed through the façade (API gateway/reverse proxy)?
- Does it need an adapter (e.g., converting an internal method
  call to an HTTP/gRPC call)?
- Does it need to remain in the monolith temporarily with a
  thin wrapper that calls the new service?"

send_message: "For each interaction between the extracted service
and the remaining monolith, recommend a communication pattern:

Synchronous (REST/gRPC):
- Best for: request-response patterns, queries, operations that
  need immediate confirmation
- Risk: introduces latency, creates runtime coupling

Asynchronous (events/messaging):
- Best for: notifications, data propagation, operations that
  don't need immediate response
- Risk: introduces eventual consistency, harder to debug

For each interaction:
1. What is the current pattern in the monolith? (direct call,
   shared memory, database polling, etc.)
2. What should the modernized pattern be?
3. What is the latency tolerance?
4. What happens if the call fails? (retry, fallback, circuit breaker)
5. Is idempotency needed? (can the same message be processed twice safely?)"

send_message: "The anti-corruption layer translates between
the monolith's internal model and the new service's model.

1. Where do the models diverge? (different field names, different
   data types, different enumerations, different units)
2. Where does the new service intentionally improve on the
   monolith's model? (better naming, cleaner types, explicit
   nullability)
3. What translation is needed at each integration point?
4. Should the anti-corruption layer live in the new service,
   in the monolith, or in the façade?

The anti-corruption layer is temporary — it will be removed
when all consumers have migrated to the new service's model.
Design it to be easy to remove."

send_message: "Generate a delta spec for extracting
[ComponentName] as a standalone service:

1. What the service does (business rules from Phase 2 inventory)
2. API contract (endpoints, request/response formats, authentication)
3. Data model (owned tables, with any schema improvements)
4. Integration points (how it communicates with other services
   and the remaining monolith)
5. Non-functional requirements (latency, throughput, availability)

The delta spec should capture what CHANGES from the monolith
to the extracted service — not a full system description.
Focus on the boundary: new APIs that replace internal calls,
data that moves, behavior that's preserved."

send_message: "For the [ComponentName] service implementation,
guide the extraction:

1. Which files from the monolith contain the logic to extract?
2. What modifications are needed to make this logic standalone?
   (remove internal dependencies, add API layer, add configuration)
3. What new infrastructure code is needed? (service bootstrap,
   health checks, configuration loading, database connection)
4. What test infrastructure is needed? (service-level tests,
   contract tests with the monolith facade)
5. What deployment configuration is needed? (Dockerfile,
   Kubernetes manifests, CI/CD pipeline)"

send_message: "Design the Coexist phase configuration:

1. Façade routing rules — which requests go to the new service,
   which stay in the monolith?
2. Can we start with a percentage-based rollout (e.g., 10% to
   new service, 90% to monolith)?
3. How do we compare responses between old and new? (shadow
   traffic, dual-write with comparison, manual sampling)
4. What monitoring is needed to detect behavioral differences?
   (error rates, latency percentiles, business metrics)
5. What's the circuit breaker configuration? (when does the
   façade automatically fall back to the monolith?)
6. How long should the Coexist phase last before proceeding
   to Eliminate?"

Verify behavioral equivalence for [ComponentName] using the
Business Rules Inventory from Phase 2. Compare the extracted
service against the monolith's implementation.

send_message: "Plan the Eliminate phase for [ComponentName]:

1. Which code in the monolith should be removed?
   (controllers, services, repositories, models, configuration)
2. Which database tables/schemas should be dropped or
   transferred to the new service's database?
3. What façade routing rules should be updated?
   (remove the monolith path, keep only the service path)
4. What anti-corruption layer code should be removed?
5. Are there any other monolith components that referenced
   the removed code? How are those references updated?
6. What integration tests need to be updated to point to
   the service instead of the monolith?"

send_message: "After removing [ComponentName] from the monolith:

1. Does the monolith still build and pass all remaining tests?
2. Does the extracted service continue to function correctly
   without the monolith code?
3. Are all integration points working? (test each consumer
   of the extracted service)
4. Is monitoring showing healthy metrics? (error rates,
   latency, throughput)
5. Is the data migration complete and consistent?
6. Can the system handle the full production load on the
   extracted service?"

Rename the conversation to
"RESOLVED - [Extraction] SystemName - ServiceName (WP-XXX)".

send_message: "Analyze the current transaction boundaries in [ComponentName].
Which operations currently execute within a single database transaction
but will span multiple services in the target architecture?

For each operation:
1. What data is written across what will become service boundaries?
2. What is the current rollback behavior if the operation fails midway?
3. What compensating actions would be needed in a saga?
4. Is the operation's consistency requirement strict (must be immediate)
   or eventual (can tolerate brief inconsistency)?"