feat(migrate-optimizely): add migration scope policy and bulk execution mode

[fabriziodemaria]

Why

A migration test against a large real-world summary export (360 flags) surfaced several problems with the current Phase 1 flow:

• The export marked hundreds of long-dead experiments as status: running; treating them as live A/B tests would exclude ~90% of the account, while migrating them with the skill's silent 50/50 split assumption would corrupt metrics for any experiment actually in use.
• Flags whose arms all serve the same variation (a common CMS pattern) were BLOCKED instead of migrated.
• Per-flag opt-in checkboxes + per-flag confirmation prompts don't scale to 300+ flags.
• The plan file's Progress table wasn't updated during execute, breaking resume.
• Gap reports leaked internal vocabulary ("B2 flattened per-flag summary export") that reviewers couldn't act on.

What

SKILL.md

• New Migration Scope Policy section: every flag is classified (stable rollout / same-variant experiment / stale vs live A/B test / partial-% rollout / bandit / paused / blocked) with safe defaults and a live-vs-stale confirmation driven by days_running and other staleness signals — never by export status alone.
• New plan step 2 "Review migration scope": counts-first scope summary in Optimizely terminology + plain-English gap reporting rules (what's missing, how many flags, what it means, what unblocks it).
• Duplicate variation names collapse to a single fully-rolled-out variant (no split between identical arms) instead of blocking.
• No more silent even-split assumption: splits are only written with an explicit, recorded source (full ruleset API or user-confirmed UI numbers); unknown-split experiments follow the scope policy.
• New "migrate all eligible" execution mode for large migrations (Phase 1 is a shadow deployment — nothing resolves flags until Phase 2), with the interactive review-each mode still available. Checkbox pre-ticking follows the confirmed scope.
• Mandatory plan-file updates during execute (Action line + Progress table after every flag, both modes, flag and code plans) — the plan is the resume state.
• Synthetic UUID flag keys now surface the Optimizely description as the display name everywhere and carry it into the Confidence flag.
• Documented summary-export blind spots (whitelists/forced variations, exclusion groups, project archived status) as known unknowns to raise with the customer.
• Smaller fixes: archived/paused questions only asked when the data actually has those fields; overview box states scope exclusions up front and scopes "one PR per flag" to Phase 2; bucketing-ID step asks authenticated vs anonymous IDs; unknown export fields trigger an Optimizely docs lookup instead of a guess; plan template gains an Optimizely→Confidence glossary and an explicit Excluded-flags table.

Test fixtures

• Four new synthetic summary-export flags exercising the new scope categories: duplicate-name collapse, a stale "running" A/B test (live-vs-stale question), a stable 100% rollout, and a partial 40% rollout — kept in sync between summary-export-sample.json (file path) and server.py (fake-API path), with README coverage table updated.

All fixture data is synthetic; no customer data is included.

Testing

• server.py imports and serves all 10 summary-scenario flags (_flag_public smoke over both datasets)
• summary-export-sample.json parses and remains an append-only change
• python3 -m py_compile clean on all fixture scripts

🤖 Generated with Claude Code