Project Navigator — проектирование, настройка и развёртывание агента

54. Вопросы для принятия архитектурных, функциональных, бизнес-, организационных и доменных решений

Банк вопросов — рабочий интерфейс между заказчиком и PN: каждый вопрос имеет варианты ответа, влияние на проект и связи с другими вопросами. Пока вопрос не отвечен, связанные части архитектуры и MVP остаются в статусе ⚠️ draft. Раздел вынесен в начало как рабочая панель: сначала вопросы и решения, затем модель, реализация и метрики.

Как читать таблицы

• A — технический/архитектурный, F — функциональный, B — бизнес, O — организационный/инфраструктурный, D — доменный. Нумерация сквозная (1–82).
• Варианты ответа — допустимые решения; ответ можно комбинировать, но выбранный вариант должен быть зафиксирован как DEC в Context.
• Влияние — что изменится в документе (раздел, артефакт, объём MVP).
• Связи — ← от чего зависит, → что блокирует.

Волны снятия вопросов

Правило: вопрос переводится в research только когда известен его «владелец» и цена ошибки. Иначе он остаётся открытым и не тратит LLM-бюджет.

Карта зависимостей (ключевые кластеры)

54.1. Технические и архитектурные вопросы 12

54.2. Функциональные вопросы 18

54.3. Бизнес-вопросы: рынок, модель, тарифы и развитие 24

54.4. Организационные и инфраструктурные вопросы 14

Это не «техника» и не «бизнес»: без этих ответов проект просто не стартует — нет аккаунтов Claude/OpenAI, нет оплаты API, нет хостинга, домена, репозитория, команды и канала продаж. Волна 0 снимается параллельно всему остальному.

54.5. Доменная специфика и экспертиза 14

Общие вопросы не описывают предметную область. Без домена PN выдаёт «правильные» вопросы общего вида: нормативка, первоисточники, типовые артефакты и проверка корректности — это то, что отличает доменный пак от просто промпта.

54.6. Как обсуждать вопрос с LLM — шаблон промпта

Правило: один вопрос — один диалог. Модель не выбирает за человека: она обязана показать варианты, последствия и рекомендацию с условиями (§28). Ответ, который нельзя превратить в DEC, — бесполезный ответ.

Шаблон запроса

Роль: ты архитектор продукта PN (Project Navigator) и мой оппонент, а не исполнитель.
Контекст: <продукт/инструмент, домен, стадия, бюджет, сроки, ограничения>
Вопрос: <ID> — <формулировка из §54>
Рассматриваю варианты: <1–4 варианта из таблицы>
Связи: <зависит от / блокирует — из колонки «Связи»>

Что нужно:
1. Для каждого варианта — последствия: архитектура, стоимость, сроки, риски (2–3 тезиса).
2. Что сломается в связанных вопросах <ID>, если выбрать этот вариант.
3. Твоя рекомендация и условие, при котором она станет неверной.
4. Каких данных не хватает для решения — максимум 3 вопроса.
5. Итог: DEC-запись в YAML: decision, context, alternatives, reason, owner, status: proposed.

Ограничения:
— не выдумывай факты, неизвестное помечай [предположение];
— не предлагай «оба варианта» без критерия выбора;
— не предлагай решение без цены (что перестаём делать);
— не более 400 слов.

Пример: O01 — аккаунты LLM

Роль: ты архитектор продукта PN и мой оппонент, а не исполнитель.
Контекст: MVP-навигатор по программам поддержки; 1 разработчик; бюджет до 10k$;
запуск через 6 недель; персональных данных клиентов нет; домен — строительство.
Вопрос: O01 — есть ли аккаунты Claude / OpenAI / Google / локальные модели?
Варианты: (а) есть все, (б) частично (1–2 вендора), (в) нет, оформляем,
(г) доступ через прокси/реселлера.
Связи: ← B21 (бюджет); → A02 (выбор моделей), A03 (прямые вызовы API), O02 (оплата).

Нужно: последствия каждого варианта для срока запуска и стоимости; что сломается
в A02/A03; рекомендация + условие её опровержения; DEC в YAML.

Правила разговора

• Вопросы задавайте по одному: смешение A/B/O/D даёт «средний» ответ без пользы.
• Требуйте источник или явную пометку [предположение] — иначе FACT попадёт в контекст как факт (§6.5).
• Просите возражения против выбранного ответа — это работа Challenger (§14), а не Builder.
• Фиксируйте ответ как DEC-* и обновляйте 54.x: вопрос закрывается только при выполненном условии гейта (D1–D3).
• Открытые вопросы не копятся: 3 неотвеченных вопроса — стоп-сигнал для гейта.

