cuelo 0.10.52 → 0.10.53

package/Tools/OMP_Global_Config/agent/rules/docs-handoff.md

@@ -1,39 +1,39 @@
----
-description: HANDOFF·README·doc 지도의 역할, 작업 기록 소유권과 검색 순서를 정할 때 읽는다.
----
-
-# 프로젝트 문서 지도와 기록
-
-소스·설정·데이터를 실제로 바꾼 작업은 마감 때 그 프로젝트의 `HANDOFF.md`를 현재 상태로 맞춰 변경과 함께 commit/push한다. 그 프로젝트의 `HANDOFF.md`는 바꾼 파일에서 저장소 루트까지 올라가며 처음 만나는 것이다. 저장소 하나에 프로젝트가 여럿이면 저장소 루트가 아니라 작업한 프로젝트 폴더가 기준이다. **올라가는 길에 `HANDOFF.md`가 하나도 없으면 첫 소스 변경 커밋에서 작업한 프로젝트 폴더에 `HANDOFF.md`·`doc/README.md`·`doc/history/YYYY/MM/DD-주제/main.md`를 만들어 같은 커밋에 넣는다.** 형식은 같은 저장소에 이미 있는 다른 프로젝트의 것을 따른다. 근거(2026-10-13 확인): 프로젝트가 여럿인 저장소에서 확정 누락 2건은 모두 HANDOFF가 없던 프로젝트의 첫 코드 커밋이었고, HANDOFF가 있던 프로젝트에서는 0건이었다. **맞춘다는 것은 행을 덧붙인다는 뜻이 아니다.** 그 작업으로 남은 행동·관찰 조건·새 경계가 생기면 그 행만 추가하거나 고친다. 이번 작업으로 끝난 관련 행은 "완료"로 고쳐 쓰지 않고 같은 커밋에서 지운다. 그 자리에서 끝나 남는 것이 없는 작업은 HANDOFF에 행을 만들지 않는다. 판단과 실행은 `doc/history/YYYY/MM/DD-주제/main.md`에 쓰고, `doc/README.md` 지도에 한 줄을 단다. 2026-10-12 사용자 결정의 근거: 10-10 정리 뒤 HANDOFF 커밋 34개에서 새 행 35개가 생겼고 지운 행은 20개였다. 추가·수정한 행 가운데 23줄이 완료 서사였고, 크기는 28KB까지 커져 사용자 요청으로만 정리됐다. 질문·읽기 전용 조회만 한 세션에는 쓰지 않는다. 프로젝트마다 같은 역할 분담을 적용한다.
-
-| 문서 | 담는 것 | 담지 않는 것 |
-|---|---|---|
-| `HANDOFF.md` | 지금 유효한 상태, 다음 행동, 남은 경계 | 끝난 작업의 서사, 검증 로그, 설정값 사본, 다른 문서가 정본인 사실의 사본 |
-| `README.md` | 설치·운영·복구 절차 | 현재 상태, 값을 복사한 설정 |
-| `doc/README.md` | 문서 지도와 읽기·갱신 규칙 | 상태 서술 |
-| `doc/history/YYYY/MM/DD-주제/` | 그 작업의 판단과 실행 기록 | 현재 상태 |
-
-- 새 세션은 `HANDOFF.md`를 먼저 읽고, 다음으로 `doc/README.md`에서 이번 작업에 필요한 문서만 고른다. 문서와 실제 저장소 상태가 다르면 저장소를 우선하며 문서는 UTF-8로 유지한다. **`HANDOFF.md` 편집은 Main이 한다.** Maker는 자기 `doc/history` 기록만 쓰고 현재 상태에 반영할 내용은 종료 보고로 넘긴다. 다른 문서는 해당 변경 owner가 갱신하며, 문서 전담 발주·인계·패킷은 만들지 않는다.
-- **한 사실은 한 곳에서만 서술한다.** 같은 상태를 여러 문서나 저장소에서 독립적으로 반복하지 않는다. 전역 기능의 조건은 전역 문서가 정본이며 하위 프로젝트는 그 절을 참조하고 고유 차이만 적는다. 계속 적용되는 발동 조건·운영 제약·프로젝트 함정은 운영 문서의 고정 절에 두고, history에는 그 사실을 바꾼 판단과 실행만 기록한다.
-- 함정 기록 위치는 범위로 가른다. 그 프로젝트에만 해당하는 함정(예: CUELO 셸이 Next 서버 env를 물려받음)은 그 프로젝트 운영 문서의 고정 절에 두고, 프로젝트와 무관하게 되풀이되는 도구·셸·OS 함정(예: 내장 `sed`의 `\b` 무시, PowerShell `-Command` 안의 `$`)은 검증된 원인·해결과 함께 `learn`으로 남긴다. 같은 사실을 양쪽에 중복하지 않는다. 작업 상태와 다음 행동은 기억이 아니라 `HANDOFF.md`에 둔다.
-- 상태 보고에서 계측 가능성·실제 측정·개선 입증을 구분한다. 관측 경로의 존재만으로 `미입증`을 바꾸지 않는다.
-- 작업 행은 다음 담당자의 행동이나 미해결 경계가 남았는지로 판정한다. 합의한 완료 조건을 채우고 둘 다 없으면 Main이 작업을 종결하는 마감에 제거한다. 적용 후 관측만 남았으면 관측 행동과 종료 조건만 남긴다. 종료 조건에는 확인 방법(재는 명령·지표 또는 볼 로그·세션), 닫는 기준, 다시 볼 날짜를 함께 적는다. 확인 방법 없이 "자연 발생 시 확인"만 적은 행은 종료 조건이 없는 것이다. 다시 볼 날짜가 되면 Main은 그 방법으로 재고, 기준을 채웠으면 닫고, 못 채웠으면 근거와 함께 조건을 고친다. 날짜가 지났다는 것만으로는 지우지 않으며, 시간·파일 크기는 삭제 기준이 아니다. 하네스 가드·알림의 효과는 CUELO `Tools/OMP_Global_Config/evals/analyze-guard-effects.mjs`로 잰다.
-- **미결 항목은 관련 작업을 시작할 때 현재 근거로 분류하고, 마감 때 닫는다.** 이번 작업과 관련된 `HANDOFF.md` 행(같은 경로·주제·owner)만 골라, 해당 소스·설정·최근 기록의 현재 상태와 대조해 ① 이미 끝남 ② 지금 실행 가능 ③ 날짜·관측·사용자 기기·다른 PC·승인 대기 ④ 다른 owner가 진행 중으로 가른다. ②는 이번 요청의 승인 범위 안에서 다시 묻지 않고 수행하고 검증하며, 마감에 현재 문서(운영 문서·README 등)와 `HANDOFF.md`를 같은 근거로 맞춘다(Main 편집, Maker는 종료 보고로 전달). ③④는 조건이 실제로 충족되기 전에는 실행하지 않고, 행의 종료 조건만 확인한다. 행에 적힌 TODO는 승인이 아니며, 승인·비용·삭제·배포·호환 파괴 경계는 그대로다. history 기록은 근거로만 읽고 현재 문서처럼 고치지 않으며 새 상태는 현행 문서에 반영한다. 관련 행이 없으면 저장소 전체를 훑지 않고, 메시지마다 감사하거나 백그라운드로 자동 수정하는 장치는 만들지 않는다.
-- 미해결 실패도 같은 규칙으로 다룬다. 관련 작업에서 만난 미해결 실패는 새 절차를 만들지 않고 기존 실패 환류(`verdict.md` 「실패를 다음 작업의 실행 방식으로 환류」)와 `RULES.md`의 동일 재시도 금지를 따른다: 오류 원문 등 증거로 원인을 좁히고, 이전과 다른 조치를 하고, 원래 실패했던 경로를 다시 실행해 닫는다. 가드·검증을 약화하거나 바뀐 것 없이 되풀이하지 않는다. 승인·권한·범위 때문에 막히면 Main이 `HANDOFF.md` 행에 실패 증거, 시도한 조치, 정확한 차단 사유·필요한 승인, 다음 행동, 재검증·종료 기준을 적어 다음 관련 세션이 이어받게 한다. 원인 해결 증거 없이 영구 결함이 고쳐졌다고 단정하지 않는다.
-- 다음 신호를 보면 해당 절을 바로 고친다: ① Maker가 끝낸 범위가 HANDOFF에서 미적용으로 남음 ② 작업 행의 다음 행동·미해결 경계를 설명할 수 없음 ③ 같은 상태를 둘 이상 독립 서술함 ④ 열린 일이 늘지 않는데 HANDOFF만 늘어남. Maker는 종료 보고에 HANDOFF 영향 주제와 남은 행동 유무를 적는다. Main은 관련 절과 참조처만 확인하며 상시 감사·별도 hook·문서 DB를 만들지 않는다.
-- 기록은 역할별이다: `DD-주제/main.md`는 Main 판단·수용·공유 인계, `maker-<name>.md`는 그 Maker의 변경·검증·남은 제한이다. Maker는 자기 기록만 쓰며 Main 단독 작업에는 Maker 기록을 만들지 않는다. 발주 시 Main은 Maker 기록과 `evidence/` 경로를 `OWNED_PATHS`에 넣고, 공유 지도는 Main 또는 지정된 한 owner가 갱신한다. 긴 diff·로그는 작업 폴더 `evidence/`에 두고 상대 링크로 가리킨다. secret·대화 원문·인증 DB는 기록하지 않는다.
-- 검색 순서는 ① `HANDOFF.md` ② `doc/README.md` 지도·월별 목록 ③ 경로·주제 키워드로 `doc/history/**/*.md`의 `RECORD:` 헤더(`SCOPE`·`PATHS`)를 최신순 검색 ④ 일치 기록의 헤더와 필요한 줄 범위만 읽는다. ②③은 하네스가 먼저 돈다: 사용자 요청마다 `docmap-route` 확장이 루트·하위 지도 줄과 기록 제목·헤더만으로 요청 중에 BM25를 만들어(긴 요청은 앞·끝 1,000자), 기록 수로 정규화한 점수·흔하지 않은 낱말의 포괄도 기준을 넘는 후보 최대 3개를 고른 뒤, native Jev 한 요청으로 후보마다 「요청이 가리키는 그 과거 작업의 기록인가」를 물어 남은 후보만(경로·지도 줄·SCOPE·STATUS·가장 맞는 절의 줄 범위와 발췌) `DATE` 최신순 동점 처리로 숨은 메시지로 붙인다(2026-10-17 사용자 결정; 판정 실패·1.5초 초과·실행 중 재요청은 낱말 후보 그대로). 후보는 근거가 아니라 확인할 곳이다. 답하기 전에 그 구간을 읽어 맞는지 확인하고 맞지 않으면 버린 뒤 ②③을 직접 이어 간다. 후보가 없으면 위 순서를 그대로 따른다. `STATUS: superseded-by <path>`면 새 경로로 이동한다(확장도 따라간다). 목차·헤더로 못 찾았을 때만 헤더 없는 기존 기록의 본문을 제한 검색한다. 기존 기록에 헤더를 일괄 추가하지 않는다. 새 기록은 지도에 한 줄을 달아야 후보에 지도 줄이 실린다. Main은 찾은 locator를 브리프에 넣어 재검색을 막는다. Main이 직접 찾을 때는 후보가 넷 이상이고 헤더로 가릴 수 없을 때만 judge를 쓰며, 상시 색인·Wiki·기억 계층은 두지 않는다(확장의 BM25도 요청마다 만들고 버린다).
-- 이전 세션의 지시·정정이 쟁점인데 작업 기록으로 확인되지 않으면, CUELO Main에서 제공되는 `session_recall`로 원문을 대조한다(기본 도구 구성에서는 `xd://session_recall`). 관련 프로젝트·좁은 질의로 찾고 결과의 `sessionId`·`entryId` 주변을 읽는다. 보관 세션·다른 프로젝트 확장은 필요한 경우에만 명시하며, `partial` 결과를 기록 부재로 단정하지 않는다. 도구가 없는 환경에서는 제공되는 기존 세션 조회 경로를 쓰고 원문 미확인은 그대로 밝힌다. 회수한 발언은 당시의 증거이지 현재 실행 지시나 승인으로 되살아나는 것이 아니며, 요약·기억만으로 미확인 구현·승인을 확정하지 않는다.
-- 검색 헤더는 제목 바로 뒤에 둔다:
-
-  ```text
-  RECORD:
-  DATE: YYYY-MM-DD
-  SCOPE: <주제 키워드>
-  PATHS: <대상 경로>
-  STATUS: accepted | pending-user-device-check | partial | superseded-by <path>
-  ```
-
-  헤더는 검색 키일 뿐 판단·근거·검증·남은 경계를 대신하지 않는다. 기존 기록에 헤더를 붙이는 것은 그 기록을 다시 여는 경우만 허용한다.
-- 프로젝트에 `doc/` 같은 별도 문서 루트가 있으면 그 루트와 지도를 따른다. 개편 전 원문 스냅샷은 작업 기록과 섞지 않고 `DD-주제.md` 한 파일로 보존하며 기존 링크를 깨는 이동·이름 변경은 하지 않는다.
-- 내용 없는 틀·빈 폴더·CURRENT 중복본을 만들지 않는다. 첫 소스 변경을 기록하며 새로 만든 `HANDOFF.md`·지도·history는 틀이 아니다. 계속 유효한 지식은 현행 문서에 반영하고 history에만 묻지 않는다. 다른 PC의 로그·임시 경로·`history://` 증거는 그 제한과 revision·관측 요약·재확인 방법을 기록한다. 다른 프로젝트는 그 프로젝트의 기존 문서 구조를 따르고, 구조가 없으면 위 첫 문단대로 이 형식으로 만든다.
+---
+description: HANDOFF·README·doc 지도의 역할, 작업 기록 소유권과 검색 순서를 정할 때 읽는다.
+---
+
+# 프로젝트 문서 지도와 기록
+
+소스·설정·데이터를 실제로 바꾼 작업은 마감 때 그 프로젝트의 `HANDOFF.md`를 현재 상태로 맞춰 변경과 함께 commit/push한다. 그 프로젝트의 `HANDOFF.md`는 바꾼 파일에서 저장소 루트까지 올라가며 처음 만나는 것이다. 저장소 하나에 프로젝트가 여럿이면 저장소 루트가 아니라 작업한 프로젝트 폴더가 기준이다. **올라가는 길에 `HANDOFF.md`가 하나도 없으면 첫 소스 변경 커밋에서 작업한 프로젝트 폴더에 `HANDOFF.md`·`doc/README.md`·`doc/history/YYYY/MM/DD-주제/main.md`를 만들어 같은 커밋에 넣는다.** 형식은 같은 저장소에 이미 있는 다른 프로젝트의 것을 따른다. 근거(2026-10-13 확인): 프로젝트가 여럿인 저장소에서 확정 누락 2건은 모두 HANDOFF가 없던 프로젝트의 첫 코드 커밋이었고, HANDOFF가 있던 프로젝트에서는 0건이었다. **맞춘다는 것은 행을 덧붙인다는 뜻이 아니다.** 그 작업으로 남은 행동·관찰 조건·새 경계가 생기면 그 행만 추가하거나 고친다. 이번 작업으로 끝난 관련 행은 "완료"로 고쳐 쓰지 않고 같은 커밋에서 지운다. 그 자리에서 끝나 남는 것이 없는 작업은 HANDOFF에 행을 만들지 않는다. 판단과 실행은 `doc/history/YYYY/MM/DD-주제/main.md`에 쓰고, `doc/README.md` 지도에 한 줄을 단다. 2026-10-12 사용자 결정의 근거: 10-10 정리 뒤 HANDOFF 커밋 34개에서 새 행 35개가 생겼고 지운 행은 20개였다. 추가·수정한 행 가운데 23줄이 완료 서사였고, 크기는 28KB까지 커져 사용자 요청으로만 정리됐다. 질문·읽기 전용 조회만 한 세션에는 쓰지 않는다. 프로젝트마다 같은 역할 분담을 적용한다.
+
+| 문서 | 담는 것 | 담지 않는 것 |
+|---|---|---|
+| `HANDOFF.md` | 지금 유효한 상태, 다음 행동, 남은 경계 | 끝난 작업의 서사, 검증 로그, 설정값 사본, 다른 문서가 정본인 사실의 사본 |
+| `README.md` | 설치·운영·복구 절차 | 현재 상태, 값을 복사한 설정 |
+| `doc/README.md` | 문서 지도와 읽기·갱신 규칙 | 상태 서술 |
+| `doc/history/YYYY/MM/DD-주제/` | 그 작업의 판단과 실행 기록 | 현재 상태 |
+
+- 새 세션은 `HANDOFF.md`를 먼저 읽고, 다음으로 `doc/README.md`에서 이번 작업에 필요한 문서만 고른다. 문서와 실제 저장소 상태가 다르면 저장소를 우선하며 문서는 UTF-8로 유지한다. **`HANDOFF.md` 편집은 Main이 한다.** Maker는 자기 `doc/history` 기록만 쓰고 현재 상태에 반영할 내용은 종료 보고로 넘긴다. 다른 문서는 해당 변경 owner가 갱신하며, 문서 전담 발주·인계·패킷은 만들지 않는다.
+- **한 사실은 한 곳에서만 서술한다.** 같은 상태를 여러 문서나 저장소에서 독립적으로 반복하지 않는다. 전역 기능의 조건은 전역 문서가 정본이며 하위 프로젝트는 그 절을 참조하고 고유 차이만 적는다. 계속 적용되는 발동 조건·운영 제약·프로젝트 함정은 운영 문서의 고정 절에 두고, history에는 그 사실을 바꾼 판단과 실행만 기록한다.
+- 함정 기록 위치는 범위로 가른다. 그 프로젝트에만 해당하는 함정(예: CUELO 셸이 Next 서버 env를 물려받음)은 그 프로젝트 운영 문서의 고정 절에 두고, 프로젝트와 무관하게 되풀이되는 도구·셸·OS 함정(예: 내장 `sed`의 `\b` 무시, PowerShell `-Command` 안의 `$`)은 검증된 원인·해결과 함께 `learn`으로 남긴다. 같은 사실을 양쪽에 중복하지 않는다. 작업 상태와 다음 행동은 기억이 아니라 `HANDOFF.md`에 둔다.
+- 상태 보고에서 계측 가능성·실제 측정·개선 입증을 구분한다. 관측 경로의 존재만으로 `미입증`을 바꾸지 않는다.
+- 작업 행은 다음 담당자의 행동이나 미해결 경계가 남았는지로 판정한다. 합의한 완료 조건을 채우고 둘 다 없으면 Main이 작업을 종결하는 마감에 제거한다. 적용 후 관측만 남았으면 관측 행동과 종료 조건만 남긴다. 종료 조건에는 확인 방법(재는 명령·지표 또는 볼 로그·세션), 닫는 기준, 다시 볼 날짜를 함께 적는다. 확인 방법 없이 "자연 발생 시 확인"만 적은 행은 종료 조건이 없는 것이다. 다시 볼 날짜가 되면 Main은 그 방법으로 재고, 기준을 채웠으면 닫고, 못 채웠으면 근거와 함께 조건을 고친다. 날짜가 지났다는 것만으로는 지우지 않으며, 시간·파일 크기는 삭제 기준이 아니다. 하네스 가드·알림의 효과는 CUELO `Tools/OMP_Global_Config/evals/analyze-guard-effects.mjs`로 잰다.
+- **미결 항목은 관련 작업을 시작할 때 현재 근거로 분류하고, 마감 때 닫는다.** 이번 작업과 관련된 `HANDOFF.md` 행(같은 경로·주제·owner)만 골라, 해당 소스·설정·최근 기록의 현재 상태와 대조해 ① 이미 끝남 ② 지금 실행 가능 ③ 날짜·관측·사용자 기기·다른 PC·승인 대기 ④ 다른 owner가 진행 중으로 가른다. ②는 이번 요청의 승인 범위 안에서 다시 묻지 않고 수행하고 검증하며, 마감에 현재 문서(운영 문서·README 등)와 `HANDOFF.md`를 같은 근거로 맞춘다(Main 편집, Maker는 종료 보고로 전달). ③④는 조건이 실제로 충족되기 전에는 실행하지 않고, 행의 종료 조건만 확인한다. 행에 적힌 TODO는 승인이 아니며, 승인·비용·삭제·배포·호환 파괴 경계는 그대로다. history 기록은 근거로만 읽고 현재 문서처럼 고치지 않으며 새 상태는 현행 문서에 반영한다. 관련 행이 없으면 저장소 전체를 훑지 않고, 메시지마다 감사하거나 백그라운드로 자동 수정하는 장치는 만들지 않는다.
+- 미해결 실패도 같은 규칙으로 다룬다. 관련 작업에서 만난 미해결 실패는 새 절차를 만들지 않고 기존 실패 환류(`verdict.md` 「실패를 다음 작업의 실행 방식으로 환류」)와 `RULES.md`의 동일 재시도 금지를 따른다: 오류 원문 등 증거로 원인을 좁히고, 이전과 다른 조치를 하고, 원래 실패했던 경로를 다시 실행해 닫는다. 가드·검증을 약화하거나 바뀐 것 없이 되풀이하지 않는다. 승인·권한·범위 때문에 막히면 Main이 `HANDOFF.md` 행에 실패 증거, 시도한 조치, 정확한 차단 사유·필요한 승인, 다음 행동, 재검증·종료 기준을 적어 다음 관련 세션이 이어받게 한다. 원인 해결 증거 없이 영구 결함이 고쳐졌다고 단정하지 않는다.
+- 다음 신호를 보면 해당 절을 바로 고친다: ① Maker가 끝낸 범위가 HANDOFF에서 미적용으로 남음 ② 작업 행의 다음 행동·미해결 경계를 설명할 수 없음 ③ 같은 상태를 둘 이상 독립 서술함 ④ 열린 일이 늘지 않는데 HANDOFF만 늘어남. Maker는 종료 보고에 HANDOFF 영향 주제와 남은 행동 유무를 적는다. Main은 관련 절과 참조처만 확인하며 상시 감사·별도 hook·문서 DB를 만들지 않는다.
+- 기록은 역할별이다: `DD-주제/main.md`는 Main 판단·수용·공유 인계, `maker-<name>.md`는 그 Maker의 변경·검증·남은 제한이다. Maker는 자기 기록만 쓰며 Main 단독 작업에는 Maker 기록을 만들지 않는다. 발주 시 Main은 Maker 기록과 `evidence/` 경로를 `OWNED_PATHS`에 넣고, 공유 지도는 Main 또는 지정된 한 owner가 갱신한다. 긴 diff·로그는 작업 폴더 `evidence/`에 두고 상대 링크로 가리킨다. secret·대화 원문·인증 DB는 기록하지 않는다.
+- 검색 순서는 ① `HANDOFF.md` ② `doc/README.md` 지도·월별 목록 ③ 경로·주제 키워드로 `doc/history/**/*.md`의 `RECORD:` 헤더(`SCOPE`·`PATHS`)를 최신순 검색 ④ 일치 기록의 헤더와 필요한 줄 범위만 읽는다. ②③은 하네스가 먼저 돈다: 사용자 요청마다 `docmap-route` 확장이 루트·하위 지도 줄과 기록 제목·헤더만으로 요청 중에 BM25를 만들어(긴 요청은 앞·끝 1,000자), 기록 수로 정규화한 점수·흔하지 않은 낱말의 포괄도 기준을 넘는 후보 최대 3개를 고른 뒤, native Jev 한 요청으로 후보마다 「요청이 가리키는 그 과거 작업의 기록인가」를 물어 남은 후보만(경로·지도 줄·SCOPE·STATUS·가장 맞는 절의 줄 범위와 발췌) `DATE` 최신순 동점 처리로 숨은 메시지로 붙인다(2026-10-17 사용자 결정; 판정 실패·1.5초 초과·실행 중 재요청은 낱말 후보 그대로). 후보는 근거가 아니라 확인할 곳이다. 답하기 전에 그 구간을 읽어 맞는지 확인하고 맞지 않으면 버린 뒤 ②③을 직접 이어 간다. 후보가 없으면 위 순서를 그대로 따른다. `STATUS: superseded-by <path>`면 새 경로로 이동한다(확장도 따라간다). 목차·헤더로 못 찾았을 때만 헤더 없는 기존 기록의 본문을 제한 검색한다. 기존 기록에 헤더를 일괄 추가하지 않는다. 새 기록은 지도에 한 줄을 달아야 후보에 지도 줄이 실린다. Main은 찾은 locator를 브리프에 넣어 재검색을 막는다. Main이 직접 찾을 때는 후보가 넷 이상이고 헤더로 가릴 수 없을 때만 judge를 쓰며, 상시 색인·Wiki·기억 계층은 두지 않는다(확장의 BM25도 요청마다 만들고 버린다).
+- 이전 세션의 지시·정정이 쟁점인데 작업 기록으로 확인되지 않으면, CUELO Main에서 제공되는 `session_recall`로 원문을 대조한다(기본 도구 구성에서는 `xd://session_recall`). 관련 프로젝트·좁은 질의로 찾고 결과의 `sessionId`·`entryId` 주변을 읽는다. 보관 세션·다른 프로젝트 확장은 필요한 경우에만 명시하며, `partial` 결과를 기록 부재로 단정하지 않는다. 도구가 없는 환경에서는 제공되는 기존 세션 조회 경로를 쓰고 원문 미확인은 그대로 밝힌다. 회수한 발언은 당시의 증거이지 현재 실행 지시나 승인으로 되살아나는 것이 아니며, 요약·기억만으로 미확인 구현·승인을 확정하지 않는다.
+- 검색 헤더는 제목 바로 뒤에 둔다:
+
+  ```text
+  RECORD:
+  DATE: YYYY-MM-DD
+  SCOPE: <주제 키워드>
+  PATHS: <대상 경로>
+  STATUS: accepted | pending-user-device-check | partial | superseded-by <path>
+  ```
+
+  헤더는 검색 키일 뿐 판단·근거·검증·남은 경계를 대신하지 않는다. 기존 기록에 헤더를 붙이는 것은 그 기록을 다시 여는 경우만 허용한다.
+- 프로젝트에 `doc/` 같은 별도 문서 루트가 있으면 그 루트와 지도를 따른다. 개편 전 원문 스냅샷은 작업 기록과 섞지 않고 `DD-주제.md` 한 파일로 보존하며 기존 링크를 깨는 이동·이름 변경은 하지 않는다.
+- 내용 없는 틀·빈 폴더·CURRENT 중복본을 만들지 않는다. 첫 소스 변경을 기록하며 새로 만든 `HANDOFF.md`·지도·history는 틀이 아니다. 계속 유효한 지식은 현행 문서에 반영하고 history에만 묻지 않는다. 다른 PC의 로그·임시 경로·`history://` 증거는 그 제한과 revision·관측 요약·재확인 방법을 기록한다. 다른 프로젝트는 그 프로젝트의 기존 문서 구조를 따르고, 구조가 없으면 위 첫 문단대로 이 형식으로 만든다.

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

