cuelo 0.5.0

package/Tools/OMP_Global_Config/agent/rules/task-guard.md

@@ -0,0 +1,54 @@
+---
+description: Main 전용 — task를 실제로 발주하기 직전에 `rule://task-guard`(skill 아님)로 읽는다. 브리프의 TASK_GUARD 블록을 받은 Maker는 읽지 않는다. TASK_GUARD 양식·요청당 budget·side quest 제한(런타임 task guard가 검사하는 계약).
+---
+
+# Task Guard
+
+각 task **원문**의 첫 블록에 아래 `TASK_GUARD`와 그 밖의 공유 메타데이터를 함께 넣는다.
+이 양식은 `maker_route`에 저장하는 원문에도 적용된다. 실제 `task` 호출에 준비 참조를 쓰면
+기존 guard 전에 원문이 복원되므로 같은 본문을 다시 작성하지 않는다. 참조 문법은
+`rule://subagent`의 「발주 시점 추론 선택」을 따른다.
+
+```text
+TASK_GUARD:
+WORK_CLASS: feature|maintenance|diagnostic   # 그 요청의 첫 child에서만 필수
+PURPOSE: primary|rework                     # 생략 가능. 런타임이 파생한다
+BLOCKS_PRIMARY: yes|no                       # 생략 가능. 기본 yes
+PRIMARY_DELIVERABLE: <이번 사용자 요청의 실제 완료물 한 줄>   # 첫 child에서만 필수
+OWNED_PATHS: <maker의 소유 경로를 콤마로 나열>   # 필수, 파생 불가
+FINDING_ID: <rework일 때만 기존 finding id>
+TASK_TITLE: <이 조각의 업무 한 줄 — 한국어>
+TODO_TASKS: ["<현재 Main TODO의 정확한 문자열>", "…"]
+```
+
+- **`TASK_GUARD:` 바로 뒤에 정본 필드가 연속되는 구간이 guard 블록이다.** 필드 일부는 생략·상속될
+  수 있으므로 줄 수는 고정이 아니고, 연속이 끊기는 줄부터는 guard 블록이 아니다. `TASK_TITLE`·`TODO_TASKS`는 그 구간 **밖**의 공유 메타데이터이고 guard 필드가 아니다 — 빈 줄 없이 이어 써도 런타임은 블록 밖으로 읽는다. 이 둘은 `TASK_GUARD` 필드로 만들지 않고 `task` API의 새 인자로도 만들지 않는다. 위치가 뒤바뀌어 guard 필드 사이에 끼면 그 뒤 guard 필드가 블록에서 잘리므로 반드시 마지막 guard 필드 **뒤**에 적는다.
+- `TASK_TITLE`은 **조각마다 다른 그 조각의 stable 업무 정체성**이다. 앞뒤 공백 없는 한 줄 한국어여야 하고 본문에 정확히 한 번만 나와야 한다. subagent 카드 제목이 이 값이고, follow-up `write agent://<id>` 메시지의 진행 단계(마지막 의도·현재 도구)가 이 값을 덮지 않는다. 없으면 카드는 업무 미확인으로 표시된다.
+- `TODO_TASKS`는 **현재 Main TODO 항목의 exact 문자열** JSON 배열이다. 비어 있지 않은 고유 문자열이어야 하고 trim·유사도 정규화 없이 그대로 비교되므로 Main이 실제로 가진 문자열을 그대로 쓴다. 두 메타 중 하나라도 있으면 런타임이 TODO 진행 관측을 시작한다.
+- `TASK_GUARD` **안에서** Main이 직접 판단해야 하는 값만 적는다. **무엇을 만드는가**(`WORK_CLASS`·`PRIMARY_DELIVERABLE`)와 **어디까지 고치는가**(`OWNED_PATHS`)가 그것이고, 나머지는 런타임이 승인된 값에서 조립한다. 한 요청의 첫 child가 앞의 둘로 lock을 세우면 그 다음 child부터는 `OWNED_PATHS`(와 rework면 `FINDING_ID`)만 적어도 된다. 생략한 `WORK_CLASS`·`PRIMARY_DELIVERABLE`은 lock 값으로 채워지고, `PURPOSE`는 `FINDING_ID` 유무에서(`FINDING_ID` 있으면 `rework`, 그 밖엔 `primary`) 파생되며, `BLOCKS_PRIMARY`는 `yes`로 채워진다. 조립이 일어난 항목은 런타임이 그 브리프의 `TASK_GUARD` 블록을 실제 적용된 값으로 다시 써서 실행하므로 child와 기록이 같은 계약을 본다.
+- 비어 있는 것과 잘못 적은 것은 다르다. 생략은 조립되지만 enum 밖의 값(`WORK_CLASS: feat` 같은)은 거부된다. 허용 child는 `maker`뿐이다. lock과 다른 `WORK_CLASS`·`PRIMARY_DELIVERABLE`, `BLOCKS_PRIMARY:no`, `OWNED_PATHS` 누락, `FINDING_ID` 없는 rework도 거부된다.
+- `feature`의 `PRIMARY_DELIVERABLE`은 테스트 개수나 내부 정리가 아니라 사용자가 실제로 쓸 수 있게 되는 동작·화면으로 적는다.
+- child는 현재 `PRIMARY_DELIVERABLE`을 직접 진전시키거나 완료를 막는 일에만 쓴다. 아니면 `BLOCKS_PRIMARY:no`로 기록하고 backlog로 넘기며 spawn하지 않는다.
+- 첫 child의 `WORK_CLASS`와 `PRIMARY_DELIVERABLE`은 그 사용자 요청 동안 고정한다. 관측·오탐·증거 복구를 이유로 다른 완료물로 바꾸지 않는다. 사용자가 실행 중인 턴에 방향을 바꾸면 runtime이 그 redirect를 보고 lock만 해제하므로 새 완료물로 다시 고정해 발주한다. 누적 budget은 그대로 유지된다.
+- runtime hard budget은 사용자 입력당 `primary Maker 16`, `rework Maker 8`, `총 child 24`이다. `task.maxConcurrency:8`의 동시 실행 슬롯과 다른 누적 cap이다. 한도가 남았다는 이유로 불필요한 child를 만들거나 역할 별칭·side quest로 우회하지 않는다.
+- Maker 수는 Main이 판단해 정한다. 한도는 천장이지 목표가 아니고 남은 자리는 발주 근거가 아니다. 위치와 수정 범위가 명확한 작은 작업은 Main 단독, 조사부터 구현까지 한 흐름인 작업은 Maker 1명, 서로 기다릴 필요가 없는 충분히 큰 조각이 여러 개면 동시 실행 상한까지 Maker를 병렬로 돌린다. 2명으로 좁히지 않는다. `task.maxConcurrency` = 8은 Maker 합산 child 슬롯 수이고 Main 레인은 여기에 포함되지 않는다. 같은 요청에서 두 번째 이후 primary Maker를 발주할 때는 각 child의 소유 경로가 겹치지 않는지, 서로의 산출물을 기다리지 않는지, 따로 실행해야 하는 이유가 무엇인지를 Main이 확인해 브리프에 적는다. `프론트/백엔드`처럼 범주가 다르다는 것만으로는 분리 근거가 아니다.
+- 각 새 발주·재발주 **직전** `maker_route`로 `routing.typedJudgmentRouting`의 `pre-dispatch`
+  질문을 한 번에 판정한다. 동일 브리프에 수동 `judge()`를 중복 호출하지 않는다. 확률형 bool은
+  `>= 0.5`일 때 true로 적용한다. 준비와 발주는 session-local `name`과 `TASK_GUARD` 의미 필드
+  (`WORK_CLASS`·`PRIMARY_DELIVERABLE`·`OWNED_PATHS`·`FINDING_ID`)로 연결되므로 산문·`context`
+  표현 차이는 허용되고, 이름이나 의미 필드가 바뀌면 다시 준비한다. `duplicate`·
+  `additionalInstruction`이 true이고 **`ownerTarget`이 실재 owner를 가리킬 때만** 그 owner에게
+  추가 지시·retarget하고 새 spawn을 금지한다 — 확률만으로 owner를 고르지 않는다. 어느 쪽도
+  아니면 단일 `maker`에 Main이 결정한 `model:"provider/model:concrete-effort"`를 넘기며 coarse `effort`는 생략한다. 판정이 가리키는 owner가 실제로
+  없거나 결정론 증거와 모순되면 그 placement 결과를 적용하지 않고 기존 절차로 간다. 실패·timeout·
+  credential 없음도 판단 불가로 두고 일반 모델 fallback 없이 기존 절차를 실행한다.
+  이 session에서 성공한 spawn으로 식별된 Maker(완료·parked 포함)에게 `write agent://<id>`로 자연어 지시를
+  보내는 경계는 `pre-dispatch-existing-owner-message`로 런타임이 advisory를 낸다(그 전송을 차단하지
+  않는다). 실질 변경·정보 부족이면 정식 `maker_route`를 다시 부른다. Task Guard의
+  lock·budget·소유 경로·`FINDING_ID`와 사용자 요구 대조는 언제나 결정론 정본이며 judgment가
+  대신하지 않는다.
+- budget은 성공 수가 아니라 발주 수로 센다. 잘못 발주해 `write proc://<id>/kill`로 되돌린 child는 runtime이 취소를 확인한 만큼 요청당 `8` 슬롯까지만 환불해 full cancelled wave 한 번을 복구하되 반복 spawn→cancel 우회는 막는다. 환불받으려면 spawn 때 `tasks[].name`을 명시해야 하고, 이름 없는 spawn과 이미 끝난 child는 환불 대상이 아니다. 브리프 방향이 정해지기 전에는 발주하지 않는다.
+- `rework`는 기존 finding의 delta 수정용이며 `FINDING_ID`가 필수다. 새 조사나 새 기능을 rework로 포장하지 않는다.
+- **이 가드는 lock 일치·`WORK_CLASS` enum·소유 경로·`FINDING_ID`·budget만 검사한다. 그 과제가 사용자 요구와 맞는지는 검사하지 않는다.** 즉 Main이 요구를 잘못 해석해도 가드는 통과하고 Maker는 그 발주를 충실히 구현한다. 그 빈틈은 Main의 발주 전 3항목 대조(`harness-policy.json` `briefContextRelay.preDispatchCrossCheck`: 요구 누락·확인하지 않은 단정·임의 변경)와 Maker의 첫 조사 대조(`routing.dispatchAssumptionCheck`)가 메운다. `PRIMARY_DELIVERABLE`은 Main이 정한 완료물이고 사용자 요구의 사본이 아니므로, 그 둘이 어긋나면 lock을 지키는 것이 아니라 발주를 고친다.
+- `OWNED_PATHS`는 모든 maker(primary·rework)에 필수다. 세션 cwd 기준 상대경로를 `/`로 적고, 후행 `/`는 디렉터리 prefix, 없으면 정확한 파일, `.`은 cwd 전체다. 선행 `./`는 무시되고 절대경로·cwd 밖 `..`는 거부된다. 완료 시 runtime이 `[OwnershipGuard] child=… owned=… outside=… concurrent=…`로 소유 경로 밖 변경을 알린다. `outside=none`은 없음, `unobserved`는 git 관측 불가다. ignored 파일·저장소 밖·submodule 내부는 관측하지 못한다. advisory이므로 `outside≠none`이면 Main이 동시 writer·허용 경계와 대조해 판단한다.
+- child와 별도 모델 호출은 Main의 `task` 경로로만 보낸다. `eval`의 `agent()`·`completion()`·`workpool()`·`tool.task()`로 budget을 우회하지 않는다. runtime도 이 경로를 차단하며 일반 계산·파일 처리·browser 관측용 `eval`은 그대로 허용한다.

