fix(audit): 턴 귀속을 응답 그룹의 첫 행에 맞추고 라벨 고착을 없앤다 (gen25)

[ictechgy]

머지 방식: merge commit 필수. squash 하면 main 이 깨진다.
이 PR 은 Gate-B 세대(bless + reapply 3 + record)를 담고 있고, 롤백 증명이 그 다섯 커밋을 subject 로 찾아 각각이 main 의 조상인지 확인한다. squash 는 그것들을 합쳐 버린다. 실제로 #351 에서 한 번 일어났고 복구에 #354 가 필요했다.

두 결함, 반드시 함께 고쳐야 한다

라벨 고착. claude_transcript_cost_audit.py 는 last_result 를 파일 시작에서만 초기화한다. 그래서 새 도구 결과가 없는 턴이 앞 턴의 라벨을 물려받는다. 코드 자신의 주석(:1465-1467)과 사용자용 노트가 반대를 약속하고 있었다.

스냅샷/reducer 불일치. 스냅샷은 accepted 행마다 찍히고 매번 비워지는데, reducer 는 한 응답 그룹의 마지막 행을 고른다. 여러 행으로 나뉜 응답은 이미 비워진 스냅샷을 읽는다.

순서가 결론이다. 라벨만 고치면 지금보다 나빠진다. 다중 행 턴이 전부 no_tool_result 로 재분류되기 때문이다. 이 PR 의 테스트는 라벨을 카운터보다 먼저 단언하므로, 앵커 없이 라벨만 고친 트리는 여기서 실패한다(변이 A1 로 확인).

창 누적을 별도 합산 없이 얻는 방법

검증에서 "바이트 카운터는 창 누적이 필요하다" 는 지적이 나왔다. 스냅샷 초기화를 행마다가 아니라 응답 그룹 경계에서만 하도록 옮겨서 해결했다. 그러면 그룹 첫 행의 스냅샷이 곧 "이전 응답이 시작된 이후 도착한 전부"가 되고, 소비자는 #375 가 노출한 group_first_row_ordinal 한 곳만 읽으면 된다. 그룹 중간에 도착한 tool_result 가 아무 턴에도 귀속되지 않던 문제도 함께 사라진다.

multi_result_turns 가 108 에서 2,150 으로 올라 독립 측정치(~2,137)와 맞는다.

세 갈래 캐시 축

cache_read <= cache_creation 하나로 묶으면 콜드 스타트가 재작성에 섞인다. 실측으로 콜드 스타트가 전체 토큰의 18.75%다. 그래서 셋으로 가른다.

축	턴	토큰	점유
cold_start (cache_read 없음)	138	42,784,745	18.75%
cache_rewrite (0 < cache_read <= cache_creation)	373	132,584,619	58.10%
incremental	28,204	52,839,755	23.15%

rows 의 행이 아니라 직교 필드다. 행으로 두면 이 버킷이 1위가 되어 covers_all_turns 가 거짓이 되고 aim 권고가 그 버킷을 지목한다. 테스트가 행이 되지 않는 것을 고정한다.

권고도 함께 고쳤다

접두사 쓰기가 우세하면 도구를 지목하지 않는다. 고치기 전에는 no_tool_result 를 지목하며 "규칙 파일과 MCP 카탈로그를 보라" 고 했는데, 그 버킷의 대부분이 접두사 재작성이라 틀린 곳을 가리킨다.

[P1] Most new tokens come from prefix writes, not from tool results
     76.7% of cache_creation tokens landed in 509 turns that wrote the cached
     prefix rather than extending it (372 rewrites, 137 cold starts).

교정된 수치

	배포본	이 PR
no_tool_result 점유	~1.5-3%	71.81%
Bash 점유	75.7%	17.68%
multi_result_turns	108	2,150

CHANGELOG.md:53-55 의 "81.5% of new tokens per turn landing right after a Bash result" 는 별도 PR 에서 정정한다. 정직한 대체값도 측정해 뒀다. incremental 턴만 보면 Bash 가 69.32% 로 여전히 1위이므로 escrow 기본값 결정 자체는 그 근거로 살아남는다.

