# Plan

Version: 1.0.0

## Purpose

Create the smallest implementation plan necessary to safely and verifiably complete the requested work.

The plan must be based on discovered project evidence.

Do not design from generic assumptions when the project already contains relevant patterns.

---

# Before Planning

Confirm that discovery has identified:

```text
OBJECTIVE

CURRENT STATE

DESIRED STATE

CONSTRAINTS

RELEVANT COMPONENTS

EXISTING PATTERNS
```

If critical context is still missing, use Diagnostic Intake before planning.

---

# Form Initial Approach

State the proposed approach in concise terms.

Include:

```text
WHAT WILL CHANGE

WHY THIS APPROACH FITS

WHAT WILL REMAIN UNCHANGED
```

Treat this as a working hypothesis.

---

# Mirror Audit

Before finalizing the plan, audit the initial approach using:

```text
.ai/skills/mirror-audit/SKILL.md
```

Check for:

```text
hidden assumptions

failure modes

edge cases

security

data integrity

compatibility

rollback

maintainability

unnecessary complexity
```

Revise the approach when the audit reveals a real weakness.

---

# Plan Structure

A normal implementation plan should contain:

```text
## Objective

[...]

## Files / Components

- [...]
- [...]

## Implementation Sequence

1. [...]
2. [...]
3. [...]

## Risks

- [...]

## Verification

- [...]

## Rollback

[...]  // only when relevant
```

---

# Scale to Complexity

## Fast Path

For trivial work:

```text
1. make change
2. verify
```

Do not generate a formal architecture plan.

---

## Standard Path

For normal feature work:

```text
1. inspect affected component
2. modify implementation
3. update related tests
4. verify
5. review
```

---

## High-Risk Path

For migrations, security, infrastructure, destructive changes, or major architecture:

include:

```text
preconditions

backup

rollback

execution order

verification gates

recovery

red-team review
```

---

# Dependencies

Identify dependencies that affect sequencing.

Example:

```text
database schema
    ↓
data access layer
    ↓
service
    ↓
controller
    ↓
tests
```

Do not order work arbitrarily when dependencies require a specific sequence.

---

# Verification Plan

Specify how each meaningful result will be verified.

Prefer:

```text
existing test

targeted test

build

static analysis

smoke test

query

health check

direct execution
```

Avoid:

```text
verify that it looks right
```

when stronger evidence is available.

---

# Rollback

Define rollback when:

```text
change is destructive

production state changes

schema changes

data transforms

deployment can partially fail

external state changes
```

Do not create elaborate rollback plans for trivial reversible edits.

---

# Scope Control

Explicitly identify what the implementation will NOT change when scope drift is likely.

Example:

```text
This change will add the import status reporting.

It will not replace the existing Access import mechanism.
```

---

# Avoid

Do not:

```text
create plans longer than the work

introduce architecture not justified by the request

include speculative future features

list every theoretical risk

repeat discovery details unnecessarily
```

---

# Output

Return the finalized implementation plan.

If the plan reveals a blocker, surface it before implementation.

Otherwise proceed according to the current task's execution mode.