Действующие правила проекта SKUARO

Статус политики: ДЕЙСТВУЕТ

Применено: 2026-08-26.

Реестр правил

ID	Правило	Принятое значение	Статус
CORE-01	Файлы проекта — долговременная память	Включено	ПРИНЯТО
CORE-02	STATUS.md — актуальный снимок	Включено	ПРИНЯТО
AI-01	Агент читает правила и статус до работы	Включено	ПРИНЯТО
AI-02	Опасные внешние действия требуют разрешения	Включено	ПРИНЯТО
AI-03	Повторяемый опыт агентов является общим и Git-версионируемым	Канонические правила отдельно; полезный опыт в docs/agent-memory/	ПРИНЯТО
AI-04	Skills создаются и улучшаются по проверяемому жизненному циклу	Поиск существующего Skill обязателен; критические Skills требуют независимого review	ПРИНЯТО
AI-05	Verification запускается отдельным контуром	Обычная DEV/STAGE-итерация не требует READY_FOR_VERIFICATION, verifier или evidence matrix; полный процесс включается командой ПРОВЕРИТЬ или перед PROD	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
AI-06	Агентские роли используются по отдельной необходимости	Обычная DEV/STAGE-итерация выполняется основным агентом; subagents и независимый verifier подключаются только отдельной командой или перед PROD	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
AI-07	Внешний UI/UX-агент работает через reference workspace	Одна stateful-задача в docs/ui-agent/TASK.md; result автоматически принимается целиком как точный visual reference без отдельного UI-аудита; внутренняя команда переносит его как есть, сохраняя Product contracts и runtime	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
LANG-01	Языки и локализация определены	Русский интерфейс и документация; английские код и идентификаторы; английская локализация позже	ПРИНЯТО
DOC-01	Session log создаётся при закрытии содержательной сессии	Стандартный	ПРИНЯТО
DOC-02	Changelog не дублирует Git	Только заметные пользователю изменения	ПРИНЯТО
DOC-03	Документация разделена по аудитории	User docs и developer docs в отдельном Docs-репозитории	ПРИНЯТО
GIT-01	Один приватный репозиторий на поставляемый контур	Product, Site и Docs разделены	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
GIT-02	Сохраняются все значимые данные проекта	Секреты, системный мусор, кэш и воспроизводимые файлы исключаются по принятой политике	ПРИНЯТО
GIT-03	Force push и переписывание истории запрещены без разрешения	Включено	ПРИНЯТО
SEC-01	Секреты исключаются и проверяются по содержимому	Внешняя папка /Users/alexzandr/MEGA/____SECRETS вместо защищённого менеджера	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
SIZE-01	Крупный файл требует решения пользователя	От 50 MiB	ПРИНЯТО
SESSION-01	закрываем сессию разрешает commit и push	Только текущая согласованная ветка приватного origin	ПРИНЯТО
RECOVERY-01	Новый агент сначала реконструирует контекст	Включено; продолжение подтверждает владелец	ПРИНЯТО
EXT-01	Расширения описаны и воспроизводимы	Выбраны repo-scoped agent-learning, task-verification и candidate production-readiness; остальные будущие расширения фиксируются в реестре	ПРИНЯТО
REPORT-01	Отчёт соответствует контуру	Обычная итерация: результат, URL и что проверить; расширенный evidence-отчёт только для отдельной проверки или PROD	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
PROD-01	Подготовка к production выполняется отдельно	ПОДГОТОВИТЬ К ПРОДАКШНУ запускает полный audit/repair/independent GO-NO-GO после ручного STAGE-теста; PROD deploy требует отдельной явной команды владельца	ПРИНЯТО
ARCH-01	Целевая production-архитектура выбрана	React/Vite, Fastify, PostgreSQL, Drizzle, pg-boss, Docker Compose	ПРИНЯТО
MVP-01	Ранний MVP не ограничивает продукт	Исследование «Сегодня» сохраняется как история приоритета, но CRM, коммуникации, AI и любые необходимые функции разрешены	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
ENV-01	Среды и домены разделены	DEV/STAGE на тестовом сервере, PROD на отдельном сервере	ПРИНЯТО
REL-01	Версия продукта использует CalVer	YY.MM.DD.NN только для lk.skuaro.com	ПРИНЯТО
ACCESS-01	Доступ всех пользователей определяется ролевой моделью	Платформенные и организационные роли разделены; backend является источником истины для прав	ПРИНЯТО
MODULE-01	Пользовательская функциональность разделяется на продуктовые модули	Тариф активирует модули организации; роль и module permissions определяют доступ пользователя	ПРИНЯТО
ACCESS-02	Внутренние маршруты защищаются SKUARO Auth	Текущие /settings, /today, /admin/* и целевые /home, /settings/*, /organization/settings/* с их API проверяют сессию и backend-права; серверный Basic Auth не заменяет Product Auth	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
MODULE-02	Новая разработка перед реализацией классифицируется	Product modules живут в modules/<module-id>; platform, integrations, shared packages, apps и infra разделены	ПРИНЯТО
DOC-04	Стек Docs-репозитория определён	Material for MkDocs 9.x OSS; developer docs публикуются на dev-doc.skuaro.top публично для тестов и с noindex	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
ACCESS-03	Basic Auth выключен по умолчанию	DEV, STAGE, Site, Product App, user docs, developer docs и API reference доступны для тестов без серверного логина; Basic Auth разрешён только по новому прямому запросу владельца	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
UI-01	Главная, продуктовые модули и внутренний каркас разделены	/home является platform capability; today остаётся модулем; защищённые страницы используют общий AppShell и зоны S1–S3, P1–P6, O1–O3	ПРИНЯТО
UI-02	Result UI/UX-агента принимается без повторной визуальной проверки	Цвета, размеры, компоновка, таблицы, логотипы, иконки, UI-ассеты и UI-скрипты являются точным reference и переносятся как есть; технические Product contracts и runtime остаются ответственностью внутренней команды	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
ENV-02	.top разделяет DEV и STAGE, .com сохраняется для PROD	STAGE: skuaro.top, lk.skuaro.top, doc.skuaro.top; developer docs: dev-doc.skuaro.top; служебные файлы разрешены в STAGE по необходимости	ПРИНЯТО
REL-02	STAGE является живым test-контуром	Текущий рабочий snapshot размещается после реализации без commit/hash/merge gate; merge и PROD остаются отдельными процессами	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
DEVFLOW-01	Разработка идёт через быстрый STAGE-цикл	Реализация → минимальная сборка/запуск → STAGE → ручная UI/UX-проверка владельцем → исправление	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
DEVFLOW-02	Расширенные проверки не запускаются по умолчанию	Reviewer/tester, полные suites, security, hashes, backup/restore и повторные smoke — только отдельной командой или перед PROD	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
ENV-03	STAGE функционально production-like	Открытая регистрация, email/Auth, permissions и функции работают штатно без test-only bypass, mocks, тестовых аккаунтов и ограничений среды	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ
DATA-01	Данные сред изолированы	Реальные STAGE-аккаунты создаются обычной регистрацией; клиентские бизнес-данные не копируются из PROD автоматически, DB/sessions/credentials разделены	ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ

Итого: ПРИНЯТО — 25; ИЗМЕНЕНО ПОЛЬЗОВАТЕЛЕМ — 16; НЕ ПРИМЕНЯЕТСЯ — 0; ТРЕБУЕТ РЕШЕНИЯ — 0.

Автономность AI

Без дополнительного подтверждения разрешены чтение и анализ файлов, изменения строго по поставленной задаче и безопасные проверки внутри текущего проекта.

Перед установкой или обновлением программ и зависимостей AI объясняет назначение и последствия и получает подтверждение.

Отдельного разрешения требуют:

• чтение, перечисление или изменение содержимого внешней папки секретов;
• удаление или необратимая перезапись данных;
• публикация, deploy и отправка данных третьим лицам; исключение — обычный deploy текущей разрешённой Product-итерации в существующий STAGE-контур по быстрому циклу решения 0032, если владелец не сказал работать только локально;
• создание или изменение удалённых ресурсов, включая Site/Docs репозитории, сервер и DNS;
• смена origin, видимости репозитория или веточной политики;
• merge, PR и продвижение между DEV, STAGE и PROD;
• рискованный rebase, force push и переписывание истории;
• обычный push вне подтверждённой команды закрываем сессию.

ПРИМЕНИТЬ разрешает локально применить полную подтверждённую сводку и провести аудит. Команда не разрешает установку зависимостей, внешние действия, работу с секретами, commit или push.

Архитектурная граница

Целевая архитектура описана в docs/ARCHITECTURE.md и актуальных решениях docs/decisions/. Решение 0014 делает классификацию новой разработки и каталог modules/<module-id> постоянными правилами. Решение 0018 закрепляет /home, общий AppShell, визуальные зоны и отделение личных настроек от настроек организации. Решения 0032 и 0033 устанавливают быстрый live STAGE-процесс и открытую функциональную границу. Решения 0020 и 0022 сохраняются как отдельный verification/production-контур, а не обязательный gate обычной разработки.

До объявления результата product gate были разрешены:

• продуктовая документация и UX;
• локальный технический каркас без широкой бизнес-логики;
• CI, контейнеризация и безопасные проверки;
• защищённая публикация текущего демонстрационного прототипа в DEV после отдельного разрешения на deploy.

Владелец проекта объявил результат ПОДТВЕРЖДЕНО 2026-08-21. Условие входа в фазу 4 выполнено: разрешён последовательный вертикальный backend-срез «Сегодня» по docs/IMPLEMENTATION_PLAN.md. Это не отменяет отдельных решений по зависимостям, провайдерам, реальным данным, интеграциям, AI, deploy и другим внешним действиям.

Отложенные решения

Решение	Что разрешено	Что заблокировано	Когда переспросить
Auth-библиотека	Проектирование auth-контракта и PoC Better Auth	Признание Better Auth постоянной зависимостью без PoC	После PoC sign-up/verify/login/recovery/revoke
Продолжение неподтверждённой регистрации	Спецификация отдельного реестра, содержащего только email	Сбор реальных email и отправка писем до решения consent, retention, удаления, частоты и anti-abuse	Перед реализацией реестра или первой отправкой
Внешние провайдеры и интеграции	Provider interfaces и синтетические PoC	Production email, Telegram, AI или CRM connector без выбора	Перед первым реальным подключением
Реальные клиентские данные	Синтетические и демонстрационные данные	Ввод реальных PII и клиентских данных	После правовой, security и operational проверки
Бюджет и сроки	Безопасная внутренняя работа без расходов и обещаний	Платные обязательства и обещание даты	Перед соответствующим действием

Отложенный вопрос блокирует только связанное действие и не отменяет принятую целевую архитектуру.

Документирование

• docs/STATUS.md — единственный актуальный снимок.
• docs/ARCHITECTURE.md — целевая техническая схема.
• docs/IMPLEMENTATION_PLAN.md — порядок фаз и контрольных разрешений.
• docs/DOCUMENTATION_STRATEGY.md — разделение user/developer docs и правила публикации.
• docs/AGENT_MEMORY_AND_SKILLS.md — общая память агентов и жизненный цикл проектных Skills.
• docs/AGENT_WORKFLOW.md — отдельный verification/production-контур, не обязательный для обычной DEV/STAGE-итерации.
• docs/PRODUCTION_READINESS.md — полный audit/repair/GO-NO-GO перед отдельным решением о PROD deploy.
• docs/ui-agent/TASK.md — единственная текущая задача внешнему UI/UX-агенту; results/ и memory/ хранят reference artifacts.
• docs/AGENT_ROLES.md — профили, границы ответственности и маршрутизация subagents.
• Session log создаётся при закрытии содержательной сессии и не копирует чат или полный вывод терминала.
• docs/CHANGELOG.md обновляется только при заметном пользователю изменении.
• ADR создаётся для существенного выбора архитектуры, инструмента, структуры, риска или политики.

Репозитории, Git и ветки

Экосистема разделена на три приватных репозитория:

• webuzateam/SkuAro-DEV — product-монорепозиторий и текущий корень;
• webuzateam/SkuAro-Site — согласован, но ещё не создан в рамках текущей работы;
• webuzateam/SkuAro-Docs — согласован, но ещё не создан в рамках текущей работы.

Для product-репозитория:

• origin: https://github.com/webuzateam/SkuAro-DEV.git;
• DEV — активная разработка и основная рабочая ветка;
• STAGE — тестирование;
• PROD — production;
• закрываем сессию разрешает commit и обычный push только в текущую согласованную ветку, обычно DEV;
• merge, PR и продвижение DEV -> STAGE -> PROD требуют отдельной команды; после активации решения 0020 разрешённый merge в STAGE автоматически разрешает deploy соответствующего STAGE-контура без второй команды;
• при неудачных тестах состояние можно сохранить в DEV с явной записью ошибки, но продвижение блокируется.

Секреты и крупные файлы

• Значения секретов не записываются в проект, отчёт или чат.
• Фактические секреты, ключи, логины и пароли хранятся в /Users/alexzandr/MEGA/____SECRETS.
• Путь находится вне Git-проекта, но внутри дерева MEGA; риск возможной синхронизации принят владельцем после предупреждения.
• AI не читает, не перечисляет и не изменяет содержимое внешней папки без отдельной явной задачи.
• Перед commit проверяются пути, содержимое и размеры staged-файлов.
• Файл от 50 MiB не включается в commit до решения пользователя.
• Git LFS, сжатие, внешнее хранилище, исключение и удаление не применяются автоматически.

Формат отчёта

Расширенный отчёт включает результат, контекст, границы, все изменённые файлы, проверки и причины пропусков, безопасность, ошибки, решения и последствия, Git-состояние, риски и конкретный следующий шаг.