seokang-sk 0.2.3 → 0.4.0

package/README.MD

@@ -40,16 +40,20 @@ sk status
 sk setup --configure-db-safe-read
 ```
 
-- Notion 문서까지 함께 쓸 계획이면 설치 후 한 번 더 아래 명령을 실행한다.
+- Notion publish 자동화까지 쓸 계획이면 설치 후 한 번 더 아래 명령을 실행한다.
 
 ```bash
 sk setup --configure-notion
 ```
 
-- `Records` / `Projects` 데이터베이스 URL에 Notion id가 들어 있으면 `data source id`는 setup 중 자동으로 추출한다.
+- `sk setup --configure-notion`은 MCP를 직접 호출하지 않는다. URL, `collection://...`, `?data_source_id=...`, 또는 MCP `fetch` 결과에 포함된 `<data-source url="collection://...">` 값만 local config에 저장한다.
+- 작업 턴의 기본 기록은 `~/.codex/sk/notion/outbox/pending` local Markdown이고, Codex 자동화가 이를 Notion으로 publish한다.
+- Notion publish fast path를 미리 채우려면 `--track`, `--records-data-source-id`, `--projects-data-source-id`, `--project-page-url`, `--history-data-source-id`, `--record-type`을 함께 줄 수 있다.
 
-- Notion 문서 기록이 `invalid_grant`, `unauthorized`, `forbidden` 같은 인증 오류로 실패하면 아래 명령으로 MCP 인증을 다시 연결한다.
+- Notion publish 자동화가 `invalid_grant`, `unauthorized`, `forbidden` 같은 인증 오류로 실패하면 아래 명령으로 MCP 인증을 다시 연결한다.
 - `Tool ... not found`처럼 특정 Notion tool만 빠진 경우는 로그인 문제가 아닐 수 있으니, exact error를 남기고 남아 있는 Notion MCP tool로 우회 가능한지 먼저 확인한다.
+- `notion-query-data-sources` / `query_data_sources`는 더 이상 Notion publish의 1차 탐색 경로로 두지 않는다.
+- local config에 data source id와 track별 History 위치가 있으면 `fetch` / page write callable을 먼저 쓰고, lookup이 필요할 때만 `search -> fetch` 순서로 보완한다.
 
 ```bash
 codex mcp login notion
@@ -57,13 +61,24 @@ codex mcp login notion
 
 자세한 구조 문서:
 
-- `docs/sk-setup-architecture.md`
-- `docs/sk-cli-guide.md`
-- `docs/sk-notion-workspace.md`
+- `docs/setup/sk-setup-architecture.md`
+- `docs/setup/sk-cli-guide.md`
+- `docs/setup/sk-notion-workspace.md`
+- `docs/setup/codex-workflows.md`
+- `docs/setup/README.md`
+- `docs/refactor/README.md`
+- `docs/playbooks/README.md`
+- `docs/templates/README.md`
+
+자동화 기준 문서:
+
+- `docs/automations/server-log-check.md`
+- `docs/automations/daily-thread-retrospective.md`
+- `docs/automations/notion-outbox-publish.md`
 
 이 저장소는 SeoKang 개인 개발 워크플로를 Codex Skill과 공용 Codex 데스크톱 설정 원본으로 관리하기 위한 저장소다.
 
-기능 개발, 버그 수정, 리팩토링, 기획, 배포뿐 아니라 문서화와 Notion 기록까지 포함한 작업 방식을 정리한다.
+기능 개발, 버그 수정, 리팩토링, 기획, 배포뿐 아니라 문서화와 Notion outbox publish까지 포함한 작업 방식을 정리한다.
 
 ---
 
@@ -71,6 +86,13 @@ codex mcp login notion
 
 ```text
 .
+|- docs/
+|  |- setup/               # 설치/런타임/Notion/Subagent 가이드
+|  |- automations/         # 자동화 기준 문서
+|  |- policies/            # 공통 정책
+|  |- playbooks/           # specialist 체크리스트
+|  |- templates/           # 출력/기록 템플릿
+|  |- refactor/            # 구조 개편 decision log
 |- skills/
 |  |- sk-feature-workflow  # 기능 작업 메인 오케스트레이터
 |  |- sk-bugfix-workflow   # 버그 수정 워크플로
@@ -85,15 +107,34 @@ codex mcp login notion
 |  |- config/              # ~/.codex/config.toml 공용 원본
 |  |- agents/              # ~/.codex/agents 공용 원본
 |  |- rules/               # ~/.codex/rules 공용 원본
