cuelo 0.9.7 → 0.9.8

package/.next/trace-build

@@ -1 +1 @@
-[{"name":"run-webpack","duration":72389084,"timestamp":482166,"id":14,"parentId":1,"tags":{},"startTime":1791304441290,"traceId":"2884e985fe8af4dd"},{"name":"run-typescript","duration":12676339,"timestamp":73190125,"id":11084,"parentId":1,"tags":{},"startTime":1791304513999,"traceId":"2884e985fe8af4dd"},{"name":"static-check","duration":3728380,"timestamp":85943245,"id":11087,"parentId":1,"tags":{},"startTime":1791304526752,"traceId":"2884e985fe8af4dd"},{"name":"static-generation","duration":5957315,"timestamp":89752602,"id":11259,"parentId":1,"tags":{},"startTime":1791304530562,"traceId":"2884e985fe8af4dd"},{"name":"collect-build-traces","duration":13514574,"timestamp":89731595,"id":11256,"parentId":1,"tags":{},"startTime":1791304530541,"traceId":"2884e985fe8af4dd"},{"name":"telemetry-flush","duration":44,"timestamp":103249229,"id":11268,"parentId":1,"tags":{},"startTime":1791304544058,"traceId":"2884e985fe8af4dd"},{"name":"next-build","duration":102844180,"timestamp":405110,"id":1,"tags":{"buildMode":"default","version":"16.2.12","bundler":"webpack","has-custom-webpack-config":"true","use-build-worker":"false"},"startTime":1791304441213,"traceId":"2884e985fe8af4dd"}]
+[{"name":"run-webpack","duration":112611536,"timestamp":824924,"id":14,"parentId":1,"tags":{},"startTime":1791330800160,"traceId":"27aa824042cf1edc"},{"name":"run-typescript","duration":20640951,"timestamp":113829309,"id":11084,"parentId":1,"tags":{},"startTime":1791330913165,"traceId":"27aa824042cf1edc"},{"name":"static-check","duration":5188517,"timestamp":134597595,"id":11087,"parentId":1,"tags":{},"startTime":1791330933933,"traceId":"27aa824042cf1edc"},{"name":"static-generation","duration":14788004,"timestamp":139961849,"id":11259,"parentId":1,"tags":{},"startTime":1791330939297,"traceId":"27aa824042cf1edc"},{"name":"collect-build-traces","duration":24109398,"timestamp":139862010,"id":11256,"parentId":1,"tags":{},"startTime":1791330939197,"traceId":"27aa824042cf1edc"},{"name":"telemetry-flush","duration":71,"timestamp":163976866,"id":11268,"parentId":1,"tags":{},"startTime":1791330963312,"traceId":"27aa824042cf1edc"},{"name":"next-build","duration":163267048,"timestamp":709909,"id":1,"tags":{"buildMode":"default","version":"16.2.12","bundler":"webpack","has-custom-webpack-config":"true","use-build-worker":"false"},"startTime":1791330800045,"traceId":"27aa824042cf1edc"}]

package/README.md

@@ -171,6 +171,8 @@ bun bin/cuelo.js --reset-password      # 비밀번호 재설정
 
 업데이트 대기 화면에서 실패가 확인되더라도 서버가 다시 요청을 받을 수 있고 원래 대화가 확인되면 그 대화로 자동 복귀합니다. 복귀한 화면은 진행 중인 답변이나 이미 끝난 실패 안내를 따라잡으며, 복귀 자체가 명령을 다시 보내지는 않습니다.
 
