자기야 발견: maxReplans=2, maxReviewRounds=3 budget 으로 forced REQUEST_CHANGES
검증을 돌렸는데, FSM 자체는 정상 작동했지만 (replanCount=1 정확히 카운트, plan→
review×3→implement loop 정확히 발동) 총 12 review attempts × LLM 호출 30-60s =
실 운영에서 escalation 까지 15-30분 걸림. 사용자가 "무한 루프" 라고 느낄 정도.
수정:
- src/orchestrator/context.ts:
maxReviewRounds: 3 → 2
maxReplans: 2 → 1
→ 총 budget = (1+1)*(1+2) = 6 review attempts (이전 12 의 절반)
→ 실 운영 wall-clock 약 3-6 분 안에 escalation 도달
- src/orchestrator/machine.ts: 동일하게 default context 갱신
- tests/machine.test.ts: 새 budget 에 맞춰 round 수 조정
- "after max review rounds" 테스트: 4 round → 3 round
- "escalates after both budgets exhausted" 테스트: 12 round → 6 round
- sister-agent/src/spawn.ts:
RAILS_FORCE_REVIEW_VERDICT 환경변수 가드 추가 (test-only).
APPROVE / REQUEST_CHANGES / ABORT 중 하나 설정하면 LLM 우회하고 즉시 verdict
반환. darang sister 에 박아서 retry FSM E2E 검증 가능.
운영 시점엔 env 미설정 → no-op, LLM 응답 정상 사용.
테스트: 113 통과 (변경 없음).
검증 흔적: pipeline 01KNWB8WYRR11PGY8DYMNQ1BZD 가 forced REQUEST_CHANGES 로
이전 budget (12 round) 의 60% 까지 진행 후 수동 abort. transitions 18 개에
replanCount=1, reviewRound=3 정확히 보존됨 — persistence/FSM 모두 정상.
이랑이
185320f1b9