Skip to content

영역 식별·대응 기반의 변화 설명, 리팩터링 점검 및 증분 분석 확장 #987

Description

@akcorca

현재 상태 — v0.21.0 출시 반영 (2026-09-08)

PR #988이 main에 병합됐고 v0.21.0으로 출시됐다. #984의 검토 식별자 계약과 A/B1/B2, C 중 검토 기록·적용성 확인은 출시된 범위다. 로컬 구현에만 머물러 있는 상태가 아니다.

단계 현재 상태 남은 범위
A / B1 / B2 v0.21.0 출시 완료 유지·회귀 검증
C1: 검토 기록과 적용성 v0.21.0 출시 완료 소비자의 정책·승인 소유권 유지
C2: 원래 리팩터링 대상의 처리 점검 미완료 원래 대상별 잔존·변경·판단 불가를 추적하는 전체 사용자 흐름
D: 영역 단위 재사용 조건부 후속 과제 기존 캐시로 해결되지 않는 구체적인 miss와 개선 효과를 확인한 뒤 착수 판단
E: 복잡한 대응·이력 연구 조건부 후속 과제 실제 미해결 사례와 사용자 손실을 먼저 확인하고 연구별 착수 판단

이 이슈는 C2와 후속 과제의 목표·착수 판단을 추적하는 상위 기획으로 열린 상태를 유지한다. D/E는 v0.21.0의 미완료 필수 작업이나 릴리즈 차단 조건이 아니다. 이번 릴리즈의 일반 성능 최적화·캐시 동등성 검증을 D의 영역 단위 재사용 구현 완료로 간주하지 않는다.

목적

영역 식별자, 내용·증거 기반 review_key, 명시적인 스냅샷 대응을 활용해 nose가 코드의 현재 상태와 변화 전후의 관계를 함께 설명하는 엔진으로 발전하도록 한다.

#984에서 출발한 검토 식별자의 활용을 넘어, 검출 품질·에이전트의 리팩터링 루프·분석 비용·변화에 대한 검증을 연결하는 후속 기획이다. 하나의 빠른 Rust 바이너리, 결정적 출력, 의미 동등성 판정의 soundness라는 제품 원칙을 유지한다.

제품 적합성과 첫 번째 목표

이 기획의 제품 목표는 호출 에이전트가 검출 결과를 덜 다시 읽고도 변화의 이유와 다음 조사 대상을 찾게 하는 것이다. 의미 동등성 판정의 soundness, 결정성, 빠른 단일 바이너리와 기존 nose query 탐색 경험을 완료 조건으로 둔다.

첫 출시는 완전한 두 분석 결과 → 변화 요약 → 원인별 탐색 → 개별 대상의 전후 증거라는 작은 흐름으로 제한한다. 이 흐름만으로 검토 대상 재발견 비용이 줄어드는지 측정한다. 일반 계보 플랫폼, 승인 정책 엔진, 새 위험 점수, 자동 리팩터링 실행기는 이 단계의 목표가 아니다.

현재 기반과 차이

  • 원본 버퍼와 바이트 범위로 영역을 지칭하고, 위치와 내용의 식별을 분리한다.
  • review_key는 구성원의 중복을 보존하는 내용·분석·증명 근거를 결합한다. 키의 변화만으로 변화의 이유를 설명하지는 않는다.
  • regions snapshot/compare는 singleton을 포함한 영역과 보수적인 대응 근거를 제공한다. 추출·인라인·분할·병합의 자동 계보 판정은 제공하지 않는다.
  • 현재 snapshot v1은 고정된 추출 프로필을 사용한다. 사용자 query 설정과 외부 semantic pack까지 비교하려면 별도의 명시적인 실행 프로필 및 결과 계약이 필요하다.
  • since=FILE과 status=new|changed|unchanged는 이미 저장된 baseline을 대상으로 하는 temporal lens다. 기존 baseline 의미와 신규 영역·증거 비교 의미를 구분하면서, 탐색 경험은 기존 query를 확장하는 방향을 우선 검토한다.
  • base=<ref>의 changed[].semantic_change는 이미 value/return/control/effect 변화와 coverage/caveats를 제공한다. Divergent gate 0.20: prove semantic change witnesses beyond shared-line contact #849/#852의 근거와 정책 분리를 재사용하고 별도의 의미 변화 판정기를 중복 구현하지 않는다.
  • 기존 증분 CAS·의존성 무효화, watch의 완전 dashboard 교체 스트림, bounded history mining을 기반으로 한다. watch가 현재 뷰의 완전한 응답을 제공한다는 사실은 전체 분석 모집단을 저장한다는 뜻이 아니다.
  • sort=hazard는 실질 피해 순위로 검증되지 않았고 기본값은 extractability다. 이력 연구는 이 기존 음성 결과를 출발점으로 삼는다.

