vvzvlad/gitmost

feat(ai-chat): терминальный жизненный цикл ранов — единый гейт, supersede CAS, reconcile (#487) #504

Open

agent_coder wants to merge 10 commits from feat/487-terminal-lifecycle into fix/486-iter1-prod-fires

Author	SHA1	Message	Date
agent_coder	1d704d4ec5	test(mcp): покрыть write-safe-point «после Stop новая запись не стартует» (#487 , F4) paginate-abort-safepoint покрывал только READ-safe-point; WRITE-шов (collaboration.mutatePageContent / context.mutateLiveContentUnlocked — signal?.throwIfAborted() перед session.mutate) был без теста. Добавляю мок-collab юнит через тест-сим __setCollabProviderFactory (фейковый провайдер с мгновенным onSynced): предварительно abort-нутый сигнал → оба шва реджектят ДО session.mutate, трансформ не вызывается; контрольные кейсы (живой сигнал) подтверждают, что session.mutate достижим. MUTATION-VERIFY: снятие throwIfAborted в обоих швах делает красными ровно два abort-кейса, контрольные остаются зелёными. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 07:49:30 +03:00
agent_coder	2cb07ef7fb	test(ai-chat): покрыть оркестраторы reconcile()/reconcileChat() (#487 , F3) Клаузы (a-d) тестировались по отдельности, но сам оркестратор reconcile() (ПОРЯДОК клауз + пер-клаузная try/catch-изоляция «одна упавшая не блокирует остальные») не проверялся, а reconcileChat() (старт каждого хода) не был покрыт вовсе. Добавляю: тест порядка a→b→c→d; тест изоляции (клауза b кидает — c и d всё равно отрабатывают, reconcile не реджектит); тест reconcileChat (скоуп по чату, bound 50, failed→error / прочее→aborted). MUTATION-VERIFY: снятие try/catch у клаузы (b) делает тест изоляции красным (исключение пробрасывается, c+d пропускаются). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 07:49:30 +03:00
agent_coder	9ba97b6d2b	docs(ai-chat): задокументировать наблюдаемую поверхность #487 (F2) - CHANGELOG [Unreleased]: серверный supersede + три кода (SUPERSEDE_INVALID / SUPERSEDE_TARGET_MISMATCH / SUPERSEDE_TIMEOUT) в Added; смена поведения (легаси вторая вкладка теперь → 409 A_RUN_ALREADY_ACTIVE вместо второго параллельного стрима; каждый ход — ран в обоих режимах) в Changed. - .env.example: три новых AI_CHAT_* (SUPERSEDE_TIMEOUT_MS / RECONCILE_INTERVAL_MS / INAPP_TOOL_CALL_CAP_MS, дефолты 10000/120000/120000, связь cap↔staleness). - AGENTS.md:458: ран теперь универсален (оба режима), флаг autonomousRuns = только disconnect-семантика; плюс упоминание supersede. - ai-chat.service.ts:1136: устаревший коммент про «legacy → socket signal» → оба режима на run-signal, guard runId защищает лишь no-handle fallback. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 07:49:14 +03:00
agent_coder	0b9de2c25e	fix(ai-chat): owner-gate stream() до supersede — закрыть утечку чужого runId (#487 , F1) stream() был единственным эндпоинтом ai-chat без assertOwnedChat: участник того же воркспейса (НЕ владелец чата) мог послать POST /stream {chatId:<чужой>, supersede:{runId:<любой>}} и (а) выудить активный runId жертвы из ответа 409 SUPERSEDE_TARGET_MISMATCH, затем (б) requestStop чужого рана. Добавляю owner-check в начале stream() (когда есть body.chatId), ровно как в /stop и соседях — pre-hijack, чистый 403. Это заодно закрывает и негейченную кросс-юзерную запись через тот же stream() (база #500). Тест: не-владелец POST /stream с чужим chatId → ForbiddenException, runId не утёк, supersede/requestStop не вызваны. MUTATION-VERIFY: снятие assertOwnedChat делает тест красным (возвращается путь утечки). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 07:49:02 +03:00
agent_coder	123cba7de1	fix(mcp): убрать залипший маркер конфликта в context.ts (артефакт ребейза) После ребейза в src/client/context.ts:209 остался одиночный маркер `>>>>>>> 917c4064` без парного открытия — он попал в коммит и ломал сборку всего пакета mcp (TS1185 Merge conflict marker), из-за чего не запускались никакие node --test. Код выше маркера цел; удаляю только строку маркера. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 07:48:52 +03:00
agent_coder	001eb1c923	docs(mcp): точный коммент toolAbortSignal — set-and-leave, не restore (#487 , ревью nit) Внутреннее ревью: docstring поля/метода toolAbortSignal утверждал «restores the prior value on unwind», но wrapInAppToolWithCap намеренно НЕ восстанавливает сигнал (set-and-leave) — именно это заставляет брошенного проигравшего race бросить на следующем safe-point; корректность держится на свежем клиенте на ход + перезаписи следующим вызовом. Комментарии приведены в соответствие с механизмом. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 07:26:01 +03:00
agent_coder	002c931c6b	feat(ai-chat): ретраи finalizeAssistant + owner-write приоритет + двусторонний reconcile (#487 ) Раньше finalizeAssistant ставил finalized=true ДО записи и не ретраил → один неудачный UPDATE = строка вечно 'streaming'; свип был boot-only; run-свип безусловный — асимметрия «run succeeded / message streaming навсегда». - finalizeAssistant: bounded-ретраи; once-гейт закрывается ТОЛЬКО после успешной записи; возвращает ok. Правило owner-write: терминальная запись owner'а условна на status='streaming' OR metadata.finalizeFailed (repo.finalizeOwner) — перетирает reconcile-штамп, но не проставленный терминал. ВСЕ status-only штампы reconcile (stampTerminalIfStreaming, sweepStreaming) пишут строго onlyIfStreaming И мёржат metadata.finalizeFailed:true (иначе поздний owner-write не перетрёт). - Порядок: попытка message-finalize → ран финализируется ВСЕГДА; при провале message onFinish помечает ран 'error' (не 'completed'). Ран не гейтится на message. - Периодический reconcile-джоб (setInterval, env-tunable) клаузами по порядку: (a) пере-драйв зомби; (b) message streaming + ран терминален → штамп по статусу рана (succeeded-ран + зависшая строка → 'aborted'+finalizeFailed, НЕ 'completed'-empty); (c) run running + НЕТ entry И НЕТ zombie + staleness → aborted (гейт «нет entry» первичный, staleness от last-progress updatedAt, X=max(2×per-call cap,15мин)+boot-warn); (d) message streaming + возраст>X + нет активной run-строки → aborted (двойной гейт). isInterruptResume исключает finalizeFailed-строки. Оппортунистический одно-чатовый reconcile при старте хода (best-effort, не фейлит ход). sweepStreaming boot-only → периодический. Тесты (реальная БД): owner finalizeOwner чистит finalizeFailed; штамп не перетирает терминал; поздний owner-write перетирает aborted-штамп; клаузы b/c/d (+живой entry не трогать, двойной гейт d); «убить БД на finish → после восстановления ни строка, ни ран не застряли». Юниты: finalizeFailed исключает interrupt-resume; reconcileStaleRuns «нет entry». Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 07:26:01 +03:00
agent_coder	307ad49324	feat(ai-chat): единый гейт конкурентности + серверный supersede (CAS) (#487 ) Раньше в legacy-режиме (дефолт!) гейта конкурентности НЕ было вообще — проверка 409 сидела внутри if (autonomousRuns && chatId): два таба = два параллельных стрима на один чат (интерливинг истории, падения convertToModelMessages). Серверная часть (клиентская лестница ретраев — отдельной клиентской итерацией FSM, см. ниже): - Run-строка ОБЯЗАТЕЛЬНА в ОБОИХ режимах: legacy тоже проходит beginRun/ finalizeRun (гейт партиального уникального индекса + runId в start-метаданных). Различие режимов сведено к семантике abort: legacy onClose при дисконнекте зовёт requestStop(runId) вместо аборта сокет-сигнала (которого streamText уже не потребляет). Второй таб в ЛЮБОМ режиме → 409 A_RUN_ALREADY_ACTIVE. - Supersede CAS POST /stream { supersede: { runId: X } } (AiChatRunService .supersede): валидация X.chatId===body.chatId (иначе 400 SUPERSEDE_INVALID); нет активного рана → degrade в обычный send; активный ≠ X → 409 SUPERSEDE_TARGET_MISMATCH + текущий runId; активный = X → requestStop → awaitSettled (таймаут W=10c) → «записано/сдался» (сдался → settleZombie применяет intended условным UPDATE) → ready; таймаут → 409 SUPERSEDE_TIMEOUT, ничего не персистится. W обоснован race-on-abort'ом коммита 1; DB-brownout → TIMEOUT штатен, W не увеличивать (env-tunable). - Задокументированы ограничения: нет квиесценции сайд-эффектов (в промпт нового рана добавлена строка SUPERSEDE_NOTE «предыдущий ран прерван, его последние операции могли примениться с задержкой»); кража слота между освобождением и beginRun (→ MISMATCH с новым runId, бэкстоп — уникальный индекс). Тесты: два параллельных старта (оба режима) → строго 409 второму; supersede при живом долгом ТУЛЕ (не UPDATE-задержке) settle'ится быстро; все CAS-ветки; дубль supersede-POST → degrade; зомби-путь через settleZombie; HTTP-маппинг ветвей. Кейс «beginRun ok → insert user-msg упал → ран settled, слот свободен» покрыт lifecycle-спекой против реального safety-net catch. КЛИЕНТ (deferred, точно flagged): удаление лестницы SUPERSEDE_RETRY_DELAYS_MS/ isRunAlreadyActive/supersedeRetryRef и переход на supersede-в-body требуют адопции runId из start-метаданных (сейчас клиент runId не трекает вовсе) — это и есть та «итерация клиентского FSM», которую данный серверный контракт разблокирует. Не трогаю фрагильный клиентский FSM без возможности E2E-валидации в браузере, чтобы не внести непроверяемую регрессию. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 07:26:01 +03:00
agent_coder	1031ed1ae8	feat(ai-chat): зомби-механика finalizeRun + settledPromise + условные терминальные UPDATE (#487 ) Раньше give-up-путь finalizeRun ВОССТАНАВЛИВАЛ entry (зомби неотличим от живого рана), а терминальный runRepo.update был БЕЗУСЛОВНЫМ (последний писатель перетирал терминальный статус). - Все терминальные UPDATE ранов теперь УСЛОВНЫЕ: новый repo.finalizeIfActive пишет только пока строка pending\|running (зеркально onlyIfStreaming у сообщений) → двойной settle схлопывается в benign no-op, терминальный статус не перетереть. - При исчерпании ретраев finalizeRun НЕ восстанавливает entry, а оставляет ЗОМБИ-запись { terminalWriteFailed, intended:{status,error} } в отдельной map; settleZombie пере-драйвит intended условным UPDATE (зовётся reconcile/supersede/ boot sweep). Зомби удаляется после успешного UPDATE или обнаружения строки уже терминальной. - Per-run settledPromise в ОТДЕЛЬНОЙ map runId→deferred (переживает active.delete), создаётся в beginRun, резолвится ровно один раз исходом (записано/сдался); поздний подписчик через ранее взятую ссылку получает резолвленный; peekSettled: live deferred → зомби-синтез → undefined (читать строку). Обе map bounded. - Задокументирована потеря (single-process): рестарт до пере-драйва → boot sweep пишет 'aborted' поверх фактического intended — неустранимо в phase 1. Тесты: юниты give-up-пути (зомби вместо restore + notifier terminalWriteFailed + settleZombie), двойного settle, позднего подписчика; интеграционные против реальной Б, что условный finalizeIfActive не перетирает терминал и двойной settle схлопывается. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 07:26:01 +03:00
agent_coder	3b6634c6be	fix(ai-chat): in-app тулы — race-on-abort + safe-points + per-call cap (#487 ) In-app тул-обёртки отбрасывали второй аргумент options с abortSignal — это был единственный класс тулов без отмены и без wall-clock cap. Контент-мутации идут через collab-WS (mutatePageContent), не через axios, поэтому «прокинуть signal в axios» главный write-путь не покрывал. - Переиспользован race-паттерн wrapToolWithCallTimeout: каждый in-app тул гонится против композитного сигнала (Stop + per-call cap); на abort — реджект немедленно, проигравший промис отбрасывается (латентность мс, не сетевой teardown — от этого зависит таймаут supersede в коммите 3). - Safe-point проверки сигнала между последовательными вызовами paginateAll и пре-коммитная проверка в mutatePageContent (+ реентрантный близнец) через DocmostClient.setToolAbortSignal, который обёртка публикует перед каждым вызовом. - Per-call cap покрывает весь вызов, env-tunable (AI_CHAT_INAPP_TOOL_CALL_CAP_MS, дефолт 2 мин). - Задокументировано ограничение (#487): abort между вызовами многовызовного write-тула оставляет частично применённую операцию — отмена гарантирует «новый вызов не стартует», не «запись не доехала». Тесты (честное свойство «после Stop не стартует новый HTTP/WS-вызов»): юнит wrapInAppToolWithCap (реджект-на-abort, отсутствие новых вызовов, per-call cap, публикация сигнала) + mock-HTTP тест реального paginateAll safe-point. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 07:26:01 +03:00