EveryDay

Imported from yagudArch/EveryDay (AGENTS.md). Install upstream with npx skills add yagudArch/EveryDay. Copyright stays with the author.

# AGENTS.md

## Проект

Название: «Каждый день»

Тип: мобильное приложение iOS + Android с AI-функциями.

Над проектом одновременно работают 5 AI-агентов одной модели:

1. LEAD / ARCHITECT

2. MOBILE

3. BACKEND

4. AI ENGINEER

5. QA / DEVOPS

---

# 1. ИСТОЧНИКИ ИСТИНЫ

Перед началом работы каждый агент обязан прочитать:

1. MASTER_PROMPT.md

2. AGENTS.md

3. .ai/PROJECT_STATE.md

4. .ai/TASKS.md

5. .ai/ACTIVE_WORK.md

6. .ai/ARCHITECTURE.md

7. свой файл в agent-roles/

Источниками актуального состояния проекта являются:

1. реальные файлы проекта;

2. Git;

3. .ai/PROJECT_STATE.md;

4. .ai/TASKS.md;

5. .ai/ACTIVE_WORK.md;

6. история текущего чата.

Не считать память текущего чата актуальным состоянием проекта.

---

# 2. MASTER_PROMPT.md

MASTER_PROMPT.md содержит продуктовые требования.

Все агенты обязаны соблюдать его.

Обычные агенты не имеют права самостоятельно изменять MASTER_PROMPT.md.

Если появляется новое требование от пользователя:

1. сообщить об изменении LEAD;

2. LEAD принимает решение;

3. LEAD обновляет MASTER_PROMPT.md при необходимости.

---

# 3. РОЛИ

## LEAD / ARCHITECT

Отвечает за:

- общую архитектуру;

- технические решения;

- декомпозицию;

- TASKS.md;

- координацию агентов;

- API contracts;

- shared models;

- интеграцию;

- архитектурные изменения;

- Git coordination.

LEAD является главным координатором проекта.

---

## MOBILE

Отвечает за:

- mobile application;

- UI;

- UX;

- navigation;

- onboarding;

- client-side state;

- screens;

- widgets;

- shortcuts;

- mobile integrations;

- accessibility.

---

## BACKEND

Отвечает за:

- backend;

- API;

- database;

- authentication;

- authorization;

- business services;

- subscriptions;

- persistence;

- migrations.

---

## AI ENGINEER

Отвечает за:

- AI abstraction;

- AI providers;

- Vision;

- Speech-to-Text;

- intent parsing;

- structured output;

- tool calling;

- memory;

- recommendations;

- Change Detection;

- AI Assistant.

---

## QA / DEVOPS

Отвечает за:

- build;

- tests;

- integration tests;

- E2E;

- regression;

- performance;

- CI/CD;

- environment validation;

- release checks.

---

# 4. TASKS.md

TASKS.md принадлежит LEAD.

По умолчанию TASKS.md пустой.

Только LEAD имеет право:

- создавать новые задачи;

- удалять задачи;

- назначать задачи;

- менять приоритеты;

- менять зависимости;

- закрывать задачи.

Остальные агенты:

- читают TASKS.md;

- работают только над назначенными задачами;

- могут обновлять статус своей назначенной задачи;

- не создают новые задачи самостоятельно.

Если агент обнаружил новую проблему:

1. не создавать новую задачу самостоятельно;

2. записать проблему в ACTIVE_WORK.md;

3. сообщить LEAD;

4. дождаться решения LEAD.

Если TASKS.md пустой и агенту ничего не назначено:

- не придумывать себе работу;

- не начинать произвольную разработку;

- сообщить LEAD об отсутствии назначенной задачи.

---

# 5. ACTIVE_WORK.md

ACTIVE_WORK.md — оперативный файл совместной работы.

Все агенты могут его изменять.

Перед началом работы агент должен указать:

- свою роль;

- TASK ID;

- статус;

- файлы, которые собирается изменять;

- потенциальные зависимости.

Перед commit агент обновляет свой блок, фиксируя REVIEW или BLOCKED по фактическому состоянию. После подтверждённых commit/push и чистого git status LEAD подтверждает завершение; последующее обновление блока также обязательно закоммитить и отправить по разделу 14.

Не удалять активную информацию другого агента.

---

# 6. PROJECT_STATE.md

PROJECT_STATE.md является кратким текущим снимком состояния проекта.

