<!-- task=m-backtest-data-collection-infrastructure/02+01_freshness_status plan=2 tag=REVIEW2_CLI -->

# Plan - REVIEW2_CLI KR Freshness Date Alignment

## 이 파일을 읽는 구현 에이전트에게

이 plan은 직전 `local-G07` 코드리뷰의 Required 이슈만 해결한다. 새 protobuf/API/worker/storage 변경은 범위 밖이다. 구현 후 `CODE_REVIEW-local-G08.md`의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운 뒤 active 파일을 그대로 두고 리뷰를 요청한다. 종결, log rename, `complete.log`, archive 이동은 code-review 전용이다.

구현 중 사용자 결정, 사용자 소유 외부 환경/secret/서비스 준비, 범위 충돌이 필요하면 `CODE_REVIEW-local-G08.md`의 `사용자 리뷰 요청` 섹션에 근거를 기록하고 멈춘다. 사용자에게 직접 질문하거나 선택지를 제시하거나 `request_user_input`을 호출하지 않는다.

## Roadmap Targets

- Milestone: `agent-roadmap/phase/backtest-loop/milestones/backtest-data-collection-infrastructure.md`
- Task ids:
  - `freshness-status`: 수집 성공, 실패, 누락, 최신 일자를 operator가 확인할 수 있는 상태 출력을 만든다.
- Completion mode: check-on-pass

## 배경

G07에서 freshness status와 `latest_yyyymmdd` key는 고정됐지만 KR status fixture의 날짜 정합성이 아직 깨져 있다. `market_data_status_query.yaml`의 `collection_freshness` request window는 `1746057600000..1747267200000`이며 UTC 기준 `20250501..20250515`다. 그런데 expectation, expected JSONL, fake bar timestamp, text assertion은 `20240501`을 사용한다.

이 상태는 fake API가 query window를 강제하지 않아 테스트는 통과하지만, 실제 worker/API가 window를 지키는 정상 동작과 맞지 않는 handoff evidence다.

## 범위 결정 근거

- KR fixture/test date alignment만 수정한다.
- US fixture는 request window `20240528..20240530`, expected latest `20240529`, fake timestamp `20240529`로 이미 정합적이므로 건드리지 않는다.
- 같은 Milestone Task의 완료 조건을 향하므로 `Roadmap Targets`를 유지한다.

## 구현 체크리스트

- [ ] KR `market_data_status_query` freshness request window, YAML `latest_yyyymmdd`, expected JSONL, runner text assertion, fake bar timestamp가 모두 같은 날짜 범위 안에서 일치하도록 수정한다.
- [ ] 날짜 정합성을 검증하는 테스트나 assertion을 보강해 KR latest date가 request window 밖으로 다시 drift되지 않게 한다.
- [ ] `go test ./apps/cli/internal/operator ./apps/cli/internal/cli`를 실행한다.
- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.

### [REVIEW2_CLI-1] KR Freshness Window And Latest Date

#### 문제

현재 상태:

- `apps/cli/testdata/operator/market_data_status_query.yaml:52`: request window starts at `1746057600000` = `20250501` UTC.
- `apps/cli/testdata/operator/market_data_status_query.yaml:58`: expected `latest_yyyymmdd: "20240501"`.
- `apps/cli/testdata/operator/expected/market_data_status_query.jsonl:5`: expected JSONL latest is `20240501`.
- `apps/cli/internal/operator/runner_market_test.go:51`: fake bar timestamp is `1714521600000` = `20240501`.

#### 해결 방법

가장 작은 수정은 기존 fixture request window를 유지하고 latest 값을 `20250501`로 정렬하는 것이다.

- `runner_market_test.go` KR status fake bar timestamp: `1714521600000` → `1746057600000`.
- KR status text assertion: `latest_yyyymmdd=20240501` → `latest_yyyymmdd=20250501`.
- `market_data_status_query.yaml` freshness expect: `latest_yyyymmdd: "20240501"` → `"20250501"`.
- `market_data_status_query.jsonl` freshness line: `"latest_yyyymmdd":"20240501"` → `"20250501"`.

선택적으로, 테스트에서 KR fixture의 latest date가 request window 안에 있는지도 고정한다. 단, 범위를 넓혀 새 parser/contract를 만들지는 않는다.

#### 테스트 결정

- 필수: `go test ./apps/cli/internal/operator ./apps/cli/internal/cli`
- 중간 검증: `go test ./apps/cli/internal/operator`

#### 중간 검증

```bash
go test ./apps/cli/internal/operator
```

기대 결과: exit code 0.

## 최종 검증

```bash
go test ./apps/cli/internal/operator ./apps/cli/internal/cli
```

기대 결과: exit code 0. Go test cache output은 허용한다.
