@gian-tiaga/eda 3.14.0 → 4.0.0

package/skills/eda-plan-review-fix/SKILL.md

@@ -11,16 +11,16 @@ description: 'Закрывает проваленные пункты чек-ли
 
 Текст рядом с вызовом — главный вход. Разбери путь или название review, «последнее ревью» и прямые указания пользователя. Если вход однозначен, продолжай без вопроса; при нескольких равных review или противоречивом target — `AskUserQuestion`.
 
-В Codex exec не читай stdin: верни `blocked: нужен ответ пользователя` до любых правок.
+В неинтерактивном запуске не читай stdin: верни `blocked: нужен ответ пользователя` до любых правок.
 
 ## Правила
 
 1. Работай только с review из `docs/artifacts/plan-reviews/` и его `plan` из `docs/artifacts/plans/`.
 2. Вычисли SHA-256 плана до правок. Он обязан совпасть с `plan_sha256` review. Не совпал — остановись: review устарел, нужен новый `eda-plan-review`.
-3. Перед правкой прочитай план, `docs/rules.md`, `docs/arch.md` и только применимые карточки из `sources.business` и `sources.references`; для старого плана выбери только применимые карточки через `docs/business.md` и `docs/references.md`.
+3. Перед правкой прочитай план, `docs/rules.md`, `docs/arch.md` и все файлы из `sources` полностью; для старого плана без раздела `Рамка` выбери только применимые карточки через `docs/business.md` и `docs/references.md`.
 4. Закрой каждый пункт со статусом `fail`. Пункты `pass` и `n/a` не трогай. Своих замечаний не добавляй: чего нет в отчёте, того нет в работе.
-5. **План не растёт.** Сначала ищи, что удалить или заменить, и только потом — что дописать. Прирост объёма за один fix не больше 3%; если пункт иначе не закрывается, остановись и верни `blocked: пункт требует роста плана` с объяснением.
-6. Не повторяй один факт в двух разделах: поведение живёт в `Целевом алгоритме`, контракты — в `Контрактах реализации`, фаза на них ссылается.
+5. **План не растёт.** Сначала ищи, что удалить или заменить, и только потом — что дописать. Прирост объёма за один fix не больше 3%. Пункт, который иначе не закрывается, оставь открытым с объяснением в разделе `Не закрытые пункты`, закрой остальные и сохрани отчёт со `status: partial`.
+6. Не повторяй один факт в двух разделах: требования документов живут в `Рамке`, поведение — в `Целевом алгоритме` нумерованными шагами, контракты — в `Контрактах реализации`, фаза на них ссылается.
 7. Не добавляй в план сигнатуры чужих методов, приведения типов, форму классов, внутренние вычисления без контрактного смысла и пересказ карточек — это те же пункты 9 и 10 чек-листа, только с другой стороны. Не удаляй и не переписывай только из-за формы записи формулу, которая задаёт бизнес-правило, контракт, инвариант или критерий приёмки.
 8. Продуктовый выбор, конфликт с business, rules или architecture и расширение scope не решай сам: собери все такие случаи и задай один блокирующий вопрос до любых правок.
 9. Не правь код, конфиги, зависимости, миграции и другие документы. Не запускай проверки проекта.
@@ -31,7 +31,7 @@ description: 'Закрывает проваленные пункты чек-ли
 2. Собери реальные блокирующие вопросы. Частичную правку до ответа не делай.
 3. Закрой все пункты одним связным минимальным изменением плана.
 4. Обнови front matter плана: `status: meta-reviewed`, `plan_review`, `plan_review_fix`. `status: reviewed` не ставь — это может сделать только подтверждающий review.
-5. Вычисли SHA-256 после правок как `$AFTER_SHA256`. Если пункты были, а хеш не изменился, остановись: `blocked: fix не изменил план`.
+5. Вычисли SHA-256 после правок как `$AFTER_SHA256`. Если пункты были, а хеш не изменился, сохрани отчёт со `status: no-change` и причиной в разделе `Не закрытые пункты`. `partial` и `no-change` — нормальные результаты, а не блокеры: решение о следующей итерации принимает вызывающий.
 
 ## Отчёт
 
@@ -45,7 +45,7 @@ before_sha256: <sha256 из review>
 after_sha256: <sha256 после изменения>
 before_bytes: <размер до>
 after_bytes: <размер после>
-status: done
+status: <done | partial | no-change>
 date: <YYYY-MM-DD HH:MM>
 ---
 
@@ -56,6 +56,9 @@ date: <YYYY-MM-DD HH:MM>
 |---|---|---|
 | 6 | «разумный таймаут» заменён на «30 с» | Фаза 3 |
 
+## Не закрытые пункты
+<Только для `partial` и `no-change`: номер пункта и почему он не закрыт. Иначе раздела нет.>
+
 ## Цепочка
 - **Before SHA-256:** `<hash>`
 - **After SHA-256:** `<hash>`