Его не использовать как историю изменений.

История находится в CHANGELOG.md.

LEAD является ответственным за итоговую актуальность PROJECT_STATE.md.

Другие агенты могут предоставить LEAD информацию для обновления состояния.

После значимого изменения агент должен сообщить:

- что сделано;

- что работает;

- какие проблемы остались.

---

# 7. ARCHITECTURE.md

ARCHITECTURE.md содержит актуальные архитектурные решения.

Владелец файла — LEAD.

Другие агенты:

- читают файл;

- могут предложить изменение;

- не изменяют архитектуру самостоятельно без решения LEAD.

Процесс изменения:

Agent proposal

→ LEAD review

→ architecture decision

→ ARCHITECTURE.md update

→ implementation

---

# 8. CHANGELOG.md

CHANGELOG.md — история изменений.

Все агенты могут добавлять записи.

Записи только добавляются в конец файла.

Не переписывать и не удалять старые записи без отдельного решения LEAD.

Каждая запись должна содержать:

- дату;

- агента;

- краткое описание изменений.

---

9. GIT — ОБЯЗАТЕЛЬНЫЙ WORKFLOW

Единый порядок для всех ролей, включая LEAD, и всех задач с изменениями, включая документацию и .ai:

git status → работа → тесты/build → git diff → git add → git commit → git push → git status

