문제는 이것이었다. 새 모델이 나오면 내 하네스(harness, AI가 "다 했다"고 거짓말 못 하게 증거를 강제하는 감시 장치 묶음)는 옛 모델에 맞춰 써 둔 가정을 그대로 들고 있다. 스킬(skill, 정해진 절차를 담은 작업 설명서)과 에이전트(agent, 역할을 맡은 보조 AI), 그리고 절차서(에이전트가 실행 중에 매번 읽는 단계별 지시문) 곳곳에 "이 모델은 이걸 못 하니 사람이 확인하라" 같은 문장이 남아 있다. 그래서 새 모델이 출시되면 그 모델이 직접 그 낡은 가정을 걷어내게 하는 스킬 model-release-upgrade 를 만들었다. 이 글은 그 첫 실행 결산이다. 새 모델 Claude Fable 5.1(모델 ID claude-fable-5-1)이 리드를 맡았다. 3개월 사용 실적으로 고른 40개 항목을, 항목마다 새로 띄운 fresh 워커(worker, 이전 대화 기억이 없는 빈 상태로 시작하는 작업용 AI 세션)가 편집했다. 결과는 두 가지로 검증했다. 하나는 같은 스크립트(사람 대신 정해진 검사를 실행하는 작은 프로그램)를 편집 전후에 돌려 같은 숫자가 나오는지 보는 결정론 재측정이다. 다른 하나는 비평 전용 AI가 "제대로 고쳤다"는 주장을 일부러 반박하는 적대 반박이다.
이 패스(pass, 감지부터 결산까지 절차를 처음부터 끝까지 한 번 훑는 실행 단위)는 91분 걸렸다. 편집 전 상태를 고정해 둔 기준선 커밋 2873b3f45(05:29)에서 결산 커밋 f032fbc3b(07:00)까지다. 단계는 P0 감지부터 P6 결산까지 일곱 개다. 리드 세션(전체를 지휘하고 커밋을 맡는 메인 AI 세션)은 Fable 5.1 이다. 항목마다 같은 모델의 fresh 워커를 새로 띄워 편집시킨 뒤 리드가 커밋했다. 아래 숫자의 뜻은 이렇다. 가정 카드는 워커가 절차서의 문장 하나를 두고 "옛 모델 기준의 낡은 가정인가"를 판정한 기록 한 장이다. 결정론 이식은 사람이 읽고 판단하던 문장을 스크립트 판정으로 옮긴 건수다. 사전등록(prereg, 편집 전에 예상 결과를 먼저 적어 두고 끝난 뒤 그 예측에만 대조하는 기록)은 항목마다 워커가 남겼다. S3 는 검증 단계 가운데 결정론 재측정을 부르는 이름이다.
S3 재측정 판정P4 의 워커 루프가 패스의 본체다. 워커는 리드가 왜 그렇게 판단했는지를 전달받지 않는다. 카드·파일·기준만 받는다(사유를 가리고 넘기는 이 방식을 blind 라 부른다). 커밋은 리드만 한다. 커밋 스크립트 p4-commit 은 게이트(gate, 조건을 못 채우면 다음 단계로 넘어가지 못하게 막는 검문소) 역할도 한다. 사전등록 기록의 번호인 prereg id 가 없는 커밋은 거부한다.대상 40개는 사용 실적으로 골랐다. 2026-06-02 ~ 09-02 석 달치 세션 트랜스크립트(AI 와 나눈 대화와 도구 호출을 그대로 남긴 기록 파일)를 분류해 스킬·에이전트가 실제로 몇 번 쓰였는지 셌다. 층은 셋이다. 내가 직접 부르는 스킬, 그 스킬이 스폰(spawn, 일을 나눠 맡기려고 보조 AI 세션을 새로 띄우는 것)하는 에이전트, 그 에이전트가 매번 읽는 절차서까지 한 패스에 넣었다.
내가 직접 부르는 스킬 15개다. 대화형 핵심은 team · work-recheck · init-project · autoresearch(팀 단위 구현, 완료 주장 재검증, 프로젝트 초기 설정, 자율 실험 루프를 맡는 스킬)다. 무인 자동 루프는 self-improve · loopy-era · cc-sync · auto-issue(사람 없이 주기적으로 도는 자가개선, 루프 평가·진화, 설정 동기화, 이슈 자동 처리 스킬)다. 산출물에 직결된 것은 hugh-viz · product-marketing · threads-post · higgsfield · product-planning · plan-design · harness-evolve(시각화 페이지, 마케팅 문서, Threads 글, 이미지 생성, 기획, 디자인, 하네스 진화를 만드는 스킬)다. 무인 루프는 사람이 보지 않는 동안 돌기 때문에 결함이 복리로 쌓인다.
Tier 1 스킬이 스폰하는 에이전트 25개다. 계획을 세우는 planner, 실행하는 executor, QA 5종(qa-scenario-writer · qa-functional-runner · web-qa-tester · webapp-test-runner · qa-orchestrator, 각각 시나리오 작성, 기능 실행, 웹 화면 검사, 웹앱 테스트 실행, QA 총괄), 버그를 고치는 bug-fixer, 코드를 검토하는 code-reviewer, 일부러 반박하는 harsh-critic, 빠짐없이 감사하는 exhaustive-auditor, 자가개선 분석을 맡는 self-improve-analyst, 트렌드를 수집하는 trend-harvester, 그리고 기획 체인 8종이다. 에이전트 파일에는 어떤 모델로 띄울지 정하는 핀(pin, 모델 이름을 고정해 적어 둔 설정)이 있다. 새 모델을 자동으로 물려받는 상속(inherit) 핀은 0 이었다. 즉 어느 에이전트도 새 모델을 저절로 따라오지 않았다.
에이전트가 실행 중에 Read 도구로 읽는 절차서 7개다. self-improve · loopy-era-trend-harvester · exhaustive-audit · harsh-critic · qa-functional · qa-scenario-gen · webapp-testing 의 PROCEDURE(스킬 폴더 안에 단계별 실행 순서를 적어 둔 절차서 파일)다. 스폰 로그에는 안 보이지만 워커가 매 회 읽는다. 그래서 짝이 되는 에이전트 항목에 병합해 함께 편집했다.
PROCEDURE 읽힘석 달 동안 스폰이 0 이었던 에이전트 41종은 고칠 대상에서 빼고 은퇴 대상으로 분리했다(다음 섹션). Claude Code 에 내장된 명령과 내장 에이전트(general-purpose · Explore · Plan)는 내가 편집할 수 없는 파일이라 뺐다. 측정기 3종(conformance · autonomy · integrity, 하네스가 규칙대로 도는지, 얼마나 자율적으로 완주하는지, 파일이 훼손되지 않았는지를 재는 스크립트)은 편집 대상 대신 이 패스를 시작하게 만든 계기로 썼다. 프로젝트 폴더에만 걸린 프로젝트 스코프 에이전트는 사용자 전체 범위(user-scope) 하네스 밖이라 뺐다.
스폰 0 에이전트 41종은 지우지 않고 보관 폴더로 옮겼다(비파괴). 어려운 쪽은 삭제보다 전파였다. 내 설정은 이 머신의 라이브 폴더와 git 미러(백업 겸 다른 머신 배포용 저장소) 사이를 양방향으로 동기화하는데, 이 동기화가 additive(더하기만 하고 지우지는 않는 방식)다. 그래서 정본에서 지운 파일이 미러에 남았다가 다음 apply(미러에서 라이브로 가져오는 동기화 방향) 때 부활했다. 다른 머신에서는 애초에 지워지지도 않았다. 해결은 은퇴 목록을 선언한 정본(manifest, 은퇴한 에이전트 이름을 한 줄씩 적은 파일)을 두고, 양방향 스크립트가 복사할 때마다 그 목록을 읽게 하는 것이었다.
rules-inactive(비활성 규칙을 모아 두는 폴더)의 매니페스트 패턴을 agents 폴더에도 그대로 적용했다. 보류한 12종은 다른 머신이 11일 전에 막 만든 에이전트라 이번 은퇴에서 뺐다. 은퇴한 에이전트를 아직 스폰하도록 적혀 있는 휴면 스킬 12곳은 별도 결정으로 남겼다.검증 단계 가운데 S3 는 결정론 재측정이다. 기준선 단계 P1 에서 고정한 결정론 지표(같은 입력이면 누가 언제 돌려도 같은 숫자가 나오는 지표)를 검증 단계 P5 에서 같은 스크립트로 다시 쟀다. 판정은 사람의 감상 대신 스크립트의 exit code(프로그램이 끝나면서 남기는 종료 번호, 0 이면 통과이고 2 면 차단)로 한다. 결과가 regressed(기준선보다 나빠짐)면 항목 커밋을 되돌린다. stable(기준선과 같음)일 때만 결산 단계 P6 로 간다. 통과한 상태에는 attestation(검증을 통과한 그 순간의 파일 상태를 지문처럼 남기는 증명 기록)을 찍어 둔다.
S3 실행e8f35f46attestation 상태 지문 state_hash| 지표 | 기준선 · 2873b3f45 | 종료 · 6546b08bc | 델타 |
|---|---|---|---|
| probe pass / fail(하네스 자기 점검 항목의 통과 / 실패 수) | 6 / 3 | 6 / 3 | 불변 |
replay_rate(기록해 둔 과거 사례를 훅에 다시 통과시켜 예상 판정과 같게 나온 비율) | 98.6 | 98.6 | 0.0 |
| rules(규칙 파일) 개수 / 바이트 | 104 / 333,801 | 104 / 337,606 | +3,805 B. 같은 시간에 trend-harvester 의 cron(정해진 시각에 자동 실행되는 예약 작업)이 규칙 파일에 append(덧붙임)한 분량이라 이 패스 밖이다 |
| 대상 파일 총 바이트 | 907,886 | 941,457 | +33,571 B. 산문은 −47,922 줄고 스크립트는 +81,493 늘었다(다음 섹션) |
잔존 FAIL(실패 판정) probe | replay-corpus-100 · hook-self-test · conformance-zero-gap(과거 사례 100건 재생, 훅 자체 시험, 규칙 준수 갭 0 확인) | 동일 3건 | 기준선부터 |
| 측정 갭 | conformance(interactive scope, 대화형 범위) · autonomy-eval · akm-eval 은 미실행이라 이번 패스에서 잴 수 없었다 | 정직 고지 | |
replay 통과가 69에서 67로 떨어졌다. 원인은 둘이다. ① 워커가 qa-functional 의 PROCEDURE 에 close --all 이라는 문자열을 그대로 적었다. 이것을 skill-security-scan(스킬 파일 안에 위험한 명령이 섞였는지 설치 전에 훑는 보안 검사)이 실제 금지 명령으로 잘못 잡았다. 그래서 관례 표기인 close [ALL] 로 고쳤다(f98f87ea1). ② push-gate(push 직전에 검증 증거를 확인하는 게이트)의 매처(matcher, 어떤 명령에 훅을 걸지 고르는 패턴) 픽스처(fixture, 검사기가 결함을 정말 잡는지 보려고 만들어 둔 시험용 입력)는 기준선부터 FAIL 이라 이 패스 밖이다. ①을 고치자 2·3차가 기준선과 같은 98.6 을 냈다.
파일 총 바이트는 늘었다. 그러나 늘어난 곳은 사람의 판단을 스크립트로 옮겨 심은 항목이다. 줄어든 곳은 반복 서술, 규칙이 승격된 경위를 적은 서사, 특정 모델 이름을 박아 둔 문장(모델 리터럴)을 걷어낸 절차서다.
PROCEDURE·에이전트 정의 파일의 서술 축소다. 증가 상위 3건은 전부 exit code 로 판정하는 스크립트 신설이다.새 모델이 절차서를 읽으며 "이건 사람이 판단하라고 써 둔 문장인데 스크립트가 판정할 수 있다"고 본 곳을 이식했다. 강제 수준은 두 종류다. SOFT 는 사람이 읽고 지키는 약한 강제이고, HARD 는 스크립트가 exit code 로 막는 강한 강제다. 새 검사 표면은 최소로 만들었다. 이미 있는 강제자(hook·verify 스크립트, 훅은 도구 실행 전후에 자동으로 끼어드는 검사 스크립트이고 verify 는 스킬이 자기 산출물을 검사하는 스크립트)를 가리키는 한 줄 포인터로 대체한 경우가 더 많다.
SOFT · 읽는 사람이 판정"압축이 지우고, 모델이 건너뛰는 문장"
time_budget×2 초과 시 kill"(시간 예산의 두 배를 넘기면 프로세스를 죽이라는 뜻)PASS(통과 판정)"HARD · 스크립트가 판정"되돌리면 FAIL 하는지 픽스처로 확인한 것만"(픽스처는 검사기가 결함을 정말 잡는지 보려고 만들어 둔 시험용 입력)
exit(0 if n<p …), 지표의 방향(direction, 작을수록 좋은지 클수록 좋은지)을 알고 같으면 줄 수로 승부를 가르는(tie-break) 판정perl -e 'alarm shift; exec @ARGV', 시간 초과 때 종료 번호(rc) 142 가 실제로 나오는지 실측ERR==0 ∧ OVER==false ∧ [ -s check.png ](콘솔 에러 0, 화면 넘침 없음, 스크린샷 파일 존재를 전부 만족해야 통과)check-context-doc.sh → exit 0/2(문서 검사 스크립트가 통과와 차단을 종료 번호로 답한다)PROCEDURE 헤더가 SSOT(single source of truth, 같은 규칙을 한 곳에만 적어 두는 정본)이고 다른 곳은 그것을 가리키는 1문장 포인터agent-model-1m-gate.sh 포인터 1개(이미 있는 게이트를 가리키기만 하고 새 검사 표면은 0)| 신규 스크립트 | 스킬 | 판정 대상 | exit |
|---|---|---|---|
scripts/check-page.py | hugh-viz | 섹션마다 시각화가 있는지 · SVG(벡터 그림 형식) 규격(var/font-size/rx/marker) · 태그 균형 · i18n leaf(번역 키가 잎 노드에만 붙었는지) · 금지 API · THEME(페이지 색 테마 상수) 정합. 이 페이지도 이 검사기를 통과했다 | 0 / 2 |
scripts/check-context-doc.sh | product-marketing | 필수 12섹션이 있는지 · 플레이스홀더(채워 넣어야 할 빈칸 표시) 8종이 남았는지 · 버전↔체인지로그 정합 | 0 / 2 |
scripts/check-planning-docs.py | product-planning | 기획 문서 4단계(Stage 1~4) 완료(planning-meta 머리말 · 필수 섹션 번호 · 불침투 · 고정 토큰 · 3.5 위임) + --selftest(검사기가 자기 자신을 시험하는 옵션) | 0 / 2 / 3 |
scripts/acceptance_contract.py | auto-issue | 착수 계약 check(출처 태그 · AC→TC 대응, 즉 수용 기준(acceptance criteria)마다 테스트 케이스(test case)가 있는지 · 4축 · plan 의 AC 집합 동일성) / restore(이슈 코멘트에서 승계). 픽스처 12케이스 | 0 / 2 / 3 |
verify/procedure-contract.sh | loopy-era-trend-harvester | PROCEDURE 구조 계약: Phase 헤더 · 5축 · enum(허용 값 목록) · WIRE(채택한 원리를 기존 스킬 절차에 배선하는 반영 티어) 6단계 · 헬퍼 14종 · rule-budget-gate(규칙 총량 상한 게이트) 배선 | 0 / 2 |
scripts/check-result.py | higgsfield-generate | 생성 결과(status · result_url · HTTP 상태 · content-type · 바이트 수)가 5단계(step 5) 완료 조건을 채웠는지 | 0 / 2 / 3 |
scripts/check-catalog.py | higgsfield-generate | 절차서가 인용한 job_type(생성 작업 종류 이름)이 실제 목록에 있는지 · 별칭 · 드리프트(목록과 문서의 어긋남) | 0 / 2 / 3 |
| 라우팅 분기 | self-improve · harness-evolve | Phase 0 / S2 에 model_release pending 술어(새 모델 이벤트가 아직 처리되지 않았는가를 묻는 조건)를 두고, 참이면 Skill(model-release-upgrade) 로 넘긴다. 다음 릴리즈부터는 감지가 이 스킬을 부른다 | 배선 |
검증 단계 S4 는 적대 반박이다. 비평 전용 에이전트 harsh-critic 에게 리드가 왜 그렇게 고쳤는지는 알려주지 않았다. diff(바뀐 부분만 모은 비교문)와 기준만 주고 "계약이 보존됐다는 주장을 반박하라"고 했다. 여기서 계약이란 절차서가 원래 지키기로 한 규칙을 말한다. 반박이 없었다면 "계약 보존"이 거짓인 채로 끝날 뻔한 결함이 둘 나왔다.
R1 성립: 게이트가 빠진 채 계약이 두 값으로 갈렸다1라운드에서 비평자가 지적 ④와 ①을 냈다(번호는 비평자가 매긴 지적 번호다). 지적 ④: 서브에이전트가 끝나는 시점(SubagentStop)에 절차서를 읽었는지 확인하는 게이트 promoted-agent-skill-read-gate(승격된 에이전트가 자기 스킬 절차서를 실제로 읽었는지 검사하는 훅)가 08-07 등록부 사고(훅 등록 목록이 자동 동기화 커밋에서 통째로 빠진 사고)로 사라진 상태였다. 그 상태에서 워커는 3파일을 "미등록이니 SOFT" 로 강등하고 4파일은 HARD 로 남겼다. 같은 계약이 파일마다 두 값이 된 것이다. 지적 ①: 1M 게이트(에이전트를 문맥 20만 토큰짜리 별칭 모델로 띄우면 즉시 죽으므로 100만 토큰 모델만 허용하는 훅)에 fable 예외를 둔 근거를 harness-evolve 의 서술이 부정하고 있었고, 디스크에 증거 파일도 없었다. 수리: SubagentStop 훅 재등록(59→60 훅) · 3파일 HARD 정렬 · 증거 파일 착지(fable 스폰 24기 중 22기가 200K 를 초과, 최대 507K).
R2 성립: 수리가 짝을 빠뜨렸다지적 ④의 잔여: trend-harvester · self-improve-analyst 두 에이전트에 "미등록(SOFT)" 4줄이 R1 수리 범위 밖에 남아 있었다. 지적 ①은 증거 JSON(사람과 프로그램이 함께 읽는 자료 형식) 파일을 독립적으로 다시 계산해 3/3 일치로 해소했다. 수리: 2파일 정렬. 계약은 "HARD + 등록 확인 명령(grep -c promoted-agent-skill-read-gate ~/.claude/settings.json 의 결과가 1 이상)" 한 가지 값으로 통일했다.
R3 불성립: 결정론 grep 으로 대체했다(정직 고지)에이전트 전체에서 미등록/SOFT 잔존은 0 이었다. 등록 확인 grep(파일에서 문자열을 찾아 세는 명령)은 promoted=1 · 1m=1 로 둘 다 등록돼 있었다. 적대 재스폰은 하지 않았다. 판정 근거가 결정론 술어(스크립트가 참·거짓으로 답할 수 있는 조건)로 환원됐기 때문이다. 다만 3라운드는 LLM 의 반박이 아닌 grep 결과라는 점을 기록으로 남긴다.
| 패스가 드러낸 하네스 결함 | 증상 | 수리 | 커밋 |
|---|---|---|---|
agent-model-1m-gate 가 fable 별칭 차단 | harness-evolve 가 model:"fable" 스폰을 지시하는데, 게이트가 이 별칭을 200K 별칭으로 취급했다. 이 패스의 워커 스폰 자체가 불가능했다 | 별칭 예외 + 실측 증거 파일(24기 컨텍스트 분포) | 00f254b41 |
agent-model-1m-gate 가 PreToolUse(도구 실행 직전 시점) 훅으로 미등록 | 08-08 자동 동기화 커밋에서 등록이 사라졌다. 08-07 이후 발화 0(워커 2기가 독립적으로 보고) | Agent|Task 매처로 재등록(hook-run.sh 래퍼 경유, 훅 실행 기록을 남기는 공용 래퍼) | 721ccb899 |
promoted-agent-skill-read-gate 가 SubagentStop 훅으로 미등록 | 같은 08-07 사고다. 절차서를 안 읽은 워커가 그냥 통과했다 | 재등록 59→60 훅 + 의존 에이전트 5파일 HARD 정렬 | 6546b08bc · f39e9ce97 |
auto-adversarial-review(Codex 에게 자동으로 적대 리뷰를 시키는 스크립트)의 --files 옵션이 git 미추적 파일은 diff 를 못 뜸 | Codex 마커가 INCOMPLETE(리뷰 미완료)로 남는다. 그러면 work-recheck 의 attestation 이 self_review(자기 검토만 있음)로 거부한다. 최근 90일 최대 실패 클래스의 한 원인이었다 | git diff --no-index -- /dev/null 추가 → FINDINGS(리뷰 결과 마커) 실측 | 00f254b41 |
워커 유발: qa-functional PROCEDURE 에 CRITICAL(가장 심각한 등급) 결함 | env 파일(환경변수 파일)을 심링크인지·내 소유인지 검사하지 않고 source(그 파일 내용을 그대로 실행) · 전부 SKIP(건너뜀)이어도 PASS · dev.log 에 적힌 임의 URL 을 그대로 신뢰 | QA_TMP(QA 임시 폴더) 소유 가드 · -f ∧ !-L ∧ -O(일반 파일이고 심링크가 아니며 내 소유) · localhost 정규식 · PASS≥1 · scope=full 이면 EXEC==PLAN(실행한 시나리오 집합이 계획과 같아야 함)(픽스처 5) | 762173b8d |
워커 유발: skill-security-scan 오탐 | 절차서의 close --all 문자열이 금지 명령에 매치됐다 → replay 69→67 | 관례 표기 close [ALL] | f98f87ea1 |
항목마다 워커가 편집 전에 "무엇이 줄고 무엇이 남는가"를 원장(ledger, 덧붙이기만 되고 고치거나 지울 수 없는 기록 장부)에 고정했다. 결과를 본 뒤 예측을 바꿀 수 없는 구조다. 그래서 refuted(예측이 틀렸다는 판정)가 10건 나왔다. 그것이 이 원장의 존재 의의다.
S3 는 스크립트가 판정한다. S4 는 사유를 받지 않은 비평자가 판정한다. Codex 는 다른 회사의 모델이다. work-recheck 는 그 셋이 남긴 마커를 요구하는 게이트다.아래는 보고도 고치지 않은 것들이다. 이 패스의 범위 밖이라고 판정했기 때문이다. 각 항목은 다음 패스나 별도 결정의 입력으로 남는다.
| 잔여 | 내용 | 분류 |
|---|---|---|
Codex HIGH(두 번째로 심각한 등급) 3건 | qa-functional PROCEDURE: 호출자가 넘긴 BASE_URL(테스트 대상 주소)을 제한하지 않는다(SSRF 는 서버를 속여 내부 주소로 요청을 보내게 하는 공격이다. 그 경계는 dev.log 자동 추출분에만 로컬 제한으로 걸려 있다) · procedure-contract.sh 가 헤더의 첫 등장만 검사한다(substring, 부분 문자열 일치) · Phase 4 가 PASS≥1 만 요구한다(full 이 아닌 스코프에서 필수 시나리오를 SKIP 할 수 있다) | 후속 항목 |
push-gate replay 픽스처 | push-gate-matcher-prefix-bypass 가 기준선부터 FAIL. 범용 마커를 제거해도 rc=0(통과)이 나온다. 게이트의 매처 결함으로 의심된다 | 기존 결함 |
$HOME git 저장소 | 홈 폴더 자체가 git 저장소라 .claude/ 아래 154파일을 추적 중이다. 은퇴 에이전트 삭제가 D(삭제됨)로 표시되는 세 번째 미러 표면이다. apply/sync 계약 밖이다 | 구조 |
| 자동 동기화 선착지 | 06:31 에 cc-sync 자동 동기화가 워커 편집 중이던 QA 에이전트 3파일을 먼저 커밋했다(3ae091b40, prereg id 없음). 규율 위반보다는 타이밍 문제다. 다음 패스는 sync 를 일시 정지한다 | 타이밍 |
code-reviewer frontmatter(에이전트 파일 맨 위의 설정 머리말) | rules: 키가 사라졌다. 가리키던 rule 이 은퇴 대상이라 읽는 소비자가 0 이다 | 무해 |
| 휴면 스킬 정적 참조 12곳 | 은퇴 에이전트를 스폰하도록 적힌 스킬(dependency-updater · qa-cycle · team-orchestrator 등)이다. 다시 부르면 스폰에 실패한다. 스킬 자체의 은퇴는 별도 결정이다 | 보류 |
| repo 전용 에이전트 12종 | 다른 머신이 08-22 에 커밋했고 3개월 스폰 0 이다. 생성 11일차라 은퇴에서 뺐다. manifest 에 append(한 줄 덧붙이기)만 하면 은퇴된다 | 보류 |
| 모델 핀 제안 20건(8 대상) | planner · qa-scenario-writer · critic 등은 opus-4-8 → Fable 5.1 상속으로, 기획 체인은 opus-5 → fable-5-1[1m] 로, self-improve-analyst 핀은 machinery-lint(self-improve 부품이 계약대로 배선됐는지 검사하는 lint)의 C02(analyst 계약 항목, 핀 모델 ID 를 직접 대조한다)와 동시에 갱신하자는 제안이다. 전부 페어드 A/B(같은 작업을 두 모델로 나란히 돌려 비교) 조건을 명시했다. 카드로만 제안했고, 에이전트 파일의 핀 26/26 은 불변이다 | 별도 결정 |
이번 패스에서 도출한 전환 체크리스트다. 감지부터 결산까지 사람은 시작 명령만 내리면 되게 만들었다. 이번에 헛디딘 곳은 단계 안에 주의점으로 박아 두었다.
model-registry(알려진 모델 목록)에 없는 모델 ID 를 보면 이벤트 파일을 쓴다state/model-release/<model>.json · self-improve Phase 0 / harness-evolve S2 가 이 스킬로 라우팅한다HEAD(git 의 현재 커밋) 를 baseline.json(편집 전 수치를 적어 두는 기준선 파일)에 고정survey-usage.sh 재실행, 90일 창, retired_candidates(은퇴 후보 목록) 검토MODEL_RELEASE_PASS(이 패스가 진행 중임을 알리는 환경 변수) 선언 · 워커 완료 알림 뒤에 p4-commitmarket-researcher 에서 실측) · 플러그인은 자기 repo 에 커밋 + 서브모듈 포인터 갱신 · sync 일시 정지p5-remeasure(S3 재측정 스크립트) → harsh-critic S4 → Codex AAR(auto-adversarial-review, 자동 적대 리뷰)AAR 의 --files 는 미추적 파일도 diffp6-report(결산 리포트 생성) → prereg close(사전등록 마감) → 이벤트 handled(처리됨 표시) → 핀 원복 확인 → push → 텔레그램 알림work-recheck 는 패스 종료 시 1회만(중간에 찍은 attestation 은 워커 편집으로 즉시 stale, 즉 낡은 상태가 된다)"하네스 개선의 병목은 모델이 아니라, 새 모델이 낡은 가정을 읽어낼 수 있게 절차를 열어 두는 것이다."