설계 기준: 영역 식별 계약, 제품 방향, divergent edits, 캐시 계약.

추가 기준: 에이전트 탐색 프로토콜, query 문법, JSON 증거 계약, watch 계약, 기존 hazard 평가.

개선안 — 제품 가치 기준 우선순위

1. 검출 결과의 변화와 이유 설명

두 실행의 결과를 비교해 위치 이동, 구성원 추가·삭제, 선택된 코드 변경, 분석·증명 근거 변경, 대응 불명확을 구조적으로 보고한다. 여러 변화가 동시에 발생할 수 있으므로 단일 원인으로 강제 분류하지 않는다.

키를 구성하는 영역·구성원 관계·분석 근거·외부 의존성을 비교하는 공통 모듈을 만들고, 결과 비교·검토 적용성·리팩터링 점검이 이를 공유한다. 해시 불일치만 보고 원인을 추측하지 않는다. 변화의 이유와 이를 뒷받침하는 근거를 함께 제공하며, 조회용 JSON에서 소비자가 해시 입력의 직렬화 규칙을 다시 구현하게 하지 않는다. 결정적인 정렬과 버전이 있는 JSON 계약을 제공한다.

의미: 에이전트가 다시 읽고 판단해야 할 범위를 줄이고, 검출 결과가 바뀐 이유를 설명한다.

2. 누락된 형제 코드 수정 검출 개선

기존 base=<ref>의 변경 줄·과거 clone family 정보를 영역 대응과 결합한다. 이동 및 주변 편집과 실제 공유 로직 변경을 구분하고, 수정된 형제의 현재 위치를 제공한다.

의미: 기존 semantic_change로 설명되지 않는 이동·대응 실패 사례를 먼저 고정하고, 새 영역 대응이 줄이는 오류와 늘리는 비용을 비교한다. 새 대응은 초기에는 review evidence로 제공한다. strict/gate 정책 변경은 별도 qualification을 통과한 후속 범위이며, 대응 개선만으로 기존 gate를 강화하지 않는다.

3. 리팩터링 전후 결과 점검

원래 검출된 영역들이 편집 후 어떻게 처리되었는지 보고한다. 예를 들어 세 복사본 중 둘의 공통 함수 추출 후보와 남은 한 복사본을 구분한다. 검출 결과의 소멸만으로 성공을 선언하지 않는다.

초기 범위는 현재의 확실한 대응과 잔존 영역 확인이다. 추출·인라인의 복잡한 대응은 7번의 결과에 따라 확장한다. 영역 대응, 정적 의미 증거, 실행 테스트 결과는 별도로 표시한다.

의미: 에이전트의 탐색 → 수정 → 점검 루프를 닫고, 원래 리팩터링 대상의 처리 누락을 드러낸다.

4. 검토 기록의 적용 가능성 설명

review_key와 영역 대응으로 근거 유지, 내용 변경, 새 복사본 발생, 적용 범위 변경, 판단 불가를 제공한다. 소비자는 적용 범위와 정책을 명시하며, 검토 기록·승인 여부는 계속 소비자가 소유한다.