1. До работы: выполнить git status, проверить текущую ветку, remote/upstream, последние commits, индекс и незакоммиченные изменения. Зарезервировать задачу и файлы в .ai/ACTIVE_WORK.md. При чужих или неожиданных изменениях согласовать с LEAD изоляцию работы; не включать их в свою задачу.
2. Работа: менять только согласованные файлы и свою часть общих файлов; обновить относящиеся к задаче .ai/* до сдачи. В общем рабочем дереве операции с индексом, commit и push выполняет один согласованный исполнитель последовательно, без конкурирующих Git-операций.
3. Тесты/build: запустить соответствующие тесты и сборку, устранить ошибки своей задачи и зафиксировать результаты. Для неприменимой проверки явно указать причину; недоступность обязательной проверки — блокировка, а не успешный результат. Для docs-only задач проверить согласованность правил и отсутствие изменений кода; доступные проектные проверки не пропускать молча.
4. Diff: после работы и проверок выполнить git diff, git diff --check и git status; просмотреть каждый изменённый и новый файл. Проверить также уже подготовленный индекс через git diff --cached.
5. Git identity перед каждым commit: проверить git config --get user.name, git config --get user.email, git var GIT_AUTHOR_IDENT и git var GIT_COMMITTER_IDENT. Имя/email и фактические author/committer должны соответствовать согласованной identity. При отсутствии или неожиданном значении остановиться и сообщить LEAD/заказчику; не выдумывать identity и не менять глобальную конфигурацию.
6. Адресный staging: выполнить git add -- <согласованные файлы> либо добавить только свои hunks. Не использовать слепой git add ./git add -A. Затем обязательно проверить git diff --cached --name-status, git diff --cached и git diff --cached --check: в commit не должны попасть случайные, временные, сгенерированные вне задачи, секретные или чужие изменения, даже если они уже были в индексе. При смешанном индексе остановиться и согласовать действия с владельцем/LEAD.
7. Commit обязателен: выполнить git commit с осмысленным сообщением и проверить результат/SHA. Сохранённые файлы, успешные тесты или готовый diff без commit не означают завершение.
8. Push обязателен: проверить целевой remote/ветку и состав исходящих commits, выполнить git push в согласованную ветку и проверить успешную отправку commits задачи. Не отправлять несогласованную чужую историю. Commit без push не считается завершением. Чистое дерево само по себе не доказывает отправку.
9. После push: выполнить git status и git status --porcelain=v1 --untracked-files=all. Вывод porcelain должен быть пустым: нет staged, unstaged, конфликтующих или untracked файлов. Проверить, что commits задачи присутствуют в целевой remote-ветке и нет неотправленных commits задачи. Только после этого допустим отчёт о завершении.

Если commit, push или проверка чистого дерева невозможны (identity, права, сеть, hooks, защита ветки, конфликт, чужая работа и т. п.), задача не завершена. Установить BLOCKED в своём блоке .ai/ACTIVE_WORK.md и статусе назначенной задачи; указать ветку/remote, затронутые файлы, команду и ошибку без секретов, SHA при наличии, результат push, текущий status и необходимое действие. Немедленно передать проблему LEAD, а LEAD — заказчику. При невозможности commit запись о блокировке остаётся локальной и передаётся сообщением; не скрывать её.

Запрещено обходить блокировку destructive reset, удалением/перезаписью чужих изменений, массовым revert, force-push, отключением hooks/защиты или сокрытием файлов через ignore/stash только ради чистого статуса. После устранения причины повторить оставшиеся шаги и проверки; до этого DONE запрещён.

---

# 10. КОНФЛИКТЫ ФАЙЛОВ

Не редактировать одновременно один критический файл несколькими агентами без координации.

Перед изменением общего файла проверить:

.ai/ACTIVE_WORK.md

Если файл уже занят другим агентом:

- не перезаписывать его;

- сообщить LEAD;

- дождаться решения.

К критическим общим файлам относятся:

- database schema;

- API contracts;

- shared models;

- package configuration;

- build configuration;

- environment configuration;

- архитектурные файлы.

---

# 11. ОБЩИЕ ПРАВИЛА

Все агенты обязаны:

- не выдумывать данные пользователя;

- не создавать fake production data;

- не ломать существующую функциональность;

- не скрывать ошибки mock-данными;

- проверять свои изменения;

- запускать доступные тесты;

- поддерживать работоспособность проекта.

---

# 12. ГОЛОСОВОЙ ВВОД

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

Голосовой ввод запускается только после явного действия пользователя.

Одна голосовая фраза может содержать несколько действий.

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

Неуверенные действия требуют подтверждения пользователя.

---

# 13. AI DATA INTEGRITY

AI не имеет права:

- придумывать продукты пользователя;

- придумывать одежду пользователя;

- придумывать факты о питании;

- придумывать активность;

- придумывать планы;

- выдавать abstract outfit за real wardrobe.

Если данных нет:

- получить их через соответствующий tool/API;

- либо сообщить, что данных нет.

---

# 14. ЗАВЕРШЕНИЕ ЗАДАЧИ

Завершение — не только готовый код или текст. Для каждой задачи с изменениями обязательна полная цепочка раздела 9:

git status → работа → тесты/build → git diff → git add → git commit → git push → git status

1. Проверить результат и выполнить соответствующие тесты/build; зафиксировать фактические результаты и ограничения. Ошибка обязательной проверки блокирует завершение.
2. До commit обновить свой блок .ai/ACTIVE_WORK.md, статус назначенной задачи (REVIEW, не DONE), добавить запись в .ai/CHANGELOG.md. Изменения .ai/PROJECT_STATE.md согласовать с LEAD. Все эти правки входят в проверяемый diff задачи.
3. Проверить Git identity, diff и индекс, выполнить адресный git add, проверить staged diff и сделать обязательный commit только изменений задачи.
4. Выполнить обязательный push в согласованную remote-ветку; проверить отправку commits задачи и чистый git status после push. Commit без push, неотправленные commits или нечистое дерево запрещают завершение.
5. Передать LEAD отчёт: TASK ID, изменённые файлы, результаты тестов/build, SHA и сообщение commit, целевая ветка и результат push, итоговый git status, оставшиеся ограничения. LEAD для своей задачи отчитывается заказчику.
6. Только LEAD подтверждает DONE по этим фактам. Если после подтверждения обновляются статусы или другие .ai/*, оформить их отдельным проверенным commit, выполнить push и вновь проверить чистый git status. Не оставлять незакоммиченную запись о завершении после последнего push; финальный отчёт допускается только после сдачи также этих изменений.

Если commit/push невозможен или финальная проверка не пройдена, не объявлять задачу завершённой: записать BLOCKED и диагностику в .ai/ACTIVE_WORK.md и статусе своей задачи, сообщить LEAD/заказчику по разделу 9. Частичная передача результата на REVIEW не заменяет завершение.

Эти критерии обязательны для MASTER_PROMPT.md и всех agent-roles/*.md. Ролевые инструкции дополняют, но не отменяют их; LEAD обязан поддерживать согласованность всех документов и не принимать работу без commit/push/чистого статуса.

---

# 15. ПРАВИЛО КООРДИНАЦИИ

LEAD является единственным техническим координатором.

Если между агентами возникает противоречие:

→ не решать архитектурный конфликт самостоятельно;

→ сообщить LEAD;

→ LEAD принимает решение.

Главная цель команды:

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