L1DDER

Русский

English

Русский

English

Appearance

Словарь терминов (L1DDER) ​

Термины методологии L1DDER в порядке потока работы.

Концепт (docs/concept/) ​

Базовый долгосрочный фундамент проекта: что строится, для кого и как устроено системно (idea.md, vision.md, architecture.md, data-model.md, integrations.md, api-contracts.md). Создаётся на старте проекта (через /l1-onboard) и обязательно актуализируется в конце каждого спринта в рамках гигиенической задачи Doctor Checklist.

Фаза концепта и этапы онбординга (/l1-onboard) ​

  • Фаза концепта — проработка docs/concept/ на онбординге, до банка идей и фич. Не путать с Discovery Queue — очередью проработки идей в спеки в docs/roadmap.md.
  • Этап концепта — проработка одного файла онбординга раундами до 7 вопросов, с черновиком и «ок» в конце. Этапов шесть: идея, видение, архитектура, модель данных, стек, банк идей и роадмап.
  • Разбор ответа — реакция агента на ответы человека: что стало понятно, что стоит усилить, что осталось неясным и что перенести в файл другого этапа.

Банк Идей (docs/ideas.md) и IDEA-NNN ​

Единый реестр всех идей продукта. Пополняется и развивается через скилл /l1-idea. Каждая идея имеет уникальный код IDEA-NNN, приоритет (P0..P3), карточку описания и строгий статус:

  • 📋 нереализована — идея сформулирована, ждёт проработки в фичу.
  • 🚧 реализация — по идее создана фича (FEAT-NNN) и/или идут спринты разработки.
  • ✅ реализована — все связанные с идеей фичи полностью закрыты.
  • ❌ отклонена — от идеи отказались (причина сохранена в карточке).

Фича (FEAT-NNN) и Спецификация (docs/specs/FEAT-NNN-<slug>/) ​

Функциональный блок продукта, вырастающий из идеи IDEA-NNN при проработке через скилл /l1-feature. Включает:

  1. Папку спецификации docs/specs/FEAT-NNN-<slug>/ из трёх файлов:
    • requirements.md — user stories и acceptance criteria (GIVEN/WHEN/THEN).
    • design.md — технический дизайн, глубокие модули (Deep Modules), публичные швы тестирования (Pre-agreed Test Seams) и схемы данных.
    • tasks.md — первичная нарезка (груминг) на кандидаты спринтов и задач (FEAT-NNN.01 .. FEAT-NNN.99).
  2. Запись в Бэклоге (docs/backlog.md) с обязательной привязкой к IDEA-NNN, приоритетом и статусом:
    • 📝 проработка → 📋 в бэклоге → 🗓 запланирована → 🚧 реализация → ✅ реализована (или ❌ отклонена).

Бэклог и Таск-трекер (docs/backlog.md) ​

Единый операционный файл-трекер проекта, состоящий из четырёх секций:

  1. Реестр Фич (FEAT-NNN) — все проработанные фичи со ссылками на IDEA-NNN, папку спеки и назначенные спринты SPRINT-NN.
  2. Спринты и Задачи (SPRINT-NN и TASK-NN.MM) — полная декомпозиция фич на спринты и атомарные задачи с их текущими статусами и ссылками на plan.md / summary.md.
  3. Журнал Хотфиксов (HOTFIX-NNN) — реестр быстрых исправлений, выполненных через /l1-hotfix.
  4. Журнал служебных правок (CHORE-NNN) — по одной строке на каждую правку самого проекта, выполненную через /l1-chore.

Роадмап (docs/roadmap.md) и Roadmap Gate ​

Единый источник истины (Single Source of Truth) по очерёдности работ в проекте. Управляется через скилл /l1-planning. Содержит две очереди:

  1. Delivery Queue (Очередь реализации): строгий порядок выполнения спринтов SPRINT-NN и фич FEAT-NNN.
  2. Discovery Queue (Очередь проработки): строгий порядок проработки идей IDEA-NNN из Банка Идей в спеки через /l1-feature.

Roadmap Gate (Железное правило): запрещено брать в работу задачу или фичу, которой нет на активной позиции в docs/roadmap.md. Любое изменение планов сначала вносится в docs/roadmap.md через /l1-planning. Исключения — /l1-hotfix (срочный баг продукта), /l1-chore (правки самого проекта, которые не меняют продукт) и /l1-fast (небольшая фича продукта — вызывает строго только человек, для агента запускать по своей инициативе запрещено, и только когда позиция 1 (CURRENT) пуста).

