원고 검사가 성공했다고 해서 지금 보고 있는 원고가 맞다고 단정할 수는 없었다. 최근 개발 기록에는 다른 글의 탭에서 검사했는데도 성공한 사례가 있었다. 조건 비교가 틀린 것이 아니라 비교할 대상을 과거 탭으로 바꿔 버린 문제였다. 나는 남아 있는 실패 기록과 수정된 소스를 함께 읽으며 검사 결과에 대상의 문맥까지 붙어 있어야 한다는 기준을 다시 정리했다.
맞는 원고를 두 번 검사한 것만으로는 부족했다
기존 보고서에는 기준 원고 A에서 검사가 두 번 통과한 뒤 다른 원고 B에서 실행했는데도 성공한 순서가 남아 있다. 실행 결과의 주 대상은 A였고 요청 문맥은 B였다. A의 내용이 기준과 맞다는 사실만 반복해서 확인한 셈이다. 올바른 조건을 다른 자료에 적용하면 성공 기록이 오히려 문제를 가릴 수 있다.
그래서 성공과 실패를 나눌 때 내용 비교 전에 어느 탭을 선택했는지도 살폈다. 이 글에서 당시 실제 실행을 다시 재현한 것은 아니다. 원래 거짓 통과와 그 뒤의 수정 보고, 현재 남은 함수와 시험을 대조한 제작 기록이다. 고객 원고나 계정 내용을 가져와 공개하지 않고 대상 선택의 구조를 설명한다.
저장된 프로그램의 기억에는 원래 역할이 있었다
일반 반복 프로그램의 탭 재사용 함수는 같은 프로그램에 묶인 탭을 먼저 찾는다. 이전 작성 흐름의 자리를 다시 사용하는 데는 그 기억이 도움이 된다. 문제는 현재 탭의 상태만 읽어 판단해야 할 사전검사에도 같은 우선순위를 적용했을 때였다. 현재 요청을 읽는 검사기가 과거에 성공했던 자리로 돌아가면 질문 자체가 바뀐다.
기존 글에서는 작성 목적지와 참고 탭, 자연어 요청과 오래된 추천을 나눴다. 이번 경우는 같은 서비스의 비슷한 편집기 사이에서도 읽기 전용 검사 결과가 잘못된 원고에 붙을 수 있다는 질문이다. 작성 목적지를 고르는 일반 정책을 전부 바꾸기보다 어떤 종류의 프로그램이 현재 요청에 묶여야 하는지 좁혀 정했다.
검사 전용이라는 이름보다 실제 단계로 판별했다
isReadOnlyCheck는 단계가 비어 있지 않고 모든 단계가 verify이며 보조 탭 정의가 없는 Recipe를 판별한다. 이름에 검사라고 적었다는 이유로 특별 취급하지 않는다. 빈 프로그램이나 입력 단계가 섞인 정의, 여러 탭을 쓰는 정의는 이 좁은 경로에 들어가지 않는다. 프로그램 실행기가 그 조건을 읽고 내부 readOnlyCheck 값을 만든다.
호출자가 새 공개 입력에 참을 적어 이 제한을 얻는 방식으로 설명하지 않았다. 조건에 맞는 정의가 실제 호스트의 읽기 경로로 연결되는지 확인해야 한다. 읽기 전용이라는 표현도 모든 호스트 상태가 그대로라는 뜻은 아니다. 코드에는 탭 소유 처리와 선택, 로딩 대기가 있고, 여기서 보존한 것은 재탐색·새 탭·기존 프로그램 바인딩 덮어쓰기를 피하는 범위다.
정확한 요청 탭이 없으면 다른 탭으로 대체하지 않는다
새 선택 함수는 요청 때 잡은 defaultTabId를 우선하고 그것이 없을 때 currentTabId를 쓴다. 명시된 ID가 있는데 찾지 못하면 다른 후보로 조용히 바꾸지 않는다. 그 탭의 프로필과 프로젝트가 맞아야 하고 정확한 URL도 같아야 한다. 보조 별칭을 받아 여러 탭의 검사로 넓히지도 않는다. 같은 주소의 탭 두 개는 여전히 다른 검사 대상일 수 있다.
선택 뒤에는 기존 페이지를 빌려 읽고 automationKey를 덮어쓰지 않는다. 다른 발행 프로그램의 기억을 사전검사가 가져가지 않게 한 선택이다. 이 함수가 실제 로그인이나 원고의 의미를 인증하는 것은 아니다. ID·범위·URL의 대상 조건을 먼저 맞춘 뒤 별도 제목과 본문 조건으로 이번 원고를 확인해야 한다.
다른 원고에서 실패하는 것이 필요한 결과였다
수정 뒤의 기존 설치판 보고에는 기준 원고 통과, 다른 원고의 내용 불일치, 기준 원고로 돌아와 같은 검사 재사용 통과가 기록되어 있다. 가운데 실패는 기능이 망가진 결과가 아니라 이번 요청의 원고가 기준과 다르다는 정상적인 거절이다. 같은 프로그램을 다시 쓰되 과거 탭의 성공을 가져오지 않는지를 보는 흐름이었다.
원래 단위시험 파일도 요청 탭 우선과 기존 바인딩 보존, 없는 ID·다른 계정·프로젝트·URL·별칭 거절을 다룬다. 나는 그 시험과 보고서를 읽었고 원래 프로그램의 시험·설치·실사이트를 이번에 다시 실행하지 않았다. 과거 거짓 통과 기록을 지우거나 실패를 성공으로 바꾸지 않았다는 당시 근거도 현재 새 실행의 성과처럼 세지 않는다.
사전검사 통과가 다음 입력의 자동 보장은 아니다
이 수정은 제한된 검사 프로그램이 어디를 읽는지에 대한 것이다. 보고서에는 검사한 탭을 모든 후속 작성 흐름에 자동으로 고정하는 공통 연결은 아직 없다고 명시되어 있다. 검사 뒤 탭을 바꾸거나 원고가 달라지면 이전 결과를 다음 입력의 허가처럼 쓰면 안 된다. 검사의 대상과 시점이 후속 작업까지 어떻게 이어지는지는 별도 계약이다.
공유 자료로는 기존 request-bound-work-context 모듈을 재사용했다. 현재 공개 ZIP을 다시 받아 해시와 바이트를 대조하고 추출한 코드의 18개 합성 시험을 실행했다. 이 모듈은 명시한 탭과 프로필·프로젝트, 목적지와 참고를 나누는 순수 규칙이다. 정확한 실제 URL이나 원고, 로그인, 읽기 전용 분류와 후속 입력 연결을 검증하지 않는다. 다른 구현의 더 넓은 보장을 붙이지 않고 독자가 대상 선택의 출발점을 직접 살펴볼 수 있게 연결했다.