Skip to content

PROCESS.md

Latest commit

 

History

History
56 lines (42 loc) · 4.74 KB

PROCESS.md

File metadata and controls

56 lines (42 loc) · 4.74 KB
Raw

Процесс разработки Konvey

Роли

  • Архитектор (Claude Opus 4.7 в отдельной сессии): принимает архитектурные решения, пишет промпты для спринтов, контролирует декомпозицию.
  • Исполнитель (Claude Code): получает промпт от архитектора через владельца, реализует, отчитывается.
  • Владелец (Сергей): контролирует процесс, тестирует результаты, передаёт информацию между архитектором и исполнителем.

Цикл спринта

  1. Архитектор пишет промпт → передаёт владельцу
  2. Владелец передаёт промпт исполнителю
  3. Исполнитель работает в течение спринта (несколько часов/дней), фиксирует решения в DECISIONS.md, открытые вопросы в QUESTIONS.md
  4. По завершении спринта исполнитель создаёт docs/SPRINT_N_REPORT.md с фиксированным форматом (см. ниже)
  5. Владелец передаёт отчёт + git tree + ключевые файлы архитектору
  6. Архитектор анализирует, отвечает на QUESTIONS, пишет следующий спринт

Что должно быть в каждом отчёте о спринте (SPRINT_N_REPORT.md)

  1. Что сделано — список deliverables с пометками ✓ done / ⚠ partial / ✕ skipped (с причиной)
  2. Принятые архитектурные решения — ссылки на ADR в DECISIONS.md
  3. Открытые вопросы — со ссылками на QUESTIONS.md
  4. Тестовое покрытие — вывод pytest и vitest
  5. Структура проекта — tree -L 3 (или эквивалент)
  6. Метрики — кол-во файлов, кол-во строк по слоям (frontend / backend / Rust)
  7. Что не работает или работает плохо — честный список, без приукрашивания
  8. Что нужно от архитектора — конкретные вопросы для следующего спринта

Обработка неясностей

  • Тривиальная техническая мелочь (имя переменной, выбор stdlib функции, формат логов) — решаешь сам, добавляешь короткую запись в DECISIONS.md если это устанавливает паттерн на будущее
  • Архитектурная неясность (выбор паттерна, решение про границы модулей, новая зависимость) — добавляешь запись в QUESTIONS.md, продолжаешь с заглушкой/best-guess решением, помечаешь # TODO: see QUESTIONS.md#NN
  • Запрос на изменение требований (что-то в промпте кажется неправильным) — добавляешь в QUESTIONS.md, продолжаешь как написано в промпте, не отклоняешься
  • Внешний blocker (нужна информация от владельца, недоступный ресурс) — добавляешь в QUESTIONS.md, реализуешь заглушку, продолжаешь следующие пункты

Никогда не блокируйся на одном пункте. Всегда переходи к следующему deliverable с заглушкой, если текущий упёрся.

Тестирование

  • Каждый Python-модуль с логикой → pytest-тест в backend/tests/
  • Каждый React-компонент со state/логикой (не презентационный) → Vitest-тест
  • Минимум: happy path + 1 edge case + 1 error case на функцию
  • Static parse tests (просто проверка что файл существует и парсится) не считаются покрытием

ADR (Architecture Decision Records)

Формат записи в DECISIONS.md:

ADR-NNN: Краткое название
Дата: YYYY-MM-DD
Статус: accepted | superseded by ADR-XXX
Контекст: что за проблема, какие варианты рассматривались
Решение: что выбрали
Последствия: что это значит для архитектуры