The team lead's runtime is tracked via config.leadSessionId, not as a
spawned runtime process. In the OpenCode adapter path,
buildTeamAgentRuntimeSnapshot creates a synthetic runtime entry for the
lead with alive:false (no CLI child pid) and no livenessKind, which the
getCurrentRuntimeOfflineVisualState function then classifies as
stale_runtime. This causes every team to show the lead as stale-runtime
permanently.
Add a guard in getCurrentRuntimeOfflineVisualState to skip the
stale_runtime classification when the member is the team lead and the
runtime entry carries the 'lead' backend marker.
Wire claude-opus-4-8 (+ [1m] variant) through the team model picker
alongside 4.7 and 4.6, point the opus alias label at 4.8, update the
reasoning/long-context predicates, and switch the fast-mode UI
message to mention 4.8.
Pre-existing regressions из 'cache transcript and telemetry scans':
- pidsMissingUsageStats теперь всегда фильтрует runtimeUsagePids по
отсутствию stats, а не только когда runtimeProcessRowsForSnapshot
null. Пустой/неполный results-row больше не блокирует pidusage
fallback.
- Кэш runtimeProcessTableCache очищается при invalidateRuntime-
SnapshotCaches и не репопулируется in-flight'ом, который начат до
invalidate (через generation token + caller-aware cache context).
- runtimeProcessUsageStatsCacheByPid очищается в invalidate, а в
shared OpenCode host refresh branch'е сбрасывается negative-cache
для конкретного pid'а перед таргетным sample'ом.
Зеленит 25 теста в TeamProvisioningService > getTeamAgentRuntimeSnapshot,
включая 'uses batched pidusage rss values', 'captures CPU and memory
history', 'does not cache live runtime metadata when invalidated while
the probe is in flight', 'shows RSS for OpenCode secondary lane host
pids'.
Collapses the per-member resume scan in getMemberSpawnStatuses into a single
readdir + file lock + pass over the team's tasks. Avoids N x IO when multiple
members become alive at launch. Semantics of the applied-set guard are
preserved 1:1; the single-member API stays as a wrapper around the batch.
readPersistedStatuses каждый раз делал полный sync-scan всех task
JSON под file lock и звал resumeActiveIntervalsForMember для каждого
member с runtimeAlive=true — на больших командах блокировал main
до 8s. Теперь маркируем member как 'resume applied' пока он остаётся
alive, сбрасываем маркер при переходе в not-alive (через
syncMemberTaskActivityForRuntimeTransition и в readPersistedStatuses
loop). Resume остаётся идемпотентным и материализует интервалы из
истории один раз за цикл alive.
Когда снимок liveness возвращает stale_metadata для direct-process
teammate с persisted runtimePid, который реально мёртв — собираем
кандидатов на очистку и сбрасываем их runtimePid/bootstrap-поля
из config.json через двойной чек под guard для запущенных run/launch
state. Это убирает мёртвые pid из последующих snapshot'ов и не
трогает OpenCode/lane-aware/runtime-session-имеющиеся записи.
Дополнительно добавлены targeted-pid liveness check (используется
расширение TeamRuntimeLivenessResolver.targetedProcess) и
shouldUsePersistedLaunchRuntimePidForMetadata, чтобы не подсасывать
устаревший pid в metricsPid для членов с lane-aware конфигурацией.
resolveBootstrapRuntimeEvidenceBoundaryMs учитывает оба источника
времени старта (firstSpawnAcceptedAt и bootstrapExpectedAfter) и
принимает более раннее, если у member и runtime совпадает
bootstrapProofToken + runId. Это лечит случай, когда proof подписан
до того, как app зафиксировал firstSpawnAcceptedAt, но после
bootstrap boundary самого ранкона. Та же логика применена в
isBootstrapMemberEvidenceCurrentForMember для confirmation evidence.
resolveTeamMemberRuntimeLiveness принимает опциональный targetedProcess
с pid + command — если строка процесса проходит team/agent verification,
liveness отмечается как 'runtime_process' даже когда полная process table
не нашла его (например при гонке snapshot vs spawn). Дополнительно для
direct-process backend разрешён fallback по --agent-name, когда команда
запущена без --agent-id.
Распознаём отдельную диагностику для EPERM на создании managed
node_modules symlink под Windows и подсказываем пользователю
запустить приложение от имени Administrator. UI-подсказка и
provisioning hint показываются только для этого случая, обычный
Windows access-denied flow не затрагивается.