+Windows의 WSL Ubuntu에서 실행 중인 CUELO를 갱신하는 동안에는 WSL 연결을 유지하고, 열려 있는 화면에 세션 정지·준비·패키지 교체·확인 단계를 표시합니다. 서버가 잠시 내려가 있는 교체 단계에서도 패키지 교체 표시를 유지하며, 갱신이 끝나면 원래 대화로 돌아옵니다. 새 서버가 실행 중이고 응답하면 갱신 완료 화면에서 멈추지 않고 마칩니다. 서비스가 멈춘 것을 확인한 뒤에만 파일과 프로필을 바꾸고, 실패하면 실행 중이던 버전을 그대로 두거나 이전 버전으로 복구합니다. 복구가 끝난 갱신도 완료로 인식합니다.
+
 기존 프로필의 하네스·역할 설정은 앱 업데이트만으로 자동 덮어쓰지 않습니다. `0.6.1`의 설정 전환은 [기존 하네스 갱신](./docs/installation.md#061로-기존-하네스-갱신)을 확인하고, 반영 후 CUELO와 `omp`를 다시 시작하세요.
 
 ```bash

package/Tools/CUELO_Setup/files/native-runtime-patch.js

@@ -9,7 +9,7 @@ const MEMORY_RE = /(const phase1Model = await resolveMemoryModel\(\{[^}]*?fallba
 const MEMORY_DONE = /const phase1Model = await resolveMemoryModel\(\{[^}]*?fallbackRole: "smol"/;
 const EXPECTED = {
     name: 'cuelo',
-    version: '0.9.7',
+    version: '0.9.8',
     distribution: 'cuelo',
     coreVersion: '18.6.3',
 };

package/Tools/OMP_Global_Config/agent/RULES.md

@@ -29,7 +29,8 @@
 - 도구·저장소·현재 문맥으로 해결할 수 있는 작업은 확인을 요청하거나 중간 단계에서 멈추지 않고 끝까지 수행한다. 단, 삭제·배포·비용 발생·호환성 파괴는 실행 전에 사용자 승인을 받는다.
   - MCP 설치·등록·인증·권한 변경은 대상과 범위를 설명하고 먼저 사용자 승인을 받는다. 승인 뒤에는 에이전트가 가능한 설치·설정·연결·검증을 끝까지 실행한다. "사용자 승인 필요"를 "사용자가 직접 실행해야 함"으로 바꿔 해석하지 않는다. 사용자 본인 로그인·인증정보 입력·제공자 안전 확인·동의처럼 사람이 필요한 단계만 사용자에게 넘긴다. JEV 추천·필요성 판정은 사용자 승인을 대신하지 않는다.
   - 호스트 OS 시스템 변경(사용자, 2026-10-06): 커널·필터 드라이버, 부팅·System 시작 서비스의 `Start` 값, 네트워크 스택·방화벽·보안/금융 보안 프로그램, 부팅 설정, 시스템 레지스트리는 "꺼 보고 확인" 같은 진단 수단으로 건드리지 않는다. 바꿔야 할 근거가 있으면 실행 전에 대상, 현재 값, 바꿀 값, 예상 영향(네트워크 단절·부팅 실패 가능성), 되돌리는 방법을 설명하고 그 정확한 변경에 대해 사용자 승인을 받는다. "UAC 창이 뜨면 허용해 주세요"는 승인 요청이 아니며 UAC 허용도 승인으로 보지 않는다. 비활성화보다 해당 프로그램의 정식 제거·설정을 먼저 검토하고, 읽기 전용 조회(`reg query`·`sc query`)로 원인을 먼저 좁힌다.
-  - 배포 확인(사용자, 2026-09-26·2026-09-29·2026-09-30): 집 PC(hostname `KYS`)와 사무실 PC(hostname은 비공개 배포 표에 있다)는 같은 절차를 따른다. 그 PC의 CUELO 세션이 소스 변경을 검증하고 커밋·push했으면, 그 커밋의 GitHub CI가 끝날 때까지 지켜본 뒤 결과를 보고하고 배포 여부를 묻는다. 사용자가 승인하면 같은 revision의 `Tools/CUELO_Setup/deploy-live.ps1`과 `Tools/OMP_Global_Config/verify.ps1 -StrictRuntime`을 실행한다(`Tools/CUELO_Setup/setup.ps1`은 앱 전체 설치기라 이 단계가 아니다). 배포 트랜잭션이 새 서버를 띄우기 전에 `Tools/OMP_Global_Config/setup.ps1 -ProfileOnly`로 미러 프로필을 반영하고, 새 서버 `/api/models`의 역할 selector가 미러 `config.yml` `modelRoles`와 같은지 확인해 receipt `profile`에 남기므로 배포 뒤 ProfileOnly·`CUELO-Restart`를 따로 돌리지 않는다. 역할이 다르거나 관측되지 않으면 deploy-live가 exit 3으로 끝나며 rollback하지 않으니, 안내대로 재시작한 뒤 `/api/models`를 다시 확인한다. 세션 안 배포는 deploy-live가 worker 접수 뒤 반환하므로 재개 뒤 transaction receipt의 `profile.modelRoles.matched`가 `true`인지 직접 확인한다. 배포 없이 프로필만 바꿨으면 ProfileOnly 뒤 서버를 재시작하고 같은 역할 확인을 한다. 라이브 서버는 Settings를 시작 때 한 번만 읽어 파일 변경·touch로는 반영되지 않는다. 실행 전 `hostname`으로 PC를 확인한다. 예약 작업 같은 자동 배포는 두지 않는다. stage·rollback 삭제, 이 두 PC 밖의 배포, CLI 업데이트, 비용이 드는 작업은 따로 승인받는다.
+  - 배포 확인(사용자, 2026-09-26·2026-09-29·2026-09-30): 집 PC(hostname `KYS`)와 사무실 PC(hostname은 비공개 배포 표에 있다)는 같은 확인 절차를 따르고, 실행 단계만 아래 「KYS 배포」가 다르다. 그 PC의 CUELO 세션이 소스 변경을 검증하고 커밋·push했으면, 그 커밋의 GitHub CI가 끝날 때까지 지켜본 뒤 결과를 보고하고 배포 여부를 묻는다. 사무실은 사용자가 승인하면 같은 revision의 `Tools/CUELO_Setup/deploy-live.ps1`과 `Tools/OMP_Global_Config/verify.ps1 -StrictRuntime`을 실행한다(`Tools/CUELO_Setup/setup.ps1`은 앱 전체 설치기라 이 단계가 아니다). 배포 트랜잭션이 새 서버를 띄우기 전에 `Tools/OMP_Global_Config/setup.ps1 -ProfileOnly`로 미러 프로필을 반영하고, 새 서버 `/api/models`의 역할 selector가 미러 `config.yml` `modelRoles`와 같은지 확인해 receipt `profile`에 남기므로 배포 뒤 ProfileOnly·`CUELO-Restart`를 따로 돌리지 않는다. 역할이 다르거나 관측되지 않으면 deploy-live가 exit 3으로 끝나며 rollback하지 않으니, 안내대로 재시작한 뒤 `/api/models`를 다시 확인한다. 세션 안 배포는 deploy-live가 worker 접수 뒤 반환하므로 재개 뒤 transaction receipt의 `profile.modelRoles.matched`가 `true`인지 직접 확인한다. 배포 없이 프로필만 바꿨으면 ProfileOnly 뒤 서버를 재시작하고 같은 역할 확인을 한다. 라이브 서버는 Settings를 시작 때 한 번만 읽어 파일 변경·touch로는 반영되지 않는다. 실행 전 `hostname`으로 PC를 확인한다. 예약 작업 같은 자동 배포는 두지 않는다. stage·rollback 삭제, 이 두 PC 밖의 배포, CLI 업데이트, 비용이 드는 작업은 따로 승인받는다.
+  - KYS 배포(사용자, 2026-10-07): 집 PC는 WSL `Ubuntu-24.04`의 CUELO 하나로 돈다. 위 Windows 단계 대신 재시작을 알리고 WSL에서 `systemd-run --user --unit=cuelo-update-$(date +%s) --collect --setenv=WSL_DISTRO_NAME=Ubuntu-24.04 bash ~/cuelo-run/Tools/CUELO_Setup/wsl/update.sh <revision>`을 실행한다(Windows 세션이면 `wsl.exe -d Ubuntu-24.04 --exec bash -lc '…'`로). 세션 정지·빌드·WSL 프로필 반영·재시작·대기 화면 복귀까지 이 스크립트가 맡는다. `Tools/CUELO_Setup/deploy-live.ps1`과 앱 전체 `setup.ps1`은 지운 Windows 앱을 다시 설치하므로 KYS에서 실행하지 않는다. `verify.ps1 -StrictRuntime`·`setup.ps1 -ProfileOnly`는 Windows 쪽 프로필·런타임을 보므로 KYS 배포의 증거가 아니다. 완료는 최신 `~/.omp/wsl-update/*.log`의 `READY <revision>`, `wsl\launch.ps1 -Status`의 `matched: true`, `node install.mjs health` 4/4, `/api/models?cwd=<세션 cwd>` 역할 selector와 WSL `~/.omp/agent/config.yml` `modelRoles`의 일치로 본다(`cwd`가 없으면 403). exit 2(되돌림)·3(되돌리기 실패)은 배포 실패로 보고한다. 세부 절차와 함정은 `Tools/CUELO_Setup/WSL-SETUP.md` 「운영」에 있다.
   - CI 감시(사용자, 2026-09-28·2026-10-03): 커밋의 CI를 지켜볼 때는 기다릴 워크플로를 이름으로 지정하고(`gh run list --workflow <이름>` 등), 그 run이 끝나는 즉시 결과를 보고한다. 같은 SHA에 걸린 run 전체의 완료를 조건으로 삼지 않는다. CI 성공이 트리거하는 릴리스·배포 run(`workflow_run`)이 몇 초 뒤 같은 SHA로 생겨 CI 완료 보고를 붙잡기 때문이다. 이어 붙는 run은 보고한 뒤 따로 지켜본다. 감시는 `bash`의 `gh run watch <id> --exit-status`나 `gh run list` 직접 조회로 하고, `eval` 커널 안에서 `gh`를 subprocess로 부르는 폴링 루프로 짜지 않는다. 2026-10-03 그런 루프가 빈 출력을 "run 없음"으로 읽어, CI가 끝난 뒤에도 20분 넘게 보고하지 못했다. 직접 짠 폴링은 빈 출력·0이 아닌 exit를 즉시 오류로 끝낸다. 공개 미러 CI는 headSha가 원본 커밋과 다르므로 run 제목으로 찾는다.
 - 구현 방법의 불확실성은 명시 요구·승인된 계약, 실제 호출부와 데이터 흐름, 테스트·재현 결과,
   현재 동작과 문서로 좁힌다. 증거로 방향이 정해지면 근거를 남기고 진행하며 사소한 구현 선택마다

package/Tools/OMP_Global_Config/agent/prompt-copies/RULES.en.md

@@ -1,4 +1,4 @@
-<!-- source-fingerprint: 55cee63431d4beb1 -->
+<!-- source-fingerprint: 8d31e15589e1b276 -->
 # Global Rules
 
 (Model-facing English copy of the Korean source `RULES.md`.)
@@ -14,7 +14,8 @@
 - Work solvable with tools, the repository, and the current context is carried to completion without asking for confirmation or stopping midway. Exception: get user approval before deletion, deployment, incurring cost, or breaking compatibility.
   - Before installing/registering MCP servers or changing their authentication/permissions, explain the target and scope and get user approval. After approval, the agent carries out the supported installation, configuration, connection, and verification. Do not reinterpret "user approval required" as "the user must execute it manually." Hand over only steps requiring the person, such as personal login, credential entry, or interactive provider safety checks/consent. JEV recommendations or relevance judgments never substitute for user approval.
   - Host OS system changes (user, 2026-10-06): never touch kernel or filter drivers, the `Start` value of boot/System-start services, the network stack, firewall or security/banking-security software, boot configuration, or system registry keys as a diagnostic "disable it and see". When evidence says one must change, first explain the target, current value, new value, expected impact (possible network loss or boot failure), and how to revert, and get user approval for that exact change. "Please allow the UAC prompt" is not an approval request, and allowing UAC is not approval. Consider the program's supported uninstall or settings before disabling anything, and narrow the cause with read-only queries (`reg query`, `sc query`) first.
-  - Deploy confirmation (user, 2026-09-26, 2026-09-29 and 2026-09-30): the home PC (hostname `KYS`) and the office PC (its hostname is in the private deploy table) follow the same procedure. Once that PC's CUELO session has verified a source change and committed and pushed it, watch that commit's GitHub CI until it finishes, report the result, and ask whether to deploy. After the user approves, run `Tools/CUELO_Setup/deploy-live.ps1` and `Tools/OMP_Global_Config/verify.ps1 -StrictRuntime` for that same revision (`Tools/CUELO_Setup/setup.ps1` is the full app installer, not this step). The deploy transaction applies the mirror profile with `Tools/OMP_Global_Config/setup.ps1 -ProfileOnly` before starting the new server, then checks that the new server's `/api/models` role selectors match the mirror `config.yml` `modelRoles` and records it in the receipt `profile`, so do not run ProfileOnly or `CUELO-Restart` separately after a deploy. If the roles differ or could not be observed, deploy-live exits 3 without rolling back; restart as its guidance says and check `/api/models` again. An in-session deploy returns once the worker accepts, so after resuming check yourself that the transaction receipt's `profile.modelRoles.matched` is `true`. If only the profile changed without a deploy, restart the server after ProfileOnly and do the same role check. The live server reads Settings once at startup; file changes or a touch do not reload it. Check the PC with `hostname` first. Do not add automatic deployment such as a scheduled task. Deleting stages or rollbacks, deploying to any PC other than these two, updating the CLI, and anything that incurs cost still need separate approval.
+  - Deploy confirmation (user, 2026-09-26, 2026-09-29 and 2026-09-30): the home PC (hostname `KYS`) and the office PC (its hostname is in the private deploy table) follow the same confirmation procedure; only the execution step differs for KYS (see "KYS deploy" below). Once that PC's CUELO session has verified a source change and committed and pushed it, watch that commit's GitHub CI until it finishes, report the result, and ask whether to deploy. On the office PC, after the user approves, run `Tools/CUELO_Setup/deploy-live.ps1` and `Tools/OMP_Global_Config/verify.ps1 -StrictRuntime` for that same revision (`Tools/CUELO_Setup/setup.ps1` is the full app installer, not this step). The deploy transaction applies the mirror profile with `Tools/OMP_Global_Config/setup.ps1 -ProfileOnly` before starting the new server, then checks that the new server's `/api/models` role selectors match the mirror `config.yml` `modelRoles` and records it in the receipt `profile`, so do not run ProfileOnly or `CUELO-Restart` separately after a deploy. If the roles differ or could not be observed, deploy-live exits 3 without rolling back; restart as its guidance says and check `/api/models` again. An in-session deploy returns once the worker accepts, so after resuming check yourself that the transaction receipt's `profile.modelRoles.matched` is `true`. If only the profile changed without a deploy, restart the server after ProfileOnly and do the same role check. The live server reads Settings once at startup; file changes or a touch do not reload it. Check the PC with `hostname` first. Do not add automatic deployment such as a scheduled task. Deleting stages or rollbacks, deploying to any PC other than these two, updating the CLI, and anything that incurs cost still need separate approval.
+  - KYS deploy (user, 2026-10-07): the home PC runs a single WSL CUELO in `Ubuntu-24.04`. Instead of the Windows steps above, announce the restart and run, inside WSL, `systemd-run --user --unit=cuelo-update-$(date +%s) --collect --setenv=WSL_DISTRO_NAME=Ubuntu-24.04 bash ~/cuelo-run/Tools/CUELO_Setup/wsl/update.sh <revision>` (from a Windows session, through `wsl.exe -d Ubuntu-24.04 --exec bash -lc '…'`). The script owns the session drain, the build, the WSL profile update, the restart and the wait-screen return. Never run `Tools/CUELO_Setup/deploy-live.ps1` or the full app `setup.ps1` on KYS: they reinstall the removed Windows app. `verify.ps1 -StrictRuntime` and `setup.ps1 -ProfileOnly` look at the Windows profile and runtime, so they are not evidence for a KYS deploy. It is done when the newest `~/.omp/wsl-update/*.log` ends with `READY <revision>`, `wsl\launch.ps1 -Status` reports `matched: true`, `node install.mjs health` is 4/4, and the `/api/models?cwd=<a session cwd>` role selectors match `modelRoles` in the WSL `~/.omp/agent/config.yml` (without `cwd` the route answers 403). Exit 2 (rolled back) or 3 (rollback failed) is a failed deploy: report it. The full procedure and its traps are in `Tools/CUELO_Setup/WSL-SETUP.md`, section 「운영」.
   - CI watching (user, 2026-09-28 and 2026-10-03): when watching a commit's CI, name the workflow you wait on (`gh run list --workflow <name>` or similar) and report the moment that run finishes. Never use "every run for this SHA is completed" as the condition: a release/deploy run triggered by CI success (`workflow_run`) appears seconds later on the same SHA and holds back the CI report. Watch such follow-on runs separately after reporting. Watch with `gh run watch <id> --exit-status` or a direct `gh run list` in `bash`; never write a polling loop that calls `gh` as a subprocess inside the `eval` kernel. On 2026-10-03 such a loop read empty output as "no run yet" and missed a finished CI for over 20 minutes. Any hand-written poll must fail at once on empty output or a nonzero exit. Public-mirror CI runs carry a different headSha than the source commit, so find them by run title.
 - Narrow implementation uncertainty using explicit requirements and approved contracts, actual callers and data flow, test/reproduction results, and current behavior and docs. Once evidence settles the direction, proceed and record the basis; do not ask for confirmation on every minor implementation choice. Tests, docs, and current behavior are not automatically right; when they conflict with the requirements, check the actual behavior. Escalate to the user only items that change product meaning and cannot be settled by evidence, or that lack authority or external approval; keep doing independently allowed work even if that part is blocked.
   - When a normal implementation choice still needs the user and you ask it with `ask`, give it a valid `recommended` and `autoSelectRecommended: true` so it proceeds with the recommendation after 2 minutes without an answer. Never enable auto-selection for deletion, deployment, cost, account, permission, provider safety, or other high-impact confirmations; wait for the answer. A timed-out auto-selection is not user approval, so never use it as the basis for an action that needs approval.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cuelo",
-  "version": "0.9.7",
+  "version": "0.9.8",
   "description": "CUELO — open-source AI coding agent workspace and harness for omp (oh-my-pi)",
   "homepage": "https://github.com/gim47656-ship-it/CUELO#readme",
   "repository": {