의미: Ceal 등 소비자가 독자적인 지문 알고리즘 없이 기존 검토를 관리할 수 있게 한다. nose는 내용·증거·scope에 관한 사실을 제공하고, 업무 정책 해석과 승인 저장소를 구현하지 않는다. 업무 정책에 따른 최종 적용 여부는 이 사실들을 받은 소비자가 결정한다. 새 복사본에 대한 승인을 자동으로 상속하지 않는다.

5. 영역 단위 분석·증명 재사용 확대

기존 캐시에서 실제 재분석 비용을 측정한 뒤, 파일 일부 변경 시 영향받지 않은 영역의 분석 재사용을 확대한다. 원문 외에 정규화 설정, 의존성, pack, 증명 규칙·스키마 버전 등 단계별 필수 입력을 재사용 조건에 포함한다. 위치 정보는 현재 원본에 재결합한다.

의미: 편집 규모에 비례하는 재분석 비용을 지향한다. 기존 캐시의 재사용률과 병목을 먼저 측정하고 새 식별 자산이 해결하는 구체적인 miss가 있을 때 착수한다. review_key나 내용 키만으로 캐시 유효성을 판정하지 않는다. 실행 시 증명/인터프리터 검증을 추가하는 범위가 아니다.

6. 코드 변화를 검증하는 평가 체계

이동·복사·추출·인라인·분할·병합·의존성 변경을 평가 축으로 삼는다. 통제된 변형과 검토된 실제 변경 이력을 함께 사용한다. 동일 내용의 삭제 후 재생성처럼 스냅샷만으로 판별할 수 없는 사례도 포함한다.

의미: 변화 후 잘못된 대응, 불필요한 검출 변동, 증분 캐시 오류를 지속적으로 측정한다. 초기 기반 작업부터 구축하고 후속 기능의 공통 검증 장치로 사용한다.

7. 추출·분할·병합을 표현하는 영역 대응

일대다·다대일 대응을 명시적으로 표현한다. 부분 영역 정렬, 주변 구조, 의미 분석을 후보 근거로 사용하고 후보와 확정 가능한 사실을 구분한다. 작은 후보 집합을 색인으로 찾은 뒤 제한된 정렬을 수행하며, 예산 초과와 모호함을 결과에 남긴다.

생물정보학의 구간 정렬·중복 관계 표현, CAD의 지속적 식별, record linkage의 미결정 상태 등 기존 연구 방향을 검토하되, 해당 분야의 정확도를 nose의 정확도로 간주하지 않는다.

의미: 복잡한 리팩터링을 설명하는 조건부 연구 과제다. 현재 대응으로 해결되지 않는 실제 리팩터링 사례와 사용자 손실을 먼저 확인한다. 현재의 보수적인 대응을 비교 기준으로 삼아, 잘못된 대응·미해결률·비용을 함께 평가한다. 개선이 없으면 기존 대응과 명시적인 미해결 상태를 유지하고 연구를 종료할 수 있다.

8. 변경 이력을 이용한 리팩터링 우선순위

명시적으로 제공된 bounded history에서 함께 반복 수정된 복사본, 반복적으로 수정이 누락된 형제, 독립적으로 변해 온 복사본을 구분한다. 기존 history mining의 중복 결과 묶음에도 영역 대응을 활용한다.

의미: 먼저 이미 발생한 누락 수정의 증거와 반복 결과 묶음 개선을 제공한다. 새로운 순위는 현재 extractability 및 기존 history grouping 대비 추가 가치가 시간 분할·저장소 분리 held-out 평가에서 확인될 때만 선택 기능으로 제공한다. 공동 변경·발산 빈도를 실제 피해나 리팩터링 필요성과 동일시하지 않는다. 기본 순위를 바꾸지 않으며 최종 판단은 소비자가 한다. 이력은 선택 입력이고 기본 실행에 Git 이력이나 네트워크를 요구하지 않는다.

CLI 자체설명과 EDA 탐색 계약

