feat: let a delegated tool start from an empty strategy and find what to put in it

[kcrmin]

후속: Idea2Strategy/Idea2Strategy#479

목표는 이것이다 — 사람이 "애플 요즘 좋던데 RSI 써서 만들어줘" 라고 하면 외부 AI 가 우리 CLI 를
도구처럼 써서 전략을 만든다. 그 사이를 막고 있던 세 가지를 없앤다.

1. 빈 전략의 첫 편집이 항상 422 였다

새 전략의 문서는 {"groups":[],"mode":"BASIC"} 이고 catalogId 가 없다. 그런데 제안된 문서는
반드시 정식 조립체로 파싱돼야 하고 그 파싱이 catalogId 를 요구한다. 즉 ADD_GROUP 을 넣은
뒤에도 새 전략의 첫 편집은 예외 없이 실패했다. AWS 실측으로 확인했다.

첫 편집이 자기가 검증받는 그 카탈로그를 문서에 찍는다. 값을 지어내는 게 아니라, 이미 그 편집의
기준인 카탈로그를 명시할 자리가 없었던 것뿐이다.

왜 안 잡혔나: 단위 테스트 픽스처가 전부 catalogId 를 갖고 있었고, HTTP 저니는 빈 전략에서
나온 422 를 "아직 그룹이 없어서" 로 해석해 정상으로 단언했다. 맞는 코드에 틀린 이유였고, 그래서
아무도 몰랐다. 두 테스트 모두 이제 새 전략이 실제로 갖는 문서 에서 출발한다.

2. 도구가 무엇을 쓸지 알아낼 방법이 없었다

사람은 "애플" 과 "RSI" 라고 말하는데, 컨테이너는 종목을 id 로 지목하고 블록은 발행된
요소 코드 로 지목한다. 조회 명령이 없으면 도구는 추측해야 하고, 추측한 코드는 거절된다 — 받은
요청을 완수할 방법이 없다.

catalog instruments --symbol AAPL     -> {"id":"aa268aa6-…","symbol":"AAPL"}
catalog elements                       -> BASIC_RSI_CROSS · BASIC_BOLLINGER_REVERSAL · …

두 라우트는 이미 있었고 CLI 만 닿지 못했다. AWS 에서 실제로 확인했다.

3. 계약이 순서를 알려주지 않았다

외부 도구는 tool-contract 를 읽고 사용법을 배운다. 거기에 조회 단계와 전략 생성·위임 단계가
없어서, 편집 워크플로만 알고 그 앞을 몰랐다. 이제 discovery 와 create/delegate 가 계약에 있다.

검증

:apps:idea2strategy-cli:test · :modules:backend-application:test ·
:apps:backend-api:test --tests '*ExternalToolDelegatedEditJourney*' 통과.

새 커버리지: 빈 전략에서 컨테이너 → 블록 3개 → 연결 2개를 만들어 valid: true 로 apply 까지
가는 단위 테스트. HTTP 저니도 이제 빈 전략에서 preview 200 을 받고 diff[0] == "ADD_GROUP buy BUY", previewHash, expectedEditSequence, 그리고 찍힌 catalogId 를 단언한다.

남는 것

브라우저 로그인이다. 지금 login 은 stdin 으로 비밀번호를 받는다. "설치하고 설정해줘" 에
브라우저가 열리려면 별도 인증 흐름이 필요하고, 이 PR 범위가 아니다.

🤖 Generated with Claude Code