같은 세션에서 두 번째 DAG 실행이 시작 시 실패하는 대신 상주 슬롯을 기다립니다. 세션의 모든 실행, 팀 및 task 스포운은 하나의 상주-자식 제한을 공유합니다(task.residency_max_children, 14코어 호스트에서 16). 한 실행의 자식이 모든 슬롯을 점유하면, 두 번째 실행은 residency_denied: resident child cap reached and no task can free a slot 오류로 몇 초 내에 모든 리프 노드를 실패하고, 집계자들은 건너뛰어지며, 종료 상태로 진행시킬 아무것도 없어서 실행은 running 상태로 영구적으로 머물렀습니다(#8396, #8398). 스케줄러는 자체 기록으로 전체 세션을 판단했는데, 나중에 도착한 실행의 기록은 비어있었습니다. 태스크 관리자는 이제 상주 자식이 종료 상태에 도달하거나, 제거되거나, 중단되거나, 마지막 보류 중인 전송을 처리할 때 실행되는 세션 범위 웨이크를 노출합니다. 거부된 노드는 scheduled 상태로 유지되고, 첫 대기는 residency_queued로 한 번 기록되며 몇 개의 상주 자식이 제한을 점유하고 있는지, 몇 개가 다른 소유자에게 속하는지를 기록합니다. 스케줄러는 모든 웨이크에서 재검사합니다. 상주 자식을 명시하지 않는 거부만 노드를 실패시킵니다. 모든 리프가 허용 시점에 실패하는 실행은 이제 failed로 정산되고 종속 항목은 skipped가 되므로, retry가 이에 대해 작동합니다. mass-ulw 용량 모델은 큐가 실행 간에 유지됨을 문서화합니다.
더 좁은 도구 정책을 가진 자식이 이제 부모 JavaScript 도구를 수신할 수 있으며, 자신의 권한으로 범위가 지정됩니다. tools: { write: false }로 스포운된 자식, excludeTools 거부 또는 명시적 허용/거부가 있는 자식은 클로저의 중첩된 tool.<name>() 호출이 부모의 권한으로 실행되었기 때문에 부모 tool(fn)을 tools_unavailable 오류로 거부했습니다. 엔진이 호출 단위 범위를 광고할 때(kernelTools.capabilities.invokeScope, senpi 2026.9.16-3 이상), OmO는 좁혀진 자식에게 허용하고 그 자식 대신 만든 모든 중첩 호출의 범위로 해결된 효과적인 도구 정책을 전송합니다: 실행기가 해당 자식을 위해 설치하는 정확한 허용 목록과 그 리터럴 거부 목록(#8226, #8394). 그 범위 외의 중첩 호출은 워커 내에서 거부되고 입력된 kernel_tool_host_denied 엔벨로프로 자식의 자체 도구-결과 채널에 도착하므로, 자식이 복구할 수 있고 부모의 셀은 이로 인해 실패하지 않습니다. kernel_tools 상태 레코드는 허용이 범위가 지정되었는지 여부를 나타냅니다. 큐레이트된 읽기 전용 에이전트, 팀 멤버, 프로세스 자식 및 비-JavaScript 부모는 변경되지 않습니다.
ulw-loop는 더 이상 원장이 기록한 것 이하로 goals.json을 재구성하지 않습니다. 제거된 omo_agent_toolkit 도구 경로 아래에서 생성된 실행은 하나의 목표로 개정판을 게시할 수 있고, 목표와 증거를 계속 goals.json과 ledger.jsonl에 직접 추가할 수 있었으며, agent-toolkit-sdk가 그 이전 스냅샷에서 프로젝션을 재구성한 첫 번째 시점에 모든 이후 목표, 그 증거 및 감사 항목을 잃었습니다. 이 목표들에 대한 record-evidence와 checkpoint은 ULW_LOOP_GOAL_NOT_FOUND 오류로 실패했습니다(#8328, #8388). 조정은 이제 최신 스냅샷이 없는 목표의 이름을 가진 goals.json이 우위를 점하도록 허용하고, 다음 게시에서 전체 계획을 개정판 N+1로 접으며, 게시된 개정판 이후에 추가된 원장 라인을 해당 개정판에 귀속시킵니다. goals.json의 모든 쓰기는 조정된 원장에 대해 확인됩니다: 계획이 없는 목표는 누락된 ID의 이름을 지정하는 입력된 ULW_LOOP_PROJECTION_TRUNCATED 거부이지, 조용한 자르기가 아닙니다.
세션당 하나의 kibitzer_summary 텔레메트리 이벤트가 메모리 사이드카를 측정합니다. 몇 개의 널지를 제공했는지와 첫 번째 널지가 도착한 웨이크, 웨이크가 토큰 및 벽시간에 드는 비용, 얼마나 자주 중단되는지(널지 간 중앙값 및 p90 간격), 얼마나 많은 웨이크가 쿨다운으로 버퍼링되었거나 말할 새로운 내용이 없었는지(#8389, #8390). 이벤트는 개수, 지속 시간 및 마스킹된 모델 ID만 전달합니다. 널지 경로 및 힌트 텍스트는 절대 텔레메트리에 도달하지 않습니다. 유휴 세션은 아무것도 내보내지 않습니다.
LSP 진단은 더 이상 대기가 등록되기 전에 도착하는 게시를 놓치지 않으며, 경합하는 잠금 대기는 디스크를 계속 두드리지 않습니다. 진단 클라이언트는 서버의 응답이 그 신선도 대기가 설정되기 전의 간격에 도착할 때 빈 목록을 해결할 수 있었습니다. 대기는 이제 해당 게시의 일정에 정렬됩니다. acquireLock은 모든 재시도 틱에서 전체 배타적 게시(생성, 쓰기, fsync, 하드 링크, 제거)를 재시도했으므로, 대기자는 잠금 홀더가 쓰고 있던 볼륨을 초당 약 200개의 fsync된 생성 및 제거 사이클로 겨누었습니다. 이제 잠금 파일을 먼저 읽고 잠금이 자유로울 때만 게시합니다(#8323, #8391). Windows 콘솔 프로브는 모든 호출에서 C# 심을 컴파일하는 대신 bun:ffi를 통해 kernel32를 묻고, 스포운이 많은 두 스크립트는 Windows --parallel 아래에서 기아 상태에 빠져 있었지만, 이제 공유 직렬 격리에서 실행되며 측정이 기록됩니다. 테스트 예산이 인상되지 않았고 어설션이 약화되지 않았습니다.
npm i -g omo-ai@beta