Sprint (SPRINT-NN) ​

Ценностный итеративный блок работ, поставляющий законченный результат, который можно протестировать. Хранится в docs/sprints/SPRINT-NN-<slug>/README.md и отражается в docs/backlog.md и docs/roadmap.md. Обязательное правило L1DDER: каждый спринт строго завершается финальной гигиенической задачей TASK-NN.99: Гигиена спринта и Doctor Checklist (tasks/TASK-NN.99-doctor/). Если от текущего спринта на 1 (CURRENT) решили отказаться, он отклоняется через /l1-planning: код откатывается через git revert без переписывания истории, а документы спринта и задач остаются записью со статусом ❌ отклонена.

Гигиеническая задача спринта (Doctor Checklist / TASK-NN.99) ​

Обязательная завершающая задача каждого спринта (шаблон l1dder/templates/tasks/doctor-checklist-template.md), без которой спринт не может быть закрыт. Состоит из 4 блоков:

  1. Code & Repo Doctor — прогон make ci + двухосевой code-review + аудит чистоты кода (ponytail-audit) и сбор shortcut: (ponytail-debt).
  2. Agent E2E Verification — прогон максимального числа E2E-тестов агентом (make test-e2e + интерактивная проверка всех сценариев спринта).
  3. Living Docs Sync — обязательное обновление долгосрочной документации (docs/concept/*, docs/specs/*, docs/adrs/*, l1dder/rules/*.mdc), если в ходе спринта изменились архитектура, схемы или правила.
  4. Human UAT (Приёмочное тестирование человеком) — подготовка пошагового гайда для ручной проверки пользователем и ожидание его апрува («ок»).

Task (TASK-NN.MM ↔ FEAT-NNN.MM) ​

Атомарная единица работы внутри спринта с чётким Definition of Done.

  • До планирования спринта шаг спеки имеет ID FEAT-NNN.MM (FEAT-001.01, ..., FEAT-001.99).
  • После планирования в /l1-planning он получает парный ID задачи спринта TASK-NN.MM (TASK-01.01, ..., TASK-01.99). Выполняется через скилл /l1-task и проходит 4 фазы (Plan → Implement → Self-check → Confirm & Record) с двумя обязательными остановками на согласование. Каждая задача имеет plan.md (до) и summary.md (после) в docs/sprints/SPRINT-NN-<slug>/tasks/TASK-NN.MM-<slug>/ с полным Паспортом всех родительских ID (TASK-NN.MM, FEAT-NNN.MM, SPRINT-NN, FEAT-NNN, IDEA-NNN).

Hotfix (HOTFIX-NNN и /l1-hotfix) ​

Исключение из Roadmap Gate для срочного устранения багов и поломок в продукте. Правки самого проекта, которые продукт не меняют, идут через /l1-chore. Выполняется через скилл /l1-hotfix: воспроизведение бага (RED Reproduction Gate) → согласование краткого плана в чате → минимальный фикс (ponytail) → прогон make ci (GREEN) → запись HOTFIX-NNN в docs/backlog.md.

Служебная правка (CHORE-NNN и /l1-chore) ​

Правка самого проекта, а не того, что видят и чем пользуются его пользователи: правила работы с git (как называть ветки и коммиты, что проверять перед пушем), автопроверки в CI, обновление библиотек, Makefile, скрипты сборки, тесты, правила для ИИ-агента. Выполняется через скилл /l1-chore без идеи, спеки и спринта: проверка, что продукт не меняется → карточка CHORE-NNN и одна остановка «ок» → правка и make ci → строка в разделе 4 docs/backlog.md. Если правка меняет продукт, это уже /l1-task (или /l1-fast, когда нет активного спринта) или /l1-hotfix.

Быстрый режим (/l1-fast) ​

Режим для небольшой фичи продукта (до 3 задач в одном спринте, без новой модели данных, внешней интеграции, ADR и ломающих изменений), когда позиция 1 (CURRENT) в docs/roadmap.md пуста. Вызывает строго только человек — для агента запускать /l1-fast по своей инициативе запрещено.

  • Если 1 (CURRENT) занята обычным спринтом — строгий отказ без правки файлов: закончить спринт через /l1-task или отклонить его через /l1-planning.
  • Вместо plan.md до кода — две остановки в чате: ⛔ СТОП №1 (что строим, после уточнения по grilling и оценки масштаба) и ⛔ СТОП №2 (приёмка человеком после всех проверок).
  • Сразу после первого «ок» в docs/roadmap.md бронируются IDEA-NNN, FEAT-NNN и SPRINT-NN на строке 1 (CURRENT) с пометкой режим: /l1-fast, а до второго «ок» выполняются все проверки обычного пути и TASK-NN.99 (tdd, make ci, ponytail-review, двухосевой code-review, ponytail-audit, ponytail-debt, E2E, синхронизация доки и retro).
  • После второго «ок» заполняется вся цепочка реестров (docs/ideas.md, docs/backlog.md, docs/specs/FEAT-NNN-<slug>/, docs/sprints/SPRINT-NN-<slug>/, задачи TASK-NN.MM и TASK-NN.99 с plan.md и summary.md) со строкой | **Режим** | \/l1-fast` |` в паспорте каждого документа.

Правило двух согласований ​

Железное правило при выполнении любой задачи в /l1-task: агент останавливается дважды и ждёт явного «ок» от человека:

  1. СТОП №1: после создания plan.md — перед началом написания кода.
  2. СТОП №2: после самопроверки по DoD (или подготовки Human UAT в Doctor Checklist) — перед созданием summary.md и закрытием задачи.

В /l1-fast обе остановки проходят в чате: до кода (⛔ СТОП №1) и после всех проверок (⛔ СТОП №2), а plan.md и остальные документы записываются после кода с пометкой Режим | /l1-fast.

Edit → Sanitize → Verify ​

Обязательный микро-цикл для каждого изменённого файла при написании кода:

  1. Edit — внести минимальное полное изменение (ponytail).
  2. Sanitize — запустить линтер, форматтер и проверку типов.
  3. Verify — запустить тесты затронутого модуля.

Паспорт сущности (ID Passport) ​

Обязательная таблица в шапке каждого документа (requirements.md, design.md, tasks.md, SPRINT README.md, plan.md, summary.md, ADR), которая хранит все родительские ID вплоть до IDEA-NNN (TASK-NN.MM → FEAT-NNN.MM → SPRINT-NN → FEAT-NNN → IDEA-NNN). Позволяет любой (даже слабой) модели ИИ безошибочно обновлять связанные файлы.

Ponytail (Lazy Senior Dev Mode, shortcut:, Skipped / Risk) ​

Встроенная в коробку L1DDER дисциплина минимализма (DietrichGebert/ponytail):

  • 6-ступенчатая лестница выбора решения: Нужно ли вообще? → Есть в репо? → Есть в платформе? → Есть в установленных пакетах? → 1 строка? → Минимум кода.
  • Маркер // shortcut: <что упростили>, <лимит / триггер апгрейда> — явная пометка осознанного упрощения в коде, собираемая скиллом /ponytail-debt в конце спринта.
  • 2-строчный футер Ponytail skipped / Risk — обязательное завершение отчётов о коде, где агент честно пишет, от каких усложнений отказался и какой лимит нужно знать человеку.

Deep Modules (codebase-design) и Pre-agreed Test Seams (tdd) ​

Инженерные дисциплины проектирования и тестирования из mattpocock/skills:

  • Deep Module (Глубокий модуль): модуль, скрывающий сложную реализацию за простым и компактным публичным интерфейсом (Interface), проходящий Тест на удаление (Deletion Test).
  • Pre-agreed Test Seam (Согласованный публичный шов тестирования): точка публичного интерфейса модуля, согласованная в design.md спеки, через которую пишутся вертикальные тесты (Red → Green) без привязки к приватным внутренностям и без тавтологичных проверок.

Догфудинг (Dogfooding) и /l1-evo (l1dder/evolution/) ​

Принцип саморазвития L1DDER: доработка правил, шаблонов и скиллов самой методологии выполняется по её же собственным правилам, флоу (Правило двух СТОПов) и скиллам через команду /l1-evo с обязательной записью в l1dder/evolution/WORKLOG-CHANGELOG.md и актуализацией l1dder/evolution/HANDOFF.md.