# Основы и архитектура
Версия источника: 4880e8b4372c96001c2e052be28b68a95d31252b
Синхронизировано: 2026-11-09T11:15:07.649Z
Источник: https://github.com/sergey-from-riders/vibecoding-base/tree/4880e8b4372c96001c2e052be28b68a95d31252b
## Оглавление
- [Границы задачи](#architecture-scope)
- [Единый источник истины](#architecture-one-source)
- [Контракты компонентов](#architecture-contract-first)
- [Вертикальный сценарий](#architecture-thin-slice)
- [Зависимости проекта](#architecture-choose-dependencies)
- [Критерии готовности](#architecture-readiness)
# Границы задачи
## Коротко
Опишите поведение, которое должен получить пользователь, и способ его проверить.
## Плохо
```text
Сделай современную систему целиком.
```
## Хорошо
```text
Пользователь скачивает счёт.
Учитываем доступ и ошибки.
Готово: чужой счёт скачать нельзя.
```
## Почему
Без границ агент может потратить время на ненужные функции.
## Когда применять
Это инженерное правило справочника, а не требование протокола. Первоисточник описывает подход или механизм; конкретный процесс выбирается проектом.
Для изменений поведения. Опечатку можно исправить без отдельного проектного документа.
## Как проверить
- Можно ли понять из задачи, что должно получиться?
## Человек
Определяет результат, ограничения и приоритет задачи.
## Агент
Изучает существующий код, предлагает минимальное решение и связывает изменения с критериями приёмки.
Контроль результата:
- Можно ли понять из задачи, что должно получиться?
## Источники
- [Writing good CL descriptions](https://google.github.io/eng-practices/review/developer/cl-descriptions.html)
Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/framework/lifecycle/rules/scope.md)
---
# Единый источник истины
## Коротко
Сайт, документация и инструкции агента должны собираться из одного оригинала.
## Плохо
```text
Правило исправлено на сайте.
Markdown и инструкции остались прежними.
```
## Хорошо
```text
Правило исправлено в Markdown.
Сайт и инструкции обновлены из него.
```
## Почему
Редактируемые копии со временем противоречат друг другу.
## Когда применять
Это инженерное правило справочника, а не требование протокола. Первоисточник описывает подход или механизм; конкретный процесс выбирается проектом.
Копии для чтения и кеш допустимы, если известны источник и версия.
## Как проверить
- Внесите изменение в оригинал и проверьте все представления.
## Человек
Назначает канонический источник и владельца данных.
## Агент
Изучает существующий код, предлагает минимальное решение и связывает изменения с критериями приёмки.
Контроль результата:
- Внесите изменение в оригинал и проверьте все представления.
## Источники
- [Creating reusable content - GitHub Docs](https://docs.github.com/en/contributing/writing-for-github-docs/creating-reusable-content)
Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/framework/lifecycle/rules/one-source.md)
---
# Контракты компонентов
## Коротко
Опишите вход, выход, ошибки и права, когда несколько частей системы взаимодействуют.
## Плохо
```text
Frontend ждёт price.
Backend отдаёт amount.
```
## Хорошо
```text
Контракт: amountMinor + currency.
Обе стороны проверяют один контракт.
```
## Почему
Несогласованные интерфейсы ломают интеграцию даже при работающих отдельных модулях.
## Когда применять
Для внешних границ и совместной разработки. Внутренней функции не всегда нужен OpenAPI.
## Как проверить
- Есть ли пример успешного ответа и ошибки?
## Человек
Согласует вход, выход, ошибки и владельцев границ.
## Агент
Изучает существующий код, предлагает минимальное решение и связывает изменения с критериями приёмки.
Контроль результата:
- Есть ли пример успешного ответа и ошибки?
## Источники
- [OpenAPI Specification v3.2.0](https://spec.openapis.org/oas/v3.2.0.html)
Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/framework/lifecycle/rules/contract-first.md)
---
# Вертикальный сценарий
## Коротко
Связывайте интерфейс, данные и проверки небольшими законченными изменениями.
## Плохо
```text
20 пустых обработчиков.
Ни один сценарий не работает.
```
## Хорошо
```text
Один запрос → проверка доступа → данные → ответ.
Есть проверка результата.
```
## Почему
Так ошибки взаимодействия обнаруживаются раньше.
## Когда применять
Это инженерное правило справочника, а не требование протокола. Первоисточник описывает подход или механизм; конкретный процесс выбирается проектом.
Рекомендация для продуктовой разработки; отдельное исследование может не иметь рабочего интерфейса.
## Как проверить
- Можно ли показать завершённый пользовательский сценарий?
## Человек
Выбирает минимальный полезный сценарий для первого выпуска.
## Агент
Изучает существующий код, предлагает минимальное решение и связывает изменения с критериями приёмки.
Контроль результата:
- Можно ли показать завершённый пользовательский сценарий?
## Источники
- [Small CLs](https://google.github.io/eng-practices/review/developer/small-cls.html)
Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/framework/lifecycle/rules/thin-slice.md)
---
# Зависимости проекта
## Коротко
Новый сервис или пакет должен решать измеримую задачу и иметь понятную поддержку.
## Плохо
```text
Для справочника сразу добавлены БД, очередь и Redis.
```
## Хорошо
```text
Markdown хранится в Git.
Сайт читает проверенный снимок файлов.
```
## Почему
Каждый дополнительный компонент требует обновлений, мониторинга и восстановления.
## Когда применять
Это инженерное правило справочника, а не требование протокола. Первоисточник описывает подход или механизм; конкретный процесс выбирается проектом.
Инфраструктура оправдана нагрузкой или требованиями, а не модой.
## Как проверить
- Какое требование нельзя выполнить существующими средствами?
## Человек
Подтверждает необходимость зависимости и ограничения по поддержке.
## Агент
Изучает существующий код, предлагает минимальное решение и связывает изменения с критериями приёмки.
Контроль результата:
- Какое требование нельзя выполнить существующими средствами?
## Источники
- [Google SRE - Operational Simplicity: Stability and Agility](https://sre.google/sre-book/simplicity/)
Уровень: Зависит от задачи. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/framework/lifecycle/rules/choose-dependencies.md)
---
# Критерии готовности
## Коротко
Разделяйте готовый шаблон, работающий сервис и реально выполненные проверки.
## Плохо
```text
Production ready: папки и README созданы.
```
## Хорошо
```text
Шаблон готов. Runtime частичный.
Проверена структура. Нагрузочные тесты не выполнены.
```
## Почему
Наличие файлов не доказывает работоспособность.
## Когда применять
Это инженерное правило справочника, а не требование протокола. Первоисточник описывает подход или механизм; конкретный процесс выбирается проектом.
Для шаблонов, библиотек и релизов. Указывайте ограничения рядом с результатами.
## Как проверить
- Можно ли повторить заявленные проверки?
## Человек
Определяет наблюдаемые критерии приёмки и критические сценарии.
## Агент
Изучает существующий код, предлагает минимальное решение и связывает изменения с критериями приёмки.
Контроль результата:
- Можно ли повторить заявленные проверки?
## Источники
- [Google SRE - Deployment Strategies for Product Launches](https://sre.google/sre-book/reliable-product-launches/)
Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/framework/lifecycle/rules/readiness.md)