@@ -67,7 +70,7 @@ date: <YYYY-MM-DD HH:MM>
 
 ## Финал
 
-Сообщи пути к плану, review и fix, before/after SHA-256, изменение объёма, закрытые пункты, оставшиеся блокеры и что изменения не закоммичены. Дальше — подтверждающий `eda-plan-review` или возврат вызывающему `eda-plan-polish`.
+Сообщи пути к плану, review и fix, status, before/after SHA-256, изменение объёма, закрытые и не закрытые пункты, оставшиеся блокеры и что изменения не закоммичены. Дальше — подтверждающий `eda-plan-review` или возврат вызывающему `eda-plan-polish`.
 
 ## Чего НЕ делать
 

package/skills/eda-polish/SKILL.md

@@ -19,10 +19,12 @@ description: 'Итеративно ревьюит и исправляет изм
 
 1. В `main` основной агент сам выполняет установленные контракты `eda-review` и `eda-fix-by-review` в текущем контексте. Не запускай для них верхнеуровневых или leaf-субагентов и не заменяй их отдельным CLI.
 2. В `subagents` каждый вызов `eda-review` и `eda-fix-by-review` запускай отдельным изолированным субагентом. В Claude Code используй `Agent`, в Codex — `spawn_agent` с `fork_turns: "none"`; не оставляй `fork_turns` по умолчанию и не используй `"all"`. Если нативные субагенты недоступны, остановись без CLI-fallback.
-3. Успех требует одновременно: полный review со статусом `reviewed` или `reviewed-with-warnings`, `result: clean` и ноль находок. Score — только справочное число, условием завершения он не является.
+3. Успех требует одновременно: полный review со статусом `reviewed` или `reviewed-with-warnings`, `score: 100`, `result: clean` и ноль находок. Оценку бери только из review, сам её не повышай.
 4. Любая находка обязательно исправляется. Отклонить находку может только `eda-fix-by-review` и только при её фактической неверности.
 5. Не коммить и не отправляй ревью.
-6. Останавливайся при повторном сбое обязательной проверки review, блокере fix-агента, несокращении числа открытых находок за полный круг или достижении лимита.
+6. Штатно завершай цикл только при подтверждённых 100/100 или достижении лимита. Кроме них цикл останавливают только: технический блокер субагента, сбой обязательной проверки ревью, невалидный review, вопрос пользователю, на который в текущей среде нельзя получить ответ, и блокер `eda-fix-by-review` вне его области — например, падение несвязанной с правками проверки; это `blocked`, а не успех. Отсутствие прогресса — не причина остановки: находок не стало меньше, они повторяются, score снизился, fix отклонил все находки или ничего не изменил — продолжай до лимита.
+
+<!-- include: skills/_shared/done.md -->
 
 ## Технические остановки субагентов
 
@@ -58,7 +60,7 @@ description: 'Итеративно ревьюит и исправляет изм
    ```
 
 2. Если review остановился из-за обязательного агента, останови цикл. `reviewed-with-warnings` из-за недоступных previous reviews разрешён.
-3. Если `result: clean` и находок нет, заверши успешно. Если `result` противоречит числу находок, считай файл невалидным и остановись.
+3. Если `score: 100`, `result: clean` и находок нет, заверши успешно. Если score или result противоречат находкам, считай файл невалидным и остановись с `blocked`: при отсутствии находок score должен быть 100, при наличии — ниже 100.
 4. Если находки есть, в `main` выполни `eda-fix-by-review` сам; в `subagents` запусти отдельного субагента:
 
    ```text
