이미지를 요청했는데 답변에 글자가 없을 수 있다. 이를 무조건 미완료로 보면 결과가 있어도 계속 기다리고, 페이지에 사진이 있다는 이유로 끝내면 예전 이미지를 가져온다. 북극성에서는 텍스트 답과 이미지 답의 완료 조건을 나누되 새 결과의 출처를 놓치지 않도록 했다.
본문이 비었는지와 이미지가 준비됐는지를 따로 본다
waitAnswer의 일반 답변은 비지 않은 value가 필요하다. requireImage이면 value가 비어 있어도 같은 새 응답 group에 image-open이 있으면 다음 안정 비교로 갈 수 있다. 이미지 요청에 불필요한 안내 문장을 요구하지 않은 것이다. 글자가 없는 결과도 매체 자체로 설명할 수 있어야 했다.
하지만 어느 이미지나 쓰지 않는다. images는 비활성 제어를 제외하고 새 답변과 같은 group인지 대조한다. 이전 응답의 준비된 이미지가 새 답 옆에 있다는 것만으로 충분하지 않다. 결과의 형식에 맞춰 확인하되 이번 요청의 결과라는 연결은 계속 유지한다.
이미지 제어가 보인다는 것보다 로드 상태를 본다
어댑터는 응답 안의 실제 img에서 complete와 자연 크기를 읽어 준비 상태를 만든다. 알려진 생성 이미지 카드 버튼도 내부에 로드된 픽셀이 있는지 확인한다. 현재 구현에는 일정 크기 이상이라는 조건이 있어 작은 아이콘을 생성 결과로 읽을 여지를 줄인다. 이 숫자는 현재 어댑터의 판별 기준이지 모든 이미지의 품질 기준이 아니다.
로드됐다는 사실도 원본 해상도나 파일 저장 성공을 뜻하지 않는다. 썸네일이 보이는 것과 실제 PNG 바이트를 내려받아 검증하는 일은 다르다. 이 글은 생성 결과의 관찰을 다루며 다운로드는 별도 결과로 남긴다. 화면에서 확인한 범위를 파일 전체 검수로 바꾸지 않는다.
별도 답변 제목이 없는 카드에는 좁은 예외를 둔다
일부 실제 이미지 전용 turn에는 별도 assistant 제목이 없다. 새 answer를 못 찾았고 이미지 요청이며 busy가 아닐 때만 page 그룹의 알려진 생성 이미지 버튼을 본다. 이름·활성 상태가 맞고 이전 ordinal보다 크며 후보가 정확히 하나여야 한다. 준비된 이미지 총개수도 기준보다 늘어야 한다.
예외가 있다는 이유로 페이지 전체의 아무 새 그림을 받아들이지는 않는다. 카드가 둘이라 모호하거나 예전 ordinal, 다른 응답 group, 로딩 상태이면 기다린다. 알려진 UI 구조에서 새 생성 카드의 근거를 좁힌 경로다. 제공자 서버의 요청 ID로 암호학적 연결을 만든 기능으로 설명하지 않는다.
제목 없는 매체와 원래 매체를 시험에서 분리한다
기존 headless-image fixture는 오래된 이미지 하나와 전송 뒤 새로 보이는 준비된 카드를 만든다. 별도 assistant 제목 없이 완료되는 경우와 fresh·ready·scope 조건이 빠져 완료되지 않는 경우를 나눠 시험한다. 다른 이미지 fixture는 새 응답의 본문이 빈 상황도 확인한다.
이번에는 이 코드와 시험을 읽었고 새 이미지 생성을 요청하지 않았다. 같은 이미지를 두 번 보내 본 시험도 아니다. 원본 제품의 과거 fixture와 독립 합성 모듈을 실제로 실행한 근거는 나눴다. 그림이 존재한다는 판단을 어떻게 반박할지까지 있어야 조건이 좁아지는지 확인할 수 있다.
공유 예제는 같은 자료를 선언 관찰로만 다룬다
새 모듈은 image 목표에서 같은 answer의 ready 매체를 받거나 명시한 page 예외를 사용한다. 이름 있는 카드가 하나인지, 개수와 ordinal이 늘었는지, 다른 응답의 이미지를 받지 않는지 실제 시험했다. 이미지가 준비됐다는 입력 자체는 호출자 선언이므로 실제 페이지 로드를 확인한 것은 아니다.
모듈의 observed_complete에도 business_success_verified=False가 남는다. 요청 전송·브라우저 관찰·파일 다운로드를 구현하지 않았기 때문이다. 코드와 기록을 읽으며 판단을 실험할 수는 있지만 이 예제를 실행했다고 실제 생성 서비스의 성공을 보고할 수는 없다. 재사용할 때 남은 연결 책임을 명시했다.
결과의 형태에 맞게 완료를 정의한다
텍스트와 이미지에 같은 완료 조건을 강제하면 한쪽에서는 불필요한 글자를 기다리고 다른 쪽에서는 그림 없이 문장만 받고 끝낼 수 있다. 요청이 어떤 결과물을 원하는지 먼저 정하고 그 형태의 준비 증거를 비교해야 한다. 새 답변이 반드시 긴 문장이어야 하는 것은 아니다.
나는 생성형 서비스를 다루는 프로그램도 결과를 정확히 읽을 수 있을 때 쓰기 쉬워진다고 보았다. 어떤 카드가 새것이고 어느 매체가 준비됐으며 파일 확인은 남았는지를 구분하면 다음 단계가 분명해진다. 이미지를 이미지로 확인하되 예전 그림을 새 결과로 착각하지 않는 경계다.