planner prompt를 고정 부분 앞, 가변 식별자 뒤 순서로 직렬화

[Createyouracccount]

배경

PR #57 뒤 Qwen3.8 27B(Q4_K_M, Ollama)로 쓰기 Run이 완료되지만 planner 호출당 68/96/107초가 걸렸습니다.
호출 하나의 절반은 planning context prefill이고, user message 9,064바이트 중 capability catalog가
8,304바이트(92%)로 사실상 상수인데도 매 호출 다시 prefill되고 있었습니다. 원인은 wire 키 순서입니다.
callId·requestDigest·runId·authority·journalHeadDigest처럼 호출마다 바뀌는 값이 envelope과
context의 맨 앞에 있어, 앞에서부터 같은 token만 재사용하는 provider prefix cache가 첫 50토큰에서
끊깁니다.

XGENy 코드 없이 같은 요청에 새 식별자만 바꿔 두 번씩 보낸 실측입니다.

변형	1회	2회
현재 키 순서	72.2s	61.7s
가변 키를 뒤로	64.8s	30.7s
동일 요청 재전송		28.1s

이 이득은 model이 아니라 provider의 캐시 구조에서 오므로 Ollama·vLLM·llama.cpp에 같은 방식으로
작용하고 model 선택과 무관합니다.

변경 사항 (ADR-0036)

• Wire 순서를 "고정 → 누적 → 가변"으로 고정합니다. Envelope: profileVersion, planningContext, callId, requestDigest. Context: profileVersion, capabilities, omittedCapabilities, catalogDigest, goal, planningConstraints, steps, omittedSteps, toolOutputs, totalSteps, verifiedCompletedSteps, runId, authority, authorityEpoch, journalSequence, journalHeadDigest. steps/toolOutputs는 턴마다 뒤에 추가되므로 같은 Run의 다음 턴에서도 이전 prefix가 재사용됩니다.
• 키 순서는 이제 계약이므로 REQUEST_ENVELOPE_PROFILE을 xgeny.planner-request/v2로 올립니다. Planning context profile은 v3을 유지합니다(내용과 canonical digest 불변).
• Catalog 내용은 바꾸지 않습니다. outputSchema를 빼면 prompt가 29% 줄지만(3,683→2,621 token) model이 "read-text가 digest를 돌려준다"를 그 schema에서 배우므로 품질 검증 없이는 하지 않습니다.

데이터 경계

context_digest와 request_digest는 RFC 8785(JCS)로 계산되어 키 순서와 무관합니다. 변경 전 main에서
채취한 golden context_digest가 변경 후에도 같음을 테스트로 고정했습니다. Journal·Receipt·manifest·
protocol fixture는 바뀌지 않습니다. 바뀌는 것은 envelope revision이 들어가는 request_profile_digest
하나이며, 그 golden은 의도적으로 재채취했습니다. 이 PR 이전에 시작해 완료되지 않은 Run은 resume 시
configuration_mismatch로 닫힙니다(ADR-0035 §4와 같은 결과, ADR-0036 §2에 명시).

실제로 동작하게 된 것

같은 machine, 같은 goal, 같은 GGUF, 같은 프로필(300s/1024)입니다.

BEFORE (PR #57)  27B c. write natural  COMPLETED 271s   호출별 68 / 96 / 107 s
AFTER  (v2 순서) 27B c. write natural  COMPLETED 189s   호출별 59 / 67 / 64 s   (wire 순서 확인 3/3)
                 config.toml workers 4→8
                 8B read COMPLETED 35s ; 27B probe PASS

2·3번째 호출이 각각 약 30초·43초 줄었습니다. 1번째 호출은 catalog가 아직 캐시에 없어 그대로입니다.
2번째 호출은 tool output이 더해져 prompt가 3,144→3,627 token으로 늘었는데도 빨라졌습니다.

검증

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --locked -- -D warnings
• cargo test --workspace --locked --no-fail-fast (566 passed / 0 failed, 45 binaries)
• cargo build --workspace --release --locked
• xgeny protocol check
• sh scripts/check-rc3-public-docs.sh
• sh scripts/check-third-party-licenses.sh --check
• 실제 로컬 endpoint(Ollama 27B·8B)에서 위 before/after와 wire 순서 확인

실패 테스트를 먼저 추가해 red를 확인한 뒤 구현했습니다: runtime은 직렬화된 context의 키 위치와
순서 무관 golden digest, provider는 envelope v2와 user message 바이트 순서를 검사합니다.

범위 밖

Catalog 축소(outputSchema·$schema), proposal 스키마 maxLength/pattern, --allow-file scope
제약은 별도입니다. 이 PR은 게시나 태그 생성을 수행하지 않습니다.