DDR для AI-driven разработки

Начал тут разрабатывать мобильное приложение, обнаружил, что пришлось обсудить порядка 10-15 разных аспектов, прежде чем добраться до кода. Т.е. да, формально ЭП/ТП/РД по ГОСТ нам не нужны, но многие вопросы всё равно нужно продумать и сохранить. Причём это не только ADR, но и множество других тем — см скриншоты.

Мне в целом понравилось, что GPT 5.2 предложил итерационный подход — серию релизов, каждая из итераций, в итерации шагов. В среднем на уровень около 6 элементов, итого около 200 шагов-кусков кода для создания приложения. Выглядит весьма управляемо.

Однако при переходе к созданию кода он даёт достаточно точную инструкцию, что сделать, но никак не объясняет, зачем и как оно работает. Те можно за ним что-то повторять как обезьянка, но совершенно не понимая, что именно мы делаем (а у меня опыт мобильной разработки нулевой).

Пришлось его попросить оформлять описания каждого из шагов в виде своего рода Design & Development (Decision) Records, куда я включил: — что нужно сделать — зачем это нужно (на уровне продукта и на уровне технологии) — как оно работает — какие принципы и паттерны используются — какие альтернативы и почему они не подошли — как это сделать (собственно инструкция по созданию кода)

Этого тоже оказалось мало, тк он часто оперирует понятиями, не объясняя, что это такое — типа "Создайте Application". Что это такое, этот Application — класс, пакет, интерфейс, файл — со стороны ХЗ, поэтому пришлось его дополнительно потрясти, чтобы он указывал РОД почти каждого уникального слова, которое использует и давал определение вновь употребимым понятиям.

Какой промт у меня получился в итоге:

Опиши следующую итерацию разработки приложения в формате Design & Development Decision Records (DDR).

Контекст:

• Приложение: офлайн-first Android-приложение (Kotlin, Jetpack Compose)
• Архитектура предыдущих итераций уже зафиксирована
• Итерации идут последовательно (A → B → C → …)

Общие требования к ответу (обязательны):

1. Формат:

• Итерация должна быть описана целиком, как единый DDR-документ.
• Итерация должна быть разбита на шаги (например: C1, C2, C3…).
• Каждый шаг — это отдельное архитектурно-разработческое решение.

2. Для КАЖДОГО шага обязательно должны быть секции:

• Род понятий (явно указать: класс / интерфейс / файл / пакет / функция / библиотека / плагин / паттерн / принцип / конфигурация)
• Что предлагается сделать
• Зачем это нужно: • сначала на уровне продукта • затем на уровне технологии реализации
• Как это работает: • какие паттерны используются • на какие принципы разработки опирается • в чём архитектурный замысел
• Альтернативы: • какие альтернативы возможны • почему они здесь не выбраны
• Как именно это сделать: • какие файлы создать • какие классы / интерфейсы / функции реализовать • какие ограничения и инварианты соблюдать

3. Термины и понятия:

• Каждый раз, когда в ответе появляется НОВОЕ для этого чата понятие, ты ОБЯЗАН: • указать его род (класс, интерфейс, тип, файл, паттерн и т.п.) • дать краткое, чёткое определение
• Нельзя использовать термины без определения.
• Если понятие уже вводилось ранее в чате, повторное определение не требуется.

4. Стиль:

• Без туториального тона
• Без “магии” и неявных допущений
• Объяснения должны быть инженерными и системными
• Предпочтение архитектурной ясности, а не краткости

5. Назначение результата:

• Документ должен быть пригоден: • для помещения в репозиторий (docs/ddr/DDR-X.md) • для использования как исполняемая спецификация • для передачи Codex командами вида: “Реализуй DDR-X3”

Задача: Опиши итерацию <НАЗВАНИЕ ИТЕРАЦИИ> (например: Iteration C — Scanning & Document Pages) в полном соответствии с требованиями выше.