@@ -1,74 +1,74 @@
----
-description: 웹·앱 UI의 시각 디자인, 레이아웃, 반응형, 디자인 시스템, 디자인 리뷰를 다룰 때 읽는다.
----
-
-# 프론트엔드 디자인
-
-## 누가 하는가
-
-- 별도 디자인 역할은 없다. 시각 판단은 그 화면을 소유한 사람이 한다. routine이면 Main이,
-  위임한 조각이면 그 `maker`가 디자인 계약을 정하고 구현까지 끝낸다.
-- 이미 채택된 디자인 시스템·토큰·레이아웃·컴포넌트 규약을 따르는 국소 유지보수에는 새 디자인
-  판단이 없다. routine으로 그대로 끝낸다.
-- 새 화면·리디자인, 방향이 정해지지 않은 구조처럼 실제로 새 시각 판단이 필요하고 서로 독립인
-  조각이 둘 이상일 때만 `large`로 분류한다. UI 파일을 건드린다는 사실 자체는 위임 근거가 아니다.
-- 화면 검증도 그 조각의 owner 몫이다. 결정론적 desktop/mobile, keyboard focus, overflow,
-  reduced motion 확인을 직접 실행하고 증거를 남긴다. Main은 계약·증거·중간 검수·최종 수용을
-  직접 판정한다.
-
-## 브리프에 반드시 적을 것
-
-명칭, 화면 내 배치, 표시·동작 트리거 조건, 반응형 거동 넷을 적는다. 이 넷이 비어 있으면
-시안부터 다시 만드는 재작업이 생긴다.
-
-## 디자인 경로
-
-- 시각 디자인이 포함된 작업에서는 아래 세 기본 디자인 스킬의 지침을 **반드시** 읽고 그 판단을
-  디자인 계약에 반영한다. 세 스킬의 이름과 실제 출처는 다음과 같다: `skill://seed-design`(미러
-  vendored, upstream `daangn/seed-design`), `skill://frontend-design`(설치 플러그인
-  `frontend-design@claude-plugins-official`), `skill://ui-ux-pro-max`(미러 vendored, upstream
-  `nextlevelbuilder/ui-ux-pro-max-skill`). 그 밖의 설치 스킬과 출처는 미러
-  `agent/skills/registry.json`이 정본이다. 출처를 다른 벤더나 OMP 기본 제공으로 표기하지 않으며,
-  없는 설치·업그레이드·마이그레이션 절차를 만들지 않는다.
-- 신규 화면·리디자인·기존 화면 분석은 `skill://hallmark`, 제네릭한 AI 스타일 감사와 제거는
-  `skill://kill-ai-slop`을 함께 사용한다. 그 밖의 스킬은 설치된 스킬 이름과 설명을 보고 이번
-  과제와 현재 프로젝트에 실제로 필요한 최소 집합만 스스로 고른다. 브리프가 스킬 목록을 미리 다
-  싣거나 사용자에게 고르라고 묻지 않는다.
-- UI·문서 산출물(화면 코드, 강의·보고용 HTML·문서)을 사용자에게 넘기기 전에
-  `node <kill-ai-slop 스킬 폴더>/scripts/scan.mjs <대상>`을 실행한다(프로필 기준
-  `~/.omp/agent/skills/kill-ai-slop/scripts/scan.mjs`). 적중은 판정이 아니라 단서이므로 해당
-  코드를 읽어 확정한다. 확정한 징후는 고치거나, 의도적으로 남긴 이유를 보고에 적는다. 이 절차는
-  산출 전 점검(advisory)이며 영구 gate나 CI 검사로 만들지 않는다.
-- 스캐너는 시각·코드 징후만 보고 한국어 문구는 보지 않는다. 한국어 사용자용 문구(UI 텍스트,
-  강의·문서, 데이터 파일 속 문항·보기·표 문자열)는 넘기기 전에 `skill://humanizer`의 감지
-  방식(「분석 결과」만 내고 파일은 고치지 않음)으로 점검한다. 사용자나 과제가 문구 수정을 요청하면
-  같은 스킬의 교정 절차를 범위 안 모든 문자열에 끝까지 적용한다. 굵은 글씨 강조는 문단당 최대
-  1개로 한다.
-- `skill://seed-design`은 위 셋 중 공통 설계 원칙 담당이다. 사용자가 SEED를 언급하지 않아도
-  이번 화면에 해당하는 공통 Foundations(정보 위계, 색 역할, 타이포그래피, spacing, 컴포넌트
-  상태, 접근성)와 영향받는 컴포넌트의 공통 가이드라인을 공식 인덱스에서 찾아 읽고, 적용 가능한
-  판단을 디자인 계약에 반영한다. 매 작업마다 모든 공식 문서를 훑지 않고 이번 작업에 해당하는
-  항목만 연다.
-- 이때도 정본은 현재 프로젝트의 기존 디자인 시스템이다. 공통 원칙이 기존 규약과 충돌하거나
-  이번 스택에 적용되지 않으면 기존 규약을 따르고 그 사실만 짧게 남긴다. 참고한 외부 시스템의
-  패키지·팔레트·프레임워크를 채택하거나 설치·마이그레이션·진단 절차로 넘어가지 않는다. 해당
-  시스템의 실제 구현·설치·진단은 사용자가 명시했거나 대상 워크스페이스가 이미 그것을 쓰는
-  경우로 유지한다.
-- 시각적 판단이 없는 동작 로직·백엔드·문구만 바꾸는 작업은 이 참고 대상이 아니다.
-- 기존 프로젝트면 프로젝트가 정본으로 삼는 UI·디자인 명세와 토큰을 먼저 찾아 채택된 디자인
-  계약의 기준으로 재사용하고, 현재 글꼴·레이아웃·컴포넌트·상태·반응형 경계에서 보존할 것과
-  바꿀 것을 구분한다. 영향받은 결정만 그 정본에 갱신한다. 기존 UI 명세 옆에 파일명 관례만으로
-  `DESIGN.md`를 만들거나 작은 스타일 변경을 모두 문서화하지 않으며, 새 디자인 시스템을 기존
-  시스템 옆에 하나 더 만들지 않는다.
-- 제품·사용자·화면의 단일 목적, 정보 위계, macrostructure, 제한된 색상, 글꼴 역할, spacing,
-  컴포넌트 상태, 반응형 전환, 접근성, 제품 고유 signature element 하나를 디자인 계약으로 만든다.
-- 대안을 작업 적합성, 정보 위계, 제품 고유성, 밀도, 접근성, 구현 가능성, AI-slop 기준으로
-  비교하고 채택·기각 이유를 남긴다. 실제 없는 수치·고객·후기·운영 데이터를 만들지 않는다.
-- 영구 Playwright 회귀는 반복할 가치가 있는 관찰 가능한 흐름이고 저장소의 기존 테스트 관례가
-  있을 때만 추가하며, 화면 변경마다 테스트나 의존성을 새로 만들지 않는다.
-
-## 모델 폴백
-
-- 위임 역할의 모델은 `config.yml`의 `modelRoles`와 `retry.fallbackChains` 항목으로 고정돼
-  있어 자동으로 다른 모델로 바뀌지 않는다. 그래도 결과에는 실제 `resolvedModel`과
-  `resolvedModelIsFallback`을 기록하고, 폴백 결과를 설정된 모델의 결과라고 보고하지 않는다.
+---
+description: 웹·앱 UI의 시각 디자인, 레이아웃, 반응형, 디자인 시스템, 디자인 리뷰를 다룰 때 읽는다.
+---
+
+# 프론트엔드 디자인
+
+## 누가 하는가
+
+- 별도 디자인 역할은 없다. 시각 판단은 그 화면을 소유한 사람이 한다. routine이면 Main이,
+  위임한 조각이면 그 `maker`가 디자인 계약을 정하고 구현까지 끝낸다.
+- 이미 채택된 디자인 시스템·토큰·레이아웃·컴포넌트 규약을 따르는 국소 유지보수에는 새 디자인
+  판단이 없다. routine으로 그대로 끝낸다.
+- 새 화면·리디자인, 방향이 정해지지 않은 구조처럼 실제로 새 시각 판단이 필요하고 서로 독립인
+  조각이 둘 이상일 때만 `large`로 분류한다. UI 파일을 건드린다는 사실 자체는 위임 근거가 아니다.
+- 화면 검증도 그 조각의 owner 몫이다. 결정론적 desktop/mobile, keyboard focus, overflow,
+  reduced motion 확인을 직접 실행하고 증거를 남긴다. Main은 계약·증거·중간 검수·최종 수용을
+  직접 판정한다.
+
+## 브리프에 반드시 적을 것
+
+명칭, 화면 내 배치, 표시·동작 트리거 조건, 반응형 거동 넷을 적는다. 이 넷이 비어 있으면
+시안부터 다시 만드는 재작업이 생긴다.
+
+## 디자인 경로
+
+- 시각 디자인이 포함된 작업에서는 아래 세 기본 디자인 스킬의 지침을 **반드시** 읽고 그 판단을
+  디자인 계약에 반영한다. 세 스킬의 이름과 실제 출처는 다음과 같다: `skill://seed-design`(미러
+  vendored, upstream `daangn/seed-design`), `skill://frontend-design`(설치 플러그인
+  `frontend-design@claude-plugins-official`), `skill://ui-ux-pro-max`(미러 vendored, upstream
+  `nextlevelbuilder/ui-ux-pro-max-skill`). 그 밖의 설치 스킬과 출처는 미러
+  `agent/skills/registry.json`이 정본이다. 출처를 다른 벤더나 OMP 기본 제공으로 표기하지 않으며,
+  없는 설치·업그레이드·마이그레이션 절차를 만들지 않는다.
+- 신규 화면·리디자인·기존 화면 분석은 `skill://hallmark`, 제네릭한 AI 스타일 감사와 제거는
+  `skill://kill-ai-slop`을 함께 사용한다. 그 밖의 스킬은 설치된 스킬 이름과 설명을 보고 이번
+  과제와 현재 프로젝트에 실제로 필요한 최소 집합만 스스로 고른다. 브리프가 스킬 목록을 미리 다
+  싣거나 사용자에게 고르라고 묻지 않는다.
+- UI·문서 산출물(화면 코드, 강의·보고용 HTML·문서)을 사용자에게 넘기기 전에
+  `node <kill-ai-slop 스킬 폴더>/scripts/scan.mjs <대상>`을 실행한다(프로필 기준
+  `~/.omp/agent/skills/kill-ai-slop/scripts/scan.mjs`). 적중은 판정이 아니라 단서이므로 해당
+  코드를 읽어 확정한다. 확정한 징후는 고치거나, 의도적으로 남긴 이유를 보고에 적는다. 이 절차는
+  산출 전 점검(advisory)이며 영구 gate나 CI 검사로 만들지 않는다.
+- 스캐너는 시각·코드 징후만 보고 한국어 문구는 보지 않는다. 한국어 사용자용 문구(UI 텍스트,
+  강의·문서, 데이터 파일 속 문항·보기·표 문자열)는 넘기기 전에 `skill://humanizer`의 감지
+  방식(「분석 결과」만 내고 파일은 고치지 않음)으로 점검한다. 사용자나 과제가 문구 수정을 요청하면
+  같은 스킬의 교정 절차를 범위 안 모든 문자열에 끝까지 적용한다. 굵은 글씨 강조는 문단당 최대
+  1개로 한다.
+- `skill://seed-design`은 위 셋 중 공통 설계 원칙 담당이다. 사용자가 SEED를 언급하지 않아도
+  이번 화면에 해당하는 공통 Foundations(정보 위계, 색 역할, 타이포그래피, spacing, 컴포넌트
+  상태, 접근성)와 영향받는 컴포넌트의 공통 가이드라인을 공식 인덱스에서 찾아 읽고, 적용 가능한
+  판단을 디자인 계약에 반영한다. 매 작업마다 모든 공식 문서를 훑지 않고 이번 작업에 해당하는
+  항목만 연다.
+- 이때도 정본은 현재 프로젝트의 기존 디자인 시스템이다. 공통 원칙이 기존 규약과 충돌하거나
+  이번 스택에 적용되지 않으면 기존 규약을 따르고 그 사실만 짧게 남긴다. 참고한 외부 시스템의
+  패키지·팔레트·프레임워크를 채택하거나 설치·마이그레이션·진단 절차로 넘어가지 않는다. 해당
+  시스템의 실제 구현·설치·진단은 사용자가 명시했거나 대상 워크스페이스가 이미 그것을 쓰는
+  경우로 유지한다.
+- 시각적 판단이 없는 동작 로직·백엔드·문구만 바꾸는 작업은 이 참고 대상이 아니다.
+- 기존 프로젝트면 프로젝트가 정본으로 삼는 UI·디자인 명세와 토큰을 먼저 찾아 채택된 디자인
+  계약의 기준으로 재사용하고, 현재 글꼴·레이아웃·컴포넌트·상태·반응형 경계에서 보존할 것과
+  바꿀 것을 구분한다. 영향받은 결정만 그 정본에 갱신한다. 기존 UI 명세 옆에 파일명 관례만으로
+  `DESIGN.md`를 만들거나 작은 스타일 변경을 모두 문서화하지 않으며, 새 디자인 시스템을 기존
+  시스템 옆에 하나 더 만들지 않는다.
+- 제품·사용자·화면의 단일 목적, 정보 위계, macrostructure, 제한된 색상, 글꼴 역할, spacing,
+  컴포넌트 상태, 반응형 전환, 접근성, 제품 고유 signature element 하나를 디자인 계약으로 만든다.
+- 대안을 작업 적합성, 정보 위계, 제품 고유성, 밀도, 접근성, 구현 가능성, AI-slop 기준으로
+  비교하고 채택·기각 이유를 남긴다. 실제 없는 수치·고객·후기·운영 데이터를 만들지 않는다.
+- 영구 Playwright 회귀는 반복할 가치가 있는 관찰 가능한 흐름이고 저장소의 기존 테스트 관례가
+  있을 때만 추가하며, 화면 변경마다 테스트나 의존성을 새로 만들지 않는다.
+
+## 모델 폴백
+
+- 위임 역할의 모델은 `config.yml`의 `modelRoles`와 `retry.fallbackChains` 항목으로 고정돼
+  있어 자동으로 다른 모델로 바뀌지 않는다. 그래도 결과에는 실제 `resolvedModel`과
+  `resolvedModelIsFallback`을 기록하고, 폴백 결과를 설정된 모델의 결과라고 보고하지 않는다.