# 🌙 Weekly Hermes Dreaming Report

> 점검 시각: 2026-10-11 03:33 KST · 관찰 구간: 2026-10-04 03:31 ~ 2026-10-11 03:31 KST · 범위: 기본 Hermes 프로필의 세션·스킬·cron과 현재 주입된 장기 memory/user profile. 다른 프로필의 실행 DB나 기억은 감사·수정하지 않았다. 이 문서는 **제안서**이며 기억·스킬·cron 설정은 변경하지 않았다. 이 보고서의 작성·웹뷰 게시는 요청된 전달 작업이다.

## 1. 이번 주 관찰 요약

- `hermes insights --days 7`의 점검 시점 값은 **313세션, 메시지 15,693건, 도구 호출 10,341건**. 플랫폼별 세션은 cron 261, subagent 42, Discord 9, CLI 1. 정기 실행이 사용량을 주도하므로 세션 수를 Son의 직접 요청 빈도로 읽으면 안 된다. 수치는 실행 중 증분될 수 있는 스냅샷이며, 다른 프로필을 포함한 전사 사용량이 아니다.
- skill load는 **43종·360회**, 당주 skill edit은 **0회**. 최다 호출은 `research-reporting-workflows` 196회, `grounded-citations` 23회, `learning-path-experience-design` 18회, `llm-wiki` 15회, `hermes-recurring-automation` 14회. 이 값은 호출/로드이지 품질·성공·사용자 선호도가 아니다.
- `hermes cron status`는 게이트웨이 실행 중, **활성 job 38개**를 보고했다. 개별 `last_status=ok`는 배포 본문, 신선도, 전달 성공까지 입증하지 않는다. 현재 Weekly Dreaming은 일요일 03:30 KST 활성, Discord 목적지가 지정돼 있다. 일시정지된 3D asset methodology job도 그대로 확인했다.
- `hermes curator run --dry-run`: **80개 후보 검사, 실제 상태 전이 0건**, consolidation 비활성. curator status에는 관리 스킬 80개 중 active 37/stale 43, archived 0; unmanaged 92개가 별도로 표시된다. 오래 사용하지 않았다는 표식은 삭제 권고가 아니다.
- 이번 주 직접 대화 표본은 적다. 사례의 방향은 읽을 수 있지만 **반복되는 사용자 성향**과 **cron 대량 실행의 패턴**을 같은 확실성으로 말하지 않는다.

## 2. 반복 패턴

### 성공 패턴

1. **근거 층위와 승인 단계 분리.** Companion bot 시장조사에서는 게임 전파 사례의 노출·체험·결제를 분리하고 위키 원본과 Mira 영역을 읽기 전용으로 두었다. 30일 챌린지 검토에서는 ‘서비스 URL 존재’와 ‘실사용·운영 가능’을 구분하고 기획 방향을 승인 요청 상태로 남겼다. Drive 위키에서도 현재 방향·이전 탐색·미승인 가안을 분리해 원문과 원격 산출물을 대조했다. 근거: 10/10 Companion 조사, 10/07 소개 페이지 기획 검토, 10/10 CultxRobot 위키 세션.
2. **cron의 수집→판단→검증 분리.** AI 뉴스·기술담론은 source-pack의 범위를 명시하고 웹뷰 링크를 내보내며, 게임잼/혜택 레이더는 수집과 검증·재배포 job을 분리했다. 다만 여기서 확인한 것은 cron 정의 및 일부 세션의 최종 출력이지 전 job의 원격 아티팩트 readback은 아니다.
3. **검증 불가를 승격하지 않음.** 10/10 웹디자인 immersive-game 심층 조사에서는 이미지 저장 후에도 실제 플레이/픽셀 판정을 못 했다고 밝히고 `degraded/held`로 카드 승격을 멈췄다. 이는 실패 은폐보다 낫다.

### 실패/마찰 패턴

