소스를 한 줄도 고치지 않았는데 자동 수리 한도에 도달했다면 제한이 필요한 이유와 실제 차감 시점이 어긋난 것이다. 북극성에는 복원 설치 자료를 준비하지 못한 실패가 편집 시도로 남던 기록이 있었다. 제한을 없애는 대신 무엇이 시작됐을 때 한 번으로 셀지 고쳤다.
가용 여부 확인과 한 번 예약은 다른 행동이다
종전 흐름은 소스와 설치판의 준비 전부터 시도를 예약했다. 복원 설치 파일이 없으면 실제 편집까지 가지 못해도 기록을 소비했다. 수정된 흐름은 먼저 check로 가용 여부만 보고 소스 사본·복원 설치 자료·조사 문맥 준비 뒤 첫 edit 직전에 reserve한다.
check를 두 번 했다는 사실도 두 번의 편집 시도가 아니다. 단위시험은 반복 check 뒤 시도 파일이 없고 reserve 뒤 한 행이 남는지 본다. 나는 준비를 통과했는지와 실제 편집 경로에 진입했는지를 다른 사건으로 이름 붙였다. 단계 이름만 늘리는 것이 아니라 어떤 사건이 한도를 쓰는지에 연결해야 했다.
같은 오류의 반복과 다른 설치 범위를 구별한다
AutomaticRepairBudget은 설치 버전과 프로필, 오류의 code·tool·origins 지문을 사용한다. 최근 시간 범위의 차감된 기록이 정해진 수 이상이거나 같은 입력 상태의 같은 오류면 멈춘다. 옛 버전의 준비 실패가 새 버전까지 막던 문제를 범위 없는 전역 카운터로 해결하지 않았다.
뒤에 보강된 inputRevision은 공개 소스와 검사 관련 파일의 해시로 만든다. 문서나 개인 런타임 자료를 바꿔 새 시도로 인정하지 않는다. 실제 코드·검사가 달라져도 시간당 전체 한도는 유지한다. revision이 없는 옛 기록을 새 허용으로 해석하지 않는 시험도 있다. 조건을 바꿀 근거와 반복 제한을 함께 보존한 것이다.
예전 기록은 지우지 않고 입증된 준비 실패만 분류한다
legacy 보완은 원래 request·state·수정 전 package 정보와 지문·시작 시각을 대조한다. 실제 편집이 없고 token 기록 0, 변경 파일 없음, 백업 시작과 복원 준비 실패의 두 이벤트 같은 좁은 조건에 맞는 경우만 charged=False로 바꾼다. 낮은 토큰 숫자 하나만 보고 모두 환급하지 않는다.
원래 시간과 지문·행을 남기고 최초 원문도 별도 백업한다. 어떤 작업인지 모르는 기록과 코드 편집 근거가 있는 기록은 보수적으로 유지한다. 손상된 JSON을 빈 배열로 바꾸는 초기화도 거절한다. 실패를 정정하는 기능이 과거 흔적을 지우는 편의 버튼이 되지 않도록 한 계약이다.
한도 함수만으로 동시 실행 전체를 보장하지 않는다
reserve는 현재 기록을 읽고 가용 여부를 다시 검사한 뒤 새 행을 써서 확정한다. 같은 오류의 중복과 공개 입력 변화, 시간 만료, 손상 기록을 원본 시험에서 확인한다. 다만 이 클래스가 여러 프로세스의 모든 경합을 단독으로 잠그는 원장은 아니다. 호출하는 서비스의 직렬화와 파일 보관 경계도 필요하다.
과거 문서는 준비 시작부터 소스 수정 요청을 직렬화했다고 설명한다. 그 사실을 파일 함수 하나의 전역 원자성으로 확대하지 않는다. 또한 한도 통과는 안전한 외부 재전송의 허가가 아니다. 결과 불확실한 클릭이나 게시의 보호 조건은 별도로 유지한다. 수리 횟수와 업무 요청의 실행 권한은 다른 기준이다.
지금은 과거 수리 설계의 기록으로 읽는다
내부 CLI 자동수리는 제거된 상태다. 이번에 실제 자동 편집을 시작하거나 사용자의 과거 한도 파일을 수정하지 않았다. 코드와 시험·과거 정정 문서를 읽어 어떤 경계에서 잘못 셌고 어떻게 보존하며 분류했는지 설명한다. 새로운 수리 기능이 현재 켜졌다는 소개가 아니다.
공유 구조 보고서 모듈은 사건의 단계만 묶고 횟수 한도나 편집을 실행하지 않는다. 다른 서비스에서는 로그인 준비·자료 준비·실제 요청 전송을 같은 실패 한 번으로 세는지부터 살펴볼 수 있다. 나는 반복을 막는 보호와 시작하지도 않은 일을 시작했다고 세지 않는 정확성을 함께 유지하는 선택을 남겼다.