workflow-ai 1.2.1 → 1.3.1

package/src/scripts/move-ticket.js

@@ -12,6 +12,7 @@
 
 import fs from "fs";
 import path from "path";
+import { fileURLToPath } from "url";
 import YAML from "workflow-ai/lib/js-yaml.mjs";
 import { findProjectRoot } from "workflow-ai/lib/find-root.mjs";
 import {
@@ -21,6 +22,11 @@ import {
   getLastReviewStatus,
 } from "workflow-ai/lib/utils.mjs";
 
+const logger = {
+  info: (msg) => console.error(`[INFO] ${msg}`),
+  warn: (msg) => console.error(`[WARN] ${msg}`),
+};
+
 // Корень проекта
 const PROJECT_DIR = findProjectRoot();
 // Базовая директория workflow
@@ -89,6 +95,45 @@ function isValidTransition(from, to) {
   return { valid: true };
 }
 
+/**
+ * Hook для обновления approval-файлов при перемещении тикета
+ * @param {string} ticketId - ID тикета
+ * @param {string} target - целевой статус
+ * @param {object} fsModule - модуль fs (для mock в тестах)
+ * @param {string} workflowDir - директория .workflow
+ */
+function updateApprovalFilesHook(ticketId, target, fsModule = fs, workflowDir = WORKFLOW_DIR) {
+  try {
+    const approvalsDir = path.join(workflowDir, "approvals");
+    if (fsModule.existsSync(approvalsDir)) {
+      const files = fsModule.readdirSync(approvalsDir);
+      const escapedTicketId = ticketId.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
+      const pattern = new RegExp(`^${escapedTicketId}_manual-gate-.*_\\d+\\.json$`);
+      for (const file of files) {
+        if (!pattern.test(file)) continue;
+        const filePath = path.join(approvalsDir, file);
+        try {
+          const data = JSON.parse(fsModule.readFileSync(filePath, "utf8"));
+          if (data.status === "pending") {
+            data.status = "approved";
+            data.decided_by = "move-ticket";
+            data.comment = `auto-approved on move to ${target}`;
+            data.updated_at = new Date().toISOString();
+            fsModule.writeFileSync(filePath, JSON.stringify(data, null, 2), "utf8");
+            logger.info(`Approval file ${file} auto-approved on move to ${target}`);
+          }
+        } catch (err) {
+          logger.warn(`Corrupt approval file ${file}: ${err.message}`);
+          // продолжаем, не падаем
+        }
+      }
+    }
+  } catch (err) {
+    // Ошибка hook'а не должна фейлить само перемещение
+    logger.warn(`Approval hook error: ${err.message}`);
+  }
+}
+
 /**
  * Основная функция перемещения тикета
  */
@@ -210,6 +255,9 @@ async function moveTicket(ticketId, target) {
     };
   }
 
+  // Hook: обновление approval-файлов (если есть) — срабатывает на любой move
+  updateApprovalFilesHook(ticketId, target);
+
   return {
     status: "moved",
     ticket_id: ticketId,
@@ -218,43 +266,60 @@ async function moveTicket(ticketId, target) {
   };
 }
 