1. **장시간 작업의 회수 경계.** 10/10 Companion 조사 과정의 기존 병렬 위임은 owner 종료로 terminal result가 불명확해 저장 근거부터 재회수했고, 10/09 책상 커스텀 조사 보조 작업은 600초 timeout이었다. *서로 다른 두 사례*로, 위임 인프라 전체 장애율을 산출한 것은 아니다. 저장된 출처와 결과 상태를 분리하고 작업을 짧게 쪼갤 필요가 있다.
2. **검증 경로의 제한.** 웹디자인 심층 job은 캡처 파일이 있어도 화면·상태 QA가 안 되는 실행환경에서 승격을 중지했다. 이번 주에 동일 장애가 여러 레인에서 반복됐는지는 따로 집계하지 않았다. 우선 반복률을 확인하고 필요할 때만 브라우저/시각 QA 경로를 보강하자.
3. **종료 후 자원 정리 누락에 대한 직접 교정.** 10/10 Son이 headless Chrome 정리를 지적했다. 당시 Windows 검사에서는 headless Chrome이 없고 일반 사용자 브라우저만 남아 종료하지 않았다. 교정 핵심은 ‘자기 작업용 브라우저·QA 서버의 종료 확인, 사용자 브라우저 보존’이며 이미 장기 memory에 들어갔다. 새 중복 항목을 만들 이유는 없다.
4. **메트릭의 의미 혼선 위험.** cron 세션 261개에 비해 직접 Discord/CLI 세션은 소수다. 10/10 웹디자인 아침 scout 8개가 모두 fresh여도 심층 검증이나 S/A exemplar 승격을 뜻하지 않았다. `ok`, fresh, 수집량을 실제 기여나 승인으로 바꿔 말하지 않는 운영 지표가 필요하다.

## 3. Memory 감사

| 분류 | 항목 | 이유 | 권장 조치 |
|---|---|---|---|
| 유지 | 단계별 승인, 원문 보존·검증, 프로필 데이터 소유 경계 | 이번 주 30일 챌린지·Companion·위키 검토에서 실제로 계속 적용. 현재 SOUL/프로필 계약과 합치 | 압축·삭제하지 말고 기준으로 유지 |
| 유지 | 3D asset 제작 위키 중단 / 3D methodology job 일시정지 | 제작 중지와 cron pause는 다른 층위이며, 재승인 전 재가동 금지는 현재 운영 방침. 오늘 job도 paused 확인 | 두 기록을 충돌이나 중복 삭제 대상으로 보지 않기 |
| 유지 | 작업용 headless Chrome·QA 서버 종료, 사용자 브라우저 보존 | 10/10 명시적 교정이며 이미 기억에 반영됨 | 추가 메모리 삽입 금지; 종료 체크는 QA 절차에서 사용 |
| 약화 | user profile의 ‘맥북 에어 M3를 중고 82만 원에 구매’ | 보유 기종은 지속성이 있지만 구매 가격은 장기 답변에서 점차 무관해질 수 있음. 이번 주 감사만으로 장비 교체 여부는 모름 | **제안:** 장비 보유·용도는 유지, 구매가/거래 세부는 과거 세션으로 내리기. 승인 전 그대로 둠 |
| 수정 | `학습 위키 운영: 3D methodology cron 일시정지; 나머지 현 상태 유지` 문구 | 나머지 위키의 개선은 무조건 증설이 아니라 실작업 기여·신선도·실패·중복을 주기 점검하는 것. 현재 문구도 그렇게 쓰여 있어 충돌은 없음 | 새 내용 추가보다 다음 개정 때만 간결화; 지금 변경 불필요 |
| 신규후보 | 장시간 위임의 중단/미회수 시 저장 산출물을 먼저 대조한다는 절차 | 한 번의 보조 작업 timeout과 한 번의 owner 종료 사례는 재사용 가능한 **절차**를 시사하지만 개인 성향이나 영구 환경 사실은 아님 | memory 추가 **보류**; 기존 스킬의 회수 체크 항목 후보로 이동 |
| 삭제후보 | 이번 주 PR·보고서 경로·일회성 숫자·시장조사 결과를 장기 memory로 올리는 안 | 곧 낡거나 프로젝트 자료로 이미 찾을 수 있다 | **신규 저장 대상에서 제외**. 기존 저장된 해당 항목을 발견·삭제했다는 뜻은 아님 |

