모델용 proposal 스키마에서 상한을 빼고 system prompt가 compact 출력과 key 규칙을 말하도록 변경

[Createyouracccount]

배경

PR #56 뒤 llama.cpp 계열 provider는 model setup에서 chat_completions_incompatible로 정직하게
실패했습니다. 원인은 planner 스키마의 maxLength: 5000(objective, summary)이 GBNF 문법 컴파일을
깨뜨리고 서버가 HTTP 200으로 제약 없는 출력을 반환하는 것이었습니다. 이 상한은 Core가
MAX_ACCEPTED_OBJECTIVE_BYTES 등으로 독립 검증하므로 스키마에서는 안내일 뿐 안전 장치가 아닙니다.

같은 GGUF를 두 provider로 실행해 측정했습니다.

실험	결과
llama.cpp, maxLength 제거 또는 ≤2000	문법 정상 강제, 실패 로그 0건
Ollama 8B, 상한 유무 A/B ×3	동일 (영향 없음)
스키마 pattern (4가지 형태)	Ollama 0.33 전부 400 failed to parse grammar; llama.cpp는 anchored만 강제
8B no-think, 쓰기 카탈로그 prompt	1024 token 안에서 100% 잘림 (pretty-print)
+ "한 줄 minified JSON" 문장	100% 순응 (767/854 token)
+ step key 규칙 문장	577 token, key 유효 3/3
27B 같은 실험	205→206 token (이미 compact, 변화 없음)

변경 사항 (ADR-0037)

• 모델용 스키마에서 maxLength/maxItems를 제거합니다. 구조(required, additionalProperties: false, enum, const)만 강제하고 Core 검증은 그대로입니다. PROPOSAL_SCHEMA_REVISION → xgeny.plan-proposal/v2.
• pattern은 넣지 않습니다(Ollama 사용자 전부를 setup에서 막습니다). Step key 형식은 Core가 검증합니다.
• SYSTEM_PROMPT·CONSTRAINED_SYSTEM_PROMPT 끝에 두 문장을 더합니다: 한 줄 minified JSON, Core step key 규칙. Template revision → v4-compact / v4-compact-constrained.
• 단위 테스트: 스키마에 maxLength/maxItems/pattern이 없고 additionalProperties·const는 유지, 두 prompt에 두 문장이 있음, revision 문자열. Request profile golden은 의도적으로 재채취했습니다.
• 문제 해결 표의 chat_completions_incompatible 설명을 갱신했습니다.

실제로 동작하게 된 것

llama.cpp (brew) + Qwen3 8B      model setup PASS   (이전: chat_completions_incompatible), 문법 실패 0건
llama.cpp (Ollama 번들 바이너리; brew 빌드는 qwen35 arch 미지원) + Qwen3.8 27B
                                 model setup PASS   (프로필 --max-output-tokens 4096 --inference-timeout 600)
                                 read run  XGENY_COMPLETED (221s; 호출당 17/154/67s)
Ollama 27B write natural         XGENY_COMPLETED 162s (이전 #58 189s), workers 4→8
Ollama 8B  write natural ×2      XGENY_COMPLETED 69s / 66s, workers 4→8   (이전: 잘림·변동)
Ollama 27B probe                 PASS

llama.cpp 27B 쓰기 Run은 다섯 번째 호출에서 4096 token을 넘겨 model_rejected.provider_limit로
닫혔습니다(reasoning 10,148자). 같은 model이 Ollama에서는 reasoning 244~671자로 끝나는 것과 달리
llama.cpp의 --jinja 기본 thinking이 훨씬 길게 이어집니다. 이는 provider의 thinking 정책이며
--max-output-tokens를 더 올리거나 서버의 reasoning budget으로 다룹니다. 8B의 Run 실패
(write_approval_required로 pause, invocation_invalid)는 model 품질이며 이제 class로 진단됩니다.

데이터 경계

스키마 revision과 prompt template은 request_profile_digest 입력이므로 이 PR 이전에 시작해 완료되지
않은 Run은 resume 시 configuration_mismatch로 닫힙니다(ADR-0035 §4, ADR-0036 §2와 같은 결과).
#58과 함께 머지해 resume 단절을 한 번으로 줄이는 것을 권합니다. Journal·Receipt·manifest schema는
바뀌지 않습니다. 이 브랜치는 #58 위에 쌓여 있습니다.

검증

• 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-third-party-licenses.sh --check
• 실제 로컬 endpoint 세 곳(Ollama, brew llama.cpp, Ollama 번들 llama.cpp)에서 위 before/after

실패 테스트를 먼저 추가해 red를 확인한 뒤 구현했습니다.

범위 밖

outputSchema 축소(prompt −29%, 품질 검증 필요), --allow-file scope 제약, planner 경로
provider_limit의 잘림/429 분리는 별도입니다. 이 PR은 게시나 태그 생성을 수행하지 않습니다.