stash init: offer plan-or-implement choice before handoff

[coderdan]

Summary

After stash init completes the install/detection steps, immediately rolling into implementation isn't always what the user wants. User feedback shows that planning first is often the better default — especially for migrate-existing-column work where the wrong order of operations risks data loss.

We should add a step before the handoff where the user picks between:

1. Write a plan first (default / recommended)
2. Go straight to implementation (current behaviour)

Both routes still terminate at one of the existing handoff targets (Claude Code, Codex, AGENTS.md, CipherStash Agent / wizard). The difference is the prompt the agent receives — a planning prompt that produces a reviewable plan file, vs. the current implementation setup-prompt.

Why

• Direct user feedback: `stash init` is too eager to implement.
• The migrate-existing-column flow spans multiple deploys and is hard to undo if rushed; a plan step gives the user a checkpoint.
• Aligns with the doctrine we already encode in skills ("orient before you act").
• Pairs with the planned setup-prompt accuracy fix (followups §4.3) — the planning prompt should orient + verify, not assert what init did.

Proposed flow

```
stash init
…existing steps (authenticate, resolve db, install deps, install EQL, gather context)
→ How to proceed? [NEW STEP]
(•) Write a plan first (recommended)
( ) Go straight to implementation
→ Choose handoff target
(•) Claude Code / Codex / AGENTS.md / CipherStash Agent
→ next-steps
```

When plan-first is chosen, the handoff invokes the agent with a planning prompt template:

• Tell the agent to produce a plan file (e.g. `docs/plans/encryption-.md`).
• The plan covers: which columns to encrypt, which lifecycle path applies (path 1 = new column / path 3 = migrate existing), the deploy ordering, and any project-specific risks.
• Agent should not make code changes during this phase.
• After the plan is written, the user re-runs the implementation handoff (or a new `stash init --resume-from-plan` shortcut).

When implementation is chosen, behaviour matches today.

Handoff targets and planning support

• Claude Code — invoke with the plan-mode-style prompt (or pass `--mode plan` once we have a planning prompt template).
• Codex — same idea; prompt template differs because of AGENTS.md conventions.
• CipherStash Agent / wizard — needs a planning prompt fetched from the gateway. Track gateway-side work separately if it can't be done same-PR (cross-references followups §2.1).
• AGENTS.md — write an AGENTS.md whose content directs the assistant to plan first.

Code touchpoints

• `packages/cli/src/commands/init/steps/how-to-proceed.ts` — split into two prompts (mode, then target) or chain a new step before this one.
• `packages/cli/src/commands/init/lib/setup-prompt.ts` — add a planning-mode variant of the setup prompt.
• `packages/cli/src/commands/init/types.ts` — add a `mode: 'plan' | 'implement'` field on `InitState`.
• Each `handoff-*` step reads the mode and selects the correct prompt template.

Acceptance criteria

• New step asks the user to choose plan-first vs. straight-to-implementation, defaulting to plan-first.
• All four handoff targets respect the mode choice and use a different prompt template per mode.
• Planning prompt produces a plan file at a known location and does not make code changes.
• Existing "go straight to implementation" behaviour is preserved bit-for-bit when that mode is selected.
• Tests cover both branches for at least the Claude/Codex/AGENTS.md targets.

Related

• Followups doc §4.3 (setup-prompt accuracy) — should be co-implemented; the planning prompt should not assert what init did.
• Followups doc §2.1 (wizard gateway prompt template) — gateway needs its own planning prompt; coordinate.