/goal

결과: 결제 API의 timeout 오류를 고친다.
제약: public API와 database schema는 바꾸지 않는다. 배포·push는 하지 않는다.
검증: 재현 테스트와 관련 test suite가 통과하고, git diff에서 변경 파일을 검토한다.

goal text에 남길 정보

결과는 “카드 다섯 장을 수정한다” 같은 활동보다 “다섯 장이 카드 규칙과 내용 검사에 맞고 build가 통과한다”처럼 최종 상태로 적습니다. 제약에는 금지할 변경, 반드시 사용할 도구, 호환해야 할 환경을 넣습니다. 검증에는 test, measurement, review처럼 목표가 끝났음을 스스로 판별할 evidence를 적습니다.

나쁜 목표: 성능을 개선한다.

검증 가능한 목표: 이미지 목록 첫 화면을 1초 안에 표시한다.
제약: API 응답 형식과 이미지 품질은 유지한다.
검증: production build와 측정 시나리오를 통과하고 변경 전후 수치를 남긴다.

작업 범위가 아직 정해지지 않았다면 /goal부터 시작하지 않습니다. /plan으로 Codex가 필요한 질문, 수정 대상, 성공 기준을 정리하게 한 뒤 그 결과를 goal로 옮깁니다. 이미 한 목표가 있다면 follow-up message로 제약과 검증 기준을 수정할 수 있으므로, 새 goal을 겹쳐 만들 필요가 없습니다.

진행 중인 goal 다루기

장기 작업은 같은 chat 또는 session에서 이어야 이전 결정과 현재 evidence를 함께 사용할 수 있습니다. status recap이 필요하면 같은 흐름에서 진행 상황을 요청합니다. desktop app에서는 goal progress row로 pause, resume, edit, clear를 조절하고, CLI와 IDE에서는 같은 interactive chat에 후속 메시지를 보냅니다.

parallel goal은 chat마다 context와 결과가 분리됩니다. 두 task가 같은 파일에 쓰면 마지막 변경이 앞선 판단을 덮거나 diff 검토가 불가능해질 수 있습니다. 병렬 코딩이 필요하면 task마다 별도 Git worktree를 주고, 한 task가 수정하는 파일과 검증 책임을 명시합니다.

Task A: Web/components/checkout/만 수정하고 component test를 실행한다.
Task B: Web/app/api/payment/만 수정하고 API test를 실행한다.
공통 파일과 lockfile은 한 task만 수정한다.

권한과 완료의 경계

Goal mode는 작업을 계속 붙잡아 주지만 sandbox, approval policy, writable root를 넓히지 않습니다. 경계 밖 명령, network access, 외부 파일 수정이 필요하면 평소와 같이 승인을 거쳐야 합니다. 완료가 선언되면 goal text의 검증 항목과 현재 Git 상태를 대조해 실제 evidence가 있는지 확인합니다.