한 단계가 막혔다고 처음부터 실행하면 이미 올린 자료나 입력까지 다시 보낼 수 있다. 북극성의 부분 재개는 먼저 전달됐는지를 나눴다. 실행을 유지한 채 같은 단계로 돌아갈 수 있는 경우와 원래 결과만 읽어야 하는 경우, 재시작 뒤 입력 상태를 확인하는 경우는 서로 다른 경계였다.
실패 단계 앞의 작업을 다시 열지 않는다
engine은 단계 인덱스와 completedSteps를 실패 콜백에 넘기고 같은 실행 안에서 현재 단계만 처리한다. 전달 전 대상 찾기 실패라면 제한된 의미 대상 재연결을 적용할 수 있다. 앞의 열기·추출·입력 전체를 처음부터 반복하는 경로로 돌아가지 않는다.
관련 시험은 추출→확인 클릭→추출 세 단계를 두고 중간 이름을 고친다. 열기 한 번, 클릭 한 번, 두 추출이 각각의 원래 위치에서 실행되는지 본다. 클릭 수가 적다는 숫자만이 아니라 어떤 단계가 이미 끝났고 무엇이 새로 실행됐는지를 확인한다. 합성 대역 시험이며 실제 외부 제출의 새 성공을 뜻하지 않는다.
한 번 전달한 행동은 수리 후보로 다시 보내지 않는다
failure.dispatched가 참이면 repairProgramStep은 모델로 새 target을 고르기 전에 원래 pending 결과를 verifyOutcome으로 읽는다. 원래 결과를 붙잡고 있지 않거나 확인이 실패하면 OUTCOME_UNKNOWN이다. 전달 이후 새 패치를 제안해도 모르는 결과가 안전해지는 것은 아니다.
시험은 클릭이 이미 한 번 전달된 뒤 불확실 오류를 내게 하고 원래 조건 확인이 성공하면 sent가 한 번이고 모델 판단은 없었는지 본다. 반대 시험은 확인 실패·중지·완화된 expect가 재시도를 허용하지 않는지 본다. 확인할 대상을 바꾸는 것보다 원래 결과 조건을 유지하는 것이 이 분기의 핵심이다.
재시작한 입력은 같은 문서와 실제 값을 확인한다
verifyResumedInput은 남은 입력 영수증의 탭과 URL에서 새 관찰을 읽는다. 역할·이름·type이 맞는 대상이 정확히 하나여야 한다. 문서 제목이 기록돼 있으면 제목 필드도 유일해야 하고 실제 제목과 본문 값을 verifyField로 확인한다. 같은 본문이 다른 제목의 글에 있다고 같은 입력으로 인정하지 않는다.
이 읽기 호출의 dispatch 콜백은 재전송이 발생하면 오류를 내도록 돼 있다. 확인을 위해 같은 본문을 다시 넣는 길을 막는다. 관찰과 값 확인을 기다린 뒤에는 실행 세대도 다시 검사한다. 정상 재개와 새 타이핑은 다른 동작이다. 정확한 값 비교가 필요한 내부 확인 자료는 공개용 진단 구조와 다르므로 실제 원고를 그대로 공유 모듈에 넣지도 않았다.
확인 기록이 남은 다음에 보호를 푼다
제목과 값이 모두 맞으면 원래 stepId·taskId의 checkpoint를 read_after_repair로 저장한 뒤 scope와 task의 resumeInput을 지운다. 저장을 기다리기 전에 보호를 먼저 지우는 순서가 아니다. 기록 확정과 메모리 보호 해제를 나눠 읽을 수 있는 위치다.
시험에는 다른 제목, 중복 필드, 바뀐 URL과 일치하지 않는 본문이 있다. 이 경우 보호가 유지되고 발행 클릭이나 입력 재생이 OUTCOME_PENDING으로 차단되는지 본다. 화면에서 그럴듯한 본문이 보이는 것만으로 다음 단계로 넘어가지 않는다. 원래 입력을 식별할 기준과 현재 읽기의 일치가 함께 필요하다.
자료에서 읽은 재개와 이번 실행을 분리한다
이 글은 남아 있는 broker·engine 함수와 과거 부분 수리 계약의 해설이다. 현재 내부 모델 수리는 제거돼 있으며 모든 현재 플러그인에 이 helper가 자동 연결돼 있다고 검증한 것은 아니다. 원래 서비스에 재전송하거나 재시작 복구를 새로 실행하지 않았다.
함께 연결한 합성 결과 조건 모듈은 원래 조건과 관찰을 비교하는 작은 예제다. 실제 원고 복구기나 영속 업무 엔진은 아니다. 나는 이어하기를 처음부터 빨리 다시 하는 일로 만들지 않으려 했다. 무엇이 이미 끝났는지 보존하고 확인하지 못한 결과 앞에서는 멈출 수 있어야 다음 작업의 신뢰도 이어진다.