@k0t0vich/meta-agents-template 0.1.6 → 0.1.8

package/template/.meta-agents/scripts/verify-commit-link.mjs

@@ -7,8 +7,8 @@ function readLastCommitSubject(ref = "HEAD") {
 }
 
 function validateMessage(message) {
-  const hasIssueNumber = /#\d+\b/.test(message);
-  return hasIssueNumber;
+  const normalized = String(message || "").trim();
+  return /^#\d+\s+\S.*$/.test(normalized);
 }
 
 function parseArgs(argv) {
@@ -48,7 +48,9 @@ function main() {
     }
 
     if (!validateMessage(message)) {
-      console.error("Commit link FAIL: message must contain #issue.");
+      console.error(
+        "Commit link FAIL: message must match '#<issue-number> <summary>' and start with issue ref.",
+      );
       console.error(`Message: ${message}`);
       process.exit(1);
     }

package/template/README.md

@@ -3,11 +3,10 @@
 Проект инициализирован шаблоном `meta-agents-template`.
 
 ## Что уже подключено
-- `agents.md`: роли, правила и жёсткие критерии приёмки;
-- `tracker-command-template.md`: команды управления задачами и спринтами;
-- `.meta-agents/`: конфигурация системы и шаблоны PRD/verification;
-- `.github/workflows/gitflow-lite-verify.yml`: branch-aware CI-проверки для Git Flow Lite;
-- `tasks/`: backlog/sprint/status-log.
+- `agents.md`: локальный входной файл с ссылками на canonical правила в npm-пакете;
+- `.meta-agents/config/project-context.yaml`: project name + выбранный tracker provider;
+- `.meta-agents/config/trackers.yaml`: lock tracker provider и доступные providers;
+- `meta:*` npm scripts, которые запускают canonical tooling из `node_modules/@k0t0vich/meta-agents-template/template/.meta-agents/scripts/*`.
 
 ## Source of truth по tracker provider
 - Выбранный при `init` provider фиксируется в `.meta-agents/config/project-context.yaml`.
@@ -44,7 +43,7 @@
 12. Перед релизом `Publishing Agent` обязан обновить публичный `CHANGELOG.md`.
 
 ## Команды
-Смотри `tracker-command-template.md`.
+Смотри `node_modules/@k0t0vich/meta-agents-template/template/tracker-command-template.md`.
 
 Дополнительно:
 ```bash

package/template/agents.md

@@ -148,7 +148,7 @@ Name: <agent role>
 - без подтверждения пользователя максимум допустимого статуса: `REVIEW`.
 - `SET_STATUS -> READY` разрешён только после `RUN_REVIEW_GATE: PASS_CONFIRMED`.
 - для задач реализации по умолчанию используется отдельная ветка `feature/*`; прямой рабочий поток на `develop`/`main` не допускается.
-- сообщение коммита обязано содержать ссылку на задачу (`#issue-number`).
+- сообщение коммита обязано начинаться с ссылки на задачу и summary в формате `#issue-number <summary>`.
 - `READY` означает: коммит сделан и отправлен (`push`) в `feature/*`, `release/*` или `hotfix/*` с открытым PR по правилам ветвления.
 - `DONE` означает: изменения интегрированы в `main`; для `release/*` и `hotfix/*` подтверждён back-merge в `develop`.
 - `PUBLISH` означает: релиз опубликован и доступен в последней версии пакета.
@@ -199,7 +199,7 @@ Name: <agent role>
 19. Для статуса `DONE` подтверждена интеграция в `main`; для `release/*` и `hotfix/*` подтверждён back-merge в `develop`.
 20. Для статуса `PUBLISH` подтверждена публикация в последней версии.
 21. Для релиза обновлён публичный `CHANGELOG.md`.
-22. Коммит содержит ссылку на issue (`#issue`).
+22. Коммит следует формату `#issue-number <summary>` (issue ref в начале сообщения).
 23. Для branch routing собран e2e evidence по двум сценариям: `same feature` и `different feature`.
 24. Перед `--apply` подтверждена консистентность контекста `agents.md` (или явно подтверждён осознанный switch при diff).
 

package/template/package.json

@@ -3,15 +3,15 @@
   "version": "0.1.0",
   "private": true,
   "scripts": {
-    "meta:status": "node .meta-agents/scripts/sync-status.mjs",
-    "meta:branch": "node .meta-agents/scripts/verify-branch-strategy.mjs",
-    "meta:task-start": "node .meta-agents/scripts/task-branch-router.mjs",
-    "meta:verify": "node .meta-agents/scripts/verify-governance.mjs",
-    "meta:review": "node .meta-agents/scripts/run-review-gate.mjs",
-    "meta:review-approve": "node .meta-agents/scripts/run-review-gate.mjs --approve yes",
-    "meta:mr-review": "node .meta-agents/scripts/run-mr-review-gate.mjs",
-    "meta:mr-review-approve": "node .meta-agents/scripts/run-mr-review-gate.mjs --approve yes",
-    "meta:verify-link": "node .meta-agents/scripts/verify-commit-link.mjs",
-    "meta:ops": "node .meta-agents/scripts/tracker-gateway.mjs"
+    "meta:status": "node ./node_modules/@k0t0vich/meta-agents-template/template/.meta-agents/scripts/sync-status.mjs",
+    "meta:branch": "node ./node_modules/@k0t0vich/meta-agents-template/template/.meta-agents/scripts/verify-branch-strategy.mjs",
+    "meta:task-start": "node ./node_modules/@k0t0vich/meta-agents-template/template/.meta-agents/scripts/task-branch-router.mjs",
+    "meta:verify": "node ./node_modules/@k0t0vich/meta-agents-template/template/.meta-agents/scripts/verify-governance.mjs",
+    "meta:review": "node ./node_modules/@k0t0vich/meta-agents-template/template/.meta-agents/scripts/run-review-gate.mjs",
+    "meta:review-approve": "node ./node_modules/@k0t0vich/meta-agents-template/template/.meta-agents/scripts/run-review-gate.mjs --approve yes",
+    "meta:mr-review": "node ./node_modules/@k0t0vich/meta-agents-template/template/.meta-agents/scripts/run-mr-review-gate.mjs",
+    "meta:mr-review-approve": "node ./node_modules/@k0t0vich/meta-agents-template/template/.meta-agents/scripts/run-mr-review-gate.mjs --approve yes",
+    "meta:verify-link": "node ./node_modules/@k0t0vich/meta-agents-template/template/.meta-agents/scripts/verify-commit-link.mjs",
+    "meta:ops": "node ./node_modules/@k0t0vich/meta-agents-template/template/.meta-agents/scripts/tracker-gateway.mjs"
   }
 }

package/template/tracker-command-template.md

@@ -68,7 +68,7 @@ result PASS
 - если задача атомарная и относится к текущей feature-ветке, допускается выполнение в текущей ветке после явного подтверждения пользователя;
 - если задача не относится к текущей ветке, требуется: проверить dirty/ahead, согласовать действие с пользователем, перейти на `develop` (или `main` для hotfix), обновить и создать новую ветку;
 - перед `--apply` обязателен контекстный check: сравнить `agents.md` текущей и базовой ветки, при diff запросить явное подтверждение пользователя;
-- сообщение коммита обязательно содержит `#issue-number`.
+- сообщение коммита обязательно следует формату `#issue-number <summary>` (issue ref в начале).
 
 Для GitHub трекера статус issue задаётся label-ом (одновременно только один статус из набора):
 - `TODO`
@@ -257,7 +257,7 @@ Agile Manager Agent: commit by name,
 tracker __DEFAULT_TRACKER__,
 task "API редирект офферов",
 issue 12,
-commit message "#12 | API редирект офферов",
+commit message "#12 API редирект офферов",
 push yes,
 branch "feature/issue-12-api-redirect",
 open mr "optional",

package/agents.md

@@ -1,226 +0,0 @@
-# agents.md
-
-## 0) Профиль развернутого проекта (source of truth)
-- Project: `meta-agents-template`
-- Tracker provider (обязательный): `github`
-- Файл-источник: `.meta-agents/config/project-context.yaml`
-- Консистентность: значение обязано совпадать с `.meta-agents/config/trackers.yaml -> tracker_gateway.default`.
-- Операционное правило: если пользователь явно не изменил конфиг, все команды (`CREATE_TASK`, `SET_STATUS`, `ASSIGN_SPRINT`, `COMMIT_BY_NAME`, `PREPARE_RELEASE_NOTE`, `MARK_TASKS_PUBLISH`) выполняются только через выбранный tracker provider.
-
-## 1) Назначение системы
-Система работает как мета-оркестрация разработки: сначала формализуем задачу и проверяемость, потом делаем реализацию.
-
-Базовый поток:
-`clarify -> PRD step -> verification design -> decomposition -> execution -> evidence -> acceptance`
-
-Главный принцип:
-`acceptance-first` и `verification-first`.
-
-## 2) Обязательный PRD на каждом шаге
-Каждый этап (уточнение, архитектура, декомпозиция, реализация, ревью) обязан иметь PRD-запись в строгом порядке:
-
-1. `Описание`.
-2. `Проверяемость`.
-3. `Что сделано`.
-
-Правило запуска этапа:
-- если не заполнены `Описание` и `Проверяемость`, этап не стартует.
-
-## 3) Роли агентов
-- `Chief of Staff Agent`: оркестрация цепочки, приоритеты, блокеры, эскалации.
-- `Status Agent`: сводный статус проекта (`tracker/sprint/task/git`) по запросам состояния.
-- `Agile Manager Agent`: операции по задачам/спринтам/статусам/коммитам через трекер.
-- `Governance Watchdog Agent`: обязательный контроль PRD/критериев/разрешений перед каждой командой.
-- `Product Manager Agent`: формулирует PRD и критерии приёмки.
-- `Solution Architect Agent`: проектирует архитектуру и контракты компонентов.
-- `Verifier Designer Agent`: проектирует модель валидации и evidence-план.
-- `Decomposer Agent`: режет систему на проверяемые компоненты.
-- `Engineering Agent`: реализация по контракту.
-- `QA Agent`: проверка выполнения критериев и качество тестового покрытия.
-- `Reviewer/Judge Agent`: независимая приёмка по заранее согласованным правилам.
-- `MR Review Agent`: обязательный pre-merge review для MR/PR (task linkage + PRD evidence + Git Flow target).
-- `Publishing Agent`: готовит release notes, фиксирует вошедшие задачи и переводит их в `PUBLISH`.
-- `Publishing Agent`: обновляет публичный `CHANGELOG.md`, готовит release notes, фиксирует вошедшие задачи и переводит их в `PUBLISH`.
-- `Documentation Agent`: поддержка и синхронизация артефактов.
-
-## 3.1) Маршрутизация статус-запросов
-Если пользовательский запрос содержит intent `статус`, `что в процессе`, `процесс`, `где мы`, по умолчанию выбирается `Status Agent`.
-
-Формат ответа `Status Agent` (обязательный):
-1. Какие трекеры используются (locked provider + доступные providers).
-2. Какой текущий спринт.
-3. Какая задача сейчас в работе.
-4. Текущий веточный контекст (branch, branch type, branch task ref, alignment с текущей задачей).
-5. Что не закоммичено (modified/staged + untracked + ahead/behind).
-6. Короткая сводка.
-
-Приоритет источника данных:
-- `github`: GitHub tracker — источник истины; локальные `tasks/*` только cache/legacy.
-- `local`: локальные `tasks/*` — источник истины.
-- `mcp/custom`: внешний трекер — источник истины; локальные `tasks/*` только cache.
-
-## 4) Жёсткий Auto-Select и показ имени агента
-Автовыбор агента обязателен перед каждой задачей и перед каждой командой (`CREATE_TASK`, `SET_STATUS`, `COMMIT_BY_NAME`, `ASSIGN_SPRINT`).
-
-Обязательный префикс:
-```text
-[Agent Auto-Select]
-Selected: <agent role>
-Reason: <short reason>
-
-[Task Agent]
-Name: <agent role>
-```
-
-Правило исполнения:
-- если префикс не выведен, задача/команда не выполняется;
-- если пользователь явно указал роль, она используется, но блок `Task Agent` обязателен.
-
-## 5) Единица работы: Verified Component
-Каждый компонент обязан иметь:
-- цель;
-- входы/выходы;
-- ограничения и инварианты;
-- критерии приёмки;
-- стратегию проверки;
-- required evidence;
-- владельца компонента;
-- ссылку на PRD-этап.
-
-## 6) Типы валидации
-- `strict`: схемы, типы, правила, инварианты, policy, state transitions.
-- `statistical`: benchmark/метрики/judge score/пороговые значения.
-- `human`: review/approval в рискованных и неоднозначных точках.
-
-## 7) AgentWorkContract
-Перед передачей задачи Executor-агенту фиксируется контракт:
-- scope;
-- допустимая свобода решений;
-- required outputs;
-- required evidence;
-- acceptance criteria;
-- failure/escalation правила;
-- трекерная привязка (`task_id`, `tracker_provider`, `sprint`).
-
-Без контракта делегирование запрещено.
-
-## 8) TrackerGateway
-Трекер выделяется в отдельный адаптерный слой, независимый от ролей агентов.
-
-`TrackerGateway` поддерживает провайдеры:
-- `local`;
-- `github`;
-- `mcp` (alias `mpc`);
-- `custom`.
-
-Режим по умолчанию для командной работы: `github` (или другой внешний трекер). `local` используется как fallback.
-
-## 9) Канонические команды
-Все рабочие операции проходят через `Agile Manager Agent` + `TrackerGateway`.
-Операционные шаблоны команд: [tracker-command-template.md](./tracker-command-template.md).
-
-0. `VERIFY_GOVERNANCE_GATE`
-1. `CREATE_TASK`
-2. `PREPARE_TASK_BRANCH`
-3. `SET_STATUS`
-4. `RUN_REVIEW_GATE`
-5. `COMMIT_BY_NAME`
-6. `RUN_MR_REVIEW_GATE`
-7. `ASSIGN_SPRINT`
-8. `PREPARE_RELEASE_NOTE`
-9. `MARK_TASKS_PUBLISH`
-10. `STATUS_SNAPSHOT`
-
-## 10) Коммиты и закрытие задач: только по подтверждению пользователя
-Запрещено выполнять автоматически:
-- `COMMIT_BY_NAME`;
-- перевод задачи в `DONE`.
-
-Обязательное правило:
-- для режима `git_flow_lite` статусный цикл задачи фиксируется как `TODO -> IN_PROGRESS -> REVIEW -> READY -> DONE` (для релизных задач дополнительно `-> PUBLISH`);
-- рабочие ветки: `feature/*`, `release/*`, `hotfix/*`; долгоживущие ветки: `develop`, `main`;
-- интеграционные правила: `feature/* -> develop`, `release/* -> main` + back-merge в `develop`, `hotfix/* -> main` + back-merge в `develop`;
-- `RUN_REVIEW_GATE` сначала формирует отчёт ревьювера и рекомендацию (`PASS_CANDIDATE`/`FAIL`);
-- финальный `RUN_REVIEW_GATE: PASS_CONFIRMED` допускается только после явного подтверждения пользователя `Review Approved: yes`;
-- `COMMIT_BY_NAME` выполняется только после `RUN_REVIEW_GATE: PASS_CONFIRMED` и отдельного явного подтверждения пользователя в текущем диалоге;
-- merge в целевую ветку выполняется только после `RUN_MR_REVIEW_GATE: PASS_CONFIRMED` и явного подтверждения пользователя `MR Review Approved: yes`;
-- `SET_STATUS -> DONE` выполняется только после явного подтверждения пользователя в текущем диалоге;
-- без подтверждения пользователя максимум допустимого статуса: `REVIEW`.
-- `SET_STATUS -> READY` разрешён только после `RUN_REVIEW_GATE: PASS_CONFIRMED`.
-- для задач реализации по умолчанию используется отдельная ветка `feature/*`; прямой рабочий поток на `develop`/`main` не допускается.
-- сообщение коммита обязано содержать ссылку на задачу (`#issue-number`).
-- `READY` означает: коммит сделан и отправлен (`push`) в `feature/*`, `release/*` или `hotfix/*` с открытым PR по правилам ветвления.
-- `DONE` означает: изменения интегрированы в `main`; для `release/*` и `hotfix/*` подтверждён back-merge в `develop`.
-- `PUBLISH` означает: релиз опубликован и доступен в последней версии пакета.
-
-## 10.1) Правило для больших фич (GitHub tracker)
-Если задача классифицирована как большая фича, система обязана предложить:
-- создать `feature issue` (`type:feature`);
-- создать `epic issue` (`type:epic`);
-- выделить отдельную ветку разработки;
-- связать feature с epic в GitHub issue (ссылка в body/comment/task list).
-
-Для текущего этапа (только GitHub tracker) epic реализуется как обычный issue с label `type:epic`.
-
-## 10.2) Обязательная маршрутизация ветки для Agile Manager Agent
-Перед началом реализации агент обязан:
-1. Проверить веточный контекст через `meta:status`.
-2. Запустить branch-routing preflight через `meta:task-start -- --task <#issue> --slug <slug> --kind atomic|feature|release|hotfix`.
-3. В названии рабочей ветки использовать GitHub issue ref в формате `issue-<number>` (например, `feature/issue-21-canonical-github-issue-id`).
-4. Если задача относится к текущей feature-ветке (атомарная подзадача), продолжить в этой ветке только после подтверждения пользователя.
-5. Если задача не относится к текущей ветке, проверить незакоммиченные изменения и непушенные коммиты.
-6. Согласовать с пользователем способ обработки (`commit/stash/discard/push`).
-7. Переключиться на базовую ветку (`develop` или `main`) и обновить её.
-8. Создать новую рабочую ветку по Git Flow Lite.
-9. Перед переключением проверить консистентность `agents.md` между текущей и базовой веткой; при отличиях показать явное предупреждение и запросить подтверждение пользователя.
-
-Без этого preflight выполнение реализации запрещено.
-
-## 11) Жёсткие критерии приёмки (все обязательны)
-Задача принимается только если одновременно выполнены все условия:
-1. Заполнены все PRD-блоки этапа: `Описание`, `Проверяемость`, `Что сделано`.
-2. Выполнен обязательный префикс `Agent Auto-Select` + `Task Agent`.
-3. Пройдены все обязательные `strict` проверки.
-4. `statistical` метрики не ниже зафиксированных порогов.
-5. Пройдены обязательные `human` approvals.
-6. Собран полный evidence-пакет (артефакты, логи, ссылки на проверки).
-7. Синхронизированы `task/status/sprint` в трекере.
-8. Если был коммит, есть явное подтверждение пользователя на коммит.
-9. Если задача закрыта в `DONE`, есть явное подтверждение пользователя на закрытие.
-10. Перед каждой командой пройден `VERIFY_GOVERNANCE_GATE` от `Governance Watchdog Agent`.
-11. Перед коммитом пройден `RUN_REVIEW_GATE` от `Reviewer/Judge Agent`.
-12. Есть явное подтверждение пользователя на прохождение review (`Review Approved: yes`).
-13. Перед merge пройден `RUN_MR_REVIEW_GATE` от `MR Review Agent`.
-14. Есть явное подтверждение пользователя на MR review (`MR Review Approved: yes`).
-15. До review gate задача переведена в статус `REVIEW`.
-16. Статус `READY` выставлен только после `RUN_REVIEW_GATE: PASS_CONFIRMED`.
-17. Для статуса `READY` подтверждены `commit + push` в `feature/*|release/*|hotfix/*` и открытый PR в целевую ветку (`develop` или `main`).
-18. Для merge подтверждён `RUN_MR_REVIEW_GATE: PASS_CONFIRMED`.
-19. Для статуса `DONE` подтверждена интеграция в `main`; для `release/*` и `hotfix/*` подтверждён back-merge в `develop`.
-20. Для статуса `PUBLISH` подтверждена публикация в последней версии.
-21. Для релиза обновлён публичный `CHANGELOG.md`.
-22. Коммит содержит ссылку на issue (`#issue`).
-23. Для branch routing собран e2e evidence по двум сценариям: `same feature` и `different feature`.
-24. Перед `--apply` подтверждена консистентность контекста `agents.md` (или явно подтверждён осознанный switch при diff).
-
-Если хотя бы один критерий не выполнен, задача не принимается.
-
-## 12) Verification-first gate
-Реализация не начинается, пока не определены:
-- acceptance criteria;
-- метрики и пороги;
-- инварианты и ограничения;
-- процедуры проверки;
-- зоны неопределённости и правила эскалации;
-- способ фиксации в трекере.
-
-## 13) Реакция на провал проверки
-Допустимые сценарии:
-- `retry` с корректировками;
-- пересмотр архитектуры;
-- уточнение критериев;
-- эскалация пользователю/founder;
-- возврат статуса задачи в `IN_PROGRESS` или `BLOCKED`.
-
-## 14) Главный инвариант
-Нельзя делегировать работу и нельзя закрывать задачу без формализованных критериев приёмки, PRD-блока `Проверяемость` и требуемых доказательств в трекере.