v0.52.5 — 두 tool이 서로를 가리키기만 하던 자리

v0.52.4에서 처음 잰 "모델이 옳은 tool을 고르는가"를 스크립트로 승격하고, 승격하자마자
첫 재실행이 짚은 두 자리를 고쳤다. 둘 다 값 계산은 맞는데 문구가 사실과 다르거나
모자란 부류다 — 이 저장소에서 다섯 라운드 연속 같은 유형이다.

고친 것

• get_order_executions ↔ get_transactions — 전자는 "과거 일자는 get_transactions로",
  후자는 "체결가는 get_order_executions로"라 적어 둬서 '어제 체결가'를 물으면 모델이 두
  tool 사이를 왕복만 했다(모델 셋이 셋 다 다른 답을 냈다). 실제로는 ka10076이 지난 일자를
  주지 않고 kt00015는 결제일(D+2) 기준이라 어제 체결분은 오늘 어느 쪽에도 없다.
  리다이렉트 대신 그 사실을 양쪽 description에 적고, 빈 결과 각주에도 같이 넣었다 —
  각주에만 있으면 라우팅이 못 읽고, description에만 있으면 빈손을 받은 사용자가 이유를
  모른다.
• get_theme_groups / get_sector_stocks — "'반도체'처럼 업종을 뜻한 것이라면
  get_sector_stocks가 맞습니다"라는 단정이 '반도체 테마에 뭐가 들어있어?'를 업종으로
  보냈다(모델이 그 문장을 근거로 인용했다). 이름이 겹친다는 사실과 사용자가 쓴 말을
  따른다는 기준으로 바꾸고, 업종 쪽에도 거울 문구를 넣었다(테마명은 받지 않는다).

감시

라우팅 시험이 scripts/routing.py 한 명령이 됐다 — 카탈로그 덤프(tools/list 응답
그대로) → 시험지 → 소스를 못 보는 별도 프로세스의 답안 → 채점. 그전까지는 손 절차라
질문·정답표가 로컬에만 있었다. 이제 데이터는 저장소에 있고, npm run check의 일곱 번째
검사가 그 정답표가 실제 tool·파라미터를 가리키는지 본다. 시험 자체는 모델을 부르므로
CI에 없어서, 그 사이 정답표만 조용히 낡기 때문이다 — 특히 param_check의 이름이 낡으면
"이 파라미터를 넘기지 말 것" 검사가 영원히 통과한다.

검증

같은 시험 재실행에서 haiku·sonnet·opus 셋 다 52/52(직전 라운드는 52·51·52).
제한은 첫 문장에 적어야 따라온다는 것도 여기서 나왔다 — 같은 사실을 문장 뒤쪽에 두면
haiku는 읽고도 그 tool을 불렀고(명령형을 붙여도 그랬다), 첫 문장으로 올리자 넘어왔다.

빈 결과 각주는 모의 스윕으로 눈으로 확인했고, 새 각주 단언은 실패 주입으로 가짜 가드가
아님을 확인했다.

동작 변화는 없다. 바뀐 것은 모델이 읽는 문구와 빈 결과 각주 한 줄, 그리고 감시다.