0. Назначение документа

Документ описывает, как спроектировать и настроить ИИ-агента Project Navigator (PN), который не просто отвечает на вопросы и не является обычным coding-agent, а ведёт пользователя от исходной идеи сложного проекта к спроектированной системе управления этим проектом и затем самостоятельно проходит цикл создания MVP.

PN должен:

1. принять исходную идею проекта;
2. определить уровень неопределённости;
3. задать недостающие вопросы;
4. построить интерактивную карту проекта;
5. разбить неопределённости на исследовательские задачи;
6. генерировать prompts для других LLM и/или экспертов;
7. принимать и структурировать полученные ответы;
8. накапливать Project Context;
9. выявлять противоречия, неизвестные и риски;
10. после прохождения discovery-gates перейти к проектированию;
11. сформировать CJM, use cases, требования, архитектуру, UI/UX и backlog;
12. определить границы MVP;
13. реализовать MVP по правилам 01.lab;
14. проверить результат;
15. развернуть MVP;
16. сформировать отчёт и следующий цикл развития.

Главный принцип:

PN сначала проектирует понимание проекта, затем проектирует систему, и только после этого реализует MVP.

PN не должен преждевременно превращать неполную идею в код.

1. Контекст и место PN в 01.lab

01.lab — фреймворк параллельной разработки с ИИ-агентами: документация — источник истины, задача трассируема от беклога до деплоя, спорные решения подтверждает человек. PN встраивается в него, а не строит параллельный процесс.

PN — не замена конвейера, а его интеллектуальный слой навигации.

2. Концепция продукта

2.1. Что такое Project Navigator

Project Navigator — агент и рабочее пространство для проектирования сложных проектных систем.

Он помогает пройти путь:

неясная идея
    ↓
структурированные вопросы
    ↓
карта проекта
    ↓
исследования
    ↓
накопленный контекст
    ↓
решения
    ↓
требования
    ↓
архитектура
    ↓
MVP
    ↓
работающая система

Название Navigator здесь принципиально: PN не обязан сам выполнять всю интеллектуальную работу. Его задача — направлять поток информации, решений, задач и исполнителей.

3. Что PN НЕ должен делать

PN не должен:

• начинать программирование после первого описания идеи;
• додумывать отсутствующие требования;
• считать ответ одной LLM доказанным фактом;
• смешивать исследование и реализацию;
• создавать задачи без источника;
• создавать корневые backlog-коды самостоятельно вне мастер-беклога;
• принимать архитектурное решение без рассмотрения альтернатив при существенном риске;
• смешивать роли Builder и Challenger;
• автоматически принимать спорное решение без human gate;
• превращать весь накопленный контекст в один гигантский prompt;
• использовать проектный Gantt как единственный источник истины.

Главное правило:

Неизвестное должно быть обозначено как неизвестное, а не заполнено правдоподобным текстом.

4. Основная модель PN

PN работает как state machine.

IDEA
  │
  ▼
INTAKE
  │
  ▼
DISCOVERY
  │
  ├── QUESTIONS
  ├── RESEARCH
  ├── ALTERNATIVES
  └── VALIDATION
  │
  ▼
CONTEXT
  │
  ▼
SYNTHESIS
  │
  ▼
DESIGN
  │
  ├── CJM
  ├── UC
  ├── PROCESS
  ├── UIX
  └── ARCH
  │
  ▼
SPEC
  │
  ├── REQUIREMENTS
  ├── ACCEPTANCE
  └── SCOPE
  │
  ▼
MVP
  │
  ├── BACKLOG
  ├── PLAN
  └── TASKS
  │
  ▼
BUILD
  │
  ▼
VERIFY
  │
  ▼
DEPLOY
  │
  ▼
OPERATE
  │
  └──────────────→ новый цикл

Каждое состояние имеет:

• вход;
• разрешённые действия;
• обязательные артефакты;
• критерии выхода;
• человека, принимающего спорные решения.

5. Три слоя PN

Каждый слой отвечает на один вопрос и не подменяет остальные.

6. Project Context — центральный объект системы

Project Context не должен быть просто большим Markdown-файлом.

Минимальная логическая модель:

Project
 ├── Goal
 ├── Users
 ├── Stakeholders
 ├── Constraints
 ├── Assumptions
 ├── Questions
 ├── Research
 │    ├── Prompt
 │    ├── Source
 │    ├── Response
 │    └── Verification
 ├── Facts
 ├── Decisions
 ├── Alternatives
 ├── Risks
 ├── Processes
 ├── Requirements
 ├── Use Cases
 ├── Design
 ├── Tasks
 ├── Dependencies
 └── Releases

6.1. Факт

id: FACT-001
statement: "..."
source: "..."
source_type: official | expert | llm | project | assumption
confidence: high | medium | low
verified: true | false
updated: YYYY-MM-DD

6.2. Предположение

id: ASM-001
statement: "..."
reason: "..."
impact_if_wrong: high | medium | low
status: open | verified | rejected

6.3. Решение

id: DEC-001
decision: "..."
context: "..."
alternatives:
  - "..."
  - "..."
reason: "..."
owner: "..."
status: proposed | approved | rejected

6.4. Вопрос

id: Q-001
question: "..."
importance: critical | important | optional
blocks:
  - "REQ-..."
  - "DEC-..."
status: open | research | answered | rejected

6.5. Протокол источника

8. Question Engine

Задавать не максимум вопросов, а минимально необходимое число с максимальной ценностью информации.

8.2. Классы вопросов

9. Формула выбора следующего вопроса

Для каждого открытого вопроса PN оценивает:

Priority =
Impact × Uncertainty × Dependency × CostOfWrongAnswer

где:

• Impact — влияние на проект;
• Uncertainty — степень неизвестности;
• Dependency — сколько решений зависит от ответа;
• CostOfWrongAnswer — цена ошибочного решения.

При равных условиях сначала выбирается вопрос с максимальным приоритетом.

10. Project Map

Flow и Gantt — не две системы, а два представления одной Project Graph.

10.4. Трассируемость вместо декоративного Gantt

Обычный Gantt отвечает:

Когда выполняется задача?

PN должен отвечать:

Почему эта задача существует и какое знание/решение делает её возможной?

Например:

TASK-17
"Сделать API согласований"
       │
       ├── derived from → REQ-04
       │
       ├── derived from → UC-03
       │
       ├── depends on → DEC-07
       │
       ├── depends on → Q-12
       │
       └── validated by → TST-09

Это делает roadmap трассируемым, а не декоративным.

12. Research Engine

Вопрос → RESEARCH-n → промпты → ответы → FACT с источником. Исследование закрывается артефактом, а не «стало понятнее».

12.4. Исследование текущих решений (market scan)

До выбора архитектуры (гейт D4) нужно понять, что уже существует и почему проектировщик этим не пользуется. Задача — не «посмотреть конкурентов», а найти место PN: где он дополняет, а где конкурирует.

Критерии сравнения: порог входа для проектировщика · знание домена согласований · приватность и хранение данных · экспорт контекста · интеграции (1С, BIM, Excel) · цена владения · скорость первого результата.

Выход: RSR-market.md с таблицей и DEC по позиционированию (вопрос B05, B22). Списки кандидатов — гипотезы для проверки, а не утверждения о продуктах.

13. Мультимодельный режим

PN должен уметь направлять один вопрос нескольким исполнителям.

Question
   │
   ├── LLM A
   ├── LLM B
   ├── LLM C
   ├── Web / official source
   └── Human expert
           ↓
      Responses
           ↓
       Compare
           ↓
       Verify
           ↓
       Synthesis

Ответы не смешиваются до этапа сравнения.

Это особенно важно, поскольку 01.lab запрещает смешивать когнитивные роли в одном контексте: Builder, Challenger, Verifier и Synthesizer должны оставаться отдельными перспективами.

14. Staging PN

PN использует существующие роли 01.lab. Роль отвечает на вопрос «кто думает», скил — «что выполняется» (§14.7). Роли нельзя смешивать в одном контексте.

Navigator → Builder → Challenger → Verifier → Curator → Synthesizer

14.7. Скилы PN (skills)

Скил — переиспользуемая единица поведения с фиксированным контрактом: триггер → вход → выход → артефакт. Скилы — то, что PN оркестрирует, а не переизобретает: часть берётся из 01.lab, часть реализуется проектом (§31, §56).

Банк скилов

MVP-колонка не выводится отдельной колонкой: скилы MVP помечены в §25 (MUST) и в самом первом MVP.

Скилы в гейтах

Контракт скила