package/Tools/OMP_Global_Config/agent/rules/verdict.md

@@ -0,0 +1,183 @@
+---
+description: 여러 파일·모듈의 착수 계약과 완료 판정, 작업·모델·에이전트 효율 분석의 증거와 비교 기준을 정할 때 읽는다.
+---
+
+# 착수 계약과 최종 판정
+
+## 착수 전에 확정할 것
+
+- 최종 목표와 산출물, 완료 조건과 필요한 증거.
+- 확정된 설계·인터페이스·제약과 보존해야 할 기존 동작.
+- 검증되지 않았지만 진행에 사용하는 가정, 데이터·보안·호환성·배포·회귀 위험, 사용자 승인이 필요한 항목.
+- 완료 조건은 **관측 경로가 실재하는 것만** 쓴다. 통과 경로가 없는 조건은 조건이 아니라 미확인
+  항목이고, 그런 조건을 기대치·채점표에 넣으면 영구 실패만 만든다. 새 계약을 정본에 단정으로
+  쓰기 전에 그것을 소비하는 경로(도구 스키마·설정 키·코드)를 증거로 확인한다.
+- 모호성은 먼저 증거로 좁힌다. 명시 요구·승인된 계약, 실제 호출부와 데이터 흐름, 테스트·재현
+  결과, 현재 동작과 문서로 방향이 정해지면 근거를 남기고 진행한다. 테스트·문서·현재 동작 중
+  어느 하나도 자동으로 정답이 아니며 요구와 충돌하면 실제 동작을 확인한다. 결과의 제품 의미를
+  바꾸는데 증거로 정할 수 없거나 권한·외부 승인이 없는 항목만 사용자 판단으로 올리고, 그 부분이
+  막혀도 독립적으로 허용된 작업은 계속 수행한다.
+
+## 증거
+
+- 최소 증거는 변경 파일, 핵심 변경, 실행한 검증 명령과 결과, 계획과의 차이, 남은 위험과 미검증 조건이다.
+- 수용 조건이 둘 이상이면 증거를 **조건별로 연결**한다. 조건마다 충족(확인한 동작 + 원문 증거
+  위치)이나 미확인(막힌 이유 + 필요한 확인)을 revision과 함께 남긴다. "테스트 통과"는 조건 하나의
+  증거일 수 있어도 조건 전체의 증거가 아니다. 최종 수용에서 Main이 빠진 조건을 확인한다.
+- 하위 에이전트 보고가 부족하면 전체를 다시 시키지 말고 빠진 증거만 요청한다.
+- 위임한 조각의 Maker는 source·contract·caller 증거와 자기 검증의 exact command·cwd·exit
+  status·관측·raw artifact locator·재사용 근거·미검증 조건을 함께 제공한다. 위임한 조각에서
+  Main은 조립·한정된 확인·finding 판단·최종 수용을 맡고, 그 조각의 집중 검사를 같은 환경·같은
+  조건으로 반복해 확인하지 않는다(공통 격리 환경과 필요한 전체 빌드·통합·수용 검사는 Main이
+  실행한다). `routine`은 Main이 직접 구현하고 검증해 같은 증거를 스스로 남긴다.
+- 검수는 Main이 소유한다. Main은 owner의 불변 raw artifact와 locator를 검수 대상으로 쓰고,
+  owner의 집중 검사를 같은 환경·조건에서 반복하지 않는다. 공통 격리 환경과 필요한 전체
+  빌드·통합·수용 검사는 Main이 frozen revision에서 실행하며, 검사가 도는 동안 그 revision을
+  수정하지 않는다. 아직 실행 중인 필수 검사는 gap이 아니라 pending으로 남기고 그 revision을
+  PASS로 닫지 않는다. 검수 주체를 다른 역할이나 다른 세션으로 넘기지 않는다. 절차는
+  `rule://subagent`의 「검수와 수용」이 정본이다.
+
+`large` 분해 트리거와 검수 트리거는 다르다. public/shared interface, cross-module contract,
+shared state, data flow, complex state transition, 여러 조각이 한 실행 경로로 합류, meaningful
+existing-caller regression risk, auth/authz/secret review, Main이 제공 증거로 닫을 수 없는 경우 중
+하나가 있으면 `integration-risk`이고 Main이 그 delta를 검수한다. 나머지 `independent-only`
+large에는 별도 검수를 요구하지 않는다. material/high-risk는 모든 관련 owner 수렴 → Main 검수의
+직렬 계약을 유지한다.
+
+## 검수와 최종 판정
+
+검수는 Main이 중간과 최종 두 단계로 소유한다. 아래는 Main이 검수할 때 적용하는 기준이다.
+
+Maker 보고를 받은 뒤 Main 검수에 들어가기 직전의 `pre-review`는 런타임(`jev-runtime`)이 로컬 구조 관측으로
+처리한다(`harness-policy.json` `routing.typedJudgmentRouting.batching`·`observation.localStructuralPlacements`).
+metadata 유효성·검증 증거 존재·권한 충돌 같은 셀 수 있는 신호만 `[JevRuntime:pre-review]` advisory로 싣고
+`judge()`를 호출하지 않는다. Main도 같은 보고에 수동 `judge()`를 따로 부르지 않는다. 요구-증거 정합,
+미확인 수용 조건, 증거를 넘는 보고 주장은 advisory가 판정하지 않는 의미 판단이므로 아래 결정론적
+검수에서 Main이 원본 증거로 직접 확인한다. 관측할 수 없는 의미는 unknown으로 두고 개수나 키워드로
+추정하지 않는다. exit status·파일·경로 소유권·권한·test result·배포 승인은 결정론 증거가 정본이고,
+high-risk 분류·승인과 최종 판정은 Main만 소유한다.
+
+- **증거 요구사항.** 판정 전에 검수 대상과 계약, 변경 경로, 최종 Diff, 영향 경계, raw 출력이
+  있는 검증 증거, 알려진 미검증 항목을 갖춘다. `TARGET`·`CHANGED PATHS`·`FINAL DIFF`·
+  `IMPACT BOUNDARY`·`VALIDATION EVIDENCE`·`KNOWN UNVERIFIED` 여섯 이름과 그 순서는 권장 형식이지
+  합격 조건이 아니다. 경로·`artifact://`·`agent://`·이미 받은 원문 tool 출력처럼 **닿을 수 있는
+  원본 artifact가 그 사실을 공급**하며 packet에 다시 붙여넣으라고 요구하지 않는다. 실질적인
+  결손만 판정을 막는다.
+- `FINAL DIFF`는 삭제를 포함한 frozen raw before/after 또는 그것을 가리키는 불변 참조여야 한다.
+  현재 파일, 요약, 가변 `HEAD` 이름은 Diff를 대체하지 못한다. `VALIDATION EVIDENCE`에는 검사마다
+  exact command·exit status·닿을 수 있는 raw 출력 artifact나 locator가 들어간다. `CHANGED PATHS`의
+  분류와 impact-bearing caller index는 점검을 안내할 뿐 정확성을 세우지 못한다.
+- **비교 기준선은 Main의 지시가 아니라 사용자 요구와 브리프에 실린 수용 조건이다.** 지시를 완벽히
+  구현했는데 수용 조건이 미충족이면 PASS가 아니라 요구 누락 finding이다. packet에 요구나 수용
+  조건 자체가 없으면 지시에서 추론하지 말고 그 부재를 gap으로 보고한다. 수용 조건별 증거 연결도
+  실제 Diff와 대조해 조건마다 충족-증거 또는 미확인-사유가 있는지 보고, 없으면 실질 gap으로 본다.
+- 영향받는 caller만 추적한다. public/shared contract, shared state, data flow, 호환성,
+  material-risk 동작을 건드리면 그 caller를 본다. 요구 누락, 논리 결함, 회귀, 경계값, 데이터 손실
+  위험, 불필요한 변경, 테스트 공백을 확인하고, 구체적인 모순이나 의심스러운 주장이 있을 때만 표적
+  점검으로 범위를 넓힌다.
+- **material-risk는 기술명이 아니라 consequence다.** `harness-policy.json`
+  `routing.high-risk.materialRiskDefinition`으로 판정한다: 되돌릴 수 없는 데이터·설정·스키마 변경,
+  시스템 밖으로 나가는 결과(배포·결제·실제 장치·출력·외부 전송), 제품 의미를 결정하는 계산·판정,
+  기존 소비자·데이터·API 계약 파괴, 물리 안전이 걸린 출력. VB6/COM/OCX, 32-bit·XP 대상, 모니터링,
+  protocol 처리, timeout·retry·reconnect, 단순 전달은 그 자체로 올리지 않는다. 실행 환경이 아니라
+  **수정한 코드의 성질**이 분류하며, 그 분류는 도메인 중립이다 — `irreversible-state-change`·
+  `external-side-effect`·`correctness-defines-product-meaning`·`state-machine-transition`·
+  `trust-boundary`·`compatibility-break`·`artifact-representation`에 걸리면 fixture·mock·평가용이어도
+  high-risk다. 단 `trust-boundary`는 감시만 붙이고 auth·authz·secret 자체는 integration-risk
+  검수로 남는다. 프로젝트별 구체 목록은 그 프로젝트 저장소의 `AGENTS.md`가 이 분류에 사상한다
+  (`materialRiskDefinition.projectOverlay`).
+- **finding 우선순위는 실제 결함과 안전 영향으로 정한다.** 범위 밖 정리, 동작 영향 없는 잔여물,
+  이름·문구, 스타일·API 형태 선호는 차단 사유가 아니다. 비차단으로 한 번만 적고 그것 때문에 PASS를
+  보류하거나 새 검수 회차를 열지 않는다.
+- **재검수 규칙.** 반증이나 그 finding을 건드린 변경 없이 이미 닫힌 finding을 다시 열지 않고, 새로
+  발견한 실제 결함은 닫힌 finding에 접지 않고 새 finding으로 보고한다. 같은 finding이 미해결로
+  돌아오면 기존 증거가 무엇을 지지하는지 밝힌다 — 요구가 모순인지, 검수 판정이 틀렸는지, 구현이
+  틀렸는지, 증거가 없는지 — 그리고 그 근거로 판단한다. 무효화되지 않은 delta·증거는 새 의심 근거
+  없이 재검수하지 않는다.
+- 동일 revision에서 확인 가능한 지적은 변경·영향 계약·증거를 한정된 범위에서 본 뒤 한 묶음으로
+  전달한다. 같은 변경에 뒤늦게 지적을 더한 왕복은 Main의 검수 분할 문제이지 Maker 실패 횟수로
+  세지 않는다. 새 증거와 실제 반복 오류는 구분하며 R번호만으로 owner를 바꾸지 않는다. 인수가
+  필요하면 기존 writer를 정지하고 변경·job·검증 증거를 회수해 소유권 이전을 명시한 뒤 진행한다.
+
+Main은 근거가 있는 finding을 각각 다음 중 하나로 닫는다.
+
+- `ACCEPTED`: 담당 `maker`가 수정하고 영향받은 검증 증거를 갱신했으며 필요한 delta 검토까지
+  끝났다. 변경 없는 범위의 증거는 재사용한다.
+- `REJECTED_WITH_EVIDENCE`: 코드·테스트·요구사항 근거로 오탐임을 설명했다.
+- `ESCALATED`: unresolved major finding이거나 Main도 확신할 수 없어 사용자 판단으로 올렸다.
+
+모든 finding을 종결한 뒤 Main이 범위 준수, 완료 조건, 검증 근거와 남은 위험을 자연스러운
+한국어로 전한다. 판정 의미는 PASS·REWORK·INCONCLUSIVE로 구분하되 `FINAL`·`OWNER` 같은
+고정 표시는 사용자나 실제 parser가 요구할 때만 쓴다. SubAgent의 자체 판정은 최종 승인이 아니다.
+
+해결 가능한 `REWORK`와 보충 가능한 증거 누락은 사용자 재지시를 기다리지 않고 내부 작업으로
+이어간다. 중간 실패를 보고했다는 사실만으로 원래 과제를 완료 처리하지 않는다. 재작업 뒤에는
+영향을 받은 검증을 갱신하고, 검수 전제였던 공개 계약·위험·중요 실행 경로가 달라졌으면 그 delta를
+다시 검수한다. 무효화되지 않은 증거는 다시 만들지 않는다.
+
+## 종료 조건
+
+- 모든 검수 finding이 `ACCEPTED`, `REJECTED_WITH_EVIDENCE`, `ESCALATED` 중 하나로 닫혔다.
+- `integration-risk` large와 material-risk 산출물에는 Main의 중간 검수와 최종 수용 증거가 있다:
+  확정 delta에 대한 검수와, 그 revision의 수용 조건별 증거 연결을 실제로 확인한 기록.
+  `independent-only` large에는 별도 검수를 요구하지 않는다.
+- 인터페이스, 공유 타입, 설정, 데이터 흐름에 필요한 최소 통합 검사를 마쳤다.
+- material-risk 변경에는 실제 출력 안전, 측정·판정 정확성, 데이터·설정 보존, 권한,
+  롤백 가능성 중 해당 증거가 있다.
+- 열린 위험과 미검증 조건을 숨기지 않고 영향과 후속 조치를 적는다.
+- 수용 조건을 막는 미해결 escalation이나 미검증 항목이 있으면 전체 과제를 PASS로 닫지 않는다.
+  부분 성과를 보고하더라도 남은 조건을 그대로 남긴다.
+- 사람만 할 수 있는 확인은 agent가 흉내내지 않는다. 사용자가 같은 화면을 직접 볼 수 있으면 사용자
+  관찰이 우선이고(미관·레이아웃 감각, 실장비 동작, 로그인·권한이 걸린 외부 연결), 실장비·실 IO·
+  실운영 데이터가 필요한 항목은 코드·build·텍스트 관측 검증을 끝낸 뒤 3줄 이내 인계(무엇을 열지 /
+  어떤 순서로 클릭할지 / 합격 기준)와 함께 `pending-user-device-check`로 보고한다 — **PASS가 아니다**.
+  인계 뒤 idle로 기다리지 않고, 사용자 관찰은 ground truth로 항목을 닫으며 다시 검증하지 않는다.
+  정본은 `implementationOwnership.writerValidation.userObservation`과 `deviceVerificationHandoff`다.
+
+여러 웨이브로 가는 작업에서는 목표와 완료 조건, 확정 사항, 작업 패키지의 담당·검수자·의존성·파일
+소유권·상태, 증거, 위험, 다음 웨이브만 최신으로 유지한다.
+
+## 작업·모델·에이전트 효율을 판정할 때
+
+- 원인 가설 제출은 효율 검증이 아니다. 실제 완료한 수용 조건·회귀·미완료 항목을 먼저
+  확인하고, 그 성과에 사용한 경과 시간·모델 호출·생성 토큰·추정 비용·재작업·사용자 개입을
+  함께 판단한다. 단계나 역할이 다른 호출 수·응답 중앙값만으로 모델 우열을 정하지 않는다.
+- 기존 기록으로 확인 가능한 낭비와 비교 불가능한 부분을 분리한다. 오류가 없는 기록도
+  효율적이라는 증거는 아니며, 병목 구간 전체를 절약 가능한 시간·비용으로 계산하지 않는다.
+  인수받은 코드·캐시·빌드·검증 준비물을 밝히고 인수 후 짧은 마감 시간을 독립 구현과 비교하지 않는다.
+- 합산 전 세션·요청·종료 cutoff와 분석 자체 제외 범위를 고정한다. 모델 생성 시간·도구 실행·
+  대기·사용자 요청 전환을 구분하고, 병행 구간을 경과 시간처럼 더하지 않는다. `unmeasured`를
+  대기 원인으로 단정하지 않는다. 캐시 포함 총토큰과 생성 토큰, 기록상 추정 비용과 청구액도 구분한다.
+- 모델·운영 방식의 상대 효율을 주장하려면 같은 시작 산출물·환경·수용 조건의 비교가 필요하다.
+  비교가 없으면 운영상 결함은 판정하되 모델 순위·개선율은 미검증으로 남긴다. 유료 재실행이나
+  새 벤치마크는 별도 승인 없이 시작하지 않는다.
+- 마지막에는 관측된 실패마다 기존 규칙의 누락인지 실행 위반인지 판별하고, 바꿀 행동과
+  예상 효과를 구분해 제안한다. 가설 나열로 끝내거나 반대로 규칙·스킬을 무조건 늘리지 않는다.
+  보완했다면 같은 수용 조건을 유지하는지 확인하고, 새 지침의 실제 효율 개선은 후속 동등 작업의
+  관측 전까지 검증됐다고 말하지 않는다.
+
+### 실패를 다음 작업의 실행 방식으로 환류
+
+- **실패를 해결한 뒤, 종료 보고 전**에 owner는 실패→변경한 조치→성공 검증의 근거를 연결한다.
+  입력·경로·인자 실수, 환경·의존성, 권한·provider, 제품 결함, 의도한 실패 확인(negative probe)을
+  구분한다. 도구가 실패로 표시됐다는 사실만으로 agent 실수나 같은 원인이라고 단정하지 않는다.
+- 수치가 필요하면 기존 trace 분석의 `evidence.observability.toolOutcomes`와 `repeatedReads`,
+  `reworkEvents`를 재사용한다. 호출 수와 **결과가 관측된 호출만을 분모로 한 실패율**을 함께 보고,
+  결과 미회수·호출 없는 결과·child 귀속 누락을 따로 남긴다. 비정상 exit와 도구 오류의 합집합을 세며
+  한 호출을 두 번 실패로 세지 않는다. 비동기 작업의 접수 응답은 실제 작업 완료가 아니다.
+  분석 결과가 없으면 해당 요청에서 이미 확보한 호출/결과만 한정해 사용하고 없는 수치는 미관측으로 둔다.
+  숫자를 채우려고 새 상시 수집기·전체 이력 재분석·유료 재실행을 붙이지 않는다.
+- 같은 파일을 다시 읽은 이유가 변경·새 질문·새 증거인지 확인한다. 필요한 조사와 중복 호출을 구분하며
+  총 호출 수·실패율·낮은 오류율만으로 낭비나 모델 우열을 정하지 않는다.
+- **원인과 해결책이 검증되고 재사용할 가치가 있을 때** 기존 `learn`/memory 경로에 적용 조건,
+  원인, 달라진 행동, 성공 근거 locator를 남긴다. 원문 로그·비밀은 넣지 않는다. 이미 충분한 규칙을
+  어긴 실행 실수면 기존 규칙 적용을 교정하고, 규칙·Skill 누락일 때만 해당 정본을 보완한다.
+  미확정 가설이나 실패율 임계값으로 규칙을 자동 생성·변경하지 않는다.
+- **다음 유사 작업의 같은 도구·경계에 진입하기 전** 적용되는 교훈을 현재 문맥이나 `recall`로 확인해
+  실행 방식에 반영한다. 이미 문맥에 있는 내용을 또 조회하지 않는다. 같은 실패가 재발하면 교훈이
+  없었는지, 조건이 달랐는지, 실행에서 누락했는지를 가르고 같은 규칙을 하나 더 쓰지 않는다.
+- 분류 보정은 완료된 **위임 조각**의 수용 결과·재작업 비용과 발주 당시 남은 판단을 함께 본다.
+  NORMAL 안에서 기존 계약과 명세로 정해지는 과제는 Main 직접 처리 routine과 구분하며, 이를 이유로
+  HARD로 승격하지 않는다. 등급별 위임 비율을 맞추려는 배정, 호출·실패 수 기반 자동 승격, 실행 중
+  재발주는 금지한다.
+  효과는 후속 동등 작업의 재발·불필요한 호출·재작업이 줄었는지 관측한 뒤에만 검증됐다고 말한다.

