Идеи
идеяобновлено 26 окт 2026 · создано 24 окт 2026

Product Digital Twin

Офлайн CLI, который связывает требования, схемы Payload CMS, код Next.js и тесты в граф и показывает, что сломается при правке

toolingcmsarchitecture

Сейчас

Написать 2 паспорта фич на реальных блоках и проверить удобство формата

  • Формат feature_passport.md (Markdown с YAML-frontmatter): связывает требование ↔ схему Payload ↔ TS-типы ↔ пути в коде ↔ тесты.
  • Архитектура CLI: сканирует src/payload/blocks/*, извлекает контракты, сверяет их с паспортами, кэширует в graph.cache.json, выдаёт diff и отчёт о консистентности.
  • Критический анализ: как использовать автогенерируемые типы Payload (payload-types.ts) как «естественный граф» и ловить нарушения контрактов ещё до компиляции.

Суть

Статус: идея, контекст собран. Исходный промпт: PROMPT.md.

Офлайн CLI-инструмент для этапа разработки. Он связывает бизнес-требования, схемы Payload CMS, код Next.js и тесты в один граф и показывает, что сломается при изменении.

Проблема

  • Проект: Next.js (App Router) + Payload CMS, конструктор маркетинговых страниц. Маркетологи сами собирают секции и блоки в админке.
  • Требования приходят по крупицам, дизайн чинится на лету.
  • Блоки динамические, с условной логикой. Правка одного поля или схемы молча ломает рендер, ограничения или бизнес-правила в компонентах.
  • Хочется чистоты (SOLID/GRASP, строгий TS, тесты), а бизнес требует скорости.

Решение

  1. Impact analysis: поменяли требование или поле Payload → какие компоненты, типы и тесты затронуты.
  2. Мёртвый / слепой код: код или схемы без связи с требованием; требования без реализации.
  3. Загрязнение архитектуры: простой блок вдруг тянет глобальный контекст или чужой домен (нарушение SOLID/GRASP).

Не делаем

  • Никакого парсинга Figma и синхронизации с ней: дизайн слишком изменчив.
  • Никакого сравнения скриншотов через AI: адаптив даёт слишком много шума.
  • Отслеживаются только текст, код, схемы и бизнес-логика.

Итог

Контекст собран, MVP не начат. Следующий шаг: написать 2 паспорта на реальных блоках и проверить, удобен ли формат; потом шаг 2 из mvp-cli.md.

Что нужно спроектировать (задачи из промпта):

  • Формат feature_passport.md (Markdown с YAML-frontmatter): связывает требование ↔ схему Payload ↔ TS-типы ↔ пути в коде ↔ тесты.
  • Архитектура CLI: сканирует src/payload/blocks/*, извлекает контракты, сверяет их с паспортами, кэширует в graph.cache.json, выдаёт diff и отчёт о консистентности.
  • Критический анализ: как использовать автогенерируемые типы Payload (payload-types.ts) как «естественный граф» и ловить нарушения контрактов ещё до компиляции.

Подробнее

Что отслеживает граф (узлы)
Слой Что
Бизнес Текстовые требования, правила, SEO-запросы («поменять H1 на H2 в секции X»)
CMS Коллекции и блоки Payload, поля, условная логика админки
Код Компоненты Next.js, доменные интерфейсы, хуки
Проверки E2E на Playwright, юнит-тесты на Vitest/Jest

Опора (источник правды): исходные спеки, seed JSON (моки начальной раскладки) и реальные конфиги кода.

Мои заметки
  • Это и есть «матрица требований и граф зависимостей» из моих целей, только на реальном рабочем стеке.
  • Хорошо ложится на pipeline-kit (../ai-agents-24-7/pipeline-kit/): паспорт фичи близок к спеке в issue, а граф может автоматически давать скауту контекст.
  • По правилу «буханки» стоит начать с MVP: паспорта плюс скрипт, который сверяет поля блоков из payload-types.ts с паспортами. Граф, кэш и SOLID-проверки — потом.
  • Если это рабочий проект, код и схемы не отправлять в сторонние модели (см. ../ai-agents-24-7/knowledge/14_chinese_models_security.md).
Дизайн (черновик)