현재 주입된 memory는 **2,197/2,200자**, user profile은 **1,360/1,375자**로 여유가 매우 작다. 무리한 신규 삽입보다 실질적으로 충돌/중복이 확인될 때 원문을 보존하며 교체 승인받는 편이 안전하다. 이 표는 현행 메모리의 일부 후보만 평가한 것이지 전 항목 검증 판정은 아니다.

## 4. Skill 감사

| 스킬/절차 | 관찰 | 권장 조치 |
|---|---|---|
| `research-reporting-workflows` + `grounded-citations` | 이번 주 load 196회·23회; 조사/레이더 업무의 핵심. 출처 확인과 독립검토 사례에 유효하나 반복 호출은 cron의 영향이 큼 | **유지.** 호출 수만 보고 품질 향상이나 사용자 선호라고 해석하지 말 것 |
| `hermes-recurring-automation` | 14회 load, Windows 네이티브 경로·정본/배포/신선도 계약을 이미 포함 | **유지.** 이번 주 사고 중 스킬에 없는 재현 가능한 결함이 확인될 때만 패치 승인 요청 |
| `web-design-reference-research-worker` | 활성 scout/deep job 다수가 이 경량 스킬을 사용. 10/10 한 레인은 QA 한계로 `degraded/held` | **개선 후보:** 실패 판정 자체는 유지하고 레인별 held 비율과 QA 불가 원인을 모은 후, 검증 가능한 브라우저 경로를 좁게 보강. 즉시 승격 규칙 완화 금지 |
| `agent-usage-analysis` | `insights`가 cron 비중과 skill load를 요약하지만 프로필별·성공률 분해는 따로 필요 | **유지/스킬화 경계:** 주간 리포트에 `default direct vs cron vs subagent`와 실재 프로필 실행을 분리하는 재사용 절차를 제안. 숫자를 메모리로 저장하지 않기 |
| `character-agent-persona-design` 등 stale 표시 스킬 | curator에서 stale 43개이지만 전체 명단별 의존·수명은 감사하지 않았고 Mira/캐릭터 계약에 연결될 수 있음 | **아카이브 보류.** 90일 기준·활성 프로젝트 의존·원문 회복 경로를 개별 확인한 뒤 승인받기; 이번 주 자동 아카이브/삭제 없음 |
| `learning-path-experience-design` / 기획 검토 절차 | 18회 load와 30일 챌린지에서 ‘기획 후보와 확정/실증 구분’이 중요하게 작동 | **유지.** 프로젝트별 미확정 숫자는 스킬·장기기억이 아닌 해당 기획 문서에 남기기 |

Curator의 `dry-run`은 **이번 실행의 자동 전이 없음**을 보여줄 뿐, 모든 stale 스킬이 필요하다거나 92개 unmanaged 스킬의 존폐를 판정하지 않는다. 직접적인 skill patch/delete는 하지 않았다.

## 5. Cron/자동화 감사