변이 테스트

변이	결과
A1 앵커 없이 라벨만 수정	잡힘 (다중 행 테스트에서)
A2 라벨 수정 없이 앵커만	잡힘
A3 행마다 초기화로 되돌림	잡힘
A4 cold_start 를 cache_rewrite 에 합침	잡힘

검증

python3 scripts/verify_gate_b_rollback.py   OK (active_generation=gen25, generations=25)
tests.test_gate_b_rollback_proof            Ran 73 OK, exit 0
audit 관련 스위트 3종                        Ran 74 OK, exit 0
scripts/ci_test_gate.py fast                Ran 76 OK, exit 0
실제 3.11 compileall                         exit 0
scripts/sync_plugin_copies.py --check       plugin copies synchronized
scripts/prepublish_check.py --skip-tests    prepublish check: OK
scripts/release_preflight.py                경고 없음

preflight 이 세대 밖 동결 편집을 실제로 잡는지 대조 실험으로 확인했다. 같은 편집을 세대 없이 별도 워크트리에 커밋하면 ::warning::Gate-B frozen paths changed (gen24) 가 나온다.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DE3AupXcyv64SEuQeTckSh

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: dfd82206-eb3f-44e3-bad1-74e7ee80425b

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ictechgy]

core-pr 실패 추적: 제 변경이 드러낸 잠재 결함이었습니다

core-pr 이 두 번 실패했습니다. 저장소 규칙대로 대조 실험부터 했습니다.

1차 실패 4건 중 3건은 알려진 flaky. adversarial.test_g012_mcp_capabilities 는 tests/AGENTS.md 표에 등재돼 있고, contract.test_g008_runner 는 핸드오프에 "병렬 게이트에서 실패, 단독 통과" 로 기록돼 있습니다. 재실행에서 셋 다 사라졌습니다.

남은 1건은 재현됐고, 진짜였습니다. test_stream_parser_maps_runtime_decode_limits_to_fixed_codes 가 두 번 다 'success' != 'invalid_stream' 로 실패했습니다. 이 테스트 파일은 claude_transcript_cost_audit, transcript_usage_reducer, by_preceding_tool, group_first_row_ordinal 중 무엇도 참조하지 않고, 로컬에서는 3.11·3.12·3.14 전부, origin/main 에서도 통과합니다.

원인. claude_transcript_cost_audit.py 의 parse_json_line 이 프로세스 전역 재귀 한도를 1,000 에서 10,000 으로 올리고 되돌리지 않습니다. core 파티션은 1,797개를 한 프로세스에서 돌립니다. 이 PR 이 audit 스캔을 실행하는 테스트 4개를 추가하면서 그 누수가 벤치마크 스트림 테스트보다 먼저 일어났고, 2,000단 중첩 JSON 이 거부되지 않고 파싱됐습니다.

한 프로세스에서 순서대로 돌려 로컬 재현했습니다.

recursionlimit before: 1000
(audit 테스트 실행)
recursionlimit after:  10000
benchmark stream test -> FAIL

조치. 누수를 막았습니다. restored_recursion_limit() 컨텍스트 매니저가 scan() 을 감싸 끝날 때 원래 값으로 되돌립니다. 줄 단위 핫 패스인 parse_json_line 에서 매번 복원하지 않는 이유도 주석에 적었습니다. 회귀 테스트 두 개를 넣었습니다. 스캔 후 한도가 그대로인지, 그리고 예외가 나도 finally 로 복원되는지. 복원을 빼는 변이가 잡히는 것을 확인했습니다.

같은 프로세스에서 audit 테스트 뒤에 벤치마크 스위트를 돌려 191건이 모두 통과합니다.

이 수정은 동결 파일이라 세대를 최종 내용으로 다시 작성했습니다. 지문은 그대로 bd21e82a 입니다.