legacy-plan

name	legacy-plan
description	Use when running Step 3 of legacy refactoring protocol — generates PLAN.md for module migration. Two phases — skeleton (3 sections only) and finalize (full plan from green tests). Triggers on '/legacy-plan <module> --phase=skeleton', '/legacy-plan <module> --phase=finalize', or when user asks to 'написати скелет плану', 'дописати план з тестів'.
argument-hint	<module-name> --phase=skeleton|finalize
allowed-tools	Read, Write, Bash
disable-model-invocation	false

legacy-plan — Step 3.1 (skeleton) і 3.3 (finalize)

Один skill з двома фазами. Між ними — /legacy-tests (окремий skill). Skeleton має тільки те, що Step 3 знає до тестів. Finalize заповнюється з зелених тестів, не зі здогадок.

Аргументи

• <module-name> — імʼя нового модуля
• --phase=skeleton — фаза 3.1 (5-10 хв у Plan mode)
• --phase=finalize — фаза 3.3 (після зелених тестів)

Phase 1: skeleton

Inputs

• SPIKE.md (з Step 1)
• LEGACY/<module>.md (з Step 2.1)
• CRITIC.md (з Step 2.2)

Output: PLAN.md з 3 заповненими + 3 порожніми секціями

# PLAN — <module-name>

## 1. Чому цей модуль  ✅ (з SPIKE.md)
- module: <module-name>
- критерії: churn=<X>, debt=<Y>, isolation=<Z>, spike verdict=<YES/RISKY>
- скільки часу: <1-2 тижні>

## 2. Що будуємо  ✅
internal/<module-name>/
  ├── domain/      <list of entities + sentinel errors>
  ├── app/         <list of UseCases>
  ├── infra/       <list of Adapters>
  └── ports/       handler.py · dto.py · errors.py

Public interface (без змін, з LEGACY/<module>.md секція 1):
- <signature>
- <signature>

## 3. Що НЕ чіпаємо у цьому циклі  ✅ (з CRITIC.md "невизначені" + LEGACY секція 5)
- <item> — причина: <hypothesis>, окремий цикл
- <item> — причина: <hypothesis>

## 4. Поведінка яку зберігаємо
TBD — заповнюється у --phase=finalize з зелених тестів

## 5. Шматки міграції
TBD — заповнюється у --phase=finalize з блоків параметризованих тестів

## 6. Відкат
TBD — заповнюється у --phase=finalize

Phase 2: finalize

Inputs

• PLAN.md skeleton (з Phase 1)
• tests/<module>/{contract,characterization,architecture}/ (з /legacy-tests)
• Результат pytest tests/<module> (має бути зелений)

Output: PLAN.md повний

Доповнює секції 4-6:

## 4. Поведінка яку зберігаємо  ✅ (з зелених тестів)
- 1 параметризований кейс = 1 пункт
- ...

## 5. Шматки міграції  ✅
- [ ] Register · 1 коміт · domain.User + RegisterUseCase + UsersRepo.Insert + EmailSender.SendWelcome
- [ ] VerifyEmail · 1 коміт · ...
- [ ] ResetPassword · 1 коміт · ...

(або інша стратегія chunking — див. лекцію 4.9 секція Step 4)

## 6. Відкат  ✅
- Register cutover зламається → `git revert <hash>` + один рядок у container.py
- VerifyEmail зламається → теж
- ResetPassword зламається → теж

Acceptance criteria

Skeleton

• 3 заповнені + 3 порожні секції
• Секція 3 («Що не чіпаємо») має ≥2 пункти з причиною
• Секція 2 має повний public interface

Finalize

• Усі 6 секцій заповнені
• «Поведінка» = 1-в-1 з зелених тестів (кожен parametrize-кейс окремий пункт)
• «Шматки міграції» — checklist - [ ] для кожного use case
• pytest зелений перед finalize (skill попереджає, якщо ні)

Examples

/legacy-plan account --phase=skeleton
/legacy-tests account
pytest tests/account/
/legacy-plan account --phase=finalize

Anti-patterns

• Не заповнюй «Поведінка» зі здогадок — тільки з зелених тестів. Помилка тут стає silent — рефакторинг проходить, але «зберігає» поведінку, якої немає.
• Не пропускай skeleton перед тестами — без скелета тести генеруються «на все», розпухають у 50+ кейсів і втрачають фокус.
• Не міксуй «Що не чіпаємо» зі справжніми bugs — bugs у «Що не чіпаємо» з позначкою known bug, fix after cutover. Не «правь план щоб виглядав красивіше за тести».