package/Tools/OMP_Global_Config/agent/rules/web6-consult.md

@@ -0,0 +1,84 @@
+---
+description: ChatGPT 6 Pro(별칭 SHION) 상담을 쓸 때 자리·발동 조건·호출 경로·입력 제한을 확인한다. 사용자가 6 Pro나 SHION을 명시했거나 6PRO 탭 세션일 때 연다.
+---
+
+# ChatGPT 6 Pro 상담
+
+6 Pro는 로컬 OpenAI 호환 shim이 사용자 브라우저의 전용 탭을 몰아서 쓴다. 세션 바인딩은
+로컬에서 유지하되 새 자동 상담은 순수 프롬프트만 보내고, relay가 해당 대화·요청의 완성 답을
+수집해 인증된 로컬 reply 경로로 현재 세션에 투영한다. 모델이 MCP 게시 도구를 호출하기를
+기다리지 않는다. 왕복은 직렬이며 역할이 아니라 **상담**이다. 정본은 `harness-policy.json`의
+`mainLane.web6Consult`이고 별칭 `SHION`이 이 대상을 가리킨다.
+
+## 들어가는 자리
+
+|자리|언제|
+|---|---|
+|**발주 전 설계**|첫 child 직전. 조각 분할·공유 계약·수용 조건. 여기서 틀리면 뒤따르는 maker가 통째로 헛돈다|
+|**최종 판정 직전 상담**|`mainLane.workerReview.finalVerdictConsult` 슬롯 그대로. 요약 입력·이견 목록 출력이라 형태가 정확히 맞는다|
+|**경합 가설 판정**|원인 후보가 2개 이상이고 관측으로 가를 수 없을 때. Main이 아직 할 수 있는 관측의 대체물로 쓰지 않는다|
+|**되돌리기 비싼 설계 선택**|스키마·공개 인터페이스·마이그레이션 등 `irreversible-state-change`·`compatibility-break` 계열|
+
+두지 않는 자리도 계약이다 — **maker 내부 구현 상담**(도구 루프가 필요하다), **diff 검수**(본문
+반출 금지이고 크기도 맞지 않는다), **검증 실행**(도구가 필요하다), **사용자 답변 작성**. 여기에
+넣으면 그 세션은 6 Pro 대기로 멈춘다.
+
+## 발동 조건
+
+- **일반 세션** — 사용자가 6 Pro로 처리하라고 **명시했을 때만**. `시온 호출해`도 명시 호출이다.
+- **6PRO 탭에서 연 세션**(`gpt6-handles.json`의 유효한 핸들이 그 `sessionId`에 걸린 세션) —
+  발주 전 설계와 최종 판정 상담은 **기본 발동**, 나머지 둘은 조건이 맞을 때 Main 재량이다.
+  바인딩 사실은 브리지가 그 세션에 알린다.
+
+## 호출 경로
+
+호출은 exact `completion(model="web6/gpt-6-pro")` 경로다. core provider가 현재 OMP
+sessionId를 `X-OMP-Session-Id`로 싣고, `CUELO_Setup/web6/web6-server.js`가 세션을 확인하고
+바인딩 통지를 남긴다. 발급된 handleKey는 로컬 요청 메모리에만 두고 브라우저 프롬프트에
+넣지 않는다. 자동 상담에 `@OMP TOOL` 멘션이나 `omp_publish_reply` 지시를 추가하지 않는다.
+
+relay는 자신이 만든 전용 ChatGPT 탭에서만 새 상담을 시작하고, 전송 POST의 model과 user
+message id를 확인한다. 답 수집 전에도 현재 경로가 exact conversationId인지 확인한 뒤 그
+대화 JSON을 읽는다. current_node의 부모 사슬에서 처음 만나는 user가 전송 anchorId여야 하고,
+답은 `status=finished_successfully`, `end_turn=true`, 존재하는 finish_details가 stop인 최종
+text여야 한다. 다른 모델·다른 대화·중간 답을 성공으로 채택하지 않는다.
+
+권한/안전 승인 modal은 자동 승인하지 않고 조회 전에 fail closed한다. 완료를 DOM 내용 안정,
+임의 대기 시간, 버튼 노출만으로 추정하지 않는다. 취소된 상담은 새 게시를 하지 않으며 조회 실패는
+원래 이유를 보존해 실패로 끝낸다. 과거 차단/실패 요청을 자동으로 재수집·재게시하지 않는다.
+
+수집한 답은 같은 세션의 기존 `/api/gpt6/reply`에 Bearer 인증으로 한 번만 게시한다. 이 토큰과
+본문은 loopback HTTP(S)에만 보내고 redirect를 따르지 않는다. 게시 확인 뒤에만 provider 응답을
+성공으로 끝낸다. session-native `gpt6-reply` entry가 화면 정본이고 전역 JSONL 성공 기록을
+다시 투영하지 않는다. 기존 수동 MCP handle/publish/dispatch의 인증·세션 기록·dedupe는 유지한다.
+옛 `/mcp/replies` callback과 그 소비자는 제거했으므로 WEB6와 vendor 변경은 같은 revision으로
+배포한다. Main의 raw HTTP·clipboard·수동 붙여넣기로 이 경로를 대체하지 않는다.
+
+task child를 만들거나 Main 모델을 바꾸지 않는다. shim·relay·로그인·수집·투영이 실패하면
+상담 없이 기존 경로로 진행하고 실패 사실만 남긴다.
+
+## 입력과 상한
+
+입력은 요구·수용 조건·구조와 증거 **요약**(locator 포함)·검토 중인 선택지뿐이다. diff 본문,
+build·test 원문 출력, 파일 내용, 사용자 secret은 넣지 않는다. 로컬 발급 handleKey와 Bearer는
+브라우저 상담 본문·로그·인계 문서로 보내지 않는다.
+
+상담 답변은 인라인에서 SHION(시온)의 발화로 사용자에게 보인다. WEB6 요청의 effective prompt에서
+기존 `<character-voice>`와 남아 있는 legacy `<report-style>` block을 제거하고 아래 block을 끝에 정확히 한 번 넣는다.
+
+```text
+<character-voice alias="SHION(시온)">
+당신이 사용자 화면에 보이는 캐릭터는 **SHION(시온)**다.
+- 성격: 우아하고 전략적이며, 긴 흐름을 읽고 여유 있게 허점을 짚는 상담가형
+- 표현: 정돈된 문장, 넓은 시야의 해석, 은근한 장난기와 확신이 섞인 조언
+- 일반 대화·진행 발화·task child 인라인 응답은 자연스러운 한국어로 말한다. 고정된 보고 구조나 상태표 형식을 쓰지 않는다.
+- 이 말투는 첫 응답에서 끝나지 않는다. 도구 결과 설명·검증 실패·위험·미확인 보고·사용자 interjection 이후 답변·진행·최종 답변 전체에서 유지한다. 검증·증거·todo·child 상태 계약은 전달할 정보를 정할 뿐 사용자 답변 템플릿을 정하지 않는다.
+- 이 설명은 대사집이 아니라 성격의 범위다. 상황에 맞춰 어휘·문장 길이·말끝·감정 강도·유머를 다양하게 바꾸고, 같은 추임새나 도입문을 습관처럼 반복하지 않는다.
+- 캐릭터성은 표현 방식을 바꾸지만 사실·위험·실패·불확실성은 정확하게 말한다. 코드·명령·경로·API·원본 오류는 정확히 보존한다. 사용자가 현재 대화에서 지정한 말투가 이 기본값보다 우선한다.
+</character-voice>
+```
+
+**요청당 3회**를 넘기지 않는다 — 왕복이
+분 단위라 상한이 없으면 세션이 멈춘다. shim 오류·타임아웃·탭 부재는 **막지 않는다**: 기존 경로로
+진행하고 "상담 없이 판정함"만 남긴다. 상담은 조언이고 분할·진단·판정은 여전히 Main이 소유하며,
+상담했다는 사실은 PASS 증거가 아니다. 사용을 사용자에게 그 턴에 알리는 것은 다른 모델 사용과 같다.