사용자는 nose query의 landing → slice/facet → 개별 대상 → 근거 → 다음 명령 흐름을 그대로 따라갈 수 있어야 한다. CLI 표현은 단계 A에서 고정한다. 아래는 제품 계약이며 아직 지원하지 않는 문법을 실행 예시처럼 제시하지 않는다.

  1. 진입과 요약: 기존 query의 시간 비교 맥락에서 새 분석을 발견할 수 있게 한다. since=FILE의 기존 baseline 해석은 유지하고, 새 산출물의 형식/프로필을 구분한다. regions snapshot/compare는 영역 산출물과 재현 가능한 저수준 비교를 맡는다. 별도 탐색 DSL을 만들기 전에 query 통합안을 먼저 평가한다.
  2. 점진적 탐색: 비교 입력 두 개와 프로필, 전체/표시 건수, 변화 유형별 수, 모호함·미해결·비교 불가 수를 먼저 보여준다. 이후 변화 이유·증거 상태와 기존 scope/lang/path/witness 등의 적용 가능한 축으로 필터·그룹하고, 대표 항목에서 상세 증거로 이동한다. 복수 변화 이유의 그룹 건수는 중복 집계를 명시한다.
  3. 상세 대상 주소: 현재 family의 id=/at= 탐색과 연결하되, 사라진 항목·singleton·복수 대응은 과거 산출물과 발생 위치를 포함하는 명시적인 주소로 연다. many-to-one인 review_key를 유일한 family/발생 위치 주소로 쓰지 않는다. id=의 기존 의미를 바꾸지 않는다.
  4. 실행 가능한 다음 단계: 요약·그룹·항목·빈 결과·부분 결과에 이유가 있는 next:/JSON next를 제공한다. 다음 명령은 두 입력, 분석 모드, 다중 root, config/pack, 현재 필터와 비교 범위를 보존한다. 필터를 완화할 때는 무엇을 바꾸는지 표시한다. 공백·특수문자가 있는 경로도 올바르게 인용한다. 현재 원본이 없어도 저장된 비교 증거는 열 수 있어야 한다. 저장하지 않은 원문이나 필수 입력이 없으면 실행 불가능한 원문 drilldown을 만들어내지 않고 필요한 입력을 설명한다.
  5. 사람/기계의 같은 의미: human과 JSON은 같은 선택과 증거 상태를 표현한다. 짧은 의미 설명과 구조화 reason code를 함께 제공하고, 원문/상세 증거는 필요할 때 펼친다. 미계산·미지원·누락·모호함·예산 초과를 각각 구분한다. 구현 해시·캐시 상세는 일반 탐색에 강제로 노출하지 않는다. capabilities, --help, query 도움말과 agent recipe에서 기능·허용 필드·조합·출력 스키마를 발견할 수 있어야 한다. CLI 입력의 알 수 없는 필드/값과 지원하지 않는 조합은 명시적인 오류다. JSON 소비자의 알 수 없는 추가 필드 처리 규칙은 기존 버전 계약을 따른다.
  6. 기존 뷰와 제한: base=는 현재 일반 필터/group/id 조합을 거부한다. 새 EDA 요구를 구현할 때 지원 범위를 명시적으로 확장하거나 별도 조회 맥락을 제공하며 기존 제한이 이미 풀린 것처럼 다루지 않는다. watch v1의 완전 dashboard 교체·오류 회복 계약과 기존 gate의 판정 모집단을 유지한다. top=N은 표시 제한이며 대응 후보 예산이나 완전성을 바꾸지 않는다.
  7. 비용: 추가 근거 비교·원문 표시·이력 분석은 명시적으로 요청할 때 수행한다. 일반 query 기본 경로의 시간·메모리·출력 크기 영향을 함께 측정하고, 큰 증거는 공통 산출물을 참조하여 반복 전송을 줄인다. 명시적 입력으로 재현하며 숨은 서버 세션을 요구하지 않는다.