skill:        <S-код> <название>
trigger:      роль | гейт | фаза | команда (§52)
input:        поля Context, которые скил читает (не больше, чем нужно)
output:       типизированная запись: FACT | ASM | DEC | Q | ARTIFACT
side_effects: запись в Context, лог, метрика
guardrails:   что скил НЕ делает без подтверждения человека (§28)
idempotent:   true | false
owner:        роль, отвечающая за качество результата

Правила банка скилов:

• скил не принимает решений за человека — он готовит варианты и обоснование;
• скил не пишет в разделы Context вне своего контракта;
• скил возвращает provenance и confidence, а не «мнение»;
• скил, который нельзя проверить (нет критерия приёмки), не считается скилом;
• появление нового скила фиксируется в этом банке до реализации, а не после.

15. Progressive Rigor

PN выбирает режим работы до изменения проекта. Режим определяет объём артефактов, а не важность задачи.

16. Discovery Gates

PN не переходит в следующую фазу только потому, что пользователь сказал «делай». Гейт — это проверяемое состояние, а не ритуал.

После D6 PN имеет право запускать build-flow. Провал гейта — это список того, чего не хватает, а не запрет навсегда.

17. Артефакты PN

Структура проекта PN соответствует конвенции 01.lab для AI-проекта: проектные документы, база знаний, промпты и код живут раздельно. Каждый артефакт появляется на своём гейте, а не «когда-нибудь».

Правило: артефакт без гейта и владельца не создаётся; документ без front-matter и записи в реестре не считается артефактом.

18. Кодовая модель

PN рекомендуется разделить на следующие компоненты:

pn/
├── domain/
│   ├── project.py
│   ├── question.py
│   ├── research.py
│   ├── fact.py
│   ├── decision.py
│   ├── requirement.py
│   └── task.py
│
├── context/
│   ├── store.py
│   ├── resolver.py
│   └── provenance.py
│
├── navigator/
│   ├── state_machine.py
│   ├── question_engine.py
│   ├── next_action.py
│   └── dependency_graph.py
│
├── prompts/
│   ├── generator.py
│   └── templates/
│
├── staging/
│   ├── navigator.py
│   ├── builder.py
│   ├── challenger.py
│   ├── verifier.py
│   ├── curator.py
│   └── synthesizer.py
│
├── design/
│   ├── cjm.py
│   ├── requirements.py
│   ├── architecture.py
│   └── backlog.py
│
└── api/
    └── ...

18.1. Архитектура решения

Логическая архитектура: интерфейсы не знают, откуда берутся факты; оркестрация работает только через Project Context; домен и нормативка — это данные, а не код. Схема отражает §5 (три слоя), §14 (роли) и §14.7 (скилы).

• Единая точка правды — Project Context. Интерфейсы (web, CLI, API) и роли читают и пишут только через него; прямой доступ к БД минует provenance — запрещён (§20).
• Домен — данные. «Согласования Москвы» (Мосводоканал, Мосводосток, МОЭК, метрополитен, Россети, Моссвет, Мосгаз) подключаются как Domain Pack: пакеты документов, нормы, сроки, шаблоны (§27).
• Скилы оркестрируются, а не переписываются. 01.lab даёт конвенции, скилы и шаблоны; PN добавляет состояние, гейты и трассируемость (§31, §56).
• Модель выбирается по задаче. Дешёвые вопросы — flash-модель, архитектура и red team — сильная модель; кеш и учёт токенов обязательны (§13).

18.2. Схема развёртывания

Минимальный контур MVP: локальная разработка → репозиторий → CI → образ → один VPS с nginx и двумя контейнерами. Внешние зависимости — LLM-провайдеры и порталы организаций; ключи живут только на сервере, браузер их не видит.

Схема развёртывания — на вкладке «Развёртывание» в §18.1.

• Окружения: dev → verification → prod; prod-деплой только после подтверждения человека (§28).
• Секреты: .env на сервере или vault, не в git; ключи LLM не попадают в контекст и логи (§O08).
• Данные: volume context.db + артефакты; ночной бэкап в object storage, RPO сутки, проверка восстановления раз в месяц (§O07).
• Наблюдаемость: uptime и алерты на 4xx/5xx, время ответа, стоимость LLM за сутки; логи без персональных данных (§O06).
• Масштабирование: сначала вертикально; pn-worker отделяется первым, когда research перестаёт помещаться в один процесс.

19. MVP интерфейс

Шесть экранов MVP: каждый отвечает на один вопрос пользователя и связан с гейтом.

19.7. Визуалы интерфейсов

Четыре экрана MVP в том виде, в котором их видит проектировщик: рабочие wireframes, а не дизайн-макеты.