-// Main entry point
-const rawArgs = process.argv.slice(2);
-let ticketId, target;
-
-if (rawArgs.length >= 2) {
-  // Прямой вызов: node move-ticket.js IMPL-001 in-progress
-  ticketId = rawArgs[0];
-  target = rawArgs[1];
-} else if (rawArgs.length === 1) {
-  // Вызов через pipeline runner: один аргумент — промпт с контекстом
-  // Формат: "skill-name\n\nContext:\n  ticket_id: X\n  target: Y\n..."
-  const prompt = rawArgs[0];
-  const ticketMatch = prompt.match(/ticket_id:\s*(\S+)/);
-  const targetMatch = prompt.match(/target:\s*(\S+)/);
-  ticketId = ticketMatch?.[1];
-  target = targetMatch?.[1];
-  if (!ticketId || !target) {
-    console.error(
-      "[ERROR] Cannot parse ticket_id or target from pipeline context",
-    );
-    printResult({
-      status: "error",
-      error: "Missing ticket_id or target in pipeline context",
-    });
-    process.exit(1);
+// Export for testing
+export { moveTicket, updateApprovalFilesHook };
+
+// Main entry point — guard prevents execution when imported as module in tests.
+// Используем fs.realpathSync чтобы корректно сравнивать пути на Windows когда .workflow/src/scripts/ — junction.
+// Без realpathSync argv[1] = путь через junction, а import.meta.url = разрешённый target — строки не совпадают.
+function __isMainModule() {
+  try {
+    const argvPath = fs.realpathSync(path.resolve(process.argv[1] || ""));
+    const metaPath = fileURLToPath(import.meta.url);
+    return argvPath === metaPath;
+  } catch {
+    return false;
   }
-} else {
-  console.error("Usage: node move-ticket.js <ticket_id> <target>");
-  console.error("Example: node move-ticket.js IMPL-001 in-progress");
-  console.error("Available targets:", VALID_STATUSES.join(", "));
-  printResult({ status: "error", error: "Missing arguments" });
-  process.exit(1);
 }
 
-moveTicket(ticketId, target).then((result) => {
-  printResult(result);
-  if (result.status === "error") {
+if (__isMainModule()) {
+  const rawArgs = process.argv.slice(2);
+  let ticketId, target;
+
+  if (rawArgs.length >= 2) {
+    // Прямой вызов: node move-ticket.js IMPL-001 in-progress
+    ticketId = rawArgs[0];
+    target = rawArgs[1];
+  } else if (rawArgs.length === 1) {
+    // Вызов через pipeline runner: один аргумент — промпт с контекстом
+    // Формат: "skill-name\n\nContext:\n  ticket_id: X\n  target: Y\n..."
+    const prompt = rawArgs[0];
+    const ticketMatch = prompt.match(/ticket_id:\s*(\S+)/);
+    const targetMatch = prompt.match(/target:\s*(\S+)/);
+    ticketId = ticketMatch?.[1];
+    target = targetMatch?.[1];
+    if (!ticketId || !target) {
+      console.error(
+        "[ERROR] Cannot parse ticket_id or target from pipeline context",
+      );
+      printResult({
+        status: "error",
+        error: "Missing ticket_id or target in pipeline context",
+      });
+      process.exit(1);
+    }
+  } else {
+    console.error("Usage: node move-ticket.js <ticket_id> <target>");
+    console.error("Example: node move-ticket.js IMPL-001 in-progress");
+    console.error("Available targets:", VALID_STATUSES.join(", "));
+    printResult({ status: "error", error: "Missing arguments" });
     process.exit(1);
   }
-});
+
+  moveTicket(ticketId, target).then((result) => {
+    printResult(result);
+    if (result.status === "error") {
+      process.exit(1);
+    }
+  });
+}

package/src/scripts/pick-next-task.js

@@ -567,28 +567,25 @@ function pickNextTicket(planId) {
     return { status: 'empty', reason: 'No tickets in ready/' };
   }
 
-  // Фильтрация по условиям и зависимостям
-  const eligibleTickets = tickets.filter(ticket => {
+  // Фильтрация: разделяем на обычные и human с проверкой условий/зависимостей
+  const eligibleNonHuman = [];
+  const humanCandidates = [];
+  
+  for (const ticket of tickets) {
     const { frontmatter } = ticket;
 
-    // Пропускаем тикеты, требующие ручного выполнения
-    if (frontmatter.type === 'human') {
-      logger.info(`Skipping ticket ${ticket.id}: type is 'human' (requires manual execution)`);
-      return false;
-    }
-
     // Проверка условий
     const conditions = frontmatter.conditions || [];
     const conditionsMet = conditions.every(checkCondition);
     if (!conditionsMet) {
-      return false;
+      continue;
     }
 
     // Проверка зависимостей
     const dependencies = frontmatter.dependencies || [];
     const depsMet = checkDependencies(dependencies);
     if (!depsMet) {
-      return false;
+      continue;
     }
 
     // Обнаружение и удаление дубликатов: тикет не должен существовать в других колонках
@@ -607,46 +604,75 @@ function pickNextTicket(planId) {
       } catch (err) {
         logger.error(`Failed to archive duplicate ${ticket.id}: ${err.message}`);
       }
-      return false;
+      continue;
     }
 
-    return true;
-  });
+    // Разделение по типу
+    if (frontmatter.type === 'human') {
+      humanCandidates.push(ticket);
+    } else {
+      eligibleNonHuman.push(ticket);
+    }
+  }
+
+  // Имеются ли обычные (non-human) готовые тикеты — старший приоритет
+  if (eligibleNonHuman.length > 0) {
+    eligibleNonHuman.sort((a, b) => {
+      const priorityA = a.frontmatter.priority || 999;
+      const priorityB = b.frontmatter.priority || 999;
 
-  if (eligibleTickets.length === 0) {
+      if (priorityA !== priorityB) {
+        return priorityA - priorityB;
+      }
+
+      const dateA = new Date(a.frontmatter.created_at || '9999-12-31');
+      const dateB = new Date(b.frontmatter.created_at || '9999-12-31');
+      return dateA - dateB;
+    });
+
+    const selected = eligibleNonHuman[0];
     return {
-      status: 'empty',
-      reason: 'No eligible tickets (conditions/dependencies not met)'
+      status: 'found',
+      ticket_id: selected.id,
+      priority: selected.frontmatter.priority,
+      title: selected.frontmatter.title,
+      type: selected.frontmatter.type,
+      required_capabilities: JSON.stringify(selected.frontmatter.required_capabilities || [])
     };
   }
 
-  // Сортировка по приоритету (меньше = важнее), затем по created_at
-  eligibleTickets.sort((a, b) => {
-    const priorityA = a.frontmatter.priority || 999;
-    const priorityB = b.frontmatter.priority || 999;
+  // Если есть созревшие human-тикеты — новый статус human_ready (для manual-gate)
+  if (humanCandidates.length > 0) {
+    humanCandidates.sort((a, b) => {
+      const priorityA = a.frontmatter.priority || 999;
+      const priorityB = b.frontmatter.priority || 999;
 
-    if (priorityA !== priorityB) {
-      return priorityA - priorityB;
-    }
+      if (priorityA !== priorityB) {
+        return priorityA - priorityB;
+      }
 
-    // При равном приоритете - по дате создания (старые первые)
-    const dateA = new Date(a.frontmatter.created_at || '9999-12-31');
-    const dateB = new Date(b.frontmatter.created_at || '9999-12-31');
-    return dateA - dateB;
-  });
+      const dateA = new Date(a.frontmatter.created_at || '9999-12-31');
+      const dateB = new Date(b.frontmatter.created_at || '9999-12-31');
+      return dateA - dateB;
+    });
 
-  const selected = eligibleTickets[0];
+    const selected = humanCandidates[0];
+    return {
+      status: 'human_ready',
+      ticket_id: selected.id,
+      priority: selected.frontmatter.priority,
+      title: selected.frontmatter.title,
+      pending_count: humanCandidates.length
+    };
+  }
 
   return {
-    status: 'found',
-    ticket_id: selected.id,
-    priority: selected.frontmatter.priority,
-    title: selected.frontmatter.title,
-    type: selected.frontmatter.type,
-    required_capabilities: JSON.stringify(selected.frontmatter.required_capabilities || [])
+    status: 'empty',
+    reason: 'No eligible non-human tickets (and no ready human tickets)'
   };
 }
 
+
 /**
  * Архивирует все done-тикеты, принадлежащие архивным планам (plans/archive/).
  * Сканирует все планы в plans/archive/, находит их тикеты в done/ и перемещает в archive/.
@@ -778,6 +804,9 @@ async function main() {
   }
 }
 
+// Экспортируем функции для тестирования
+export { pickNextTicket, readReadyTickets, readReviewTickets, readInProgressTickets, findCompletedInProgress, filterByPlan };
+
 main().catch(e => {
   logger.error(e.message);
   printResult({ status: 'error', error: e.message });

package/src/skills/__test-cal-001-1777553217513/SKILL.md

@@ -0,0 +1,2 @@
+# Calibration Test Skill
+version: 1.0

package/src/skills/__test-runner-1777553217483/SKILL.md

@@ -0,0 +1,5 @@
+# Test Skill
+
+SIGNATURE_PRESENT
+SomeOtherContent
+version: 1.0

package/src/skills/coach/SKILL.md

@@ -123,11 +123,12 @@ ticket_prefix: COACH
 
 ## Принципы
 
-1. **Root Cause First** — при обнаружении проблемы в артефакте (тикете, плане, отчёте) всегда определи скил-источник, который создал этот артефакт, и предложи исправить **скил** первым. Не предлагай ручную правку артефактов (последствий), пока корневая причина (скил) не исправлена. Порядок действий: (1) найти скил-источник → (2) проследить цепочку вверх: если артефакт-источник (план, шаблон) уже содержал дефект — root cause в скиле, создавшем **его**, а не в скиле-обработчике → (3) исправить скил → (4) если нужно, предложить пересоздать артефакт исправленным скилом. **Антипаттерн «остановка на ближайшем скиле»:** тикет неатомарен → правишь декомпозитор. Но если задача **плана** уже неатомарна — root cause в скиле планирования, декомпозитор — вторая линия обороны. **Антипаттерн:** если данные невалидны — root cause в том, кто/что генерирует данные (шаблон, скил, воркфлоу), а НЕ в обработчике данных (скрипт, парсер). Не правь обработчик под невалидный формат — исправь источник формата. **⚠️ Обязательно перед правкой:** прочитай лог или артефакт до конца — определи точный паттерн нарушения (кто, когда, что именно записал). Гипотеза о root cause без evidence из лога — не основание для правки. **Семантика первична:** перед диагностикой сформулируй назначение скила одним предложением (что он должен решать, что НЕ должен). Если поведение противоречит назначению — это ошибка в скиле, не в смежных компонентах. **⚠️ Физический автор ≠ семантический владелец:** при определении скила-источника ищи не «кто владеет предметной областью артефакта», а **кто физически записывает** (Edit/Write) проблемный фрагмент. Если скил A выполняет предметную работу, но скил B записывает результат в тикет — root cause в инструкциях скила B, а не A. Антипаттерн: «тикет предметной области X → правлю скил предметной области», хотя физическую запись в тикет выполняет скил-исполнитель. **⛔ Повторный инцидент по той же корневой проблеме:** перед формулированием правки **обязательно** прогрепай `coach-backlog.yaml` на ключевые термины текущей проблемы (имя скила-жертвы, имя нарушенного правила, имя задействованной нормы). Если обнаружен CHG за последние 30 дней на тот же скил и ту же корневую проблему — это сигнал, что **текстовое усиление инструкции не работает** (предыдущий текст уже содержал норму, но нарушитель её проигнорировал). В этом случае: (а) ещё одна текстовая правка того же скила — недостаточная мера; (б) обязательно создай тикет эскалации стейкхолдеру с рекомендацией ввести **машинную защиту**, не зависящую от дисциплины агента (валидация пайплайном, пост-гейт-стадия, автоматический откат, инфраструктурная проверка); (в) в тикете явно опиши, что попытки дисциплинарного усиления исчерпаны, и почему только машинная защита закрывает класс ошибки. Текстовую правку всё равно применяй — она страхует дисциплинированного агента, — но **не считай её решением проблемы**, пока машинная защита не введена. Антипаттерн: «усилю формулировку ещё жёстче, напишу ⛔ крупнее» — агент, который не прочитал прошлую норму, не прочитает и новую.
+1. **Root Cause First** — при обнаружении проблемы в артефакте (тикете, плане, отчёте) всегда определи скил-источник, который создал этот артефакт, и предложи исправить **скил** первым. Не предлагай ручную правку артефактов (последствий), пока корневая причина (скил) не исправлена. Порядок действий: (1) найти скил-источник → (2) проследить цепочку вверх: если артефакт-источник (план, шаблон) уже содержал дефект — root cause в скиле, создавшем **его**, а не в скиле-обработчике → (3) исправить скил → (4) если нужно, предложить пересоздать артефакт исправленным скилом. **Антипаттерн «остановка на ближайшем скиле»:** тикет неатомарен → правишь декомпозитор. Но если задача **плана** уже неатомарна — root cause в скиле планирования, декомпозитор — вторая линия обороны. **Антипаттерн:** если данные невалидны — root cause в том, кто/что генерирует данные (шаблон, скил, воркфлоу), а НЕ в обработчике данных (скрипт, парсер). Не правь обработчик под невалидный формат — исправь источник формата. **⚠️ Обязательно перед правкой:** прочитай лог или артефакт до конца — определи точный паттерн нарушения (кто, когда, что именно записал). Гипотеза о root cause без evidence из лога — не основание для правки. **Семантика первична:** перед диагностикой сформулируй назначение скила одним предложением (что он должен решать, что НЕ должен). Если поведение противоречит назначению — это ошибка в скиле, не в смежных компонентах. **⚠️ Физический автор ≠ семантический владелец:** при определении скила-источника ищи не «кто владеет предметной областью артефакта», а **кто физически записывает** (Edit/Write) проблемный фрагмент. Если скил A выполняет предметную работу, но скил B записывает результат в тикет — root cause в инструкциях скила B, а не A. Антипаттерн: «тикет предметной области X → правлю скил предметной области», хотя физическую запись в тикет выполняет скил-исполнитель. **⛔ Повторный инцидент по той же корневой проблеме:** перед формулированием правки **обязательно** прогрепай `coach-backlog.yaml` на ключевые термины текущей проблемы (имя скила-жертвы, имя нарушенного правила, имя задействованной нормы). Если обнаружен CHG за последние 30 дней на тот же скил и ту же корневую проблему — **сначала сравни даты выполнения тикета-нарушителя и применения предыдущего CHG, до классификации «повторный инцидент»**. Источники дат: для CHG — `git log` на файл скила (commit-дата правки) или `analyzed_tickets.analyzed_date` в `coach-backlog.yaml`; для тикета — `updated_at`/`completed_at` в frontmatter или ближайшие временные метки в логе пайплайна, где произошёл инцидент (стадии execute-task / review-result, дата записи `## Ревью`). **Если выполнение тикета предшествует дате CHG** — это **не** повторный инцидент: тикет проходил пайплайн до того, как текстовое усиление было применено, нарушение исторически объяснимо (фикса ещё не существовало). Класс — обычный новый, эскалация на машинную защиту **не нужна**, обработай как стандартный CHG. **Только если выполнение тикета строго ПОСЛЕ даты CHG** — это сигнал, что **текстовое усиление инструкции не работает** (предыдущий текст уже содержал норму, но нарушитель её проигнорировал). В этом случае: (а) ещё одна текстовая правка того же скила — недостаточная мера; (б) обязательно создай тикет эскалации стейкхолдеру с рекомендацией ввести **машинную защиту**, не зависящую от дисциплины агента (валидация пайплайном, пост-гейт-стадия, автоматический откат, инфраструктурная проверка); (в) в тикете явно опиши, что попытки дисциплинарного усиления исчерпаны, и почему только машинная защита закрывает класс ошибки. Текстовую правку всё равно применяй — она страхует дисциплинированного агента, — но **не считай её решением проблемы**, пока машинная защита не введена. Антипаттерн 1: «усилю формулировку ещё жёстче, напишу ⛔ крупнее» — агент, который не прочитал прошлую норму, не прочитает и новую. Антипаттерн 2: классифицировать «повторный инцидент» по факту повторяемости пары (скил, класс ошибки) **без сравнения дат** CHG и выполнения тикета. Эскалация без date-check — преждевременная: возможно, тикет проходил пайплайн ещё до текстового усиления, и фикс не имел шанса сработать. **Date-check — необходимое, но не достаточное условие.** Дополнительно сверь **семантический класс ошибки** предыдущего CHG и текущего инцидента: даже если выполнение тикета строго после CHG, инцидент может быть другого класса (CHG покрывал ортогональную проблему — например, semantic-mismatch vs structural-integrity, test-isolation vs review-rubric). Тогда это новый класс, а не повторный инцидент, и эскалация не требуется. Условие эскалации: **(дата выполнения > дата CHG) И (семантический класс совпадает)**.
 2. **Evidence-Based** — все выводы основаны на данных из завершённых тикетов, планов и логов пайплайна, а не на предположениях. **При анализе лога обязательно строй временную диаграмму ключевых событий по ID артефакта** (тикет, план, отчёт): проследи всю цепочку перемещений/изменений артефакта от первого упоминания до последнего, обращая внимание на события, отстоящие далеко друг от друга по времени, но связанные одним ID. **Антипаттерн:** прочитал начало лога (события archive/cleanup), прочитал середину (события create/decompose), но **не сопоставил** их — упустил коллизию ID или другой паттерн взаимного влияния. Перед формулированием findings задай себе вопрос: «Я проверил всю историю каждого упомянутого ID, или только последнее событие с ним?» **⚠️ Проверка фактической практики перед нормативной правкой:** если правка вводит новое правило про путь, имя, формат, расположение — **обязательно `Grep` по всему проекту** (код, конфиги, скилы, тикеты) на ключевой термин этого правила, чтобы измерить **масштаб уже существующей практики**. Один-два аномальных артефакта — не основание объявлять их новой нормой. Если фактическая практика противоположна гипотезе — гипотеза неверна, или (если стейкхолдер действительно хочет миграцию) нужен явный миграционный план и согласие на масштаб правок. Антипаттерн: получил короткий ответ стейкхолдера на развилку → принял за сильное правило → пошёл править скилы → не проверил, что в проекте 20+ артефактов уже живут по противоположному правилу. Перед каждой нормативной правкой задай себе вопрос: «Сколько уже существующих файлов/строк проекта противоречат тому, что я собираюсь записать?» Если ответ > 5 — остановись и переспроси у стейкхолдера, точно ли это миграция. **⚠️ Обязательный diff формулировок при анализе цепочки артефактов:** когда анализируешь инцидент, прошедший через несколько стадий (план → тикет → исполнение → ревью), **перед назначением виновного** обязан построчно сопоставить формулировки критериев на каждом стыке: (1) дословная строка критерия в плане, (2) дословная строка в тикете, (3) что реально проверяет assertion/тест, (4) что ревьюер проверял. Виновник — стадия, на которой произошла первая потеря семантики. Антипаттерн: прочитал план и увидел расхождение с результатом → обвинил последнюю стадию (ревьюера), не проверив, на какой промежуточной стадии формулировка была ослаблена. Гипотеза «ревьюер должен был поймать» невалидна, если ревьюер работал по формулировке тикета, а тикет уже не содержал потерянного уточнения.
 **⚠️ Антипаттерн «уход в формулировки вместо root cause»:** стейкхолдер задаёт вопрос о наблюдаемом дефекте («почему не поймали?»), а коуч анализирует текст формулировок, семантику переносов, чеклисты — вместо того чтобы ответить на прямой вопрос: какой конкретный шаг в какой конкретной стадии не выполнил конкретное физическое действие (открыть файл, посмотреть на картинку, запустить команду). Формулировки — это причина второго порядка; причина первого порядка — «агент X не сделал действие Y». Всегда начинай с причины первого порядка, потом объясняй, почему инструкции это допустили.
 **⚠️ Антипаттерн «оценка по результату вместо сверки с инструкцией»:** при анализе действия агента — **не оценивай** его «разумность» или «допустимость» по своему суждению. Вместо этого открой скил агента и **дословно сверь** действие с инструкцией. Если инструкция говорит «разбей тикет», а агент объединил шаги — это нарушение, даже если результат выглядит «приемлемо». Коуч не имеет права смягчать finding на основании того, что дефект «небольшой» или «единичный» — скил либо нарушен, либо нет.
 **⚠️ Антипаттерн «пересказ вместо цитаты» при утверждениях о коде:** перед утверждением вида «скрипт/функция X использует/читает/пишет Y» обязан открыть файл и **дословно процитировать** строку, на которой это поведение происходит. Пересказ по памяти (даже свежей) теряет операторы-fallback (`a || b`, `a ?? b`), условные ветви, ранние return'ы — те детали, которые как раз и задают реальное поведение. Источник ошибки: агент видит ключевое слово в строке, строит «достаточное» утверждение о поведении и идёт дальше. Правило: если утверждение про код войдёт в финдинг, CHG, черновик правки или ответ стейкхолдеру — строка должна быть в отчёте целиком (либо скопированной в цитату, либо явной ссылкой `file:line`, открытой и перечитанной непосредственно перед утверждением).
+**⚠️ Антипаттерн «отрицательное утверждение о capability инструмента без проверки» (расширение предыдущего):** правило «дословная цитата» применяется не только к **позитивным** утверждениям («X делает Y»), но и к **отрицательным** («инструмент/фреймворк/тест X **не умеет / не покрывает / не подходит для** Y»). Отрицательное утверждение о capability — такое же утверждение о коде, как и позитивное, и требует тех же доказательств: либо (1) Grep по тестам/коду проекта, использующим инструмент, на ключевой паттерн использования (например, для гипотезы «Playwright не покрывает extension popup» — `Grep "loadExtension|launchPersistentContext|chrome-extension://"` по `tests/`), либо (2) дословная цитата из официальной документации. Источник ошибки: агент экстраполирует «общеизвестное» назначение инструмента (Playwright = веб-сайты, jest = unit-тесты и т.п.) без проверки фактической практики проекта или актуальных возможностей. Триггер срабатывания: если в черновике финдинга/ответа есть конструкция «{инструмент} не {глагол} {объект}» и от неё зависит root cause или CHG — **обязательна** проверка перед показом стейкхолдеру. Без проверки финдинг невалиден, даже если интуиция кажется правильной.
 3. **Итеративность** — улучшай скилы инкрементально. Маленькие точечные улучшения > масштабные переписывания.
 4. **Обратная совместимость** — улучшения не должны ломать существующие воркфлоу и интеграции.
 5. **Актуальность знаний** — активно ищи в интернете лучшие практики, фреймворки и подходы для обогащения скилов.

package/src/skills/execute-task/SKILL.md

@@ -70,6 +70,14 @@ description: >
 |----------|----------------|
 | `algorithms/execution-strategy.md` | **ВСЕГДА** — стратегия анализа, выполнения и верификации задачи |
 
+## Загрузка шаблонов
+
+Подгружай из `templates/` при необходимости:
+
+| Шаблон | Когда загружать |
+|--------|----------------|
+| `templates/result-template.md` | При создании секции `## Result` в тикете — структура и правила заполнения |
+
 ## Шаги выполнения
 
 ### 1. Прочитать тикет
@@ -122,6 +130,8 @@ description: >
 3. Прочитать `context.notes` — дополнительный контекст от создателя тикета
 4. Если тикет ссылается на план (`parent_plan`) — прочитать план для понимания общей картины
 
+**⛔ Валидация путей перед Edit:** если DoD требует изменить конкретный файл, указанный в `context.files` или описании, используй **ровно тот путь**, который указан. Перед каждым Edit сверь целевой путь с путём из контекста тикета. Одноимённый файл в другой директории — не целевой файл. Пример нарушения: тикет указывает `workflow-ai/README.md`, агент редактирует `./README.md`.
+
 ### 5. Выполнить работу и фиксировать результат инкрементально
 
 Действовать по описанию и DoD тикета. Подход определяется **содержимым тикета**, а не типом:
@@ -131,6 +141,8 @@ description: >
 - Если тикет требует тестирования — выполнить чеклист проверок из DoD, зафиксировать pass/fail по каждому пункту
 - Если тикет требует исследования — использовать доступные инструменты для сбора данных, подкреплять источниками
 
+**⛔ Перед вставкой кода в существующий файл — прочитай целевой участок и пойми его структуру.** Определи границы функции/класса/блока, в который вставляешь код. Вставляй код в семантически правильное место, а не в произвольную точку файла. Если не уверен в месте вставки — прочитай окружающий контекст (строки до и после) и убедись, что вставка не разрывает существующую структуру.
+
 **⚠️ ИНКРЕМЕНТАЛЬНАЯ ЗАПИСЬ (ОБЯЗАТЕЛЬНО):**
 
 После выполнения **каждого пункта** — **сразу** запиши результат в тикет:
@@ -156,7 +168,7 @@ description: >
 
 К этому моменту секция Result уже содержит результаты по каждому пункту (записаны инкрементально на шаге 5). Осталось:
 
-- Обновить/добавить **Summary** — краткое резюме всей работы
+- Обновить/добавить **Что сделано** — краткое резюме всей работы
 - Дополнить **Изменённые файлы** и **Заметки** если нужно
 - **НЕ удалять и не переписывать** уже записанные результаты
 
@@ -191,13 +203,21 @@ description: >
 
 ### 9. Вывести структурированный результат
 
+**⛔ Перед выводом RESULT пройди все три GATE из `workflows/execute.md` (шаг 6).** GATE-1 (Edit-проверка), GATE-2 (механическая Read-проверка), GATE-3 (self-check). При любом нарушении — вернись к шагам 5–7.
+
+⛔ **GATE-1 — EDIT-ПРОВЕРКА (выполни ПЕРЕД Read-проверкой):**
+
+За текущую сессию ты должен был вызвать инструмент **`Edit`** на файл тикета как минимум дважды: один раз для обновления DoD-чекбоксов (`[ ]` → `[x]`), один раз для записи секции Result. Если ни одного вызова `Edit` на файл тикета `.workflow/tickets/in-progress/{TICKET-ID}.md` не было — секция Result физически пустая и DoD не отмечен, независимо от написанного в stdout. Это призрачное выполнение (ограничение #9). Немедленно вернись к шагам 5–7.
+
+**Ключевой принцип:** stdout (текст ответа) ≠ файл тикета. Результат существует только в том, что записано через инструмент `Edit`.
+
 **⛔ ОБЯЗАТЕЛЬНАЯ МЕХАНИЧЕСКАЯ ПРОВЕРКА — перечитай файл тикета перед RESULT:**
 
 Перед выводом `---RESULT---` выполни `Read` на файл тикета (`.workflow/tickets/in-progress/{TICKET-ID}.md`) и глазами убедись:
 
 1. **Ни одного чекбокса `[ ]`** в секции критериев готовности / DoD. Все переведены в `[x]` или помечены причиной невыполнения (`[x] Пункт — не применимо: <причина>`).
 2. **Секция `## Result` / `## Результат выполнения` физически заполнена** — содержит реальный текст (summary, изменённые файлы, заметки), а не оставлена в виде скелета-шаблона с `### Что сделано\n- ...`.
-3. **Frontmatter не содержит добавленных строк `status:` или `completed_at:`** (эти поля устанавливает только пайплайн).
+3. **Frontmatter не модифицирован вообще** — никаких новых ключей, никаких изменённых значений (включая `notes`, `tags`, `context.*`). Frontmatter — собственность создателя тикета и пайплайна. Эта проверка шире, чем запрет на `status:` и `completed_at:` (см. ограничение #5): любая правка frontmatter — потенциально источник YAML-несовместимостей (двоеточие+пробел в неэкранированном скаляре, дубль ключа, нарушенный отступ массива). Если необходимо зафиксировать прогресс/итерации/наблюдения — пиши в **тело тикета** (секции Result/Заметки), не в frontmatter.
 
 Если хоть один пункт нарушен — **вернись к шагу 5 или 7** и выполни правки инструментом `Edit` на файл тикета. Не обходи эту проверку: вывод `---RESULT---` при пустом Result или `[ ]`-чекбоксах считается **призрачным выполнением** (см. ограничение #9) и ведёт к retry → blocked.
 
@@ -219,6 +239,7 @@ description: >
 - Нет побочных эффектов — не созданы тикеты/планы, не перемещены файлы
 - Поля `status` и `completed_at` не записаны в файл тикета ни в каком виде
 - Секция `## Ревью` не создавалась и не редактировалась тобой
+- Все временные/промежуточные файлы и пустые директории, созданные в ходе работы и не являющиеся deliverable, удалены; файлы, путь которых зависит от конфига инструмента (mock/test/fixture/snapshot/output), лежат в директории, указанной в конфиге, а не в произвольном месте
 
 **⛔ ФОРМАТ STDOUT — СТРОГО:**
 
@@ -273,6 +294,12 @@ status: default
 
    При визуальных/семантических/поведенческих критериях в Result **явно обоснуй**, почему структурной проверки недостаточно (одна строка). Полная таблица соответствий — `algorithms/execution-strategy.md` раздел «Соразмерность проверки критерию».
 
+9. **Configured paths и cleanup** — файлы, создаваемые во время работы тикета, размещай в местах, явно указанных в конфиге соответствующего инструмента. Перед созданием файла, путь которого может зависеть от конфигурации (mock, тест, фикстура, стаб, snapshot, сгенерированный artifact, временный файл сборки и подобное) — **прочитай соответствующий конфиг проекта**, найди в нём поле target-директории (`roots`, `testDir`, `paths`, `output`, `outDir`, `srcDir` или аналог в конфиге твоего инструмента) и помести файл туда. Создавать файл в корне репозитория без проверки конфига запрещено.
+
+   **После удаления временных/ошибочных файлов — проверь и удали пустые родительские директории**, созданные в ходе тикета. Каждая созданная директория — твоя ответственность вплоть до закрытия тикета. Пустая папка или артефакт вне scope, оставленные в репозитории, — побочный эффект (см. принцип 4 «No Side Effects»).
+
+   ⛔ **Антипаттерн:** создал файл в корне (mock/snapshot/test) → инструмент не подхватил из-за неправильного пути → удалил файл, но оставил пустую папку. Лечение: до создания — проверка конфига; после rm — удаление пустых директорий.
+
 ## Формат вывода
 
 - Русский язык

package/src/skills/review-result/SKILL.md

@@ -57,7 +57,29 @@ description: >
 
 ## Шаги проверки
 
-### 0. Быстрый выход
+### 0. Целостность frontmatter (pre-flight)
+
+Перед любой содержательной проверкой убедись, что frontmatter тикета **валидно парсится** YAML-парсером. Запусти:
+
+```
+node -e "const y=require('js-yaml'),f=require('fs');const c=f.readFileSync(process.argv[1],'utf8');const m=c.match(/^---\\n([\\s\\S]*?)\\n---/);if(!m){console.log('NO_FRONTMATTER');process.exit(1)}try{y.load(m[1]);console.log('OK')}catch(e){console.log('YAML_ERROR:'+e.message);process.exit(2)}" .workflow/tickets/in-progress/{TICKET-ID}.md
+```
+
+(или эквивалент в проекте — `js-yaml.load` секции между `---`).
+
+Если parse возвращает ошибку (`duplicated mapping key`, `bad indentation`, `:` followed by space в неэкранированном скаляре и т.п.) — **немедленный fail**:
+
+```
+---RESULT---
+status: failed
+issues:
+  - "Frontmatter тикета невалиден: <текст YAML-ошибки>. Файл нельзя смержить в done — downstream MCP-ресурсы (workflow://human-queue, alerts) падают на парсинге. Исправить frontmatter и перезапустить."
+---RESULT---
+```
+
+Не пытайся «прочесть содержимое глазами» и одобрить — структурно повреждённый frontmatter ломает скрипты пайплайна и MCP-ресурсы.
+
+### 0.1. Быстрый выход
 
 Прочитай тикет. Если секция `## Ревью` существует и последняя запись — `passed` или `⏭ skipped` → немедленно верни `status: passed`.