비교 산출물의 완전성과 호환성

  • 비교용 입력은 프로필, 분석 옵션, source discovery/제외 범위, 증거 가용성, 탐지/추출 coverage, 필터·표시 제한 여부를 기록한다. 비교 대상으로 선언한 모집단 안에서만 부재를 해석한다.
  • dashboard 상위 5개, 제한된 list, 필터된 query JSON, watch dashboard에서 빠졌다는 이유로 코드 삭제나 리팩터링 완료를 주장하지 않는다. all top=0도 해당 분석 프로필의 admitted 대상 범위이지 모든 코드 영역의 전수 목록은 아니다.
  • 전체/선택/표시 건수와 입력 수집·분석·대응의 coverage를 구분한다. 표시를 줄여도 전체 모집단의 대응 결과나 gate 의미가 바뀌지 않는다. 숨긴/제외한 항목은 수와 이유를 보여주고 적용 가능한 범위에서 다시 탐색할 수 있게 한다.
  • 구조화된 원인 근거가 없는 구버전 산출물은 키/관측 사실 수준까지만 비교한다. 상세 원인을 unknown/unavailable로 남기고 해시 변화에서 복원해 추정하지 않는다. 입력을 새 형식으로 다시 확보하는 방법을 안내한다.

공통 계약과 경계

  • 내용 동일성, 의미 동등성, 역사적 대응, 검토 승인, 캐시 유효성을 각각 구분한다.
  • review용 지문을 검출의 의미 동등성 승인 경로에 사용하지 않는다.
  • 같은 내용만으로 계보를 확정하지 않으며, 같은 검토 키만으로 신규 복사본을 승인하지 않는다.
  • 프로필 불일치, 누락된 원본·증거, 모호한 대응, 예산 초과를 명시한다. 불완전한 후보 목록을 유일한 대응으로 해석하지 않는다.
  • 실행 설정과 증명 근거의 비교 가능성을 검증한다. 현재 고정 프로필의 snapshot을 임의 query 결과와 묵시적으로 혼합하지 않는다.
  • 기존 family/member ID, baseline, ignore, SARIF 계약을 묵시적으로 바꾸지 않는다. 확장은 버전·capability·마이그레이션을 명시한다.
  • 영역 대응만으로 전체 프로그램의 동작 보존을 주장하지 않는다.
  • 원본은 이미 로드한 버퍼를 재사용하고, 비교 가능한 산출물은 명시적인 입력으로 저장·재현한다.