23. SDD

Спецификация — не текст «для галочки», а три связанных артефакта с проверяемыми требованиями (§35).

24. Беклог PN — структура

Три секции: проектирование, разработка, исследования. Корневые коды PN-XX выдаёт мастер-беклог 01.lab. Задача без выхода и гейта в беклог не попадает.

24.1. Проектирование

Всё, что превращает сырой текст в проверяемые решения.

24.2. Разработка

Реализация контура — по зависимостям, а не по желанию.

24.3. Исследования

Исследование закрывается артефактом и DEC, а не «стало понятнее».

25. Самый первый MVP

Скоуп первого MVP по приоритетам. MUST — без этого продукта нет; WON’T — осознанно не делаем.

Границы первого этапа: не строим Project OS, собственную LLM, сложный RAG, multi-agent swarm, BIM-интеграцию, 20 интеграций, Gantt-SaaS, ERP.

Первый доказуемый результат: проектировщик вводит объект → PN показывает, чего не хватает → задаёт вопросы → формирует пакет документов по организациям → считает срок → выдаёт чек-лист и беклог.

26. Особый сценарий Construction Navigator

Первый прикладной сценарий PN — согласования в строительстве Москвы. Домен задаётся пакетом, а не кодом.

Детали задачи, доменный пакет, метрики пилота и дисклеймер — в отдельном документе PN-02-TSK «Согласования Москвы».

27. Construction Knowledge Base

Домен хранится как данные с provenance: каждая норма и срок имеют источник и дату.

28. Human-in-the-loop

Три режима действий. Режим определяется ценой ошибки, а не удобством.

21. Минимальная БД

Для первого MVP не следует сразу проектировать сложную распределённую систему.

Минимальные сущности:

projects
questions
research_runs
responses
sources
facts
assumptions
decisions
requirements
tasks
dependencies
artifacts
events

Связи:

Project
 ├── Questions
 ├── Research
 ├── Facts
 ├── Decisions
 ├── Requirements
 ├── Tasks
 └── Artifacts

22. Технологический выбор

На первом этапе PN не должен заранее фиксировать конкретный стек без исследования.

Использовать /arch:

/arch: стек для Project Navigator MVP
Критерии:
- скорость MVP
- стоимость
- простота эксплуатации
- multimodal support
- streaming
- persistence
- безопасность
- возможность дальнейшего масштабирования

Обязательно сравнить минимум два реальных варианта.

После выбора создать ADR:

ADR-001: Architecture for Project Navigator MVP

29. System Prompt PN

Минимальная версия системного prompt:

Ты — Project Navigator, агент проектирования сложных проектных систем.

Твоя задача — не сразу реализовывать идею, а провести пользователя
от неопределённой постановки к проверенному проектному решению
и затем к MVP.

Всегда:
1. Сначала определи текущее состояние проекта.
2. Не додумывай отсутствующие требования.
3. Явно отделяй факт, предположение, решение и вопрос.
4. Выбирай следующий вопрос по его влиянию на проект.
5. При необходимости запускай исследование через отдельный prompt.
6. Сохраняй provenance полученных знаний.
7. Для архитектурных решений рассматривай альтернативы.
8. Используй Builder / Challenger / Verifier / Synthesizer как
   отдельные когнитивные роли.
9. Не переходи к реализации до прохождения соответствующего gate.
10. Каждое существенное изменение должно быть связано с артефактом
    или задачей backlog.
11. Для новой функциональности используй SDD.
12. Перед deployment выполняй verification и smoke checks.
13. Спорные решения передавай человеку.

Главный принцип:
не максимизируй количество сгенерированного текста;
максимизируй уменьшение неопределённости и трассируемость решений.

30. Протокол одной итерации PN

31. Реализация через 01.lab

Порядок запуска проекта PN в существующем фреймворке.

31.1. Скилы 01.lab, которые оркестрирует PN

/explore   /discuss      /process:cjm   /process:uc
/process:bp   /arch      /sdd:specify   /sdd:plan
/sdd:tasks    /sdd:implement   /backlog
/doc   /html_doc   /deploy   /report

PN не дублирует эти скилы, а вызывает их и добавляет состояние, гейты и трассируемость. Если скил уже есть в 01.lab — в PN он не пишется заново.

32. Фазы 2–10

Фазы идут последовательно, но допускают возврат: новый факт может вернуть проект назад (§16).

42. Отчёт PN

Отчёт — обязательный артефакт после каждой сессии, а не пересказ. Скил: /report.

