Daily Experience Wiki 원본 cron prompt historical backtest 통합 보고서
결론
고정 기간 [2026-07-20 00:00 KST, 2026-07-24 00:00 KST)의 9개 profile history를 원본 prompt 기준으로 격리 조사해 Case Card 5건을 선정했다. 최초 6건 중 outcome 문턱이 약한 1건은 reviewer 지적을 받아 near-miss로 강등했다. canonical Wiki에는 적용하지 않았고 cursor·cron·gateway·config를 바꾸지 않았다.
선정 사례
- 공통 운영 규칙의 전 profile 전파 — 사용자 교정은 수정만 하지 말고 관련 프로필 전파와 read-back까지 같은 work unit으로 묶는다.
- stale worker와 거짓 진행 보고 방지 — 준비·smoke·본수집을 분리하고 PID, 상태 freshness, 작업량으로 진행을 검증한다.
- 반복 UAC 승인 루프 방지 — 공식 옵션, 실제 등록 경로, quoting, 대기 수명을 승인 전에 확정한다.
- 페이지 공개와 저장소 공개의 범위 분리 — fallback도 사용자가 승인한 side-effect 범위 안에서만 고른다.
- 차트의 의미와 전체 조합 검증 — 한 화면 모양이 아니라 3×3 조합, 도메인 의미, 추정/실제 표현을 검증한다.
조사 범위와 방법
- prompt source:
[비공개 정보 제거], job ID965649349830 - prompt SHA-256:
[비공개 정보 제거] - SQL 시간 조건:
timestamp >= 1784473200.0 AND timestamp < 1784818800.0 - 전체 metadata scan: 9 profiles, 245 profile-session entries, 60,815 messages
- role: user 2,473, assistant 23,386, tool 34,907, session_meta 49
- 원문 deep review 선언 범위: 15 sessions, 18,236 in-window messages
- inventory는 제목·본문 없이 metadata만 저장했다. Case에는 필요한 message ID와 비식별 요약만 기록했다.
- Case의 message ID는 session 안 순번이 아니라 DB의 전역 절대 ID이므로
deep-review-scope.json의 session별 메시지 수와 숫자 크기를 직접 대조할 수 없다.
Look-ahead 차단
현재 README/SCHEMA와 validator는 형식·안전 원칙만 이해하는 데 사용했다. 2026-07-24 이후 생성된 Case, Playbook, report 또는 현재 Wiki의 사후 판정을 “정답”으로 사용하지 않았다. 사건의 wrong turn, 교정, 결정적 행동, 결과는 지정 기간 안의 session 메시지와 그 안에서 보고된 tool outcome만 근거로 삼았다.
선택 품질
- explicit correction 또는 expectation mismatch: 5/5
- 기간 안 verified operational outcome: 5/5
- reviewer 강등: 초보자 설명 1건을 outcome 미확인과 transition near-miss 대비 문턱 비대칭 때문에 제외
- playbook: 생성·승격하지 않음. 단일 기간의 case만으로 개선을 일반화하지 않았다.
- excluded/near-miss: 중복 근본 원인, 단순 Q&A, outcome 부족, PII 혼재, 자기참조를 별도 기록했다.
안전 및 비밀정보
원문 credential, auth 값, cookie, 가족 세부 정보, 여행 예약 식별자는 저장하지 않았다. URL은 공개 배포 결과 외에는 사건 이해에 필요하지 않아 생략했다. raw session dump도 만들지 않았다.
Reviewer 및 검증
Claude Max CLI를 project-scoped read-only로 정확히 1회 실행했고 exit code 0, 판정은 PASS_WITH_NOTES였다. reviewer는 파일을 수정하지 않았다. 핵심 준-blocker였던 CASE-BT20260720-006과 transition one-page의 비대칭을 해소하기 위해 006을 선택 목록에서 제외했다. CASE-004/005가 공유한 27108은 배포 성공 확인과 다음 오류 제보가 한 메시지에 붙은 경계이며, 두 case가 서로 다른 부분만 사용한다고 명시했다. edges는 대표 관계만 기록한다.
scripts/validate_batch.py: PASS, 5 cases, 0 errorsscripts/validate_wiki.py읽기 전용 실행: PASS, canonical 16 cases / 30 edges / 0 errors / 0 warnings- current batch-input schema: required key와 enum을 schema에서 직접 읽어 동등 검증 PASS. 설치된
jsonschema는rpds.rpdsimport 오류였고 package 설치가 금지돼 추가 설치하지 않았다. - 10개 source message ID range의 session/profile/고정 시간범위 존재 검사: PASS
- secret-like 값 scan: PASS, 0 hits
- canonical hash guard: PASS, cases/playbooks/relations/evaluations/cursor/log/index 23/23 unchanged
- 상세 결과:
validation-results.json
한계
- 전체 60,815개 메시지는 metadata/role 기준으로 scan했지만, 모든 본문을 한 줄씩 수동 정독한 것은 아니다. correction signal로 triage한 15개 session의 18,236개 메시지를 deep-review 범위로 고정했다.
- session DB에는 compaction 때문에 같은 대화가 새 ID로 반복 저장된 부분이 있다. 중복 메시지를 독립 사건으로 세지 않았다.
- 외부 세계의 현재 상태는 검증하지 않았다. historical session 속 tool outcome만 당시 검증으로 취급했다.
- canonical apply와 cursor 변경은 의도적으로 하지 않았으므로, 이 결과는 운영 Wiki 반영물이 아니라 prompt 실험 산출물이다.
jobs.json전체 파일 hash는 실험 시작 시d192f6...에서 최종 검증 시589329...로 달라졌다. 이 파일에는 scheduler의 volatile 실행 상태도 있어 본 실험이 원인이라고 단정할 수 없으며, 본 작업에서 이 파일을 쓰는 명령은 실행하지 않았다. 대상 job prompt의 SHA-256은 시작·snapshot·종료 모두45bd8328...로 동일했다. 따라서 prompt 불변은 확인했지만 jobs 파일의 다른 runtime field 전부가 불변이었다고는 주장하지 않는다.