실행 순서와 완료 조건

  • A. 최소 공통 기반: 기존 since/baseline, semantic_change, region snapshot, cache, watch의 역할·중복을 표로 고정한다. 완전한 비교 입력/프로필·근거 투영과 CLI EDA 계약을 설계하고 대표 변형 fixture를 만든다. 첫 사용자 흐름에 필요한 범위만 공통화한다. (1, 6)
  • B1. 첫 사용자 가치: 두 완전 분석 결과의 변화 요약 → 원인별 그룹 → 항목 → 전후 증거 흐름을 human/JSON으로 제공한다. 검토 근거 유지/변경 및 신규 복사본 등 소비자 정책에 필요한 사실도 함께 제공한다. 산출물만을 이용한 비교와 가능한 탐색을 검증하고, 기존 since= 및 외부 단순 JSON 비교 대비 재검토 대상 재발견 비용을 측정한다. (1, 4)
  • B2. 기존 검출 워크플로 적용: 기존 semantic_change가 놓친 이동·대응 사례에 영역 대응을 적용해 divergent-edit의 증거 품질과 비용을 비교한다. gate 정책은 유지한다. B1의 가치는 B2 완료와 독립적으로 출시·평가한다. (2)
  • C1. 검토 기록·적용성 연결: --write-review와 --reviews, review=applicable|recheck|unreviewed를 출시했다. 기록은 원래 capture·family observation·review key·scope에 연결된다. 고유한 이동에서는 근거를 유지할 수 있고, 새 복사본·근거/범위 변경·불완전하거나 모호한 대응은 재검토 대상으로 남긴다. 기록은 소비자가 소유하며 gate나 승인 정책을 바꾸지 않는다. (4, C의 완료 범위)
  • C2. 원래 리팩터링 대상의 처리 점검: 원래 대상별 잔존·변경·판단 불가를 검토 기록에 연결해 탐색 → 수정 → 점검 흐름을 완성한다. 기존 member_changes와 전후 원문 증거를 재사용하되, admitted family가 사라진 사실을 원래 영역의 삭제나 추출 성공으로 해석하지 않는다. family 밖에 남은 singleton 등 추적 범위와 coverage를 명시하고, 복잡한 추출·인라인은 확정 계보로 승격하지 않는다. (3, 4 통합의 남은 범위)
  • D. 조건부 실행 비용 개선: 기존 캐시 병목과 해결 가능한 miss를 확인하면 영역 단위 재사용을 적용한다. clean/cold/warm/edited 출력 동등성과 시간·메모리·저장 공간, 일반 query 비용을 검증한다. 효과가 없으면 현 구조를 유지한다. B/C와 독립적으로 착수 여부를 결정한다. (5)
  • E. 조건부 연구 확장: 실제 미해결 사례를 수집해 분할·병합·추출 대응을 평가한다. 이력에서는 실제 누락 수정의 증거와 반복 그룹 개선을 먼저 제공한다. 새 순위는 기존 대안 대비 추가 가치가 확인될 때만 도입한다. 두 연구는 각각 중단/축소 가능하며 서로의 완료를 요구하지 않는다. (7, 8, 3 확장)

각 단계는 독립적으로 검토 가능한 후속 이슈/PR로 나눈다. 각 하위 이슈는 기존 기능으로 풀리지 않는 구체적 사례, 사용자 행동의 전후 차이, 최소 구현 범위, 비교 기준, 성공·중단 기준, CLI 탐색 인수 시나리오를 착수 전에 명시한다. 이 이슈는 목표와 의존성을 관리하며 연구 단계 전체의 구현을 첫 출시 조건으로 삼지 않는다.

대표 인수 사례

변화 기대 결과
함수 위에 주석 추가 위치 변경을 설명하고, 선택된 내용·증거가 같으면 검토 근거 유지
같은 함수를 다른 파일에 복사 기존 영역 유지와 새 발생 위치를 구분하며 승인 자동 상속 없음
원문은 같고 외부 pack의 증명 조건 변경 증명 근거 변경을 설명하고 필요한 분석 재검증
일부 복사본을 공통 함수로 추출 확인 가능한 대응 근거/추출 후보 및 남은 복사본 제시
동일 내용 후보가 여러 개 모호함과 후보를 보존하며 계보 강제 선택 없음
구성원 수·분석 프로필·검토 범위 변경 각각의 변경을 노출하고 근거 유지 여부를 별도 판단
후보 예산 초과 또는 원본 누락 불완전 상태 명시, 확정 대응·근거 유지로 승격하지 않음
dashboard/list의 표시 순위에서만 항목 소멸 삭제·해결로 판정하지 않고 비교 모집단과 coverage를 설명
구버전 입력에는 해시만 있고 원인 증거가 없음 관측 가능한 차이만 보고하고 상세 원인은 unknown/unavailable
전체 모집단은 같고 top/정렬/필터만 변경 표현 변화와 실제 내용·증거 변화를 구분

CLI 탐색 인수 시나리오

  • 에이전트가 도움말·capabilities와 출력에 제시된 명령만 따라 landing → 원인 그룹 → 개별 대상 → 전후 증거에 도달한다. JSON 스키마를 추측하거나 jq로 소비자 비교 알고리즘을 만들 필요가 없다.
  • 같은 시나리오를 human/JSON으로 실행하여 선택·건수·근거 상태·다음 대상이 일치한다. 필터 미지정/빈 결과/모호한 결과/비교 불가에서도 이유와 유효한 다음 단계가 있다.
  • 제시된 모든 다음 명령을 실제로 실행한다. 공백 경로, 다중 root, 비기본 mode/config/pack, 과거 산출물, 삭제된 현재 파일에서도 입력/프로필을 잃거나 다른 대상을 열지 않는다. 필요한 원본이 없으면 이를 정확히 설명한다.
  • 기존 since= 상태·baseline/ignore·base= gate·watch 복구 계약을 회귀 검증한다. top=N 변경으로 판정이 바뀌지 않고, 타이핑 오류/미지원 조합은 실패한다.

