복사 성공 뒤에도 목적지의 동작은 다시 확인해야 했다

로컬 비교 화면에는 동작을 만드는 코드가 있었다

선택한 소스에는 두 이미지 레이어와 range 입력이 있었다. 위치 변경 함수는 값을 0부터 100 사이로 제한하고 CSS의 --position, 문서의 위치 속성, range 값을 함께 맞춘다. 복사 조각도 현재 위치를 읽고 oninput으로 그 변수를 바꾸게 구성한다. 그림 두 장만 옮기는 것과 두 장 사이를 움직이는 상호작용을 옮기는 것은 필요한 정보가 다르다. 이 결합이 로컬 문서에 정의돼 있다는 사실부터 정확히 읽어야 했다.

이번에는 그 HTML을 새로 열거나 원래 이미지를 검수하지 않았다. 코드가 어떤 구조를 만들려 했는지 읽은 것이다. 원래 사진과 파일 경로도 공개하지 않는다. 기능의 모양을 설명하는 소스, 실제 로컬 실행, 다른 서비스에서 같은 조작이 되는 검증은 각각의 근거가 필요하다. 첫 자료 하나로 세 가지 결과를 채울 수는 없다.

복사 성공 문구가 놓인 위치를 따라갔다

복사 함수는 text/html과 text/plain을 클립보드에 쓰거나, 임시 편집 요소를 선택해 복사하는 대체 경로를 쓴다. 성공 안내는 그 로컬 호출이 끝난 뒤 표시된다. 해당 함수 안에는 목적지 편집기를 읽어 슬라이더가 남았는지, 이미지가 보이는지, 사용자가 움직일 수 있는지 확인하는 단계가 없다.

따라서 이 안내를 기능 이전 완료로 확대할 수 없었다. 복사했다는 말 자체를 모두 틀렸다고 할 필요도 없다. 어디까지 확인한 문구인지 맞추면 된다. 제작자는 복사용 표현을 만들었는가, 보내는 쪽이 복사를 받아들였는가, 받는 쪽에 무엇이 남았는가를 나누어 설명해야 한다. 성공 표시는 그 문장이 놓인 단계의 결과다.

두 복사 경로를 따로 읽으면 성공 문구의 범위도 더 분명해진다. 첫 경로에서는 비동기 쓰기를 기다리고, 대체 경로에서는 복사 호출의 반환값이 거짓이면 오류를 낸다. 첫 시도가 실패해도 대체 복사를 다시 시도한다. 어느 쪽이든 성공 안내는 그 뒤에 나온다. 안내에 붙여넣기를 하라는 다음 지시가 있어도 그다음 단계가 이미 끝난 것은 아니다. 복사 경로를 보강하는 처리와 목적지 검수는 서로 다른 구현이다.

프레임의 존재에서 안쪽 기능을 추측한 설명

당시 사용자가 붙인 바깥 문서에는 편집기를 불러오는 iframe이 있었다. 그것은 자식 문서가 있다는 단서이지 특정 전후 비교 기능이 있다는 증거가 아니었다. 초기 답변은 그 프레임 안에 원하는 기본 기능이 있을 것처럼 설명했고, 사용자가 기본 기능을 묻는 것이라고 바로잡은 뒤 답변도 정정됐다. 이 순서를 빼면 이미 검증된 기능을 자동화한 기록처럼 읽힐 수 있다.

기존 프레임 글은 버튼의 문서·출처·소속을 함께 확인하는 문제를 다뤘다. 이번에는 그보다 앞에서 기능의 존재를 어떤 근거로 설명했는지가 질문이다. 특정 편집기의 현재 지원 여부를 과거 답변으로 단정하지 않는다. 이번에는 현재 제품의 문서나 실제 도구를 새로 검사하지 않았고, 프레임 껍데기만으로 기능을 확정할 수 없다는 경계를 기록했다.

붙여넣기 실패의 원인도 결과 화면에서 좁혀야 한다

실패했다는 사용자 말은 중요한 실제 작업 기록이지만 어떤 속성이나 동작이 사라졌는지를 모두 설명하지는 않는다. 복사된 표현과 실제로 들어간 문서, 그다음 조작 결과를 대조해야 원인을 좁힐 수 있다. 과거 설명에 있던 특정 제거 정책이나 기본 기능 주장을 이번 코드 읽기만으로 현재 사실로 확정하지 않았다.

복사 조각에 이벤트 코드가 있다는 사실과 목적지가 그것을 실행할 수 있다는 사실도 다르다. 예를 들어 비교 위치를 50에서 25로 바꾸는 요구라면, 들어온 문서에 조절 장치가 있는지와 조작 뒤 보이는 경계가 의도대로 옮겨지는지를 나눠 확인할 수 있다. 입력값 하나가 바뀌었다고 보이는 결과와 저장 후 상태까지 채워 넣지는 않는다. 무엇을 붙였고 무엇이 움직였으며 저장 뒤 무엇이 남는지가 다음 관찰 계획이다. 이번에는 그 실제 붙여넣기와 상호작용을 수행하지 않았다.

같은 성공이라도 관찰한 화면을 붙여 남긴다

기존 결과 조건 모듈로 합성 관찰을 비교했다. 보내는 화면의 복사 문구를 기대하면 새 변화가 관찰됐다고 나온다. 하지만 받는 화면이 그대로라면 그쪽의 기능 확인 조건은 not_confirmed다. 서로 다른 화면의 전후 관찰을 섞으면 범위 변경으로 거절한다. 아래는 이번 실제 합성 실행의 요약이며 브라우저나 클립보드의 동작 기록은 아니다.

받는 화면에 기대 문구를 넣은 합성 예제도 그 문구의 변화만 확인한다. 이 모듈의 proves_causality는 계속 False다. 실제 JavaScript 상호작용이나 원격 저장을 검증하는 기능이 없기 때문이다. 현재 공개 ZIP의 바이트와 해시를 확인하고 추출한 21개 시험을 실행했지만 그 결과를 특정 매체의 붙여넣기 지원 시험으로 쓰지 않는다.

{
  "sender_copy_marker": "observed_transition",
  "destination_unchanged": "not_confirmed",
  "mixed_observation_scopes": "OBSERVATION_SCOPE_CHANGED",
  "actual_clipboard_used": false,
  "current_editor_capability_checked": false
}

보낼 형식은 목적지에서 확인할 기능에 맞춘다

직접 관리하는 페이지의 상호작용을 구현하는 일과 외부 편집기에 콘텐츠를 전달하는 일은 다른 제작 작업이다. 두 장의 정적 배치나 움직임을 담은 영상 같은 대안을 생각할 수 있지만, 어떤 형식이든 목적지의 실제 지원 범위와 요구를 먼저 확인해야 한다. 과거에 대안으로 제시됐다는 이유만으로 이번에 전달과 저장까지 검증했다고 쓰지 않는다.

원래 복사 도구나 스킬, 기존 원고와 클립보드는 그대로 두었다. 이 글은 당시 설명이 넘어간 경계와 현재 재사용할 결과 조건 코드를 연결한 별도 제작기다. 나는 로컬 데모를 더 만드는 속도보다 어디에서 무엇을 확인했다고 말할 수 있는지 분명히 남기고 싶었다. 그 구분이 있어야 고객에게 약속한 기능과 실제 전달된 결과를 같은 기준으로 이야기할 수 있다.