60 단계의 한정된 설명 검토 규칙 — 준비안

기존 코드 설명이 실제 구현을 얼마나 충실하게 전달하는지, 그리고 요청의 어떤 조건을 담거나 빠뜨리는지를 나누어 검토합니다. 현재 문서는 검토 방법과 근거 위치를 미리 정한 준비안입니다. 실제 설명 평가와 승인은 아직 0이며 모든 상태는 pending입니다. 원본 선언을 다시 연결하는 60 단계 실행과 이 규칙의 별도 동결이 끝난 뒤에만 본 평가를 시작합니다.

대상은 이미 정한 stable-odd, atomic-commit, error-identity 세 계열입니다. 기존 부모 12개, 후보 위치 36개, 소스 ID 11개, 서로 다른 후보 문장 12개, 유한 사례 34개를 그대로 사용합니다. 문장이나 후보 위치가 반복되어도 새로운 독립 요청으로 세지 않습니다. 이 범위는 기존 738개 검토 항목 중 요청 12개, 후보 연결·충실도·범위 각 36개, 관찰 계약 3개에 해당하는 123개 항목의 준비 범위입니다. 아직 123개도, 전체 738개도 완료되지 않았습니다.

같은 질문으로 합치지 않는 네 축

기존 축	검토할 내용
source_fidelity	설명이 그 구현의 동작을 충실하게 전달하는가? 의도적으로 틀린 구현도 정확히 설명할 수 있습니다.
request_contract_coverage	요청과 설명이 유한 계약의 조건을 담거나 빠뜨리거나 서로 충돌하는가?
observation_fields	반환값·오류·변경된 상태·순서·소유권·패닉 관찰이 실제 관찰 범위 안에서 설명되는가?
explicit_negative_boundaries	포함·제외, 잘못된 입력, 지원하지 않는 입력과 범위가 명확한가?

상태 이름은 59 단계의 pending, consistent_with_scoped_evidence, omits_required_scope, contradicts_scoped_evidence, unsupported_or_uncertain을 유지합니다. 한 축의 일관성은 다른 축의 통과를 뜻하지 않습니다. 예를 들어 양수인 홀수만 남긴다는 설명이 구현에 충실하더라도, 음수 홀수도 남겨 달라는 요청과는 충돌할 수 있습니다. 기존 정답·오답 플래그, 허용 후보, 실패 수, 랭킹 점수를 설명 충실도의 판단이나 학습 특징으로 복사하지 않습니다.

어느 근거가 있어야 상태를 바꿀 수 있나

자동으로 확인할 부분은 원본 파일과 문장의 SHA·바이트 수·JSON 포인터, 후보 순서와 ID, 계약 참조, 소스의 원본·서식화·정규화·묶음 해시가 정확히 이어지는지입니다. 60 단계의 성공 결과는 정확한 실행기·Go 도구 모음·바이너리·입력·계획과 부분 실패 카운터를 기록해야 합니다. 해시 연결 성공이나 녹색 CI 자체는 문장의 의미를 승인하지 않습니다.

그다음 독립적인 코드 읽기로 각 문장의 실제 구절, 해당 구현의 분기와 쓰기 순서, 필요한 작성 함수·도우미·타입·메서드·센티널, 관찰기와 리터럴 필드를 연결합니다. 표준 라이브러리에 의존하는 가정도 적습니다. 연결 검토가 해당 유한 범위의 작성 의존성을 빠짐없이 설명했을 때만 그 범위의 일관성을 기록할 수 있습니다. 일반적인 객체 해석이나 프로그램 전체의 완전한 의존성 분석을 수행했다고 주장하지 않습니다.