검증 지표

  • 잘못된 대응 및 잘못된 unchanged_evidence 판정, 모호함/미해결 비율, 변화 유형별 대응 재현율.
  • 위치만 바뀐 경우의 불필요한 재검토율과 새 복사본에 대한 잘못된 검토 적용 사례.
  • divergent-edit의 검토된 precision/recall 및 기존 gate 대비 영향.
  • 리팩터링 후 남은 대상 검출과 후보 근거의 정확성. 테스트 통과를 전체 동작 보존의 증명으로 취급하지 않음.
  • clean/cold/warm/edited 결과 동등성, 스레드 수·입력 순서별 결정성.
  • 전체 및 단계별 p50/p95 시간, 메모리, 캐시 크기, 출력 크기, 후보 수·예산 사용량. 변경 비교 미사용 일반 query 비용 포함.
  • 기존 탐색 대비 명령 수, 재조회/재검토 항목 수, 전달 바이트/토큰과 고정 과제 완료율. 근거를 숨겨 비용만 줄이는 개선을 통과시키지 않음.
  • 모든 생성 next 명령의 실행 성공·맥락 보존, human/JSON 선택 일치, 허용 필드·조합의 capabilities/help 발견 가능성.
  • 의미 동등성 경로는 기존 false-merge·oracle·proof 검증을 유지. 대응 연구의 성과로 이 기준을 완화하지 않음.

모든 결과를 미해결로 남겨 오류만 낮추는 구현은 성공으로 보지 않는다. 유형별 coverage·과제 완료율과 잘못된 확정 대응을 함께 평가한다. 통제된 fixture의 통과와 실제 변경 이력에서의 정확도 추정은 구분해 보고한다. 성능 및 품질 개선은 구현 후 동일 조건의 비교 측정으로 확인한다.

구현 및 출시 기록

A/B1/B2와 후속 C1 구현은 PR #988을 통해 main에 반영됐으며 v0.21.0에 포함됐다. 아래 초기 커밋과 통제된 측정은 구현 당시의 근거로 보존한다. 현재 완료 여부는 상단 상태표와 실행 순서의 C1/C2 구분을 따른다.

  • 2e9ad816: 완전한 admitted-family 분석 저장과 오프라인 변화 탐색.
  • 9506f459: 비교 검증 기록과 현재 제품 트리의 oracle receipt.
  • 48aa4fe0: base=의 제한된 원본 영역 후보 증거와 잘못된 range 대응의 불확실성 표시.
  • b9684eb2: B2 제품 트리로 oracle receipt 재검증.

바로 사용할 수 있는 흐름

nose query src --save-analysis before.json
# 같은 분석 설정으로 편집 후 저장
nose query src --save-analysis after.json
nose query --before before.json --after after.json
nose query --before before.json --after after.json group=reason
nose query --before before.json --after after.json evidence=recheck

출력의 next 명령으로 개별 변화와 전후 근거까지 탐색한다. 입력 프로필·coverage·후보 예산·모호함을 보존하며, 원본 파일이 없어도 저장된 관측을 열 수 있다. 저장 모집단은 admitted code families이고, singleton을 포함한 모든 AST 영역의 전수 목록은 아니다. 검토 근거 유지 사실과 소비자의 최종 승인은 계속 분리한다.