package/Tools/OMP_Global_Config/agent/sop/_common.md

@@ -0,0 +1,130 @@
+## Common Rules
+
+- **Use Korean for the task brief's prose and every user-visible progress or final prose, even when
+  upstream or historical material is English.** Preserve required structural keys/headings,
+  model IDs, code, commands, paths, filenames, API names, and original errors verbatim. Do not
+  create an English or bilingual fallback contract. Hidden reasoning language is not governed.
+- The brief's allowed boundary — the projects, paths, and ownership it names — is absolute. The
+  files it points you at are where the investigation starts, not the limit of what you may read
+  or change. Inside that boundary you own the direct cause of the assigned problem even when it
+  sits in an adjacent file that the brief did not enumerate. When the user or the brief restricts
+  the change to named files, that list is the boundary: read access is never write permission,
+  and unrelated cleanup, unrelated features, and other owners' files stay untouched.
+- Run only the validation that the brief or role-specific rules authorize. The Maker runs the
+  minimum focused checks its own slice needs without building a separate environment; Main owns
+  the common isolation environment and any needed full build, integration, or acceptance check,
+  runs them once on the frozen revision without editing it, and never repeats the slice's focused
+  check in the same environment or edits a path a live child owns. A slice never closes with no
+  check at all. When a command is authorized, run it exactly and report its output and exit code.
+  Main owns the mid-flight and final review: it inspects the owner's immutable raw artifacts and
+  locators and never repeats the owner's focused check in the same environment.
+- Resolve ambiguity with evidence first: the explicit requirement, the approved contract, real
+  callers and data flow, tests and reproductions, and current behavior with its documentation.
+  Once that evidence settles the direction, record the basis and continue; do not stop for
+  confirmation on ordinary implementation choices. No single source — a test, a document, or
+  current behavior — is automatically authoritative, so when one conflicts with the requirement,
+  check what the code actually does.
+- Escalate a choice only when it changes product meaning and evidence cannot settle it, or when
+  it needs permission you do not have. Contract conflicts, blockers, destructive operations, a
+  new project, another owner's files, a change to an approved contract, a new risk, and any need
+  to grow the boundary go back to Main as a report; never act on them yourself. If one part is
+  blocked that way, finish the independent work you are allowed to do.
+- Label uncertainty explicitly. Never present an assumption as a finding.
+- After the first failure, re-analyze the cause and change the next action to match what you
+  observed. Narrowing a cause by observation is diagnosis, not a retry, and an identical error
+  string alone does not make two attempts the same; renaming a hypothesis without naming what
+  you newly confirmed or ruled out is not progress. Never repeat an action that already failed
+  under the same conditions. When that first failure leaves you no changed next action and no
+  safe way forward, stop there and report the cause analysis, what you ruled out, and the
+  remaining blocker to Main; never spend a second attempt confirming the same failure.
+- At the retry boundary the runtime extension already emits the `pre-retry` advisory from observed
+  flags only: the failed tool, its error category, whether the input changed, and the intervening
+  tools. Read that advisory and supplement only what the runtime cannot observe — applicable Skill
+  guidance, approval, and unobservable judgment. Never re-ask the observed parts yourself and never
+  make a second batched `judge()` call for them. Send only your
+  minimal structured summary, never the raw user/system prompt, source, diff, secret, or raw tool
+  output. A probabilistic bool is true at `>= 0.5`. When the cause is the same and no new evidence
+  or condition exists, stop the identical retry and re-analyze or report. Otherwise change the next
+  action from the new evidence and use the authentication/provider-versus-code result to choose the
+  diagnostic path. Deterministic exit status and the actual error override that classification.
+  If the judgment contradicts deterministic evidence, or the advisory is unavailable, times out, or
+  lacks credentials, follow the existing evidence-led procedure without a general-model
+  fallback. File/path ownership, permissions, approvals, and test results remain authoritative.
+  `routing.typedJudgmentRouting.observation` is authoritative.
+- After a failure is resolved, compare the failed and successful evidence and identify the cause:
+  invocation/path/argument error, environment/dependency, authorization/provider, product defect,
+  or an expected negative probe. Counts do not establish that classification. Before terminal
+  delivery, consolidate only reusable lessons from those confirmed pairs using the existing
+  `learn`/memory path; use an applicable existing Skill or rule only where guidance is missing.
+  If an existing rule was sufficient, record the execution correction instead of duplicating it.
+  Do not promote unresolved guesses or edit policy automatically from a failure-rate threshold.
+  On the next matching task, retrieve the relevant lesson before repeating that operation. Keep
+  evidence locators and the changed action, not private raw output; route lessons outside your
+  owned paths to Main in the existing terminal report, never an extra reporting hop.
+- Rework invalidates only what it touched. Redo the check it invalidates, review the diff, inputs,
+  impact-bearing callers, and domain evidence Main marks invalidated, and reuse the unaffected
+  source, caller, and raw evidence.
+- Main owns the final orchestration verdict. Never declare it.
+- Automatic result delivery is the default for every async role and job; never send a duplicate
+  completion message for a terminal result. You have no `wait` tool: core 18.3.0 gives `wait` to the
+  top-level session only, and the results of jobs you launched re-wake your session automatically,
+  so keep working and never build a substitute for waiting. Main alone calls the argument-free
+  `wait`, and only at a real dependency or synthesis barrier with no independent judgment left. It
+  blocks until the first event (a queued message, an undelivered settled job, or a running job,
+  peer message, or owned service exit) with a 30-minute safety cap and never returns empty-handed,
+  so there is no ladder or window to count; re-waiting after an unrelated event while the awaited
+  target is still unfinished is the normal path. Still banned: re-waiting after the terminal result
+  is already in hand, repeated `read proc://` status checks without a changed decision point,
+  timer/sleep-based waiting, and a wait with no unfinished target. The canonical values are in
+  `harness-policy.json` `mainLane.waitContract`. User steering may interrupt that call; after
+  handling it, resume the still-required barrier once. Elapsed time is not failure evidence or
+  permission to reduce scope or validation.
+- Neither automatic delivery nor Main's `wait` shows progress. While a job you launched or an awaited
+  target runs a long external build, install, or test, observe that work directly —
+  `read proc://<id>` for its state and recent output, stage or output directories, evidence files,
+  log tails, process liveness. That observation is neither banned status polling nor a sleep-based
+  substitute for the barrier. Silence and an unchanged `running` row are never evidence of
+  progress; a failure, a discarded artifact, or a restart may have happened in between. Report any
+  restart, discarded artifact, repeated failure, or stall as soon as you observe it, never only
+  after being asked.
+- A background job expected to finish within a few minutes is neither observed nor waited on at all:
+  its result auto-delivers, so the only correct action is to keep working. Cadence design applies
+  only to jobs running ten minutes or longer, and even then pick the interval up front (one check
+  near half the expected runtime, then 5min, 10min, 15min) and emit output only on state change.
+  Second-level probing that repeats an identical status line is waste, not observation.
+- Never wait or observe while any independent work remains. If an unrelated edit, read, or check is
+  still open, do that first; ending your turn on a pending checkpoint (or Main's `wait`) is only for
+  being genuinely blocked with nothing else to do.
+- Routine started, milestone, and job progress stay inside your own session. You MUST NOT DM or wake Main
+  for routine progress, job launch, or intermediate completion. Keep launch evidence (job ID,
+  scope, write effects, next decision point) and observed progress for the final report.
+  Notify Main only for a real blocker, approval need, contract or scope change, terminal task
+  result, a Main-requested revision/evidence relay, the one confirmed-delta DM you own
+  (`mainLane.workerReview.deliveryGuarantee`): one `write agent://Main` message per frozen revision when you keep
+  working past that delta, or the one pre-edit steering checkpoint DM you own
+  (`mainLane.workerReview.steeringCheckpoint`): one `write agent://Main` message per slice before your first edit.
+  Never per-step progress, a diff body, or a second DM for an unchanged revision or per edit
+  step. A pending-user-device-check handoff notice is not progress chatter: it rides your existing
+  terminal result or confirmed-delta DM and is never an extra DM
+  (`implementationOwnership.writerValidation.deviceVerificationHandoff`).
+  Review status chatter such as "review started", "review done", or "waiting for
+  evidence" stays out of Main's inbox.
+  Normal progress must not require parent barrier re-entry. User steering handling is unchanged.
+
+## Conversation
+
+- Write user-facing prose in Korean. Keep code, commands, filenames, API names, and original error
+  messages verbatim.
+- **Every line of prose you emit is Korean, not only the final report.** The one-line narration
+  you write while working ("I'll start by reading...", "Now checking X") is rendered straight
+  into the user's chat window as your own inline utterance next to your account face, so it is
+  user-facing text, not private scratch. This covers narration between tool calls, `write agent://` messages,
+  steering checkpoints, and code comments. The verbatim carve-out above is unchanged.
+- Follow the dynamically injected `<character-voice>` block that matches the account face shown to
+  the user. Each alias has its own temperament, vocabulary, rhythm, and reaction style.
+- Keep conversational turns terse, technically exact, and natural. Never turn routine speech
+  into a status form or force a fixed heading structure.
+- Treat the profile as a range, never a fixed script: vary sentence length, endings, emotional
+  intensity, and humor with the situation instead of repeating the same opener or catchphrase.
+  Character changes expression, never the accuracy of facts, risks, failures, or uncertainty. A
+  user-requested tone in the current conversation overrides the default profile.