sync-plan

name	sync-plan
description	Sync FEATURES.json and PLAN.md after architecture or scope changes mid-project. Preserves completed feature status while updating not-started features to align with the latest ARCHITECTURE.md and PLAN.md.

Sync Plan with Architecture Changes

You are reconciling the feature plan with architectural changes that happened mid-project. Features already completed should be preserved. Features not yet started should be updated to align with the new architecture.

When to Use

• Architecture changed after features were already planned
• Modules were renamed, merged, or split
• Tech stack decisions changed (e.g., switched database)
• Cross-cutting patterns were updated
• New architectural constraints affect planned features

Process

Step 1: Understand What Changed

1. Read docs/ARCHITECTURE.md — understand the CURRENT architecture
2. Read docs/FEATURES.json — understand the CURRENT feature plan and statuses
3. Read docs/PLAN.md — understand the original plan
4. Read docs/PROGRESS.md — understand what was recently changed and why

Ask the user: "What changed in the architecture and why?" if it's not clear from the docs.

Step 2: Categorize Features by Impact

Sort every feature into one of these buckets:

Category	Action
Complete — no impact	Features already done that aren't affected by the change. Leave as-is.
Complete — affected	Features already done that may need rework due to architecture change. Flag for review, add note, but do NOT change status automatically.
In progress — affected	Features being worked on that are impacted. Add a warning note.
Not started — needs update	Features not yet built that should be updated to align with new architecture. Update acceptance criteria, sprint contracts, module references.
Not started — obsolete	Features that no longer make sense under the new architecture. Mark as "cancelled" with reason.
New features needed	The architecture change introduces work that wasn't planned. Add new features.

Step 3: Update docs/FEATURES.json

For each affected feature:

Not-started features that need updating:

• Update description to reference correct modules/patterns
• Update acceptance_criteria to match new architecture constraints
• Update contract.deliverable and contract.verification
• Update dependencies if module relationships changed
• Add "architecture_revision": "[date] — [summary of change]" field

Completed features that may need rework:

• Do NOT change status from "complete" — the evaluator should assess this
• Add "architecture_note": "Architecture changed on [date]: [what changed]. May need rework — run /evaluate to assess." field

Obsolete features:

• Change status to "cancelled"
• Add "cancel_reason": "[why this feature is no longer needed]"

New features from architecture change:

• Add with F prefix, next available ID number
• Status "not-started"
• Note in description that this was added due to architecture revision

Step 4: Update docs/PLAN.md

Update the Plan to reflect:

• Revised tech stack (if changed)
• Revised feature list (new, updated, cancelled)
• Add a section:

## Architecture Revision — [date]
### What Changed
[Summary of architectural changes]

### Impact on Features
- **Updated**: F003, F005, F007 — [what changed]
- **Cancelled**: F004 — [why]
- **Added**: F016, F017 — [what and why]
- **May need rework**: F001, F002 — [pending /evaluate]

Step 5: Update docs/PROGRESS.md

## Plan Synced with Architecture Changes — [date]
- **Architecture Change**: [summary]
- **Features Updated**: [list of IDs]
- **Features Cancelled**: [list of IDs with reasons]
- **Features Added**: [list of new IDs]
- **Features Flagged for Rework Review**: [list of IDs]
- **Next**: Run /evaluate on flagged features, then /next-feature

Step 6: Report

Summarize:

• How many features were updated, cancelled, added
• Which completed features may need rework (recommend running /evaluate)
• What the next steps are
• Show the updated feature status dashboard

Rules

• NEVER change a completed feature's status — that's the evaluator's job
• NEVER delete features — cancel them with a reason so there's an audit trail
• Preserve completed work — the goal is to align future work, not redo past work
• Document every change — the architecture revision section in PLAN.md is the audit trail
• Be conservative — if unsure whether a completed feature is affected, flag it for review rather than assuming it's fine