model call Unknown class 노출과 provider 동작 고정 테스트, CI no-fail-fast

[Createyouracccount]

배경

PR #57·#58을 검증하면서 planner timeout을 진단할 때마다 Run의 SQLite를 직접 열어야 했습니다.
XGENY_RECOVERY_REQUIRED reason=model_call_unknown은 journal이 이미 구분해 기록하는 timeout /
transport_unavailable / interrupted를 한 단어로 뭉갰습니다(PR #53·#55가 rejection 경로에서 고친
것과 같은 손실). 또 #56 검증에서 한 test binary가 실패하자 CI 방식의 cargo test가 45개 중 14개만
보고해, 나머지 binary의 상태를 알 수 없었습니다.

변경 사항

• RecoveryReason::ModelCallUnknown이 journal과 동일한 ModelCallUnknownReason을 전달하고 model_call_unknown.<class>로 보고합니다. Durable Unknown 상태, process 경계 뒤 남은 reservation(interrupted), planner port failure(timeout, transport_unavailable) 세 경로가 같은 class로 수렴합니다. 문제 해결 표를 갱신했습니다.
• 실측으로 잡은 provider 동작을 hermetic 테스트로 고정합니다.
  • assistant message의 reasoning(Ollama) / reasoning_content(vLLM·llama.cpp) 필드는 planner·probe 양쪽에서 무시됩니다.
  • 요청을 받은 뒤 응답을 멈춘 provider(1초 예산): client는 자기 예산에서 포기하고 PlannerUnavailable(Timeout)으로 닫히며 journal에 ModelCallBecameUnknown(timeout)을 남기고 재시도하지 않습니다.
• CI와 release quality job의 cargo test --workspace --locked에 --no-fail-fast를 추가합니다. Release/npm workflow 계약 검사는 통과합니다.

실제로 동작하게 된 것

같은 machine, 재빌드한 바이너리입니다.

27B, XGENY_OPENAI_INFERENCE_TIMEOUT=5
  XGENY_RECOVERY_REQUIRED reason=model_call_unknown.timeout            (5s)
닫힌 포트
  XGENY_RECOVERY_REQUIRED reason=model_call_unknown.transport_unavailable
위 timeout Run을 resume
  XGENY_RECOVERY_REQUIRED reason=model_call_unknown.timeout            (durable class 보존)

이전에는 세 경우 모두 reason=model_call_unknown이었습니다.

데이터 경계

노출하는 class는 journal의 model_call_became_unknown이 이미 기록하는 값과 같으며 prompt·model
출력·provider 응답 본문을 포함하지 않습니다. Request profile digest·manifest·journal·receipt는 바뀌지
않습니다.

검증

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --locked -- -D warnings
• cargo test --workspace --locked --no-fail-fast (568 passed / 0 failed, 45 binaries)
• cargo build --workspace --release --locked
• xgeny protocol check
• sh scripts/check-rc3-public-docs.sh, check-release-workflow.sh, check-npm-distribution-workflow.sh, check-third-party-licenses.sh --check
• 실제 로컬 endpoint(Ollama 27B)에서 위 재현

실패 테스트를 먼저 추가해 red를 확인한 뒤 구현했습니다(journaled/un-journaled 경로의 class 수렴,
세 class의 코드 문자열). 8B 스모크는 같은 입력에서 COMPLETED/provider_limit/invocation_invalid가
번갈아 나와 회귀 기준선으로 쓰지 않았습니다. 이 브랜치는 planner 요청 조립을 건드리지 않습니다.

범위 밖

Planner 경로의 provider_limit(출력 잘림과 HTTP 413/429 동일 class) 분리는 durable journal enum
변경이라 별도입니다. 이 PR은 게시나 태그 생성을 수행하지 않습니다.