{
  "pass": false,
  "risks": [
    {
      "severity": "critical",
      "description": "`--affected-only` 설계가 다시 부분 테스트 중심으로 회귀합니다. 문서상 시나리오 4는 `git diff` 후 `test_feature_gate.py`만 실행하는데, 이것은 원래 문제였던 멀티 스택 연쇄 실패(`pytest`는 통과하지만 `tsc`/`vitest`는 실패)를 그대로 놓칠 수 있습니다. 특히 타입체크나 프론트 테스트는 파일명 매칭으로 좁히기 어려워 목적과 충돌합니다."
    },
    {
      "severity": "high",
      "description": "러너 실행 명세가 현재 저장소 관례와 맞지 않습니다. 설계 문서는 `tsc --noEmit`, `vitest run`, `jest --ci`를 직접 호출하지만, 워크스페이스의 기존 태스크/문서들은 `python3 -m pytest`, `npx tsc --noEmit`, `npx vitest run` 형태를 전제로 합니다. 글로벌 바이너리가 없는 환경에서는 정상 프로젝트도 `command not found`로 오탐 실패할 가능성이 큽니다."
    },
    {
      "severity": "high",
      "description": "Python 스택 감지가 너무 거칠어 오탐 실패를 만들 수 있습니다. `pyproject.toml`/`setup.py`/`requirements.txt` 존재만으로 pytest를 강제하면, 테스트가 없거나 테스트 경로가 표준 위치가 아닌 프로젝트도 `no tests collected` 같은 non-zero 종료로 FAIL 처리될 수 있습니다. 시나리오 5의 '테스트 대상 없음이면 PASS'와도 경계가 불명확합니다."
    },
    {
      "severity": "medium",
      "description": "타임아웃 계약이 일관되지 않습니다. 계획서에는 러너당 120초와 전체 300초가 함께 적혀 있는데 최대 4개 러너를 순차 실행하면 총 480초까지 필요할 수 있어 서로 양립하지 않습니다. 또 TIMEOUT을 `exit 0 + overall=WARN`으로 처리하면 `finish-task.sh` 통합 시 경고와 성공을 exit code만으로 구분할 수 없어 게이트 모드(`warn/fail`) 연계가 불안정합니다."
    }
  ],
  "suggestions": [
    "`--affected-only`는 최적화로만 두고, 최소한 `tsc --noEmit` 같은 전역 정합성 검사는 항상 실행하세요. 관련 테스트를 찾지 못하거나 스택 매핑이 애매하면 전체 스위트로 자동 폴백하는 규칙도 필요합니다.",
    "모든 러너는 프로젝트 루트에서 로컬 툴체인 기준으로 실행하세요. 예: `python3 -m pytest`, `npx --no-install tsc --noEmit`, `npx --no-install vitest run`, `npx --no-install jest --ci`. 의존성이 없으면 FAIL 대신 명시적 SKIP/WARN 사유를 남기는 편이 안전합니다.",
    "결과 계약을 명확히 분리하세요. `PASS|FAIL|WARN`을 기계가 읽을 수 있게 한 줄 요약 외에 JSON으로도 출력하고, `no tests collected`, `runner not installed`, `timeout` 각각의 처리 규칙을 문서에 고정하세요. 동시에 전체 시간 예산과 러너별 시간 예산 중 하나를 조정해 모순을 없애는 것이 좋습니다."
  ],
  "source": "codex_companion",
  "fallback_reason": null,
  "error": null,
  "task_id": "task-2148",
  "timestamp": "2026-04-23T23:53:58.951105+00:00"
}