+|- templates/
+|  |- agent/               # 프로젝트용 AGENTS.md bootstrap 템플릿
 |- scripts/                # 공용 설치 / 보조 스크립트
 ```
 
 - 실제 skill 엔트리는 `skills/sk-*/SKILL.md`다.
 
+## 하네스 지원 파일
+
+- 작업 계약 템플릿: `docs/templates/task-contract.md`
+- 영향도 맵 템플릿: `docs/templates/impact-map.md`
+- 하네스 워크플로 기준: `docs/playbooks/harness-workflow.md`
+- default/fallback 체크: `node scripts/check_no_unauthorized_defaults.mjs <path ...>`
+- DDL comment 체크: `node scripts/check_ddl_comments.mjs <path ...>`
+- 문서 링크 무결성 체크: `node scripts/check_docs_integrity.mjs <path ...>`
+- GPT-5.6 기본/agent 모델 배치 체크: `node scripts/check_codex_model_routing.mjs`
+- custom agent 실제 적용 smoke: 호출 직전 UTC 시각과 `spawn_agent`가 반환한 task path를 사용해 `node scripts/check_codex_agent_runtime.mjs --role <agent-name> --agent-path <task-name> --since <ISO-8601>` 실행 (`--thread-id <uuid>`도 지원)
+- CLI smoke 체크: `node scripts/check_sk_cli_smoke.mjs`
+- UI runtime router 체크: `node scripts/check_ui_runtime_router.mjs`
+- automation safety 체크: `node scripts/check_automation_safety.mjs`
+- 전체 하네스: `npm run check:harness`
+- 하네스는 subagent 대체가 아니라 preflight/check 레이어다.
+
 ## 어디를 수정하나
 
 - skill 동작 변경: `skills/sk-*/SKILL.md`
 - 설치/런타임 설정 변경: `codex-config/**`, `scripts/**`
+- 프로젝트용 AGENTS.md 기본 틀 변경: `templates/agent/*.md`
 - 사용법/운영 가이드 변경: `docs/**`, `README.MD`
 
 ---
@@ -108,7 +149,8 @@ codex mcp login notion
 ## 실행 방식
 
 - `sk`는 별도 앱 UI가 아니라 CLI 명령으로만 동작한다.
-- `sk setup`이 sync하는 대상은 `~/.codex`이고, `sk init`은 현재 프로젝트의 `.sk/` 상태를 준비한다.
+- `sk setup`이 sync하는 대상은 `~/.codex`이고, `sk init`은 현재 프로젝트의 `.sk/` 상태를 준비한다. 필요하면 `--agents-md`로 프로젝트 루트 `AGENTS.md`도 함께 만든다.
+- 옵션과 예시는 `sk help`, `sk help <command>`, `<command> --help`로 바로 확인한다. 예: `sk help init`, `sk init --help`
 - OMX가 `omx setup`처럼 짧아 보이는 이유는 npm 전역 CLI로 설치되기 때문이다.
 - 지금 `sk`도 최초 1회만 `npm link`로 등록하면 이후에는 `sk setup`, `sk init`만 기억하면 된다.
 - 실행 전제:
@@ -133,7 +175,7 @@ sk check
 sk status
 ```
 
-- Notion 기록을 쓸 계획이면 최초 1회는 아래처럼 사용자별 Notion 위치도 같이 설정한다.
+- Notion publish 자동화를 쓸 계획이면 최초 1회는 아래처럼 사용자별 Notion 위치도 같이 설정한다.
 
 ```bash
 sk setup --configure-notion
@@ -143,7 +185,7 @@ sk setup --configure-notion
   - `sk init --cwd /path/to/project`
   - `sk status --cwd /path/to/project`
 - npm link 없이도 저장소 안에서는 fallback으로 `sh ./sk setup`을 계속 쓸 수 있다.
-- `sk` 사용 흐름 설명은 `docs/sk-cli-guide.md`를 기준 문서로 본다.
+- `sk` 사용 흐름 설명은 `docs/setup/sk-cli-guide.md`를 기준 문서로 본다.
 
 ## 첫 설치 예제
 
@@ -227,10 +269,15 @@ sh ./sk status
 - `~/.codex/rules/skills-shared.rules`는 저장소 원본을 그대로 복사한다.
 - `~/.codex/sk/notion/workspace.json`은 사용자별 Notion workspace 설정 파일이다.
 - setup 중 기존 대상 파일이 바뀌면 현재 작업 디렉터리의 `.sk/backups/setup/**` 아래에 백업을 남긴다.
+- 기존 활성 config가 source와 다르면 `sk setup`은 config 전체 교체만 건너뛰고 app-managed key를 보존한다. agent만 갱신할 때는 `sk sync-agents --dry-run` 후 `sk sync-agents`를 사용한다.
 - 공용 기본값은 `approval_policy = "never"`, `sandbox_mode = "danger-full-access"`다.
-- 현재 설정은 Playwright MCP 승인창이 `workspace-write + never`에서도 계속 나타나는 현상을 확인한 뒤, `danger-full-access + never`까지 실험해 보기 위한 강한 기본값이다.
+- 기본 작업 모델은 `gpt-5.6-sol`, reasoning effort는 `high`다.
+- 탐색형 custom agent는 Terra를 사용하고, 명세·리뷰·DB·UI/Figma 역할은 Sol High를 사용한다. 정확한 배치는 `docs/setup/codex-subagents.md`를 따른다.
+- Ultra는 상시 기본값으로 두지 않고, 대규모 구조 감사처럼 병렬 분해 이득이 분명한 일회성 작업에서만 선택한다.
+- 현재 설정은 승인창 없이 공용 설정 동기화를 진행하기 위한 강한 기본값이며, UI 런타임 검증은 Playwright MCP 대신 Browser / Chrome / Computer Use 라우터를 기본 경로로 둔다.
 - CLI로 쓰면 `codex --sandbox danger-full-access -a never`와 같은 기준이다.
 - shared subagent를 실제로 사용할 수 있도록 공용 source에서 `multi_agent` feature를 켠다.
+- `/goal`, Automations, Skills 중심 운영 기준은 `docs/setup/codex-workflows.md`를 따른다.
 
 설치 명령:
 
@@ -284,28 +331,33 @@ sk search "reviewer"
 
 상태 디렉터리:
 
-- `sk init`은 현재 작업 디렉터리 아래 `.sk/`를 만든다.
+- `sk init`은 현재 작업 디렉터리 아래 `.sk/`를 만들고, `--agents-md`를 붙이면 프로젝트 루트 `AGENTS.md`도 함께 만든다.
 - `sk setup`은 관리용 저장소 `~/.agents/skills/.sk/`를 setup 상태/백업 기준 경로로 사용한다.
 - `.sk/setup-scope.json`: 마지막 init/setup 기록
 - `.sk/project-memory.json`: 다음 세션이 읽을 구조화 메모
 - `.sk/notepad.md`: 우선 컨텍스트/작업 메모
 - `.sk/backups/setup/**`: setup 중 덮어쓰기 전에 남긴 백업
-- Notion workspace 설정은 `~/.codex/sk/notion/workspace.json`을 쓴다.
+- Notion workspace 설정은 `~/.codex/sk/notion/workspace.json`을 쓰고, 작업 문서 outbox는 `~/.codex/sk/notion/outbox`를 쓴다.
 
 중요 제한:
 
 - `skills-shared.rules`는 shell prefix 자동 허용만 처리한다.
-- Notion/Figma/Playwright 같은 MCP/tool 승인 정책은 `shared-config.toml`에서 함께 관리한다.
+- Notion/Figma MCP와 Browser / Chrome / Computer Use를 나누는 런타임 검증 라우팅은 `shared-config.toml`과 관련 playbook에서 함께 관리한다.
 - 공용 subagent 등록은 `shared-config.toml`의 `[agents.*]`와 `codex-config/agents/seokang/*.toml`에서 함께 관리한다.
 - `danger-full-access`는 workspace 밖 파일, 홈 디렉터리, SSH, 네트워크, 외부 명령 실행까지 sandbox 제한 없이 진행할 수 있게 한다.
 - `approval_policy = "never"`라서 승인창도 띄우지 않는다.
-- 기본 분석용 공용 subagent는 `read-only sandbox`를 기본으로 하며, `Notion MCP`와 `Playwright`는 agent 파일에서 명시적으로 비활성화한다.
-- 브라우저 재현, 콘솔/네트워크 증거, Notion 조회/기록은 전용 tool subagent를 두지 않고 메인 agent가 직접 수행한다.
-- Notion 관련 조회/기록은 MCP 우선을 기본으로 한다. 인증/권한 실패가 나면 exact error를 먼저 보고한다.
-- Notion 실패를 숨기기 위해 Playwright로 notion.so를 기본 경로처럼 사용하지 않는다. 웹 UI fallback은 사용자가 명시적으로 요청한 경우에만 허용한다.
-- 같은 설정은 Playwright만이 아니라 현재 세션 전체에 적용된다.
+- 기본 분석용 공용 subagent TOML은 `read-only sandbox`로 두지만, 현재 task의 live permission override가 있으면 부모 권한이 우선할 수 있다. `Notion MCP`, `Playwright`, `Browser`, `Chrome`, `Computer Use` 같은 tool 작업은 agent 지침에서 금지한다.
+- 브라우저 재현, 콘솔/네트워크 증거, Notion 조회/publish는 전용 tool subagent를 두지 않고 메인 agent 또는 Codex 자동화가 수행한다.
+- Notion과 Figma 관련 조회/작업은 plugin(MCP) 경로를 기본으로 사용한다.
+- 작업 문서 작성은 local outbox를 기본으로 하고, Notion 조회/publish는 MCP 우선을 기본으로 한다. 인증/권한 실패가 나면 exact error를 먼저 보고한다.
+- Figma도 browser/manual 확인보다 MCP tool 호출을 기본 경로로 두고, 우회는 exact error와 범위 불명확성이 정리된 뒤에만 사용한다.
+- Notion 실패를 숨기기 위해 브라우저 자동화로 notion.so를 기본 경로처럼 사용하지 않는다. 웹 UI fallback은 사용자가 명시적으로 요청한 경우에만 허용한다.
+- UI 런타임 검증이 필요하면 메인 agent가 Browser / Chrome / Computer Use 라우터로 실제 앱/브라우저 상태를 확인한다.
+- 로컬 dev URL은 Browser, 사용자 Chrome 세션/쿠키/기존 탭은 Chrome, 앱/OS-level UI는 Computer Use를 우선한다.
+- Computer Use로 브라우저 검증을 해야 하면 사용자 현재 탭을 쓰지 않고 전용 테스트 창 또는 탭을 열어 검증한 뒤 닫는다.
+- 사용자가 명시적으로 Playwright를 요청하지 않았다면 UI 런타임 검증에서 `PWCLI`, `playwright_cli.sh`, `@playwright/mcp`, standalone Playwright 기반 browser-use fallback을 사용하지 않는다.
 - 이 설정은 보안 유지형이 아니라 실험/자동화 우선 설정이다.
-- 현재 데스크톱 빌드 기준으로도 Playwright MCP 승인창 제거는 보장되지 않으므로, 실제 효과는 새 세션에서 직접 확인해야 한다.
+- Browser / Chrome / Computer Use 플러그인 제공 여부는 Codex 데스크톱 세션의 tool surface를 기준으로 확인한다.
 
 다른 프로젝트에도 프로젝트별 rules가 필요하면 각 프로젝트 루트의 `.codex/rules/*.rules`에 별도로 추가해서 관리한다.
 
@@ -351,18 +403,19 @@ LOCAL_JAR_PATH=./build/libs/km-admin-api.jar
 - API 계약 변경 시 전체 이름/응답 구조 확인
 - 리팩터링은 동작 유지가 전제
 - build 성공과 정상 동작은 별개로 본다
-- Notion 기록을 임의로 생략하지 않는다
+- Notion outbox 문서를 임의로 생략하지 않는다
 
 ---
 
-## 설치 스크립트 사용법
+## 최초 설치 스크립트 사용법
 
 - 이 설치 스크립트는 이 저장소의 공용 Codex 설정을 로컬 `~/.codex`로 한 번에 복사/동기화한다.
 - 같은 설치 스크립트가 공용 subagent도 `~/.codex/agents/seokang`으로 함께 동기화한다.
 - 내부적으로는 `scripts/sk.mjs setup` 흐름을 호출한다.
 - macOS shell 설치 예시: `sh ~/.agents/skills/scripts/install_codex_shared_setup.sh`
 - Windows Git Bash shell 설치 예시: `sh /c/Users/<user>/.agents/skills/scripts/install_codex_shared_setup.sh`
-- 이 저장소의 공용 Codex 설정이 바뀌면 같은 설치 스크립트를 다시 실행한다.
+- 기존 설치에서 shared agent만 바뀌면 설치 스크립트를 다시 실행하지 않고 `sk sync-agents`를 사용한다.
+- source와 다른 활성 config는 setup에서 교체하지 않고 그대로 보존된다.
 - 로컬 대상 파일이 source와 다르면 설치 스크립트가 덮어쓰기 전에 `.sk/backups/setup/**` 아래에 백업을 남긴다.
 - Windows에서 `sh`를 인식하지 못하면 Git for Windows(Git Bash)를 설치한 뒤 같은 `.sh` 명령을 다시 실행한다.
 
@@ -371,17 +424,25 @@ LOCAL_JAR_PATH=./build/libs/km-admin-api.jar
 - `setup`
   - `~/.agents/skills` 저장소를 준비하거나 재사용하고, config/rules/shared agents를 sync한 뒤 check까지 실행한다.
   - 최초 setup 시 interactive 환경이면 사용자별 Notion workspace 설정 파일도 함께 만들 수 있다.
-  - `--dry-run`, `--verbose`, `--configure-notion`, `--skip-notion`을 지원한다.
+  - `--dry-run`, `--verbose`, `--configure-notion`, `--skip-notion`과 Notion fast path 옵션(`--records-data-source-id`, `--projects-data-source-id`, `--project-page-url`, `--history-data-source-id`, `--record-type`)을 지원한다.
+- `sync-agents`
+  - `config.toml`, rules, Notion, 프로젝트 상태를 건드리지 않고 `~/.codex/agents/seokang/*.toml`만 백업 후 동기화한다.
+  - 기존 설치의 모델/지침 변경은 `sk sync-agents --dry-run` 확인 후 `sk sync-agents`로 반영한다.
+  - `--scope <user|project>`, `--cwd <path>`, `--dry-run`, `--verbose`를 지원한다.
 - `init`
   - 현재 프로젝트 루트의 `.sk/` 상태 파일을 준비한다.
-  - `--cwd <path>`, `--dry-run`, `--force`, `--verbose`를 지원한다.
+  - `--agents-md`를 붙이면 프로젝트 루트에 `AGENTS.md` 초안도 함께 만든다.
+  - 기존 `--agent-md`는 호환 alias로 유지한다.
+  - `--cwd <path>`, `--agents-md`, `--agent-md`, `--dry-run`, `--force`, `--verbose`를 지원한다.
 - `check`
   - 현재 설치가 source와 일치하는지 확인한다.
-  - Notion workspace 설정 파일 존재 여부와 필수 필드도 함께 확인한다.
-  - `--cwd <path>`, `--json`을 지원한다.
+  - Codex workflow 상태(`multi_agent`, `/goal`, automation 기준 문서, skill 원본)도 함께 확인한다.
+  - Notion workspace 설정 파일, outbox 자동화 기준 문서, fast path cache 준비 상태도 함께 확인한다.
+  - drift나 선택적 설정 경고에는 `recommended_action`을 함께 제공한다.
+  - `--cwd <path>`, `--track <name>`, `--json`을 지원한다.
 - `status`
   - 현재 `.sk` 상태, memory/notepad, Notion workspace 설정 상태, 최근 backup, check 결과를 함께 보여준다.
-  - `--cwd <path>`, `--json`을 지원한다.
+  - `--cwd <path>`, `--track <name>`, `--json`을 지원한다.
 - `memory`
   - `.sk/project-memory.json`과 `.sk/notepad.md`를 초기화하고 읽는다.
   - `show`, `init`, `add-note`, `add-directive`를 지원한다.
@@ -403,9 +464,30 @@ LOCAL_JAR_PATH=./build/libs/km-admin-api.jar
   - `db_impact_reviewer`
   - `ui_flow_mapper`
   - `design_checker`
-- 설정과 유지보수 방법은 `docs/codex-subagents.md`에 정리했다.
-- `sk-feature`, `sk-bugfix`, `sk-db`는 shared subagent가 설치되어 있으면 사용자가 따로 지시하지 않아도 내부적으로 dispatch할 수 있도록 설계한다.
-- 기본 분석용 subagent는 `Notion MCP`와 `Playwright`를 직접 사용하지 않고, 이런 tool 작업은 메인 agent가 맡는다.
+- 설정과 유지보수 방법은 `docs/setup/codex-subagents.md`에 정리했다.
+- 병렬 read/analyze/review가 실제로 유리할 때만 Codex 런타임이 적합한 custom agent를 내부적으로 고른다.
+- 최소 호출 수를 강제하거나 위임 판단을 사용자 출력 형식으로 노출하지 않는다.
+- 기본 분석용 subagent는 `Notion MCP`, `Playwright`, `Browser`, `Chrome`, `Computer Use`를 직접 사용하지 않고, 이런 tool 작업은 메인 agent가 맡는다.
+
+## 프로젝트 AGENTS.md
+
+- `AGENTS.md`는 Codex가 기본 탐색하는 프로젝트별 고정 규칙 문서다.
+- `README`는 사람용 개요/설치 문서, `.sk/*`는 세션 메모, `AGENTS.md`는 agent가 먼저 읽어야 할 프로젝트 계약서로 분리해서 쓴다.
+- 기존 `AGENT.MD`만 있는 프로젝트는 `sk init --agents-md` 실행 시 내용을 보존해 `AGENTS.md`로 마이그레이션한다. 공용 config의 fallback은 전환 기간 호환용이다.
+- 성능 차이가 크지 않은 한 기본 초안은 한글로 생성하고, 명령어/식별자/경로만 원문을 유지한다.
+- 새 프로젝트에서 바로 만들려면 아래처럼 시작한다.
+
+```bash
+sk init --agents-md
+```
+
+- 다른 프로젝트를 미리 준비할 때는 아래처럼 쓴다.
+
+```bash
+sk init --cwd /path/to/project --agents-md
+```
+
+- 기본 템플릿 원본은 `templates/agent/base.md`, `templates/agent/frontend.md`, `templates/agent/backend.md`, `templates/agent/codex.md`다.
 
 ## 작성자
 

package/docs/automations/daily-thread-retrospective.md

@@ -0,0 +1,313 @@
+# 전일 대화 회고 자동화
+
+## 목적
+- Codex에서 전날 갱신된 모든 대화 thread를 읽고 반복 마찰을 개선 backlog로 정리한다.
+- 자동화 설정값 자체는 로컬 Codex에 저장되더라도, 이 문서를 기준으로 다른 디바이스에서 동일한 자동화를 다시 만들 수 있게 한다.
+- 특정 제품 레포가 아니라 `skills` 저장소에서 자동화 기준과 스크립트를 함께 관리한다.
+
+---
+
+## 왜 이 프로젝트를 workspace로 쓰나
+- 이 자동화의 기준 문서와 실행 스크립트가 모두 `~/.agents/skills`에 있다.
+- 실제 회고 데이터는 `~/.codex/session_index.jsonl`, `~/.codex/archived_sessions`, `~/.codex/state_5.sqlite`, `~/.codex/logs_1.sqlite`에서 읽는다.
+- thread 목록과 rollout 경로는 `sqlite3`로 `state_5.sqlite`를 읽어 확보한다.
+- 그래서 자동화 workspace는 제품 프로젝트가 아니라 `~/.agents/skills`로 잡는 것이 맞다.
+- 나중에 특정 프로젝트만 보고 싶으면 `--cwd-filter /path/to/project` 옵션으로 범위를 좁히면 된다.
+
+---
+
+## 무엇이 공유되고 무엇을 각 데스크톱에서 다시 해야 하나
+- 저장소에서 공유되는 것:
+  - 기준 문서 `docs/automations/daily-thread-retrospective.md`
+  - 실행 스크립트 `scripts/daily_thread_retrospective.sh`
+  - 수집 로직 `scripts/daily_thread_retrospective.mjs`
+  - 복붙용 프롬프트 파일 `docs/automations/daily-thread-retrospective.prompt.ko.md`
+- 각 데스크톱에서 한 번씩 다시 해야 하는 것:
+  - Codex Desktop 안에서 자동화 생성
+  - 실행 시각 설정
+  - 활성화 상태 확인
+- 이유:
+  - 자동화 등록 정보 자체는 각 로컬 Codex 환경에 저장되기 때문이다.
+  - 그래서 저장소는 `기준과 스크립트`를 공유하고, 각 데스크톱은 그 기준으로 `자동화 한 건`을 직접 만들어야 한다.
+- 권장 방식:
+  - 가능하면 모든 데스크톱에서 저장소 경로를 `~/.agents/skills`로 맞춘다.
+  - 경로를 다르게 둘 경우에는 workspace와 프롬프트 안의 스크립트 경로를 같은 실제 경로로 함께 바꾼다.
+
+---
+
+## 공통 원칙
+- 자동화는 사용자를 비난하지 않고 `반복 마찰`을 개선 과제로 바꾸는 역할만 한다.
+- 전날 전체 thread를 다 읽더라도, 최종 보고서는 상위 3~5개 개선 후보만 남긴다.
+- 근거가 약하면 억지 개선안을 만들지 않고 `유의미한 반복 마찰 없음`으로 종료한다.
+- 욕설이나 강한 표현은 signal로만 쓰고, 최종 보고서 제목이나 첫 문장에 그대로 재노출하지 않는다.
+- `Process exited with code N` 같은 래퍼 오류는 같은 출력 안에 더 구체적인 원인이 없을 때만 핵심 시그니처로 취급한다.
+- 개선 후보는 먼저 `destination`을 분류하고, 그 결과에 따라 다음 단계를 다르게 쓴다.
+- 개선 후보는 `destination`만 고르지 말고 `promotion lane`도 함께 판단한다.
+- 모든 개선 후보를 `sk-feature` 수정으로 몰아주지 않는다.
+- 메모리는 `$CODEX_HOME` 상대경로 대신 `~/.codex/automations/daily-thread-retrospective/memory.md`에 직접 갱신한다.
+
+---
+
+## 개선 후보 destination taxonomy
+
+회고는 개선 후보를 만들기 전에 먼저 수정 레이어를 분류한다.
+
+- `shared-policy`
+  - 여러 skill이 같이 따르는 공통 규칙
+  - 예: DB safe-read, 공통 Notion logging, artifact boundary
+- `router`
+  - `sk-feature`의 요청 모드/대상/분기 판단
+  - 예: planning vs implementation 판정, target artifact resolution
+- `playbook`
+  - Figma / connector / UI runtime 같은 specialist checklist
+  - 예: dense Figma completion contract, connector error taxonomy
+- `template`
+  - planning / request mapping / Notion / proof artifact 양식
+- `bootstrap-config`
+  - `codex-config/**`, `scripts/**`, 설치/셋업, 공용 config
+- `docs-automation`
+  - `docs/automations/**`, 자동화 prompt, automation guide
+- `product-plan`
+  - 제품 요구, 운영 흐름, 정책 판단, 명세 정리
+- `product-bugfix`
+  - 실제 제품 버그/회귀
+- `no-action`
+  - 근거 부족, 이미 해결됨, 중복, backlog 가치 낮음
+
+## promotion lane taxonomy
+
+- `check`
+  - 정적 패턴이나 파일 구조로 기계 검출 가능
+  - 예: 근거 없는 default, 깨진 문서 링크, DDL COMMENT 누락
+- `template`
+  - 같은 출력/증거/형식 누락 반복
+  - 예: request mapping, proof artifact, lock table 누락
+- `playbook`
+  - specialist checklist 부족
+  - 예: Figma fidelity, connector preflight, UI runtime verification
+- `policy`
+  - 여러 skill 공통 불변식
+- `router`
+  - planning/implementation/target artifact 오판
+- `no-action`
+  - 단발성, 근거 약함, 이미 해결됨
+
+### 승격 임계값
+
+- 아래 중 하나를 만족할 때만 기본적으로 `승격 후보`로 본다.
+  - 같은 날 2개 이상 thread에서 같은 마찰이 확인됨
+  - 이전 `memory.md`의 미처리 후보와 오늘 후보가 다시 겹침
+- 위 조건을 만족하지 않으면 강한 근거가 없는 한 `no-action` 또는 관찰 backlog로 남긴다.
+
+### 승격 기본 힌트
+
+- 같은 섹션/증거/형식 누락 반복 → `template`
+- 문자열/설정/링크/DDL 패턴처럼 정적으로 잡을 수 있음 → `check`
+- 시각 품질/connector 처리/런타임 검증 부족 → `playbook`
+- 공통 불변식 누락 → `policy`
+- 모드/대상 오판 → `router`
+
+다음 단계 작성 규칙:
+
+- `shared-policy` → `docs/policies/... 수정`
+- `router` → `skills/sk-feature-workflow/SKILL.md` 또는 `$sk-feature ...`
+- `playbook` → `docs/playbooks/... 수정`
+- `template` → `docs/templates/... 수정`
+- `bootstrap-config` → `scripts/...` 또는 `codex-config/...` 수정
+- `docs-automation` → `docs/automations/...` 또는 `$sk-docs ...`
+- `product-plan` → `$sk-plan ...`
+- `product-bugfix` → `$sk-bugfix ...`
+- `no-action` → `다음 단계: 없음`
+
+promotion lane 작성 규칙:
+
+- `check` → `scripts/check_...` 추가/보강 또는 `codex-config/...` 검사 확장
+- `template` → `docs/templates/...` 보강
+- `playbook` → `docs/playbooks/...` 보강
+- `policy` → `docs/policies/...` 보강
+- `router` → `skills/sk-feature-workflow/SKILL.md` 보강
+- `no-action` → `다음 단계: 없음`
+
+### 공통 분류 힌트
+
+- Figma spacing/padding/icon/state mismatch 재발 → 기본 `playbook`
+- Figma lock table / visual proof / request mapping 양식 부족 → 기본 `template`
+- connector 입력 검증 / tool surface / 인증 분류 문제 → 기본 `playbook`
+- 공통 DB safe-read / Notion logging / artifact boundary 규칙 → 기본 `shared-policy`
+- planning vs implementation 오판 / target artifact 오판 → 기본 `router`
+- 회고 prompt나 automation 가이드 자체 문제 → 기본 `docs-automation`
+- 실제 제품 요구/운영 판단 → 기본 `product-plan`
+- 실제 제품 버그/회귀 → 기본 `product-bugfix`
+
+---
+
+## 현재 표준 자동화
+
+### 이름
+- `전일 대화 회고`
+
+### 실행 방식
+- 자동화는 자연어로 전체 세션 파일을 직접 훑는 방식이 아니라,
+  `skills` 저장소의 스크립트를 호출해 근거를 먼저 정리한 뒤 그 결과를 요약하는 방식으로 동작한다.
+- 현재 표준 스크립트:
+  - `~/.agents/skills/scripts/daily_thread_retrospective.sh`
+
+### 목적
+- 전날 갱신된 thread 목록을 수집한다.
+- thread별 사용자 메시지와 함수/도구 오류 출력을 읽어 반복 마찰 신호를 모은다.
+- `반복 설명 요청`, `수정 재요청`, `사용자 답답함`, `도구/설정 오류` 같은 패턴을 상위 항목으로 묶는다.
+- 최종 자동화 응답은 그날의 개선 backlog 초안으로 쓴다.
+
+### 기본 스케줄
+- 매일 오전 9시 (KST)
+
+### 기본 workspace
+- `~/.agents/skills`
+
+### 기본 메모리 경로
+- `~/.codex/automations/daily-thread-retrospective/memory.md`
+
+---
+
+## 스크립트 사용법
+
+```bash
+~/.agents/skills/scripts/daily_thread_retrospective.sh
+```
+
+기본값:
+- 날짜: 전날
+- 시간대: 시스템 로컬 시간대
+- automation thread 제외
+- 최대 200개 thread 스캔
+
+옵션 예시:
+
+```bash
+~/.agents/skills/scripts/daily_thread_retrospective.sh --date 2026-04-05
+~/.agents/skills/scripts/daily_thread_retrospective.sh --date 2026-04-05 --timezone Asia/Seoul
+~/.agents/skills/scripts/daily_thread_retrospective.sh --date 2026-04-05 --cwd-filter /Users/seokang/WebstormProjects/slk-office
+~/.agents/skills/scripts/daily_thread_retrospective.sh --date 2026-04-05 --include-automations
+```
+
+옵션 설명:
+- `--date YYYY-MM-DD`: 회고 대상 날짜 고정
+- `--timezone Asia/Seoul`: 날짜 경계 계산 시간대 지정
+- `--cwd-filter /path`: 특정 프로젝트 thread만 필터링
+- `--include-automations`: `Automation:` thread도 포함
+- `--limit 100`: 최대 스캔 thread 수 제한
+- `--codex-home /path`: 기본 `~/.codex` 대신 다른 Codex 홈 사용
+
+---
+
+## 자동화 프롬프트 기준
+- 자동화는 스크립트 출력 결과를 읽고 사람이 바로 볼 수 있는 보고서로 요약한다.
+- 스크립트는 전날 기준 thread 목록, 상위 마찰 유형, 상위 오류 시그니처, thread별 근거를 출력한다.
+- rollout 파일이 없으면 `rollout 파일 누락`으로 분리하고, 누락 수를 출력한다.
+- 스크립트는 비용 추세 참고용으로 실제 `subagent 실행 지표`를 함께 출력한다. 호출하지 않은 사실 자체는 마찰이나 누락으로 분류하지 않는다.
+- 스크립트는 반복 임계값을 충족한 `승격 후보 힌트`도 함께 출력한다.
+- 자동화는 그 결과를 기반으로 개선 우선순위를 정하고, 각 항목마다 먼저 destination과 promotion lane을 함께 분류한 뒤 그 결과에 맞는 다음 단계를 붙인다.
+- 자동화는 메모리를 `~/.codex/automations/daily-thread-retrospective/memory.md`에 덮어쓴다.
+- 최종 답변은 한국어만 사용하고, 절차 설명은 생략한다.
+
+---
+
+## 다른 데스크톱에서 설정 순서
+1. 다른 데스크톱에도 이 저장소를 clone 또는 pull 해서 `~/.agents/skills`에 둔다.
+2. 터미널에서 아래 명령으로 스크립트가 실행되는지 먼저 확인한다.
+
+```bash
+~/.agents/skills/scripts/daily_thread_retrospective.sh --date 2026-04-05 --timezone Asia/Seoul --limit 3
+```
+
+3. Codex Desktop에서 새 자동화를 만든다.
+4. 이름은 `전일 대화 회고`로 넣는다.
+5. workspace는 `~/.agents/skills`로 지정한다.
+6. 프롬프트는 `docs/automations/daily-thread-retrospective.prompt.ko.md`의 본문을 그대로 넣는다.
+7. 실행 시각은 해당 데스크톱의 로컬 시간 기준으로 매일 오전 9시로 맞춘다.
+8. 저장 후 첫 실행 결과에서 `memory.md`가 갱신되는지 확인한다.
+
+경로를 `~/.agents/skills`로 둘 수 없으면 아래 두 군데를 같은 실제 경로로 함께 바꾼다.
+- 자동화 workspace
+- 프롬프트 첫 줄의 `daily_thread_retrospective.sh` 절대경로
+
+---
+
+## 점검 체크리스트
+- workspace가 `~/.agents/skills`로 설정되어 있는가
+- 스크립트 경로가 `~/.agents/skills/scripts/daily_thread_retrospective.sh`로 맞는가
+- `~/.codex/state_5.sqlite`와 `~/.codex/archived_sessions`를 읽을 수 있는가
+- 보고서가 사용자 비난이 아니라 개선 backlog 중심으로 쓰이도록 되어 있는가
+- 최종 항목 수가 3~5개로 제한되어 있는가
+- destination과 promotion lane이 같이 기록되는가
+- `memory.md` overwrite 경로가 고정되어 있는가
+- 다른 데스크톱에서는 자동화를 새로 만들었는가
+
+---
+
+## 권장 프롬프트
+
+```text
+~/.agents/skills/scripts/daily_thread_retrospective.sh 를 먼저 실행해.
+
+스크립트 출력 결과를 바탕으로 전날 Codex 대화에서 반복적으로 나타난 마찰을 한국어로 정리해줘.
+
+반드시 아래 원칙을 지켜:
+- 사용자를 비난하지 말고 workflow friction 관점으로만 쓸 것
+- 근거가 약한 항목은 추정이라고 명시하거나 제외할 것
+- 최종 개선 후보는 우선순위 기준 최대 3~5개만 남길 것
+- 같은 문제를 wording만 바꿔 반복한 후보는 합쳐서 하나로 정리할 것
+- 각 개선 후보는 먼저 아래 destination 중 하나로 분류할 것:
+  - `shared-policy`
+  - `router`
+  - `playbook`
+  - `template`
+  - `bootstrap-config`
+  - `docs-automation`
+  - `product-plan`
+  - `product-bugfix`
+  - `no-action`
+- destination을 고르기 전에 이 문제가 `shared policy / router / playbook / template / bootstrap-config / product` 중 어디에 속하는지 먼저 판단할 것
+- `다음 단계`는 destination에 맞는 한 줄로 쓸 것. 모든 항목을 `$sk-feature`로 몰지 말 것
+- `no-action`이면 억지 실행 문장을 만들지 말고 `다음 단계: 없음`으로 적을 것
+
+그 다음
+~/.codex/automations/daily-thread-retrospective/memory.md
+파일을 이번 실행의 짧은 요약으로 덮어써.
+
+최종 답변은 반드시 한국어만 사용하고, 아래 섹션을 정확히 이 순서로 사용해:
+- 전일 회고 요약
+- 반복 마찰
+- 개선 후보
+- 다음 단계
+- 메모리
+
+전일 회고 요약에는 날짜, 확인한 thread 수, 제외한 automation thread 수, 상위 마찰 유형을 적어.
+
+반복 마찰에는 같은 설명 반복, 수정 재요청, 답답함 signal, 도구/설정 오류 중 실제로 많이 나온 항목만 적고,
+thread별 증거는 짧은 문장만 인용해.
+
+개선 후보에는 3~5개만 적고 각 항목마다 아래 형식을 유지해:
+- 문제
+- 짧은 근거
+- 추정 원인
+- 가장 작은 지속 개선
+- destination: <shared-policy | router | playbook | template | bootstrap-config | docs-automation | product-plan | product-bugfix | no-action>
+- 다음 단계: <destination에 맞는 실제 액션 한 줄>
+
+다음 단계 섹션에는 `no-action`이 아닌 항목만 우선순위 순으로 다시 묶어서 적어.
+- 형식: `<destination> — <다음 단계>`
+- 예시:
+  - `shared-policy — docs/policies/core-safety.md 수정`
+  - `router — skills/sk-feature-workflow/SKILL.md 라우팅 규칙 수정`
+  - `playbook — docs/playbooks/figma-fidelity.md completion contract 보강`
+  - `template — docs/templates/request-mapping.md 템플릿 보강`
+  - `bootstrap-config — scripts/... 또는 codex-config/... 수정`
+  - `docs-automation — docs/automations/daily-thread-retrospective.prompt.ko.md 수정`
+  - `product-plan — $sk-plan ...`
+  - `product-bugfix — $sk-bugfix ...`
+
+메모리에는 memory.md를 갱신했는지 여부를 적어.
+
+스크립트 실행 또는 데이터 확인이 실패하면 실패 이유를 정확히 적고 추정으로 채우지 마.
+```