헌팅 → 계약 → 시안 게이트 → 구현 분대 → 반복 체인 → 마감 검증까지 3.0 전 세션을 통합한다. P2(개인정보 클린룸) 6축 결함 수리를 완주하고, 코덱스 체인이 한 번도 도달하지 못했던 cleanroom(격리 실행 환경) 첫 실전 가동에서 잠복 결함 5건을 추가로 검출·수리한 뒤 3.0.0-internal.15를 설치했다.
efddfde)하고 3.0.0-internal.15로 버전을 올린 뒤(커밋 f052d23), full chain 5회전과 cleanroom 첫 실전 가동을 거쳐 검증기측 결함 5건을 추가로 잡았다. 최종 커밋 4d9cd365 기준으로 라이브 포트 4790에 3.0.0-internal.15를 설치 완료(buildVersion 실측 일치, stale:false)했고, release transition은 PASS_RELEASE_TRANSITION_PUBLISH_AUTHORIZED다. 팀원 배포 브릿지 페이지(R2·Pages·HTTP 검증)는 별도 워커가 진행 중이며 완료 시 §10을 갱신한다.
3.0.0-internal.3을 설치했고, 오르카 워커 오기동 결함의 근본 원인(에이전트 정체성 환경변수 상속)을 규명·폐쇄했다.int30-base는 HEAD 554206f5 위 7파일 uncommitted(+250/-69) 상태이며, 02:20 페이블 헤드가 신원(HEAD/tree/7파일/diff SHA) 전건 일치를 확인하고 인수했다.모두 실측치다. 추정·평균 처리한 항목은 각 카드의 맥락 줄에 밝힌다.
위 「봉인 패키지 P2 잔존 결함 6」·「uncommitted 파일 7」 두 카드는 2026-08-25 01:55 원우 지시로 수리가 중단된 시점의 스냅샷이다. 이후 02:20 인수 → 6축 완결(커밋 efddfde) → full chain 5회전 → cleanroom 첫 실전 완주 → 3.0.0-internal.15 라이브 설치까지 전부 완료됐다 — 최종 상태는 §04·§05를 본다.
헌팅부터 마감 검증 중단까지, 전환점 위주로 정리했다. 버전별 세부는 05절 표를 함께 본다.
5bd2de22f257…f93e062).fable/int30-base HEAD cb7db57(main 대비 363커밋). 안전 하네스 25/25(int30-harness-head-2) 실측.int-deploy-int30-c, 커밋 210dad3=a77dcc7+27커밋). F71 81/81·안전 하네스 25/25·G7B PASS.8a805cc). 원인 = 헤드리스 워커가 {...process.env}로 오르카 페인 정체성 env를 상속해 전역 훅 발동. stripForeignAgentHookEnv()로 9~11지점 폐쇄.210dad3(=라이브 internal.3). ㉕ AI 창 분할 폭 조정 결함 재현·수리(커밋 1eb8da4), 컨텍스트 게이지 잔존 결함 2차 REPAIR로 마무리.ps+lsof를 실행해 서버 이벤트 루프를 점유한 하네스측 결함. 「개별 수리·재실행 금지, 공통원인 감사 후 단일 batch」로 대응 전환.lstat 판정이 오판(original-fs 미사용). F71 S51 그래프 자동회복 P1 발견·수리 후 최종 상류 체인 전건 PASS, stop-line full-int30w-20260824-a. 이후 package ab 설치 전 P2가 phase-only로 차단(onboarding apply timeout 5초 부족).full-int30x-20260825-a, F71 82/82·package PASS·안전 하네스 25/25).3.0.0-internal.10에서 무접촉(internal.11~14는 전부 로컬 산출물).efddfde(6축 수리)+f052d23(internal.15 bump).c711e9f·e37a1ce.0769c80) → 2회차 PASS 뒤 fresh P2에서 P2_RAW_BINDING(raw 프로토콜 키 이중 소스 발견·RAW_ENVELOPE_KEYS 단일화, 커밋 3725980) → 3회차 PASS 뒤 첫 실전 cleanroom에서 의존성 소스맵 96개+winpty 노트 4개 출고 결함 검출·수리(커밋 df73a30) → 4회차 PASS 뒤 cleanroom에서 사전 오탐(「오름」→「오름IMC」 교정)·hdiutil 자기경로 오탐(scrubImageMetadataSelfReference() 도입, 커밋 4d9cd365) 2건 추가 검출·수리.3.0.0-internal.15·stale:false 실측 → G7B PASS → 스테이지 0444 봉인 후 release transition PASS_RELEASE_TRANSITION_PUBLISH_AUTHORIZED. DMG 132,187,052B. 이후 [6/6] 종합보고서 확정과 팀원 배포 브릿지 갱신(W8)이 병렬 진행.internal.4~9는 커밋 로그로 실측된 버전 bump 커밋이 있다. internal.10~14는 별도 bump 커밋이 grep에 걸리지 않아 태스크 노트 원문(authority 커밋)으로 대체 확인했다 — 표의 「근거」열에 구분해 표기한다.
| 버전 | 일시(KST) | 근거 | 체인 결과 | 핵심 발견 |
|---|---|---|---|---|
| internal.4 | 08-23 17:18:32 | 커밋 a636842 | 새 결함 | 실사용·클린룸 단계 결함 발견 (개별 사례는 태스크 노트, 이 조사에서 개별 특정 안 됨) |
| internal.5 | 08-23 17:54:13 | 커밋 896d7b4 | false PASS | ㉕ 조절선 수리 13체크 GO였으나, 설치 후 재확인에서 CSS cascade 순서 미검증으로 false PASS 판명 |
| internal.6 | 08-23 18:45:21 | 커밋 835885a | 배포안내만 작성 | 브릿지 페이지 배포안내 문서가 이 버전 기준으로 작성됨(§10) — 실제 R2/Pages 배포는 이루어지지 않음 |
| internal.7 | 08-23 20:39:30 | 커밋 18c560c | P2 fail-closed | production P2가 module closure 오류로 fail-closed. 방향 전환(7축 일괄 동결) 결정 |
| internal.8 | 08-24 01:46:16 | 커밋 33d7127 | 부팅 거짓 PASS | 부팅 스모크 하네스 결함 — 종료 기록 후에도 보조 프로세스 13개 6분+ 잔존 |
| internal.9 | 08-24 05:34:21 | 커밋 aa9f809 | F71 15건 fail | action 재봉인 후 F71 15건 동시 fail-closed. 공통원인 = 10ms 동기 ps+lsof 폴링 과부하(하네스) |
| internal.10 | 08-24 (시각 미상) | 태스크 노트 원문 | P2 재발 | P2 정렬 결함 수리했으나 설치 후 재발 — 라이브 4790은 이 버전에서 무접촉 상태로 남아 있다 |
| internal.11 | 08-24 (시각 미상) | 태스크 노트 원문 | shape 불일치 | P2 health 생산자/소비자 shape 불일치 발견 |
| internal.12 | 08-24 (시각 미상) | 태스크 노트 원문 | 예외 승인 진행 | 양쪽 소비자 수리, F71 82/82·package PASS·안전 하네스 23/25(예외 승인) — 완전한 25/25는 아님 |
| internal.13 | 08-24 23:49 | authority 커밋 554206f5… 계열, stop-line full-int30w-20260824-a | 상류 체인 PASS | app.asar 물리 타입 오판(patched fs vs original-fs) 수리. F71 S51 그래프 자동회복 P1 발견·수리. package ab 설치 전 P2가 phase-only 차단(onboarding timeout 5초 부족) |
| internal.14 | 08-25 00:54 | 태스크 노트 원문, stop-line full-int30x-20260825-a | 상류 체인 PASS / P2 잔존 | P2 deadline·cleanup 양면 수리 후 상류 체인 전건 PASS(F71 82/82·package PASS·안전 하네스 25/25). 그러나 봉인 패키지 fresh P2에서 6축 결함 발견 — 미해소 |
| internal.15 | 08-25 03:55~06:25 | 커밋 f052d23(bump)~4d9cd365(최종 HEAD) | 최종 확정 — 라이브 설치 완료 | Claude 헤드 인수 후 P2 6축 일괄 완결(efddfde) → full chain 5회전 동안 검증기측 결함 4건 순차 검출·수리(하네스 낡은 404 선언·RAW_ENVELOPE_KEYS 이중소스·소스맵 96+4 출고·hdiutil 자기경로 오탐, §07·§09) → 체인 5회차 PASS→fresh P2 PASS→cleanroom 첫 실전 완주 PASS→R7 시각 검수 4/4 PASS→G7B PASS. 라이브 4790 buildVersion 실측 3.0.0-internal.15·stale:false. release transition PASS_RELEASE_TRANSITION_PUBLISH_AUTHORIZED |
Claude 인수 후(02:20~06:25) 검출·수리한 결함은 총 9건이다 — 제품측 3(오늘노트 404 회귀, 소스맵 96+winpty 노트 4개 출고, journey.js false-PASS 교정) + 검증기측 5(cleanroom PNG 검사기 오결선, oracle/cleanroom 스키마 어긋남, owner 판정 충돌, walkthrough RAW_ENVELOPE_KEYS 이중소스, hdiutil 자기경로 오탐) + 하네스 선언 낡음 1(standaloneBootProbe404, 14 시나리오 은퇴). 별도로 사전 작성 오탐 1건(「오름」→「오름IMC」 교정)도 cleanroom 단계에서 함께 잡혔다. 미해결 잔여는 세 가지다 — ① P2 cleanup 그룹 재검증 간헐 레이스(재시도로 회복되나 후속 수리 대기, iCloud ctime 계열로 추정) ② R7 reviewer 어휘에 CLAUDE가 없어(CODEX|HUMAN뿐) reviewerId=claude-fable-5-head로 실제 검수자만 명기하고 어휘 자체 수리는 후속(finalizer 자기해시 결속 때문에 지금 고치면 체인 재실행 필요) ③ 팀원 배포 브릿지 페이지(R2·Pages·HTTP 검증)는 별도 워커가 진행 중 — 완료 여부는 §10에서 헤드가 최종 확인한다.
int30-base worktree git log 실측(읽기 전용 조사). 「체인」은 F71→build→harness 또는 g→v(보존→검증) 같은 전체 재검증 사이클을 뜻한다.
fix(...) 커밋test(internal): reseal ... authority이 조사에서 텍스트로 직접 셀 수 있었던 것은 08-21 세션의 「체인 5차」(F71→build→harness 반복, 17:02~18:27)까지이며, 08-23~08-25 구간은 버전 라벨(internal.4~14)마다 사실상 새 체인이 돌았다. 정확한 전체 체인 반복 횟수는 g→v 15회 외에는 개별 카운트가 산재해 정확한 합산이 불가능하다 — 이 문서는 g→v 15회를 반복 규모의 기준선으로 쓰고, 그 앞뒤 구간은 §04·§05의 서술로 보완한다.
「다음에는 주의하겠다」로 끝내지 않는다. 각 항목을 실측 사실·횟수·실제 코드로 강제된 변화로 적는다. 강제 지점이 없으면 미구현이라고 명시한다.
| 항목 | 사실·횟수 | 기계 강제 변화 |
|---|---|---|
| ① 한쪽만 검증 |
internal.5 ㉕ 조절선 수리 — 13체크 GO였으나 두 CSS(style.css/internal-chat.css)의 실제 cascade 순서를 함께 싣지 않아 false PASS. internal.11 split flow 새 helper가 action 장부에서 빠진 false-seal 위험을 빌드 전 감사가 검출. 3.0 끝의 P2 6축 결함 자체가 "제품 코드만 고치고 실제 브라우저 렌더 파이프라인·raw evidence 소비자까지는 안 본" 패턴의 누적. |
action-manifest 계약 파일 다수(reseal 체계)로 코드 변경 시 authority 결속을 기계 검증 — 구현됨. 다만 "두 CSS의 실제 cascade를 함께 싣는" 류의 렌더 파이프라인 종단 검증은 여전히 개별 사건마다 사람이 뒤늦게 발견하는 패턴이 반복돼 일반화된 기계 강제는 아직 없음. 이번 세션 반대 실증: 코덱스 24시간 체인이 한 번도 도달하지 못했던 cleanroom(격리 실행 환경) 첫 실전 가동을 실제로 끝까지 돌려, "제품 코드만 보고 실물 파서·최종 소비자까지는 안 본" 패턴이 낳는 잠복 결함 5건(PNG 검사기 오결선·oracle/cleanroom 스키마 어긋남·owner 판정 충돌·RAW_ENVELOPE_KEYS 이중소스·hdiutil 자기경로 오탐)을 한 세션에서 전부 검출·수리했다. |
| ② 결함 순차 발현 |
internal.4→5→6→7→8→9→10→11→12→13→14, 11개 버전 라벨 전 구간에서 매 단계 F71/빌드/하네스가 PASS해도 다음 단계(설치 후 실사용, 또는 P2)에서 새 결함이 하나씩 나타남 (§04·§05 전체가 근거). | internal.14에서 도입된 「보존 g→v 체인 전수 집계」(15회 중 12회 실패 실측)와 stop-line 게이트가 반복을 드러내는 것까지는 구현됨. P2 전용 계약 테스트 7종은 이번 세션에서 전부 작성·전건 PASS로 완결돼(§09) 예방적 게이트가 추가로 구현됨. 이번 세션 반대 실증: full chain 1회차에서 F71 14건이 동시 실패했을 때 하나씩 고치지 않고 14건 전수를 먼저 수집해 "전부 동일 원인"(하네스의 낡은 404 기대 선언)임을 특정한 뒤 단일 수리로 focused 14/14 PASS를 확보했다(커밋 0769c80). |
| ③ 후단 실패 시 상류 올백 |
국소 실패 지점만 고치는 방식이 3.0 스트림 대부분에서 반복됐다. 태스크 노트 원문(회고 핵심 규칙): 「국소 실패 지점만 고치는 방식을 폐기하고, 계약 변경마다 생산자 → 불변 영수증 → 실물 파서 → 최종 소비자를 하나의 양면 그래프로 전수 추적하며, 같은 실물로 최종 소비 단계까지 focused replay가 PASS하기 전에는 full build·설치를 금지한다」. | verification-stopline.js — 구현됨. 같은 64hex failure signature가 full 검증에서 2회 나오면 다음 full begin을 거부하고, focused 3연속+adjacent/pre-server 1회로만 자동 해제(종료코드 0~6 규약). 도입 시점은 08-24 15시경(network kernel 수리 이후)으로 3.0 스트림 후반에야 적용됐다.이번 세션 반대 실증: F71 14건 실패 후 처음부터 다시 시작하지 않고 focused --only 14건만 재실행했고, 5회의 full chain 사이에도 "당초 full 2회 상한"을 넘긴 것을 맹목 반복이 아니라 매번 신규 검증기 결함을 특정·수리한 뒤의 재결속으로 명시적으로 구분해 기록했다. |
| ④ 제품/하네스 오류 늦은 구분 |
internal.8 부팅 거짓 PASS(하네스 결함을 처음엔 제품 문제로 취급), internal.9 F71 15건 동시 FAIL(제품이 아니라 새 process tracker의 10ms 동기 폴링이 원인), internal.14 F71 S51(부팅 readiness 경합=하네스측 + 그래프 색인 캐시 무효화 누락=실제 제품 결함이 함께 섞인 사례). | 사건별로는 원인을 정확히 특정해 수리(하네스 3건·제품 1건 개별 커밋)했으나, "이 실패가 제품인지 하네스인지"를 자동으로 분류하는 기계 장치는 없다 — 매번 사람(코덱스/헤드)의 개별 조사로 구분. 미구현. 이번 세션 반대 실증: F71 14건 동시 실패를 발견 즉시 조사해 "제품 결함이 아니라 W1의 오늘노트 수리로 제품이 더 이상 잘못된 /api/file 프로브를 안 내는데 하네스의 기대 선언만 낡았다"고 그 자리에서 판정하고 태스크 노트에 「제품/하네스 오류를 즉시 구분(회고 지적 ④의 반대 사례)」이라고 직접 명기했다 — 다만 이 판정 역시 사람이 했고 자동 분류 장치는 여전히 없다. |
| ⑤ 실패 증거 부족 |
internal.14 6축 동결 이전까지는 실패를 재현·재해석하며 raw evidence를 남기지 않는 경우가 있었다. | internal.14 6축 동결 단계에서 「보존 P2 실패 실물 — 수정·삭제·PASS 재해석 금지」 절이 구체화됨: 스크린샷 4장(0444)·main raw JSON(0444)·terminal failure JSON·cleanup receipt를 보존하는 관행이 코드/절차로 도입됨 — 부분 구현(P2 한정, 전체 파이프라인으로 일반화되진 않음). 이번 세션 반대 실증: full chain 5회전 내내 stop-line 원장(run.50·54·55 등)에 signature를 기록하고, 실패한 P2·cleanroom 세션(예: p2-int30-ae-walkthrough-a, cleanroom stage af)을 삭제하지 않고 그대로 보존한 채 다음 회차로 넘어갔다 — 원칙이 실제로 지켜진 사례. |
| ⑥ phase resume 부재 |
원칙(「후단 실패 시 통과한 상류로 올백하지 않고 earliest-invalid phase에서만 재개한다」)은 명문화됐지만, internal.4~internal.14 구간 대부분에서 F71→package→harness 전체를 매번 재실행했다. | stop-line 게이트가 08-24 15시경 도입돼 이후 무분별한 전체 재실행은 억제됐지만, F71/package/harness 3단계를 세부 phase로 쪼개 정확한 지점부터 재개하는 코드는 이번 조사에서 확인되지 않았다 — 미구현. phase resume은 "원칙 승격은 됐으나 3.0 스트림 전체 기준으로는 늦게 도입된 부분 개선"에 그친다. 이번 세션 반대 실증: F71 14건 실패를 전체 F71 재실행 없이 --only focused 재실행(14/14 PASS)만으로 해소했다 — 다만 이는 F71 단계 내부의 부분 재개이지, F71→package→harness 3단계 사이의 phase resume은 여전히 full chain을 5회 통째로 돌리는 방식이었다. 여전히 부분 개선이라는 판정은 유지된다. |
| ⑦ 같은 빌드 반복 |
internal.4~internal.14, 11개 버전 라벨이 08-23 17:18~08-25 00시대(약 31시간) 사이 연쇄 발행됐고 다수가 "F71/빌드/하네스는 PASS했지만 P2 또는 실사용 확인에서 재차 발견"으로 local-only quarantine 처리됨. g→v 구간 명시 수치: 15회 중 12회 실패. | stop-line의 signature 재사용 거부가 같은 원인의 맹목적 재시도는 구조적으로 억제(구현됨). 다만 "다른 원인의 새 실패"는 여전히 새 full 사이클을 태우므로, 반복 빌드 자체의 총량 절감은 부분적. 이번 세션 반대 실증: 5회의 full chain이 있었지만 internal.4~14의 11회 연속 반복과 달리 같은 원인이 두 번 반복되지 않았다 — 매 회차마다 다른 신규 결함(하네스 선언·RAW 키 이중소스·소스맵 출고·hdiutil 자기경로)이었고, stop-line이 동일 signature 재사용을 실제로 거부해 맹목 반복 0건을 유지했다. |
| ⑧ producer→physical artifact→final consumer 양방향 검증 누락 |
가장 명시적으로 반복된 근본 원인 패턴. internal.9→10: P2 정렬 검증이 생산자(코드 유닛 정렬) 판정만 고치고 실물 파서(parseAsarInventory())가 다른 정렬을 반환하는 경로는 검증하지 않음. internal.13: app.asar를 lstat으로 검사했는데 Electron patched fs가 가상 디렉터리로 보여줘 실제 파일시스템 계층까지 내려가지 않은 API 레이어만 신뢰. internal.14 6축 동결이 이 문제의 최종 압축판. |
internal.14 6축 동결 지시("이 실패 실물을 최종 walkthrough·독립 cleanroom 소비자까지 읽기 전용 역재생") — 방법론은 확립됐고, 2026-08-25 01:55 원우 지시로 잠시 중단됐던 실행은 02:20 인수 이후 완주됐다. 이번 세션 반대 실증: 6축 전부를 「생산자→raw evidence→실물 파서→최종 소비자」 경로로 재생시켜 닫았고, cleanroom을 3.0 스트림에서 처음으로 끝까지 가동해 이 경로의 마지막 구간(실제 배포 산출물)까지 검증했다 — 그 결과로만 나온 결함이 5건(§09)이다. 이 원칙이 3.0 스트림에서 처음으로 완주까지 실행된 사례. |
3.0 스트림 전체를 두 시선으로 요약한다.
PENDING_CLAUDE 상태명과 모순되는 상태로 남았다 — 이번엔 reviewerId로 실제 검수자만 명기하고 어휘 자체 수리는 후속으로 미뤘다(finalizer 자기해시 결속 때문에 지금 고치면 체인 재실행 필요).파일 존재·내용 확인 기준. 「구현됨」은 코드가 실제로 동작을 강제하는 지점, 「미구현」은 원칙만 있고 코드 강제가 없는 지점이다.
| 도구/파일 | 상태 | 내용 |
|---|---|---|
verification-stopline.js | 구현됨 | 반복 full-chain 실패 정지선. 같은 64hex failure signature가 full 검증에서 2회 나오면 다음 full begin 거부, focused 3연속+adjacent/pre-server 1회로 자동 해제 |
check-spec-approval.js | 구현됨(형식 불일치) | 3.0 동결 스펙이 도구 도입 전 "8규칙" 형식이라 spec_version frontmatter·5어휘 상태표가 없어 exit 1. 기능적 승인 근거는 v0.6 GO+동결 해시+착수확정대장으로 별도 충족(도구↔형식 정합은 학습부대 백로그로 이월) |
check-ownership.js | 존재만 확인 | 내용 미검토. 병렬 워커 파일 소유권 검사용으로 추정 |
devctl.js | 구현됨 | 병렬 스쿼드 개발 스트림의 claim/release·소유 glob·주간 한도·게이트 상태 관제. Codex 주간 한도 90% 이상이면 claim을 exit 3으로 차단(단, 프로바이더별 claim 라벨 분리가 안 돼 클로드 전용 claim까지 일괄 차단되는 설계상 한계 실측됨) |
safe-harness.js/safe-harness-lib.js | 구현됨 | 25종 검사, self-hash로 게이트 6 핀(하네스 파일 변경 시 재핀 필요) — "안전 하네스 25/25 PASS"로 태스크 노트 다수 곳에서 실측 확인 |
journey.js | 구현됨 — false PASS 교정 완료, 유일 gate 아님 | 3.0 6축 결함에서 제품과 같은 오답을 복제해 false PASS한 사실이 HANDOFF에 명시. 2026-08-25 오늘노트 producer-path 회귀 수리 시 journey도 함께 재정렬해 false PASS를 교정(§04 [2/6]) — 다만 "유일 gate로 쓰지 않는다" 원칙은 그대로 유지 |
| action-manifest 계약 파일군 | 구현됨 | action 권한 재봉인(reseal) 체계가 코드로 구현. 758 candidates/17 source files, action 200개, binding 279개 등 구체 수치가 태스크 노트에 반복 인용됨 |
boot-smoke.js / boot-smoke-renderer-contract.js | 존재 확인 | 부팅 스모크 게이트 — internal.8에서 이 게이트 자체의 하네스 결함(잔존 프로세스 미검출)이 드러나 이후 보강됨 |
package-generation.js | 구현됨 | F71 authoritative 영수증의 commit/tree 결속을 기계 강제(validatePrePackageEvidence) |
deployment.js | 존재 확인 | G7B in-place 설치/롤백 절차(IN_PLACE_RSYNC_RESIGN 등) |
privacy-walkthrough.js / privacy-cleanroom.js / privacy-renderer.js | 구현됨 — 완결 | 2026-08-25 01:55 시점엔 7파일 uncommitted 부분 구현 상태였으나, 02:20 인수 이후 워커 3개 병렬(W1 public UI·W2 renderer·W3 walkthrough/cleanroom/package)로 6축을 전부 완결해 커밋(efddfde). renderer는 코덱스 패치 구조가 이미 완결 판정돼 무변경 확정, walkthrough/cleanroom은 계약 245줄+ 보강 후 전건 PASS |
| P2 전용 계약 테스트 7종 (today-note-link-browser·internal-chat-ui·privacy-renderer·privacy-walkthrough·privacy-cleanroom·p2-privacy-walkthrough-oracle·package-generation, 각 -contract.js) | 구현됨 — 7종 전부 존재·전건 PASS | 이전 조사 시점(HANDOFF "계약 미작성/미수정")과 달리, 2026-08-25 6축 완결 이후 test/에서 7개 파일명 전부 실측 확인됨(전체 180개 목록). 최종 focused 4종 헤드 재실행 전건 PASS, cleanroom-contract·package-generation-contract도 이후 별도 실행에서 PASS |
desktop/electron-builder.json 소스맵 제외 글롭 | 구현됨 (2026-08-25 신설) | cleanroom 첫 실전에서 출고 asar/unpacked에 의존성 소스맵 96개+winpty misc 노트 4개가 release-surface 정책(absent) 위반으로 실려 있음을 검출. !**/*.map·!node_modules/node-pty/deps/winpty/misc/**를 FILES 생산자측에 추가해 봉쇄(커밋 df73a30) |
scrubImageMetadataSelfReference()(desktop/privacy-cleanroom.js, test/privacy-cleanroom-contract.js) | 구현됨 (2026-08-25 신설) | hdiutil imageinfo 영수증이 자기 DMG의 절대경로(file:// URL)를 내장해 개인 홈 경로 기계에서 구조적으로 통과 불가했던 결함 수리. 정확히 자기 경로만 토큰 치환하고 타 identity 검출은 유지 — 계약에 양방향(자기경로 치환 O / 타 identity 탐지 O) 증명 포함(커밋 4d9cd365) |
RAW_ENVELOPE_KEYS 동결 상수(desktop/privacy-walkthrough.js) | 구현됨 (2026-08-25 신설) | validateRawAndScreenshots가 assertRawProtocolShape(신 17키) 옆에 자기만의 낡은 16키 리터럴(cacheProbes 누락)을 따로 갖고 있던 파일 내 이중 소스가 fresh P2에서 P2_RAW_BINDING 실패로 드러남. 단일 동결 상수로 두 검사를 통합해 이중 소스를 제거(커밋 3725980) |
standaloneBootProbe404 선언 은퇴(test/sim-harness/manifest.js) | 구현됨 (2026-08-25 신설, 하네스측) | 제품이 오늘노트 수리로 더 이상 잘못된 /api/file 프로브를 내지 않는데도 하네스가 낡은 기대 선언 14종을 유지해 F71 14건이 동시 fail. 선언 제거로 정합시키고, 이후 /api/file 404는 무선언 초과 발생으로 감시(커밋 0769c80) |
이 보고서 확정 시점 기준, 브릿지 페이지는 internal.6 기준으로 로컬 준비만 된 상태다. 3.0.0-internal.15 라이브 설치 완료(§04·§05) 이후 별도 워커(W8)가 dist-hub 갱신·R2 업로드·Pages 배포·HTTP 검증을 진행 중이며, 아래 값은 W8 착수 이전 마지막 실측이다.
bridge-release-manifest.json statuscandidate: null배포안내 문서(2026-08-23_인터널_3.0.0-internal.6_배포안내.md) frontmatter는 상태: 검증 대기이며, "R2 업로드, Pages 배포, 브릿지 HTTP 확인은 아직 완료로 기록하지 않습니다"라고 문서 자체가 명시한다. §4 영수증 슬롯(F71/안전 하네스/BOOT-SMOKE/G7B/R2/Pages/브릿지)이 전부 검증 대기로 비어 있다. index.html의 버전 표기는 4곳 모두 v3.0.0-internal.6로 남아 있다.
이 문서의 수치는 팩트시트 수집 시점(2026-08-25) 기준 실측이며, 추정치는 각 절 본문에서 "추정" 또는 "미확인"으로 별도 표기했다.
스펙 v0.6은 74항목 전수 재판정 뒤 SHA-256으로 동결됐다[1]. 착수확정대장은 시안 게이트 4라운드(D41~D54)를 거쳐 결정 21건·조건 12건으로 확정됐다[2]. g→v 보존 체인 15회 중 12회 실패는 08-24 15시경 자체 집계 수치다[3]. P2 6축 결함과 중단 시점 상태(HEAD/tree/uncommitted 7파일)는 HANDOFF.md 3~180행에 기록돼 있다[4]. 기계 강제 장치 현황은 gridos-internal-development-ops/tools/와 int30-base worktree test/(180개 파일) 파일 존재·내용 확인 기준이다[5]. 인수 이후(2026-08-25 02:20~06:25) 6축 완결·full chain 5회전·cleanroom 첫 실전·라이브 설치 완료의 커밋·시각·결함 목록은 6축 수리 태스크 노트 162~177행(원우 지시 중단 이후 절)에 기록돼 있으며, 최종 커밋 해시는 int30-base worktree git log 실측으로 재확인했다[6].
tsk-01M0BSM549MY052512TFVCXFF2) — 흡수 20·폐기 2·이월 48·보류 4, SHA-256 5bd2de22f257b3b88a3ba0008f7d26cad0d21de7c9a332484232dcc5ff93e062. 본문으로tsk-01M0CNVX98TPNEE6ZHVEQM4H40) — 착수확정대장 「대장에 없는 확정은 없는 것」. 본문으로ls test/ | wc -l 실측(2026-08-25 6축 완결 이후 기준, 팩트시트 수집 시점 179개에서 1개 증가). 7개 계약 파일은 이 재실측에서 전부 확인됨. 본문으로tsk-01M0GZ31PRTF9Q03P1H4JV3Q85) 162·167·170~177행. 최종 확정 커밋 4d9cd365d3dbe49093fa2c126e8d4b81e9f79b38은 int30-base worktree(.gridos/worktrees/int30-base) git rev-parse HEAD·git log로 재확인, working tree clean. 본문으로