- **잘 작동하는 자동화:** `cron-health-summary`는 10/10 `ok`, `cron-auto-recovery-watchdog`는 10/11 `ok`로 기재되고 게이트웨이 tick이 살아 있다. 뉴스/레이더 계열 일부 실행은 웹뷰 링크까지 생성했다. **여기서 공통으로 검증한 것은 정의·마지막 상태·세션 출력**, 전체 배포 URL의 동시 원격 readback은 아니다. 3D asset methodology 일시정지는 유지해야 한다.
- **개선 자동화 A — 성공 판정층:** Weekly Dreaming/health summary에 최근 7일 job별 `last_status`, 비어 있는 최종 출력, stale 소스, 실제 latest 아티팩트 조회를 분리해 요약하는 *읽기 전용* 감사안. `ok`만으로 게시 완료라고 쓰지 않는다. 초안·테스트 후 승인 시 반영.
- **개선 자동화 B — 웹디자인:** 8개 아침 scout와 8개 저녁 deep job 및 digest의 `fresh scout → verified deep → canonical 승격/held` 수를 비교하는 주간 운영 지표 후보. 캡처 수와 실제 픽셀/상태 QA를 별도 칼럼으로 둔다. 기존 job을 무단 수정하거나 QA 게이트를 내리지 않는다.
- **새 후보 — 위임 회수 체크:** parent 종료/timeout 뒤 저장 증거와 terminal 결과 상태를 대조하는 읽기 전용 주간 체크. 반복률 확인 전 신규 cron을 설치하지 말고 기존 주간 감사 절차에서 먼저 표본을 모은다.
- **유지할 비활성 상태:** SQAF 구형 job, 서비스/게임 시장 스카우트, 3D asset methodology 등 paused job은 현재 목록에 그대로 남아 있다. `next run`의 옛 날짜가 떠도 paused를 고장으로 간주하거나 자동 resume하지 않는다.

## 6. 다음 주 우선순위

1. **P1 — 승인 후에만** memory에서 보유 장비·용도와 구매가 같은 단기 세부를 분리할지 결정. 지금은 99% 용량이므로 새 일회성 결과를 추가하지 않는다.
2. **P1 — 읽기 전용:** 최근 7일 활성 cron에서 `ok`/비어 있는 출력/실제 웹뷰 최신 링크·원본·source freshness를 분리해 소수 대표 job부터 대조. 오류가 있으면 job ID·마지막 정상 아티팩트·재현 조건만 먼저 보고한다.
3. **P2 — 웹디자인 품질:** scout 완료율 대신 저녁 deep의 verified/held 및 held 사유를 1주간 집계해 브라우저 QA 경로 개선이 필요한 레인만 좁힌다.
4. **P2 — 위임 회수:** 다음 장시간 조사 1건에서 source packet 저장→짧은 위임→terminal result 확인→미회수 파일 대조를 시범 운영하고, 성공 여부를 원 parent 세션에서 확인한다.
5. **P3 — 큐레이터:** stale 목록에서 실제 의존이 낮고 최근 90일 무사용인 개별 스킬만 찾아 승인용 아카이브 후보를 다시 낸다. 자동 curator 실행/아카이브는 현재 요청에 포함되지 않는다.

## 7. 승인 요청

- [ ] **memory A 수정:** user profile의 맥북 구매가·거래 디테일을 줄이고 사용 중인 기종·용도만 남기는 개정을 승인할지. 승인 전 현행 유지.
- [ ] **skill B 패치:** `web-design-reference-research-worker`에 검증 불가능한 화면/게임 상태의 held 사유를 표준화하는 좁은 보완을, held 표본 집계 후 승인할지. 지금은 패치 없음.
- [ ] **skill C 아카이브:** curator stale 항목 중 실제 미사용·비의존 스킬을 **개별 제시받은 뒤** 수동 아카이브할지. 대상 미확정, 이번 주 삭제 권고 없음.
- [ ] **cron D 수정:** `cron-health-summary` 또는 `weekly-hermes-dreaming`에 성공 상태와 실제 배포·신선도 readback의 차이를 표시하는 읽기 전용 감사 단계를 추가할지. job 설정 변경 없음.
- [ ] **cron E 수정:** 웹디자인 digest의 scout/deep/held 판정을 별도 지표로 넣을지. 먼저 현재 산출물에서 지표를 시험할 것.

**감사 근거:** 기본 프로필 `hermes insights --days 7`, `hermes cron list --all`·`status`, `hermes curator status`·`usage`·`run --dry-run`, 10/06~10/10 직접 세션 및 10/10 웹디자인/브리핑 cron 표본. 성공·실패의 사례 해석은 세션 기록에 기반하며, 보고서에 없는 프로필이나 Discord 전송 readback은 확인했다고 주장하지 않는다.