@7n/llm-lib 2.9.3 → 2.9.4

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## [2.9.4] - 2026-07-26
+
+### Fixed
+
+- Додано безпечну telemetry batch verdict для coverage timeout-ів.
+
 ## [2.9.3] - 2026-07-26
 
 ### Fixed

package/lib/agent-fix.mjs

@@ -509,7 +509,11 @@ export async function runAgentFix(ruleId, violation, cwd, opts = {}) {
     blocks: guard.state.blocks,
     backstopHit,
     verifyAttempts,
-    wallMs: clock() - startedAt
+    // У trace це вже є, але consumer-ам batch-діагностики потрібен той самий
+    // безпечний агрегат без доступу до повного prompt-а чи capture body.
+    promptChars: fixPrompt.length,
+    wallMs: clock() - startedAt,
+    error
   }
   // Usage кроку для chain-агрегатів: сума по turns агентної сесії.
   const stepUsage = { input: 0, output: 0, totalTokens: 0 }

package/lib/docs/agent-fix.md

@@ -3,27 +3,25 @@ type: JS Module
 title: agent-fix.mjs
 resource: llm-lib/lib/agent-fix.mjs
 docgen:
-  crc: 73c7797b
+  crc: 5e6d8369
   model: openai-codex/gpt-5.4-mini
   tier: cloud-min
-  score: 90
-  issues: internal-name:runVerifyLoop,judge-refine:kept-original,judge:inaccurate:0.98
+  score: 100
+  issues: judge-refine:kept-original,judge:inaccurate:0.98
   judgeModel: openai-codex/gpt-5.4-mini
 ---
 
 ## Огляд
 
-`buildVerifyFeedbackPrompt`, `buildFixPrompt` і `runAgentFix` описують локальний agent-fix цикл: перші дві функції формують промпти для перевірки та виправлення, а `runAgentFix` запускає саму спробу правки. Це потрібно, щоб тримати зміни в межах заданого `violation` і пов’язаного контексту та віддавати керований результат для подальшого кроку.
-
-Усі публічні точки входу працюють fail-safe: помилки перехоплюються всередині, назовні винятки не виходять.
+Модуль формує два промпти для локального виправлення порушення за правилом: `buildVerifyFeedbackPrompt` збирає запит на перевірку вже виявленого фідбеку, а `buildFixPrompt` — запит на виправлення з урахуванням обмеженого контексту й дозволених файлів. `runAgentFix` запускає цей цикл і повертає результат без пробросу помилок назовні: будь-які збої перехоплюються, щоб процес залишався fail-safe.
 
 ## Поведінка
 
-Поточний `violation` стає джерелом правди для стартового fix-пrompt, а `ruleText`, `feedback`, `targetFiles`, `sourceFiles` і `editMode` лише уточнюють межі та контекст правки. `buildFixPrompt` формує жорстко обмежений запит на механічні зміни, щоб агент не розмивав помилку семантичними “виправленнями” поза дозволеними файлами; далі цей prompt передається в ту саму сесію, де виконуються правки, і після цього запускається внутрішня verify-петля.
+Спочатку формується fix-промпт із правилом, порушенням і доступним контекстом редагування; для generic-режиму він жорстко звужує простір змін до дозволених файлів, а для test-generation розділяє read-only джерела й тестові файли. Якщо попередня перевірка вже дала зворотний зв’язок, він додається в той самий промпт як додаткове обмеження. Далі виконується одна агентна спроба виправлення в межах рунга: результатом стає набір торкнутих файлів, телеметрія або помилка, а при фейлі повертається rollback без винесення винятку назовні.
 
-`runAgentFix` оркеструє один рунг від старту до завершення: створює сесію, дає їй prompt для правки, збирає результати редагування, а потім передає контроль у verify-loop. Якщо перевірка повертає порушення, `buildVerifyFeedbackPrompt` перетворює їх на фідбек для тієї ж сесії, щоб ітерація була локальною і не втрачала вже зроблені зміни.
+Після внесення змін запускається verify-петля над тими самими торкнутими файлами. Вона повторює canonical verify у тій самій сесії, а при невдалому результаті передає точний вивід перевірки назад у verify-feedback prompt і продовжує, доки не буде ok, не вичерпається ліміт спроб або не закінчиться спільний таймаут рунга. Якщо сама перевірка падає інфраструктурно, це не маскується під звичайне порушення: петля зупиняється чесною помилкою. Зовнішній consumer лишається джерелом правди про остаточне re-detect, а тут використовується лише рання локальна корекція.
 
-`runVerifyLoop` зупиняється лише коли перевірка стає ok, вичерпується ліміт спроб або закінчується спільний time budget рунга; він не заводить нові таймери й не маскує помилки самої перевірки. Якщо перевірка падає як інфраструктура, це повертається як помилка без спалювання ітерацій. Фінальний результат `runAgentFix` завжди fail-safe: або застосована правка з переліком touched files і telemetry, або контрольована помилка з можливістю rollback.
+Увесь потік працює fail-safe: помилки не пробиваються назовні як винятки, а повертаються у результаті як error. Загальний стан між етапами — це лише дані рунга: ruleId, violation, контекст правил, дозволені файли, feedback, verify-результати та список touchedFiles; жодного прихованого глобального стану в поведінкових гарантіях не використовується.
 
 ## Публічний API
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@7n/llm-lib",
-  "version": "2.9.3",
+  "version": "2.9.4",
   "description": "Тонкий шар роботи з LLM (локальні omlx + хмарні провайдери) поверх pi: model tiers, one-shot, agentic-раннери, write-guard, trace, telemetry, prompt-budget",
   "keywords": [
     "nitra",
@@ -55,8 +55,8 @@
     "access": "public"
   },
   "optionalDependencies": {
-    "@7n/llm-lib-darwin-arm64": "2.9.3",
-    "@7n/llm-lib-linux-x64": "2.9.3"
+    "@7n/llm-lib-darwin-arm64": "2.9.4",
+    "@7n/llm-lib-linux-x64": "2.9.4"
   },
   "peerDependencies": {
     "@earendil-works/pi-ai": "~0.80.10",