@@ -68,9 +70,9 @@ description: 'Итеративно ревьюит и исправляет изм
    Верни путь к fix-отчёту, число применённых и отклонённых находок и результат проверок.
    ```
 
-5. После успешных исправлений начни новую итерацию с полным `eda-review`.
+5. После fix с любым содержательным результатом — все находки применены, часть или все отклонены, изменений нет — начни новую итерацию с полным `eda-review`. Если fix вернул вопрос пользователю, передай его по правилам текущей среды и после ответа продолжи тот же fix.
 
-Если после полного круга число открытых находок не уменьшилось, остановись раньше лимита с конкретными оставшимися проблемами. При достижении лимита не скрывай незавершённую сходимость.
+Если после полного круга число открытых находок не уменьшилось или score не вырос, продолжай до 100/100 либо исчерпания `$LIMIT`. При достижении лимита не скрывай незавершённую сходимость; последнее исправление без следующего review не считай подтверждённым успехом.
 
 ## Финал
 
@@ -81,7 +83,8 @@ description: 'Итеративно ревьюит и исправляет изм
 - В `subagents` делать ревью или исправления основным агентом.
 - Брать режим цикла из `review.execution` или переключать его из-за размера diff.
 - Запускать отдельный этап проверки готового ревью.
-- Считать цикл успешным при наличии находок или завершать его по score.
+- Считать цикл успешным без полного review с 100/100, `clean` и отсутствием находок.
+- Останавливаться раньше лимита из-за отсутствия прогресса.
 - Выбирать или отклонять находки основным агентом: отклонение — работа `eda-fix-by-review`.
 - Переписывать `docs/settings.yaml`, правила или архитектуру ради чистого результата.
 - Коммитить, пушить или отправлять ревью.

package/skills/eda-prepare-ai/SKILL.md

@@ -5,7 +5,7 @@ description: 'Готовит проект к работе с AI: проекти
 
 # Скил: Подготовка проекта для AI (eda-prepare-ai)
 
-Превращаешь реальный проект или подтверждённый стартовый бриф в согласованную техническую рамку для людей и AI-агентов: проектируешь архитектуру, правила, строгий профиль инструментов, матрицу проверок и AI-процесс, затем создаёшь или обновляешь `docs/rules.md`, `docs/arch.md`, `docs/references.md`, карточки в `docs/references/`, `AGENTS.md` и `CLAUDE.md`.
+Превращаешь реальный проект или подтверждённый стартовый бриф в согласованную техническую рамку для людей и AI-агентов: проектируешь архитектуру, правила, строгий профиль инструментов, матрицу проверок и AI-процесс, затем создаёшь или обновляешь `docs/rules.md`, `docs/arch.md`, `docs/references.md`, их карточки в `docs/rules/`, `docs/arch/` и `docs/references/`, `AGENTS.md` и `CLAUDE.md`.
 
 ## Вход из сообщения пользователя
 
@@ -13,7 +13,7 @@ description: 'Готовит проект к работе с AI: проекти
 
 ## Главные правила
 
-1. **Не правишь код.** Меняй только `docs/rules.md`, `docs/arch.md`, `docs/references.md`, `docs/references/*.md`, `AGENTS.md` и `CLAUDE.md`; не ставь пакеты и не меняй конфиги.
+1. **Не правишь код.** Меняй только `docs/rules.md`, `docs/rules/*.md`, `docs/arch.md`, `docs/arch/*.md`, `docs/references.md`, `docs/references/*.md`, `AGENTS.md` и `CLAUDE.md`; не ставь пакеты и не меняй конфиги.
 2. **Опирайся на проект.** Читай код, структуру, зависимости, команды, тесты, инфраструктуру, git-историю и существующие документы. Не генерируй универсальный шаблон.
 3. **Разделяй документы по назначению.** Business-карточки задают подтверждённое целевое поведение и редактируются только через `eda-business`; `docs/rules.md` задаёт действия, запреты, команды проверки и требования к процессу, совместимости и безопасности; `docs/arch.md` фиксирует структуру исходного кода, назначение каталогов, модули и слои, ownership, зависимости, runtime/data-flow, данные и интеграции; references показывают уже устоявшуюся форму реализации; `AGENTS.md` объясняет, что это за проект и где читать обязательную рамку. У каждого факта должен быть ровно один документ-владелец: допустима ссылка на другой документ, но не вторая копия содержания даже в иной формулировке. Архитектурное решение не становится правилом только потому, что его удалось сформулировать как запрет.
 4. **Обновляй осмысленно.** Сохраняй актуальное, исправляй неверное, удаляй устаревшее и перестраивай документ настолько сильно, насколько требует проект. Не спрашивай отдельно, что делать с каждым существующим файлом.
@@ -25,14 +25,27 @@ description: 'Готовит проект к работе с AI: проекти
 10. **Не внедряй tooling.** Можешь рекомендовать пакеты, команды, конфиги, скилы и MCP, но не устанавливай и не настраивай их; для внедрения предложи `eda-plan`.
 11. **Новый проект разворачивается штатным CLI.** Для bootstrap из `eda-new-project` найди официальный генератор выбранного стека и точную воспроизводимую команду через его package manager (`composer create-project`, `npm create`, `npx`, `cargo new` или реальный аналог). Зафиксируй эту команду в `docs/rules.md` как обязательную для создания основы проекта; не предлагай вручную воспроизводить файлы, которые создаёт доступный официальный CLI.
 
+## Структура рамки
+
+Каждый документ рамки — короткий индекс, который агент читает для любой задачи, и карточки областей, которые он читает только для задач своей области. Любой файл рамки — не больше 20 КБ: больший файл дели на карточки, а не урезай подтверждённое содержание.
+
+| Документ | Индекс — читается всегда | Карточка — читается по задаче |
+|---|---|---|
+| Правила | `docs/rules.md`: правила для любой задачи по темам `## <Тема>` и таблица карточек | `docs/rules/<область>.md`: правила одной области кода или процесса |
+| Архитектура | `docs/arch.md`: подход, дерево верхнего уровня, модули и допустимые зависимости, таблица карточек | `docs/arch/<область>.md`: состав, ответственность, границы, потоки, данные и интеграции одной области |
+| Эталоны | `docs/references.md`: таблица карточек | `docs/references/<компонент>.md`: один минимальный пример формы компонента |
+| Бизнес | `docs/business.md`, ведёт `eda-business` | `docs/business/<тема>.md` |
+
+Таблица карточек в `docs/rules.md` и `docs/arch.md` — `| Описание | Карточка |`: описание позволяет решить, нужна ли карточка задаче, не открывая её. Карточку заводи, когда индекс не помещается в лимит или у области есть сведения, не нужные остальным задачам; маленькому проекту хватает индексов без карточек. Документы описывают текущее состояние: датированные разделы вроде «уточнение от …» или «обновление …», журналы изменений и история решений в них не попадают — изменение вносится в раздел-владелец на месте. Существующий документ больше лимита или с датированными разделами перестрой по этой структуре без потери действующего содержания.
+
 ## Интерактивные вопросы
 
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты.
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос: задай его и остановись до ответа.
+- Неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты.
 - Не запускай команды, которые ждут интерактивного ввода в терминале.
 
+<!-- include: skills/_shared/questions.md -->
+
 ## Этапы
 
 ### 1. Проанализировать проект
@@ -43,7 +56,7 @@ description: 'Готовит проект к работе с AI: проекти
 
 ### 2. Прочитать существующую документацию
 
-Прочитай `docs/rules.md`, `docs/arch.md`, `docs/references.md`, карточки из `docs/references/`, `AGENTS.md` и `CLAUDE.md`, если они есть. Если существует `docs/business.md`, сначала определи область текущей подготовки, затем по описаниям выбери относящиеся к ней карточки; при полном bootstrap весь описанный продуктовый контекст может быть применим. Business-карточки используй как требования к целевому поведению, но не редактируй. Также прочитай релевантные документы из `docs/`, на которые они ссылаются. Найди дубли, противоречия и устаревшие сведения.
+Прочитай `docs/rules.md`, `docs/arch.md`, `docs/references.md`, их карточки из `docs/rules/`, `docs/arch/` и `docs/references/`, `AGENTS.md` и `CLAUDE.md`, если они есть. Большой файл читай частями до последней строки. Если существует `docs/business.md`, сначала определи область текущей подготовки, затем по описаниям выбери относящиеся к ней карточки; при полном bootstrap весь описанный продуктовый контекст может быть применим. Business-карточки используй как требования к целевому поведению, но не редактируй. Также прочитай релевантные документы из `docs/`, на которые они ссылаются. Найди дубли, противоречия и устаревшие сведения.
 
 Если текущая задача подготовки противоречит business-карточке, остановись, покажи конфликт и через `AskUserQuestion` спроси: изменить задачу подготовки или сначала пересогласовать правило через `eda-business`. Не переноси противоречие молча в архитектуру или rules.
 
@@ -51,8 +64,8 @@ description: 'Готовит проект к работе с AI: проекти
 
 Определи область по текущему сообщению:
 
-- если пользователь вызвал просто `eda-prepare-ai` и не назвал документ — обнови весь набор: `docs/rules.md`, `docs/arch.md`, `docs/references.md`, все актуальные карточки в `docs/references/`, `AGENTS.md` и `CLAUDE.md`;
-- если явно назвал rules, architecture, `AGENTS.md` или `CLAUDE.md` — обнови только названные документы;
+- если пользователь вызвал просто `eda-prepare-ai` и не назвал документ — обнови весь набор: `docs/rules.md`, `docs/arch.md`, `docs/references.md`, все актуальные карточки, `AGENTS.md` и `CLAUDE.md`;
+- если явно назвал rules, architecture, `AGENTS.md` или `CLAUDE.md` — обнови только названные документы вместе с их карточками;
 - если явно назвал references — обнови `docs/references.md` и актуальные карточки, затем добавь или актуализируй ссылку на `docs/references.md` в `AGENTS.md`;
 - если явно назвал одну карточку — обнови только её и соответствующую строку `docs/references.md`.
 - если явно запросил проверки без полного вызова — проведи полный аудит проверок, предложи матрицу и после подтверждения обнови только относящиеся к ней правила в `docs/rules.md`;
@@ -96,17 +109,18 @@ description: 'Готовит проект к работе с AI: проекти
 4. **Стиль и качество:** formatter, linter, naming, complexity, duplication, dead code, unused exports/dependencies, forbidden patterns, TODO/FIXME и size limits.
 5. **Статический анализ:** typecheck, nullability, data-flow/taint, API misuse, unreachable code, unsafe behavior, memory/thread/address sanitizers и анализаторы языка.
 6. **Границы модулей:** forbidden imports, dependency direction, cycles, layers, public API, ownership, package boundaries, generated code и architecture fitness functions.
-7. **Конфиги/IaC:** env, YAML/JSON/TOML, CI, Docker/Compose, Kubernetes/Helm, Terraform, proxy, feature flags, IAM, observability и env-example drift.
+7. **Конфиги/IaC:** env, YAML/JSON/TOML, CI, Docker/Compose и Dockerfile lint, Kubernetes/Helm, Terraform, proxy и его анализатор конфигурации, редиректы на HTTPS и канонический хост, HSTS, feature flags, IAM, observability и env-example drift.
 8. **API/compatibility:** OpenAPI/GraphQL/Proto, breaking changes, generated-code drift, serialization, backward/forward compatibility, idempotency и pagination/filter/sort.
 9. **БД/данные:** migrations forward/rollback/dry-run, schema drift, constraints, fixtures, transactions, concurrency, N+1/query plans, backup/restore, retention/anonymization и invariants.
 10. **Security/supply chain:** secrets, SAST, DAST, dependencies, licenses, SBOM, lockfiles, container/IaC, provenance, authn/authz, injection, XSS/CSRF/SSRF, CORS/CSP/headers, rate limits и PII leakage.
-11. **Performance/reliability:** benchmarks/budgets, bundle size, load/stress/spike/soak, leaks, startup, timeout/retry/circuit breaker, graceful shutdown, chaos/fault injection и recovery.
+11. **Performance/reliability:** benchmarks/budgets, тесты на число запросов к БД и внешних вызовов на операцию, bundle size и бюджет веса CSS/JS, проверка сжатия и кеш-заголовков production после деплоя, load/stress/spike/soak, leaks, startup, timeout/retry/circuit breaker, graceful shutdown, chaos/fault injection и recovery.
 12. **Build/release:** clean-clone и reproducible builds, generated artifacts, package contents, runtime/OS/architecture matrix, install/upgrade/downgrade, semver/changelog, release dry-run, canary/rollback и post-deploy smoke.
 13. **Документация:** Markdown/style/spell, links, executable snippets, CLI help/API drift, diagrams/schemas и migration/release notes.
 14. **Эксплуатация:** health/readiness/liveness, metric/log/trace schemas, no secrets/PII in logs, alerts, dashboards as code, SLO/error budgets, disaster recovery и restore drills.
 15. **Домен:** платежи, почта, очереди/jobs, webhooks, поиск, files/media, mobile signing, offline/sync, localization, analytics events и прочие продуктовые инварианты.
 16. **AI:** prompt/output schemas, evals, prompt injection/jailbreak, data leakage, tool permissions, nondeterminism, latency и token/cost budgets.
 17. **MCP:** browser/Playwright MCP и MCP для БД, API, документации, GitHub/GitLab, cloud, observability и выбранного языка/фреймворка. Для каждого укажи сценарий, минимальные права, тестовые данные и почему CLI/CI недостаточно.
+18. **SEO и индексация:** для публичных страниц — коды ответов и редиректы, canonical, robots и `noindex` в production, sitemap, title/description, hreflang, структурированные данные и SEO-аудит страниц в CI.
 
 Для каждого предложения укажи конкретный инструмент, точную команду или сценарий, закрываемый риск и контур: `pre-commit`, `pre-push`, `PR CI`, `nightly`, `release`, `post-deploy`, `MCP/manual`. Отдели быстрый обязательный gate от тяжёлых scheduled/release-проверок, чтобы экстремальный профиль оставался исполнимым.
 
@@ -129,6 +143,8 @@ description: 'Готовит проект к работе с AI: проекти
 - для нового проекта — точная команда официального scaffold/generator CLI выбранного стека вместо ручного создания его основы;
 - действующие соглашения об именовании, формате и совместимости;
 - требования к изменениям, например обязательная миграция при изменении схемы или обновление контракта при изменении публичного API;
+- действующие эксплуатационные и SEO-соглашения, подтверждённые конфигурацией или пользователем: канонический хост и протокол, политика редиректов и завершающего слэша, где задаются переменные окружения, политика базовых образов;
+- production-конфигурация проекта, который отдаёт страницы или API, подтверждённая конфигурацией или пользователем, с указанием, где она задаётся: сжатие текстовых ответов, долгий кеш статики с хешем в имени, кто отдаёт статику, выключенный debug, кеш байткода (opcache и аналоги) и лимиты процессов runtime, сборка кешей фреймворка и установка зависимостей без dev-пакетов при деплое;
 - точечные запреты небезопасных конструкций, бесконтрольных подавлений, утечки секретов и персональных данных;
 - строгие режимы уже внедрённых инструментов.
 
@@ -161,7 +177,9 @@ description: 'Готовит проект к работе с AI: проекти
 | CQRS | Только независимые рабочие соглашения, которых нет в архитектуре | Разделение command/query, ответственность и data-flow | Устоявшаяся форма command/query handler |
 | Безопасность | Проверяемые запреты и обязательные security-команды | Trust boundaries, auth ownership и движение чувствительных данных | Устоявшийся безопасный пример конкретного компонента |
 
-Каждое принятое правило формулируй коротко, однозначно и проверяемо. Группируй правила по темам только когда это ускоряет поиск.
+Каждое принятое правило — одна строка: короткое, однозначное и проверяемое действие или запрет. Правила для любой задачи держи в `docs/rules.md` по темам; правила, которые нужны только при работе с одной областью кода или процесса, вынеси в `docs/rules/<область>.md` по разделу «Структура рамки».
+
+Всегда записывай в `docs/rules.md` правило ведения рамки: «Документы `docs/rules*`, `docs/arch*`, `docs/references*` меняй в разделе-владельце на месте, без датированных разделов и журналов изменений; файл больше 20 КБ дели на карточки области с записью в таблицу индекса».
 
 В файле должны быть только действующие правила проекта. Не добавляй введение, объяснения пользы, обоснования, предложения, наблюдения, архитектурное описание или декоративные разделы. Команду проверки указывай только как конкретное правило, например: «Перед финалом запусти `npm test`».
 
@@ -173,7 +191,7 @@ description: 'Готовит проект к работе с AI: проекти
 
 ### 7. Обновить `docs/arch.md`
 
-Опиши устройство проекта, не повторяя рабочие правила из `docs/rules.md`. Документ должен позволять понять, где находится нужная часть системы, за что она отвечает и как связана с остальными.
+Опиши устройство проекта, не повторяя рабочие правила из `docs/rules.md`. Документ должен позволять понять, где находится нужная часть системы, за что она отвечает и как связана с остальными. В `docs/arch.md` остаются подход, дерево верхнего уровня, модули и допустимые зависимости между ними и таблица карточек; подробности одной области — в `docs/arch/<область>.md` по разделу «Структура рамки».
 
 `docs/arch.md` не должен содержать команды, чек-листы разработки, настройки линтеров и других инструментов или иные рабочие правила. Если архитектурную границу проверяет конкретная команда, в `docs/arch.md` оставь только саму границу, а требование и момент запуска команды запиши в `docs/rules.md` без пересказа границы.
 
@@ -204,7 +222,7 @@ description: 'Готовит проект к работе с AI: проекти
 | Контроллер | При добавлении HTTP endpoint | [Контроллер](references/controller.md) |
 ```
 
-Индекс содержит ссылки только на карточки. В каждой карточке должны быть:
+Индекс содержит ссылки только на карточки. Карточка не больше 20 КБ и показывает одну форму компонента; несколько форм — несколько карточек. В каждой карточке должны быть:
 
 - назначение эталона и показываемая форма реализации без пересказа архитектурных границ компонента;
 - условия, при которых пример применим;
@@ -236,7 +254,7 @@ description: 'Готовит проект к работе с AI: проекти
 
 Сделай `AGENTS.md` короткой входной картой для AI-агента. В нём должны быть:
 - краткое описание проекта;
-- ссылки на `docs/rules.md`, `docs/arch.md`, `docs/references.md` и другие действительно обязательные документы из `docs/`;
+- ссылки на `docs/rules.md`, `docs/arch.md`, `docs/references.md` и другие действительно обязательные документы из `docs/` с требованием выбирать по их таблицам только карточки, применимые к текущей задаче;
 - ссылка на `docs/business.md`, если индекс существует, с требованием выбирать по нему только карточки, применимые к текущей задаче;
 - требование прочитать их и следовать им до работы над проектом.
 
@@ -249,6 +267,7 @@ description: 'Готовит проект к работе с AI: проекти
 ### 12. Проверить результат
 
 Убедись, что:
+- документы рамки построены по разделу «Структура рамки»: каждый файл не больше 20 КБ, индексы ведут ко всем карточкам, датированных разделов и журналов изменений нет, правило ведения рамки записано в `docs/rules.md`;
 - `docs/rules.md` содержит только лаконичные действующие правила;
 - каждое правило задаёт проверяемое действие или запрет, пути используются только как операнды команд или указатели на конфиги и артефакты, а топология исходного кода и архитектурные границы не продублированы в форме императива;
 - `docs/arch.md` объясняет подход, структуру папок, части системы и их связи без команд, чек-листов разработки, tooling-политик и повторения правил;
@@ -279,6 +298,7 @@ description: 'Готовит проект к работе с AI: проекти
 - Спрашивать, какие документы обновлять, если пользователь их не назвал: по умолчанию обновляется весь набор.
 - Просить выбрать режим перезаписи для каждого существующего файла.
 - Ограничивать правила фиксированным количеством или разбавлять их пояснениями и предложениями.
+- Оставлять файл рамки больше 20 КБ, датированные разделы и журналы изменений.
 - Переносить архитектурное решение в `docs/rules.md`, просто переписав его как обязательное действие или запрет.
 - Дублировать правила и архитектуру в `AGENTS.md` или `CLAUDE.md`.
 - Ссылаться из карточек на код проекта или внешние материалы вместо самодостаточного примера.

package/skills/eda-prod-check/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: eda-prod-check
+description: 'Read-only диагностика работающего окружения: находит в цифрах, почему прод или стейдж отвечает медленно или с ошибками, и сохраняет отчёт с исправлениями.'
+---
+
+# Скил: Проверка окружения (eda-prod-check)
+
+Находишь причину, почему работающее окружение — production или staging — отвечает медленно или с ошибками. Работаешь только на чтение: замеряешь, читаешь конфиги и логи, сравниваешь слои между собой. На сервере ничего не меняешь. Результат — отчёт с цифрами и списком исправлений с ожидаемым эффектом.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом — главный вход: адрес сайта или API, симптом («каждая страница открывается 5 секунд», «500 на оплате»), окружение и доступ к серверу.
+
+- Окружения, серверы, способ деплоя и пути к конфигам сначала ищи в `docs/rules.md`, `docs/arch.md` и их карточках; найденное не спрашивай.
+- Нет адреса — спроси. Нет доступа к серверу — работай снаружи, а серверные слои отметь непроверенными.
+- Симптом без числа превращается в число на первом этапе.
+
+## Главные правила
+
+1. **Только чтение.** Не перезапускай сервисы, не меняй конфиги и файлы, не чисти кеши, не ставь пакеты, не запускай миграции и запросы, которые пишут в базу. Нагрузочные тесты, полные дампы, долгие профилировщики и всё, что заметно нагружает окружение, — только после подтверждения пользователя.
+2. **Сначала симптом в цифрах.** До гипотез воспроизведи симптом одной повторяемой командой и запиши числа. Повтори 3–5 раз: одна медленная попытка — не симптом.
+3. **Снаружи — внутрь.** Проходи слои по порядку из чек-листа и сравнивай их замеры. Слой, на котором пропадает время или появляется ошибка, — кандидат в причину. Например, внешний ответ 4 с, а тот же запрос с самого сервера на `127.0.0.1` — 3,9 с: сеть и TLS ни при чём.
+4. **Гипотезы проверяемы.** После замера составь 3–5 гипотез по убыванию вероятности. Для каждой — предсказание: «если причина X, то проверка Y покажет Z». Покажи список в чате и начинай с самой вероятной, не дожидаясь ответа.
+5. **Вывод — только с доказательством.** У каждого вывода есть команда и её результат. Слой, который не удалось замерить, — «не проверено», а не «в порядке».
+6. **Секреты не выводи.** Пароли, токены, ключи и персональные данные из конфигов и логов не попадают в чат и отчёт: пиши `<скрыто>`. Из `.env` читай только нужные ключи, не печатая значения секретов.
+7. **Исправления не применяй.** Каждое исправление — что поменять и где, ожидаемый эффект в цифрах и риск. Применяет пользователь, `eda-fix` или `eda-plan`.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос: задай его и остановись до ответа.
+
+- Неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода: пароль SSH, `sudo` с паролем, интерактивные консоли.
+
+## Чек-лист слоёв
+
+Команды — примеры для Linux, nginx, PHP и Laravel; для другого стека используй аналоги. Каждый слой получает статус: `проблема`, `в порядке` или `не проверено` с причиной.
+
+| Слой | Что проверить |
+|---|---|
+| Снаружи | время DNS, соединения, TLS, первого байта и полной загрузки для главной, типовой страницы и API; код ответа; размер HTML; цепочки редиректов (HTTP → HTTPS → www); версия HTTP |
+| Отдача статики | вес CSS, JS, шрифтов и изображений первого экрана; сжатие (`Content-Encoding: gzip` или `br`); `Cache-Control` и хеш в именах файлов; кто отдаёт статику — веб-сервер, CDN или приложение |
+| Сервер | CPU и steal time (`st` — соседи на виртуалке забирают процессор), load average относительно числа ядер, память и swap, место на диске и iowait, что ещё запущено |
+| Веб-сервер и прокси | сжатие, кеш статики, keep-alive, HTTP/2, таймауты и буферы; время upstream в access-логе; ошибки в error-логе |
+| Runtime | PHP: opcache включён, памяти и слотов под файлы хватает, `validate_timestamps` выключен или проверяет редко; Xdebug и профилировщики не загружены. PHP-FPM: `pm.max_children` соответствует памяти, в логе нет «reached pm.max_children», slowlog. Для Node, Python и других — число воркеров и память процессов |
+| Приложение | debug выключен; кеши фреймворка собраны (в Laravel — `config`, `route`, `view`, `event`); автозагрузчик оптимизирован, dev-пакеты не установлены; драйверы сессий, кеша и очередей (файлы вместо Redis под нагрузкой, очередь `sync` выполняет фоновую работу прямо в запросе); отладочные панели вроде Debugbar и Telescope не пишут каждый запрос; внешние вызовы на пути запроса и их таймауты; ошибки в логе приложения |
+| База данных | медленные запросы и slow log, блокировки и долгие транзакции, число соединений против лимита, размер горячих таблиц и индексы для найденного медленного запроса |
+| Фронтенд | блокирующие скрипты и стили в `<head>`, сторонние скрипты (метрики, чаты, виджеты) и их время, изображения первого экрана без размеров и сжатия, неиспользуемый CSS |
+
+Команды по слоям:
+
+- Снаружи, 3–5 раз: `curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} size=%{size_download} code=%{http_code} http=%{http_version}\n' <url>`; редиректы — `curl -sIL <url>`. Тот же замер с самого сервера на `127.0.0.1` с нужным заголовком `Host` отделяет сеть и TLS от приложения.
+- Отдача статики: `curl -sI -H 'Accept-Encoding: br, gzip' <url файла>`; адреса CSS и JS — из HTML ответа.
+- Сервер: `nproc`, `uptime`, `vmstat 1 5`, `free -m`, `df -h`, `top -bn1 | head -20`.
+- Веб-сервер: `nginx -T` выводит действующий конфиг, ничего не меняя; access- и error-логи — `tail`.
+- Runtime: `php-fpm<версия> -i | grep -E 'opcache|xdebug'` — настройки CLI и FPM различаются, смотри FPM; конфиги пулов и лог FPM.
+- Приложение: `grep -E '^(APP_ENV|APP_DEBUG|CACHE_DRIVER|CACHE_STORE|SESSION_DRIVER|QUEUE_CONNECTION|LOG_LEVEL)=' .env`, `php artisan about`, `ls bootstrap/cache`, лог приложения.
+- База: slow log, `SHOW FULL PROCESSLIST` или `pg_stat_activity`, `EXPLAIN` для найденного запроса. `EXPLAIN ANALYZE` выполняет запрос, поэтому только для `SELECT`.
+- Фронтенд: HTML ответа; Lighthouse или аналог, если доступен.
+
+Ориентиры, а не нормы: ответ сервера (TTFB) обычной страницы без тяжёлых запросов — сотни миллисекунд, не секунды; steal time выше 10% заметно замедляет всё; CSS и JS первого экрана в сотни килобайт без сжатия — заметная задержка на мобильном интернете.
+
+## Этапы
+
+### 1. Вход и доступы
+
+Определи адрес, симптом, окружение и доступ. Команды на сервере выполняй через доступ, который дал пользователь, обычно `ssh <хост> '<команда>'`. Перед каждой серверной командой убедись, что она только читает.
+
+### 2. Замер симптома
+
+Запиши базовые числа по слою «Снаружи». Если симптом не воспроизводится, сообщи это и спроси, когда и где он проявляется: время суток, страница, пользователь, устройство.
+
+### 3. Гипотезы
+
+Составь 3–5 проверяемых гипотез по правилу 4 и покажи их.
+
+### 4. Проход по слоям
+
+Иди по чек-листу сверху вниз. Если гипотеза подтвердилась, всё равно пройди остальные слои: медленный ответ часто складывается из нескольких причин. Для каждой причины оцени вклад — какую часть времени она даёт.
+
+### 5. Сохранить отчёт
+
+Создай `docs/artifacts/prod-checks/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
+
+```markdown
+---
+target: <адрес>
+environment: <production | staging>
+date: <YYYY-MM-DD HH:MM>
+symptom: <симптом в цифрах>
+status: <cause-found | partial | blocked>
+---
+
+# Проверка окружения: <адрес>
+
+## Симптом
+<команда и замеры до проверки>
+
+## Причины
+
+### 1. <причина простыми словами>
+<1–2 абзаца: что происходит и почему это даёт симптом>
+- **Вклад:** <какая часть времени или ошибок>
+- **Доказательство:** <команда и ключевая строка вывода>
+- **Исправление:** <что поменять и где>
+- **Ожидаемый эффект:** <число>
+- **Риск:** <что может пойти не так>
+
+## Слои
+| Слой | Статус | Что видно |
+|---|---|---|
+| Снаружи | проблема / в порядке / не проверено | <цифры или причина> |
+
+## Гипотезы
+| Гипотеза | Проверка | Результат |
+|---|---|---|
+```
+
+### 6. Финал
+
+Коротко сообщи путь к отчёту, главную причину с числами и 1–3 исправления с ожидаемым эффектом. Предложи применить их через `eda-fix`, а если исправление меняет инфраструктуру или несколько частей системы — через `eda-plan`.
+
+## Чего НЕ делать
+
+- Менять что-либо на сервере, перезапускать сервисы, чистить кеши и писать в базу.
+- Строить гипотезы до замера симптома и объявлять слой исправным без замера.
+- Запускать нагрузочные тесты и тяжёлые профилировщики без подтверждения.
+- Выводить секреты и персональные данные в чат и отчёт.
+- Применять исправления вместо отчёта.