각 의미 판단은 정확한 문장 바이트 구간, 소스 선언 참조, 입력 범위, 관찰 필드, 제외 범위, 남은 불확실성, 검토자와 불변 기록 SHA를 남겨야 합니다. 필요한 내용이 빠졌으면 omits_required_scope, 명시적으로 어긋나면 contradicts_scoped_evidence, 여러 해석이 남거나 관찰보다 큰 약속이면 unsupported_or_uncertain으로 기록하는 규칙을 미리 정합니다. 실제로 해당 상태를 부여하는 작업은 아직 하지 않았습니다. 한 축 안에 해결되지 않은 중요한 구절이 있으면 그 축 전체를 일관성 통과로 묶지 않습니다. 후보를 하나의 종합 승인 값으로 바꾸지도 않습니다.

세 계열에서 특히 확인할 경계

• 홀수 유지: 음수, 중복, 순서, 짝수 제외와 입력 변경 여부를 구분합니다. 기존 slices.Equal 관찰은 nil과 빈 슬라이스를 구분하지 않습니다. 별칭·용량·할당량도 관찰하지 않았습니다. 이 기존 검사에서 패닉이나 입력 변경은 unknown이며, 다른 타입 계약의 실패 처리로 바꾸지 않습니다.
• 원자적 설정 변경: 성공 시 반환과 목적지 쓰기, 실패 시 부분 반환과 목적지 부분 변경을 따로 봅니다. 정확한 네 바이트 ASCII DD,F, Count/Enabled, 정확한 ErrSyntax, Returned/After/Error/Panicked와 새 nonnil 목적지를 연결합니다. or zero if invalid의 invalid가 앞의 두 숫자인지 전체 문법인지는 미리 한쪽으로 해석하지 않습니다. nonnil 전제가 nil 목적지의 안전성을 보장하지 않습니다.
• 오류 정체성: 같은 메시지와 같은 오류를 구분하고, 감싸기·합치기·직접 비교·문자열 비교·Is/As를 따로 봅니다. 원래 반환 코드와 반환 후 Cause.Code 변경은 다른 관찰입니다. 일부 사례에는 원인 오류가 없거나 입력 오류가 nil입니다. 따라서 Cause pointers are nonnil 구절의 범위를 그대로 검토 대상으로 남깁니다. without changing the error chain은 Cause.Code 확인만으로 체인 전체 불변성 관찰이 되지 않습니다. typed nil과 사용자 정의 Is/As/Unwrap은 현재 사례 밖입니다.

세 모호한 요청은 그대로 unknown입니다. 전체 72개 부모·216개 후보·unknown 21개·연결 그룹 17개·알려진 요청을 포함한 그룹 16개를 유지합니다. 일부 설명 근거가 정리되어도 새로운 진실 라벨이나 학습 분할을 만들거나 training_ready를 true로 바꾸지 않습니다. 2,400개 보호 최종 요청 목표는 별도로 유지하고, 모든 개발 학습에 2,400개나 새로운 15개 저장소 조건을 요구하지 않습니다.

파일과 다음 순서

규칙 JSON은 체크리스트·상태 어휘·나중의 판단 기록 필드를 담습니다. 참조 준비 JSON은 원본 59 단계에서 가져온 문장 포인터·SHA와 작성 구성 요소 참조를 담습니다. 후자의 행은 선택된 위치를 위한 참조 준비 행이며 실제 의미 판단 기록이 아닙니다. 리터럴 표를 값으로 재구성하거나 후보를 실행하지 않았고, 후보별·벡터별 실제 Got도 새로 만들지 않았습니다. 기존 집계 실패 수는 벡터별 Got의 대체물이 아닙니다.

다음 순서는 규칙과 실행 근거 동결 → 원본 선언 연결 성공 확인 → 제한된 독립 의미 검토 → 해결된 축과 미해결 구절을 함께 기록하는 것입니다. 현재 준비에서 원본 inventory·AST·formatter·SourcePins·Bind·Generate·후보 API·모델·유료 평가·새 라벨·분할·학습·가중치 생성은 모두 0입니다. 별도 사람 승인 단계를 추가하지 않고 기존 CI 병합 규칙을 유지합니다. 코드 읽기만으로 비용·메모리·속도 개선을 주장하지 않습니다.