Decomposition & Sequencing

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

Retrieve the conversation history from our architecture decision
(conversation [conversation_id]). Summarize:
1. Selected strategy per component (from the ADR)
2. Target architecture — service boundaries, communication patterns,
   data architecture
3. Migration scope — which components are in scope for modernization
4. Key constraints and risks identified

Create a CoreStory conversation titled
"[Decomposition] SystemName - Migration Planning".
Store the conversation_id for all subsequent queries.

send_message: "For each component identified in the target architecture
for modernization, determine whether it can be migrated independently
or must be migrated together with other components. Consider:

1. Which components share database tables or data stores that cannot
   be split without migrating both sides simultaneously?
2. Which components have synchronous call dependencies that would
   break if only one side is modernized?
3. Which components share business logic (duplicated or via shared
   libraries) that must be updated together?

Group the components into migration units — the smallest sets that
can be independently deployed. A migration unit might be a single
component or a cluster of tightly coupled components."

send_message: "For each migration unit you identified, define the
work package boundary:
1. What is included in this work package (components, data stores,
   integration points)?
2. What is excluded (remains on the legacy side during this migration)?
3. What temporary integration points (anti-corruption layers, adapters,
   data sync mechanisms) are needed between the migrated and
   non-migrated sides?
4. What is the expected outcome — what does 'done' look like for
   this work package?"

send_message: "For each proposed work package, validate that it can
actually be deployed independently:
1. Can the modernized component function correctly while the rest
   of the system remains on the legacy platform?
2. Can the legacy system function correctly after this component
   is extracted?
3. What data consistency guarantees are needed during the coexistence
   period?
4. Is there a clean rollback path if the modernized component fails?"

send_message: "For each work package, what are the dependencies on
other work packages? Identify:
1. Hard dependencies — WP-X cannot start until WP-Y is complete
   (e.g., WP-Y creates an API that WP-X will consume)
2. Soft dependencies — WP-X is easier if WP-Y is done first, but
   can proceed independently with additional temporary integration work
3. Shared infrastructure dependencies — both WP-X and WP-Y require
   the same infrastructure change (e.g., API gateway, event bus,
   service mesh)

Map these as a dependency graph. Identify the critical path — the
longest chain of hard dependencies that determines the minimum
total migration timeline."

send_message: "Map the shared data dependencies across work packages:
1. Which work packages share database tables?
2. For each shared table, which work package should 'own' it in the
   target architecture?
3. What data synchronization is needed during the coexistence period
   for each shared table?
4. Are there any cross-work-package foreign key relationships that
   must be maintained during migration?"

send_message: "What shared infrastructure must be in place before
any work packages can execute? Identify:
1. API gateway or service mesh (if the target architecture requires one)
2. Event bus or message broker (if moving from sync to async communication)
3. Service registry and discovery
4. Centralized logging/monitoring for the new services
5. CI/CD pipeline changes for the new deployment model

These are 'Step 0' work packages that must be completed before
component migration begins."

send_message: "Given the dependency graph, what is the recommended
order for executing these work packages? Consider:
1. Dependency chain — what must be done before what
2. Risk sequencing — should high-risk components go early (retire
   risk) or late (learn from easier migrations first)?
3. Business value — which components deliver the most value when
   modernized? Can we prioritize early wins?
4. Team capacity — are there work packages that can run in parallel
   on different teams?
5. Temporary integration cost — which sequence minimizes the total
   amount of anti-corruption layer and adapter code needed?

Provide a recommended sequence with rationale for the ordering.
Identify which work packages can run in parallel."

send_message: "Which work packages are 'quick wins' — low coupling,
high readiness score, high business value, and few dependencies?
These are candidates for the first migration sprint. Proving the
methodology works on a quick win builds team confidence and
organizational support."

send_message: "For the recommended sequence, identify the key risk
at each step:
1. What could go wrong at this step?
2. What is the blast radius if this work package fails?
3. Is there a clean rollback path?
4. What temporary integration complexity does this step introduce?

Flag any steps where the risk is concentrated — these need
additional verification or smaller batch sizes."

send_message: "For each work package in the sequence, produce a
structured definition:

1. Work Package ID and name
2. Component(s) included
3. Strategy (Refactor / Re-architect / Replatform / etc.)
4. Dependencies (which work packages must complete first)
5. Blocked by (hard blockers)

For the Transform phase:
- Delta spec scope (what changes from legacy to target)
- Target patterns (architectural patterns to follow)
- Estimated files to create or modify
- Test strategy (unit, integration, behavioral)

For the Coexist phase:
- Façade/proxy approach (how traffic is routed between old and new)
- Data migration/sync strategy (if applicable)
- Rollback plan (how to revert if issues arise)
- Verification criteria (what must pass before proceeding to Eliminate)

For the Eliminate phase:
- Legacy components to decommission
- Façade/adapter removal (what temporary code gets cleaned up)
- Final verification (behavioral equivalence confirmation)

Also estimate:
- Relative effort (low / medium / high / very high)
- Duration estimate (in sprints, if possible)
- Team/skill requirements"

send_message: "For each work package, define the acceptance criteria
that must be met before it's considered complete:
1. Functional criteria — what must the modernized component do?
2. Behavioral equivalence — which business rules from the Phase 2
   inventory must be verified?
3. Performance criteria — latency, throughput, resource utilization
   targets
4. Integration criteria — what must work with adjacent components?
5. Operational criteria — monitoring, alerting, deployment pipeline"

Create a Jira epic titled "[Modernization] SystemName - Migration Execution".
Set the description to a summary of the migration plan:
- Target architecture overview
- Number of work packages
- Estimated timeline
- Link to the CoreStory assessment and architecture decision conversations

For each work package, create a Jira story under the migration epic:

Title: "[WP-XXX] Transform: [ComponentName]"
Description:
- Strategy: [Refactor / Re-architect / etc.]
- Dependencies: [WP-YYY, WP-ZZZ]
- Blocked by: [WP-AAA must complete first]
- Delta spec scope: [what changes]
- Target patterns: [architectural patterns]
- Test strategy: [unit, integration, behavioral]
- Acceptance criteria: [from Step 5]

Labels: modernization, [strategy], [component-domain]
Priority: [based on sequence position]

Then create sub-tasks for the Coexist and Eliminate phases:
- "[WP-XXX] Coexist: [ComponentName] — façade setup and parallel run"
- "[WP-XXX] Eliminate: [ComponentName] — legacy decommission and cleanup"

For each work package dependency, create a Jira issue link:
- WP-002 "is blocked by" WP-001
- WP-003 "is blocked by" WP-001

This makes the dependency chain visible in the Jira board and
prevents work packages from being started out of order.

For each work package, create a Linear issue with:
- Title: "[WP-XXX] [ComponentName] — [Strategy]"
- Description: Paste the work package scope, acceptance criteria, and dependencies
- Labels: "modernization", "[strategy]" (e.g., "refactor", "replatform")
- Cycle: Assign to the appropriate migration wave
- Sub-issues:
  1. "Transform: [ComponentName]" — linked to delta spec
  2. "Coexist: [ComponentName]" — includes façade/routing setup and verification criteria
  3. "Eliminate: [ComponentName]" — includes legacy decommission checklist

Set blocking relationships between sub-issues (Transform blocks Coexist blocks Eliminate)
and between work packages (per the dependency map from Step 4).

Rename the conversation to
"RESOLVED - [Decomposition] SystemName - Migration Planning".

## Work Package: [Component Name]

**ID:** WP-001
**Component:** [Name]
**Strategy:** [Strangler Fig / Branch by Abstraction / Parallel Run] — [Refactor / Re-architect / Replatform]
**Migration Unit:** [Standalone / Cluster with WP-002, WP-003]
**Dependencies:** [WP-004, WP-005]
**Blocked by:** [WP-003 must complete first]
**Sequence Position:** [1st / 2nd / parallel with WP-002]
**Estimated Effort:** [Low / Medium / High / Very High]
**Estimated Duration:** [X sprints]

### Transform
- **Delta spec scope:** [what changes from legacy to target]
- **Target patterns:** [architectural patterns to follow]
- **Estimated files to create/modify:** [count]
- **Test strategy:** [unit, integration, behavioral]
- **Spec-Driven Development reference:** Use the delta spec approach from
  [Spec-Driven Development](/playbooks/spec-driven-development)

### Coexist
- **Façade/proxy approach:** [how traffic is routed between old and new]
- **Data migration strategy:** [if applicable — sync mechanism, CDC, dual-write]
- **Rollback plan:** [how to revert if issues arise]
- **Verification criteria:** [what must pass before proceeding to Eliminate]
- **Behavioral Verification reference:** Use the verification approach from
  [Behavioral Verification](/playbooks/modernization/behavioral-verification)

### Eliminate
- **Legacy components to decommission:** [list]
- **Façade removal:** [what temporary integration code gets cleaned up]
- **Final verification:** [behavioral equivalence confirmation]
- **Sign-off required:** [domain expert + tech lead]

### Acceptance Criteria
- [ ] All business rules from Phase 2 inventory verified for this component
- [ ] Performance meets or exceeds legacy baseline
- [ ] Integration with adjacent components confirmed
- [ ] Monitoring and alerting operational
- [ ] Rollback tested and documented