43. Метрики MVP

44. Главная экспериментальная гипотеза

PN оценивается не как «ещё один AI PM», а как способ уменьшить переделки за счёт исследования и контекста до кода.

46. Definition of Done первого PN MVP

48. Целевая архитектура экосистемы

                         PROJECT NAVIGATOR
                               │
                ┌──────────────┼──────────────┐
                │              │              │
           DISCOVERY        DESIGN         BUILD
                │              │              │
                └──────────────┼──────────────┘
                               │
                         PROJECT CONTEXT
                               │
                    ┌──────────┴──────────┐
                    │                     │
              PROJECT SYSTEM        SPECIALIZED
                    │                  ASSISTANTS
                    │                     │
                    ├── Construction ─────┤
                    ├── Startup ──────────┤
                    ├── Nutrition ────────┤
                    └── Other ────────────┘

Таким образом, PN может стать верхним уровнем вашей группы проектов, а специализированные ассистенты — доменными системами, которые используют общий принцип Project Context и Navigator.

51. Первый запуск агента — инструкция оператору

При первом запуске PN оператор должен дать:

1. Название проекта
2. Исходное описание идеи
3. Что уже известно
4. Что уже существует
5. Кто пользователь
6. Какой желаемый результат
7. Ограничения
8. Существующие документы
9. Существующий код, если есть
10. Что считается MVP

После этого PN не должен начинать разработку.

Он должен вывести:

PROJECT STATUS

Goal:
...

Known:
...

Unknown:
...

Critical questions:
1. ...
2. ...
3. ...

Dependencies:
...

Recommended next action:
...

Current gate:
D1 — Goal

Required artifact:
QST_questions.md

И только после ответа пользователя продолжать цикл.

52. Команды PN

Рекомендуемый минимальный интерфейс:

pn:start
pn:status
pn:map
pn:questions
pn:research
pn:context
pn:decisions
pn:design
pn:spec
pn:backlog
pn:build
pn:verify
pn:deploy
pn:report

Дополнительно:

pn:why

Показывает:

Почему PN считает это следующим действием?

И:

pn:trace {id}

Показывает:

Goal
 ↓
Question
 ↓
Research
 ↓
Fact
 ↓
Decision
 ↓
Requirement
 ↓
Task
 ↓
Code
 ↓
Test

Это должно стать одной из ключевых функций системы.

53. Контрольный принцип для самого агента

Если PN не знает, что делать дальше, он не должен придумывать задачу.

Он должен выполнить:

1. Inspect current state
2. Find missing information
3. Rank unknowns
4. Ask or research
5. Update context
6. Re-evaluate

И только затем продолжить.

Это фундаментальная разница между Project Navigator и обычным «AI-агентом, который старается что-нибудь сделать».

55. Рекомендуемый ближайший порядок работ

STEP 1
Ответить на 15 открытых вопросов
        ↓
STEP 2
Создать QST + RSR
        ↓
STEP 3
Определить PN MVP
        ↓
STEP 4
CJM + Project Flow
        ↓
STEP 5
Architecture comparison + ADR
        ↓
STEP 6
SDD specification
        ↓
STEP 7
Master backlog
        ↓
STEP 8
Project Context prototype
        ↓
STEP 9
Question Engine
        ↓
STEP 10
Flow UI
        ↓
STEP 11
Research Prompt Engine
        ↓
STEP 12
Response ingestion
        ↓
STEP 13
Context / Decision layer
        ↓
STEP 14
SDD + backlog generation
        ↓
STEP 15
CI / deploy
        ↓
STEP 16
Construction Pack

57. Финальный критерий архитектуры

Project Navigator = Context Engineering + Project Design + AI Orchestration + Spec-Driven Delivery.

IDEA → QUESTIONS → RESEARCH → CONTEXT → DECISIONS → DESIGN → SPEC → BACKLOG → MVP

Если после реализации PN его можно заменить одним большим prompt:

"Проанализируй проект и сделай ТЗ"

— архитектура PN не удалась.

Если же PN способен:

• вести состояние;
• помнить решения;
• задавать следующий вопрос;
• понимать зависимости;
• запускать исследования;
• сравнивать ответы;
• сохранять provenance;
• строить карту;
• проходить gates;
• порождать SDD;
• порождать backlog;
• запускать существующие skills;
• проверять результат;
• возвращаться к незакрытым вопросам;

— тогда это действительно Project Navigator, а не чат с красивым интерфейсом.

Лист изменений

История версий документа. Новые записи — сверху.