초기 A/B1/B2 검증 기록 (2026-09-05)

  • A/B1: 통제된 Rust 헤더 삽입 감사에서 4개 모드의 1,440개 관측 중 1,383개가 검토 근거를 유지하고 57개가 재검토 대상으로 남았다. 동일 입력의 기존 since=는 1,400개 행을 changed로 표시했다. 모드별 관측 수이며 고유 family 수나 승인 건수가 아니다.
  • B2: 함수가 다른 기존 파일로 이동하고 원래 자리를 다른 함수가 채우는 사례에서, 종전의 complete replacement를 advisory로 낮추고 실제 동일 원문 후보 위치를 표시한다. 동일 복사본 둘은 ambiguous, 실제 이름/위치 기반 수정은 complete를 유지한다. 파일/후보 cap은 partial 또는 budget-exceeded로 노출한다.
  • B2의 3개 통제 사례에서 semantic_change 외 모든 필드가 종전 바이너리와 같았다. gate 판정과 target ID도 동일하다. 2/4 worker 결과도 같았다. 여섯 교대 측정의 실행 중앙값 증가는 약 0.4–1.2 ms였으며 일반 성능 보장이나 실제 이력 precision/recall 추정이 아니다.
  • 전체 workspace 테스트 2,296개 통과, Clippy warnings-denied, rustdoc, 문서/파일 길이 검사 통과. 전체 ./scripts/check-ci-local.sh --fast --jobs 2 통과.
  • 해당 구현 시점 제품 트리의 blind oracle: 54 exact groups, false merge 0, canonicalization violation 0.

재현 하네스는 bench/regions/analysis_changes.py, bench/regions/divergence_matches.py이고, 계약과 측정 한계는 docs/region-identity.md, docs/query-json.md, docs/divergent-edits-policy.md에 기록했다.

C1 출시 근거와 C2의 남은 인수 범위

--write-review로 keep-separate|refactor|defer와 이유를 기록하고, --reviews로 변경 후 적용성을 탐색할 수 있다. 실제 원문 조회는 원본 버퍼·선택 영역 digest를 검증하며, 원문이 없거나 바뀌었으면 unavailable로 표시한다. 고유 이동 후 기존 검토 적용, 새 복사본 발생 시 재검토 등은 검토 통합 테스트와 릴리즈 사용자 여정에서 검증했다. 계약은 영역·검토 문서에 있다.

C2에서는 원래 대상 집합을 명시적으로 고정한 뒤, 편집 후 각 대상의 잔존·변경·판단 불가와 근거를 따라가는 흐름을 완성해야 한다. 예를 들어 세 복사본 중 두 개를 편집했을 때, family 밖에 홀로 남은 복사본을 단순한 검출 결과 소멸과 구분하는 인수 사례가 필요하다. 현재 저장 분석은 admitted families의 관측이며 모든 영역의 전수 목록이 아니다. 현재의 대응·member_changes·검토 기록·별도 singleton snapshot을 비교 기준으로 삼고, 구현 전에 범위와 성공·중단 기준을 고정한다. 자동 추출/인라인 계보나 리팩터링 성공 판정은 완료 기능으로 주장하지 않는다.

v0.21.0 릴리즈 검증 (2026-09-08)

최종 검증 기록과 릴리즈 근거에 소스·바이너리별 검증 범위가 고정돼 있다. 동일 제품의 전체 로컬 CI는 2,440개 최적화 테스트와 89.73% line coverage를 통과했고, 377개 작업의 출력 검증, 사용자 여정 8종, 전체 120개 저장소 및 심층 soundness, 캐시 변경·watch 복구와 네이티브 패키지 검증을 완료했다. 실제 배포 워크플로도 통과했다.

D/E는 기존 계획의 측정·착수 조건을 유지한다. 각각 증거에 따라 착수·보류·축소·종료할 수 있으며 C2나 서로의 완료를 자동으로 요구하지 않는다. nose는 판단 근거와 불확실성을 제공하고, 리팩터링 필요성·보존 이유·승인에 대한 깊은 판단은 사용자 또는 LLM이 소유한다.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions