Plan Template¶

Use this structure for the remediation plan output. Adapt depth to scope — a small remediation (3 phases) needs less structure than a full production readiness plan (8+ phases).

Title¶

{Project Name} — {Plan Type} Plan

Examples: "My Existing App — Production Readiness Plan", "My Existing App — Decoupling Plan", "My Existing App — Security Remediation Plan"

**Date:** {date} (last updated)
**Scope:** {one-sentence scope}
**Companion doc:** {link to gap analysis or audit report}
**Target state:** {one-sentence target}

1. Current State — Summary¶

1.1 What Exists¶

Table summarising each layer (API, web, CI, storage, auth, deployment, observability, etc.) with status (✅/⚠️/❌) and one-line detail.

1.2 Architecture Strengths (Preserve)¶

Bullet list of patterns that must NOT be regressed during remediation. Extracted from the gap analysis "where ahead" section.

2. Target Architecture¶

ASCII diagram showing the deployed topology: containers, services, external dependencies (auth provider, database, key vault, telemetry).

Include any topology decisions (single vs multi-container, sidecar pattern, etc.) with the recommendation and rationale.

3. Execution Plan¶

One subsection per phase. Each phase has:

Phase N — {Name} {Status Emoji} {STATUS}¶

Brief description of the phase goal.

Task table:

#	Task	Effort	Jira	Status
N.1	Action verb + target — Detail.	Small	—	⬜ Not started

Phase deliverables (bullet list of concrete artifacts).

Status Emoji Key¶

⬜ NOT STARTED
🔶 IN PROGRESS
✅ COMPLETE

4. Cross-Pollination Opportunities¶

Table of practices that should flow from the assessed codebase to the broader portfolio (or vice versa). Only include if the gap analysis identified these.

#	Practice	Direction	Effort	Notes
C.1	Name	Source → Target	Small	Why it matters

5. Key Decisions Required¶

#	Decision	Options	Recommendation	Status
D.1	Short name	(A) Option. (B) Option.	Recommended with rationale.	⬜ Pending

6. Dependency Map¶

ASCII diagram showing phase ordering:

Phase 0
    │
    ├──▶ Phase 1 ──▶ Phase 2
    │                    │
    │         ┌──────────┤
    │         ▼          ▼
    │    Phase 3    Phase 4
    ...

State the critical path and what can be parallelised.

7. Risk Register¶

Risk	Impact	Likelihood	Mitigation
...	...	...	...

8. Estimated Effort¶

Phase	Effort	Dependencies	Status
Phase 0 — Name	X–Y days	None	⬜ Not started
...	...	...	...
Total	X–Y weeks	N developers

Phase effort is wall-clock (days/weeks) for human team capacity — do not sum T-shirt labels into day counts. When this plan moves to active WIP execution, add a *.effort.json sidecar per plan-effort-estimate and re-size with the Fibonacci scale — see effort-scales.yaml.

9. Success Criteria¶

Milestone	Criteria	Target
Dev deployment	Specific, measurable criteria	End of Phase N
Production go-live	Specific, measurable criteria	End of Phase M

10. Comparison (Optional)¶

If this plan is part of a portfolio with other similar plans, include a comparison table showing how this plan differs in scope, approach, effort, and risk.

Appendix (Optional)¶

Detailed module inventories (for code migration plans)
Endpoint catalogues (for API plans)
Dead code inventories (for cleanup plans)