trex-core/docs/discovery/dcy-014_20260608_trading-date-configurable-timezone-kst.md

0. 문서 상태

이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다.

• 상태: confirmed
• 문서 ID: dcy-014_20260608_trading-date-configurable-timezone-kst
• 이슈명: 당일 슬롯 생성 기준 시간을 KST(설정 가능)로 분리 — trading_date 타임존 분리 + 일자 경계 preallocation
• 작성 시각(KST): 2026-06-08 13:58 KST
• 마지막 갱신 시각(KST): 2026-06-08 17:20 KST
• 대체됨: 없음
• 후속 Discovery 참조: 없음
• 생성된 REQ 참조: REQ-005/048/009 (전부 change-req, 신규 REQ 없음 — OQ-3; 스케줄러는 REQ-030 SnapshotScheduler 패턴 준용). 각 CHG-20260608-01. delivery: BAT-018

1. 계획 상태 요약

현재 Discovery가 어떤 배경에서 작성되고 있는지, 연계 문서가 있는지, 지금 시점의 해석이 무엇인지 짧게 요약한다.

• 연계 문서 현황:
  • 관련 점수 파일: 미생성
  • 관련 TODO/메모: GitHub issue #14 (fourblocks2020/trex-core)
• 해석:
  • daemon 이 시작 시 datetime.now(tz=timezone.utc).date() 기준으로 슬롯을 1회 preallocate 해, trading_date 가 UTC 날짜로 생성되어 KST 기준 "오늘 슬롯"과 어긋나고, 재시작 없이는 다음날 슬롯이 자동 생성되지 않는 문제를 정식 SDLC 주기로 착수한다.
  • 이번 Discovery에서는 trading_date 계산 기준을 설정 가능한 타임존(기본 Asia/Seoul)으로 분리하고, timestamp 저장은 UTC 유지하며, 일자 경계에 맞춰 다음날 슬롯이 자동 생성되도록 일일 preallocation 을 보강하는 범위를 판정한다. 이는 daemon 런타임/스케줄러/설정 baseline 변경이므로, 거버넌스는 OQ-3 결정에 따라 기존 REQ(REQ-005/048/009, 스케줄러는 REQ-030 패턴 준용) change-req 로 처리하고 신규 REQ 는 원칙적으로 생성하지 않는다.

2. 요구사항 판정 결과

이번 요청이 기존 요구사항과 비교해 신규인지, 유사한지, 중복인지 판단하고 그 근거를 남긴다.

• 판정: 신규
• 근거
  • 기존 Discovery(dcy-001~dcy-013) 중 trading_date 타임존 기준이나 일자 경계 일일 preallocation 을 다룬 문서는 없다. dcy-002(슬롯 코어 데몬화)는 부트스트랩 시 preallocation 을 도입했으나 타임존·일자 경계 자동화를 정의하지 않았다.
  • 변경이 이미 Implemented·released 된 daemon 부트스트랩(setup)·슬롯 도메인(trading_date)·설정 계약의 의미를 바꾸고, 일일 스케줄링이라는 런타임 동작을 추가하므로, 기존 Discovery 미세 조정이 아니라 독립 주기로 추적하는 것이 명확하다.

3. 문제점의 요약

문제의 현재 상태, 기대 상태, 관련 이해관계자, 제약사항을 정리한다. Discovery의 핵심 맥락을 가장 먼저 이해할 수 있어야 한다.

• 현재 상태
  • trex_core/runtime/daemon.py 의 setup()(daemon.py:291~)은 self.slot_service.preallocate_daily_slots(datetime.now(tz=timezone.utc).date(), self.config.total_slots)(daemon.py:293~294)로, UTC 날짜 기준 슬롯을 데몬 시작 시 1회만 생성한다.
  • preallocate_daily_slots(trex_core/domain/slot/service.py:42~53)는 동일 trading_date 에 대해 멱등(2회차 이후 0 반환)이다. 즉 같은 날짜에 대한 재실행은 안전하나, 날짜가 바뀌어도 자동으로 다음날 슬롯을 만들지 않는다(재시작 의존).
  • timestamp 저장은 UTC 다 — 슬롯 created_at/updated_at·전이 로그가 UTC. 그러나 trading_date 도 UTC 날짜라 KST 자정~오전 구간에 KST 캘린더 일자와 어긋난다.
  • 타임존을 설정으로 분리하는 경로는 아직 없다 — trex_core/runtime/config.py 에 trading_date 용 타임존 설정이 없다. 다만 설정 인프라는 이미 두 표면을 갖춘다: env(.env, TREX_*, 대부분 설정)와 TOML(DaemonInstanceConfig.from_toml, --config <path>.toml, REQ-048 per-instance). 즉 새 운영 설정은 기존 TOML 에 키를 추가하면 된다.
  • 유사 패턴은 이미 존재한다 — trex_core/application/snapshot_scheduler.py 의 SnapshotScheduler 는 _KST 로 now_kst.date() 를 구해 KST 일자당 1회 fire 하고(_last_fired_date.date() == now_kst.date()), tick 루프(tick_sec)로 동작한다. 일일 KST 경계 작업의 직접적인 선례다.
  • baseline 문서(docs/project-structure.md, docs/runtime-flows.md)는 존재하며 최신이다. daemon 부트스트랩/스케줄러는 runtime flow 에 속하므로 이번 변경은 docs/runtime-flows.md 갱신을 동반한다.
• 기대 상태
  • trading_date 가 설정 가능한 타임존(기본 Asia/Seoul) 기준으로 계산되어, KST "오늘 슬롯" 과 DB trading_date 가 일치한다.
  • timestamp(created_at/updated_at/전이 ts)는 UTC 저장을 유지한다.
  • daemon 재시작 없이도 TZ 일자 경계에서 다음날 슬롯이 누락 없이 자동 생성된다(멱등 일일 preallocation).
  • 운영자가 타임존을 TOML 설정으로 명시 지정할 수 있다.
• 이해관계자
  • 문서 작성자(AI agent) — Discovery/REQ/Batch 산출물 작성
  • 리뷰어/승인자 — 타임존·스케줄링·설정 계약 변경 승인
  • 운영 담당자 — 일자 경계 슬롯 생성·타임존 설정 운영
  • 전략 모듈/테스트 — KST 기준 "오늘 슬롯" 을 일관되게 관측
• 제약사항
  • 이미 released 된 daemon 부트스트랩·슬롯 도메인·설정 변경이므로 ad-hoc 수정이 아니라 정식 SDLC(change-req 또는 신규 REQ) 경유가 필요하다.
  • timestamp 는 UTC 를 유지하고 trading_date 만 TZ 기준으로 분리해, 저장 일관성과 일자 해석을 명확히 구분해야 한다.
  • 다중 인스턴스(dcy-009) 운영 시 일일 preallocation 이 중복 생성되지 않도록 멱등성에 의존한다.

주요 사용자 시나리오

사용자 또는 운영자가 실제로 어떤 상황에서 이 변경을 필요로 하는지 대표 시나리오를 적는다.

• 운영자가 KST 오전에 "오늘 슬롯" 을 조회한다 → DB trading_date 가 KST 당일과 일치해 직관적으로 해석된다(UTC 자정 경계 혼동 제거).
• daemon 이 며칠간 재시작 없이 떠 있다 → TZ 일자 경계마다 다음날 슬롯이 자동 생성되어 매일 거래 준비가 누락되지 않는다.
• 운영자가 다른 거래소/타임존을 쓰는 환경에서 TOML 로 타임존을 명시 설정한다 → 시스템 시간과 무관하게 일관된 trading_date 가 계산된다.

4. 이번에 정의할 변경

이번 Discovery에서 다루는 핵심 변경 항목을 목록으로 적는다. 기능, 구조, 규칙 변경을 함께 포함해도 된다.

• trading_date 계산 기준을 시스템 UTC 가 아니라 설정 가능한 타임존(기본 Asia/Seoul)으로 분리한다. timestamp 저장은 UTC 유지.
• daemon 시작 1회 preallocation 을 TZ 일자 경계 기준 일일 preallocation 으로 보강한다 — SnapshotScheduler 패턴(tick 루프 + TZ 일자당 1회 fire)을 따르고 기존 멱등성을 활용한다.
• 본 기능의 운영 설정(타임존 + 일일 트리거 시각)을 기존 TOML 설정(REQ-048 DaemonInstanceConfig, --config <path>.toml)에 추가하고, docs/runtime-flows.md·docs/data-model.md 에 trading_date 타임존·일일 생성 흐름을 반영한다. (이 프로젝트는 이미 env[.env, 대부분]와 TOML[per-instance, REQ-048]을 병용하므로, 본 설정은 TOML 측으로 자연스럽게 편입된다.)

영향 범위

변경이 미칠 코드/문서/운영 범위를 명시해 REQ 정제와 batch planning에서 추정 누락을 줄인다.

• 코드 영향:
  • trex_core/runtime/config.py — trading_date 타임존 + 일일 트리거 시각을 기존 TOML 설정(DaemonInstanceConfig.from_toml, REQ-048)에 추가(기본 Asia/Seoul/00:00). 신규 설정 표면이 아니라 기존 --config <path>.toml 에 키 추가
  • trex_core/runtime/daemon.py — setup() 의 UTC 날짜 preallocation 을 TZ 기준으로 변경 + 일일 preallocation 루프/스케줄러 배선
  • trex_core/application/ — 일일 preallocation 스케줄러(또는 SnapshotScheduler 유사 컴포넌트). 기존 멱등 preallocate_daily_slots 재사용
  • trex_core/domain/slot/service.py — trading_date 를 TZ 기준 date 로 받는 호출부 정합(도메인 시그니처는 date 유지)
• 문서 영향:
  • docs/runtime-flows.md — daemon 부트스트랩/일일 preallocation·trading_date 타임존 흐름 반영
  • docs/data-model.md — trading_date(TZ 기준 거래일) vs timestamp(UTC) 구분 명시
• 운영 영향:
  • 타임존·트리거 시각 TOML 설정 추가 → 배포/운영 문서 안내 필요
  • 일자 경계 자동 생성으로 재시작 의존 제거

5. 요구사항 목록

실제로 구현과 검증으로 이어질 요구사항을 기능/비기능으로 나누어 정리하고, 범위 경계를 명확히 적는다.

기능 요구사항

• FR-1: trading_date 는 설정 가능한 타임존(기본 Asia/Seoul) 기준 날짜로 계산한다. 시스템 UTC 날짜에 의존하지 않는다.
• FR-2: timestamp(created_at/updated_at/전이 ts)는 UTC 저장을 유지한다(거래일과 시각 저장 분리).
• FR-3: daemon 재시작 없이 TZ 일자 경계에서 다음날 슬롯을 자동 생성한다 — tick 루프로 TZ 일자당 1회 멱등 preallocation(SnapshotScheduler 패턴 준용). 생성 트리거 시각은 기본 00:00(TZ 자정) 이며, TOML 설정으로 변경 가능하다(OQ-1).
• FR-4: 운영자가 타임존을 TOML 설정으로 명시 지정할 수 있다(기본 Asia/Seoul). 본 기능의 운영 설정(타임존 + 트리거 시각)은 TOML 로 일원화한다.
• FR-5: docs/runtime-flows.md 와 docs/data-model.md 에 trading_date 타임존·일일 preallocation 흐름을 반영한다.

비기능 요구사항

성능, 운영성, 일관성, 자동화 안정성 등 기능 외 요구사항을 적는다.

• NFR-1: 저장 일관성 — 모든 timestamp 는 UTC, trading_date 만 TZ 기준으로 분리되어 해석 혼동이 없어야 한다.
• NFR-2: 멱등성 — 일일 preallocation 이 같은 trading_date 에 중복 슬롯을 만들지 않아야 한다(다중 인스턴스·중복 tick 안전).
• NFR-3: 자동화 안정성 — 날짜 경계에서 다음날 슬롯 생성이 누락되지 않고, daemon 재시작 없이 동작해야 한다.

범위 경계

이번 반복에서 반드시 포함할 범위와 명시적으로 제외할 범위를 구분한다.

• In Scope
  • trading_date 의 설정 가능한 타임존 분리(기본 KST) + timestamp UTC 유지
  • TZ 일자 경계 기준 일일 멱등 preallocation
  • 타임존·트리거 시각 TOML 설정 + runtime-flows/data-model 문서 갱신
• Out of Scope
  • timestamp 저장 형식 변경(UTC 유지)
  • 슬롯 용량/total_slots 정책 변경
  • (OQ-2 결정) 거래일 캘린더(주말·공휴일 비거래일 제외) — 매 캘린더일 생성으로 확정, 캘린더 도입은 후속 분리

6. 리스크/가정 목록

불확실성과 전제 조건을 분리해서 적는다. 리스크는 영향과 완화 방안을, 가정은 현재 판단의 전제를 기록한다.

리스크

• R-1 (Low, OQ-1 결정으로 완화): 일일 preallocation 트리거 시점이 운영 기대와 어긋날 수 있다.
  • 완화 방안: 기본 00:00(TZ 자정) + TOML 설정(OQ-1)으로 운영자가 조정 가능하게 하고, SnapshotScheduler 의 KST 일자당 1회 fire 패턴을 재사용해 검증 가능하게 한다.
• R-2 (Medium): 타임존 분리 전환 시점에 기존 UTC 날짜로 만들어진 슬롯과 새 TZ trading_date 가 경계 구간에서 불일치할 수 있다.
  • 완화 방안: 전환 시 당일 경계 동작을 문서화하고, 멱등성으로 중복을 막되 경계 케이스를 테스트로 확인한다.
• R-3 (Low, OQ-2 결정으로 수용): 비거래일(주말/공휴일)에도 슬롯이 생성되어 idle 슬롯이 쌓일 수 있다.
  • 완화 방안: OQ-2 결정에 따라 매 캘린더일 생성을 수용한다 — idle 슬롯은 멱등 생성이고 buy intent admit 시에만 활성화되어 무해하다. 거래일 캘린더(외부 데이터)는 후속 분리.

가정

아직 확정되지 않았지만 현재 문서 작성의 기반이 되는 전제를 적는다.

• A-1: SnapshotScheduler(snapshot_scheduler.py) 가 이미 _KST 기준 일자당 1회 fire + tick 루프를 구현하므로, 일일 preallocation 도 동일 패턴/유사 컴포넌트로 안전하게 구현할 수 있다.
• A-2: preallocate_daily_slots 가 trading_date 멱등이므로, 일일 재실행·다중 인스턴스에서도 중복 생성이 발생하지 않는다.
• A-3: 도메인의 trading_date: date 시그니처는 유지하고, 타임존 해석은 호출부(daemon/스케줄러)에서 수행하면 도메인 변경을 최소화할 수 있다.

오픈 질문

답을 아직 모르는 항목을 적는다. 추정으로 덮지 말고 REQ 초안 작성 이전에 확인할 질문으로 남긴다.

• OQ-1: 일일 preallocation 트리거 시점 — TZ 자정(00:00) 경계에 생성하는가, 장 시작 전 특정 시각(설정)에 생성하는가?
  • 상태: Answered (2026-06-08, 사용자 결정 — 기본 00:00(TZ 일자 경계), TOML 로 설정 가능)
  • 결정: 일일 preallocation 은 설정 타임존의 자정(00:00) 일자 경계에 다음날 슬롯을 생성하는 것을 기본값으로 하고, 트리거 시각은 TOML 설정으로 운영자가 변경할 수 있다(SnapshotScheduler 의 KST 일자당 1회 fire 패턴 준용). 본 기능의 운영 설정(타임존 + 트리거 시각)은 TOML 로 일원화한다(FR-4 함께 결정). 이 프로젝트는 이미 env 와 TOML(REQ-048 per-instance)을 병용하므로, 본 설정은 기존 TOML(--config)에 키를 추가하는 형태로 편입된다(신규 설정 표면 아님).
  • 반영 위치: FR-3, FR-4, R-1, 4. 변경 항목/영향 범위
• OQ-2: 비거래일(주말/공휴일) 처리 — 매 캘린더일 슬롯을 생성하는가, 거래일만 생성하는가(거래일 캘린더 도입)?
  • 상태: Answered (2026-06-08, 사용자 결정 — A안: 매 캘린더일 생성)
  • 결정: 거래일 캘린더를 도입하지 않고 매 캘린더일에 슬롯을 생성한다. 휴장일 idle 슬롯은 무해하다 — 멱등 생성이고, 슬롯은 buy intent 가 admit 될 때만 활성화되므로 휴장일엔 비어 있다가 사라지며 safety-sell·워치독 등은 holding/pending 슬롯만 대상으로 한다. KRX 공휴일 캘린더(외부 데이터·매년 유지보수)는 idle 슬롯 회피 이득 대비 비용이 커 후속으로 분리한다(필요 시: 주말 스킵 또는 거래일 캘린더).
  • 반영 위치: 범위 경계(Out of Scope), R-3
• OQ-3: 거버넌스 경로 — 기존 REQ(데몬 부트스트랩·슬롯 도메인·설정)의 change-req 로 처리할지, 일일 스케줄러를 신규 REQ 로 추적할지?
  • 상태: Answered (2026-06-08, 사용자 결정 — change-req 우선)
  • 결정: 기존 Implemented REQ 본문 수정(change-req)으로 처리한다. change-req 대상 — REQ-005(슬롯 코어 데몬 런타임 부트스트랩: setup() 의 UTC→TZ trading_date 계산 + 일일 preallocation 루프 배선), REQ-048(per-instance TOML 설정 로더: trading_date 타임존 + 일일 트리거 시각 키 추가), REQ-009(데몬/API/영속화 baseline 문서 정합: runtime-flows/data-model 갱신). 일일 preallocation 스케줄러는 REQ-030(일일 스냅샷 스케줄러)의 SnapshotScheduler 패턴을 준용한다. preallocate_daily_slots 가 이미 date 멱등이고 호출부(daemon)에서 TZ 계산을 수행하므로 REQ-002(slot 도메인) 본문 변경은 원칙적으로 불필요(정제에서 확인). 신규 REQ 는 원칙적으로 생성하지 않으며, 일일 preallocation 을 별도 컴포넌트로 분리해야 한다고 판단되면 REQ 정제에서 소형 신규 REQ 를 둘 수 있다(조건부).
  • 반영 위치: 1. 거버넌스 해석, R-1 완화 방안, 8. 확인 체크

오픈 질문 처리 기준

• Open: 아직 답이 없고 다음 단계 진행에 영향이 있는 상태다. 문서에 유지한다.
• Answered: 답이 확정된 상태다. 관련 본문/요구사항에 반영한 뒤 오픈 질문 목록에서는 제거하거나 resolved 기록으로 이동한다.
• Deferred: 지금 단계에서 결정하지 않고 다음 단계 또는 후속 이슈로 넘기는 상태다. 넘길 대상과 이유를 반드시 적는다.
• Dropped: 더 이상 유효하지 않은 질문이다. 삭제 사유를 짧게 남기고 목록에서 제거한다.

7. 초기 성공 기준

이 변경이 성공했다고 판단할 기준을 측정 가능하게 정의한다. 가능하면 데이터 출처까지 연결한다.

• S-1: 설정 타임존(기본 KST) 기준 "오늘 날짜" 와 생성된 슬롯의 DB trading_date 가 일치한다(UTC 자정 경계 포함).
• S-2: 모든 timestamp(created_at/updated_at/전이 ts)가 UTC 로 저장됨이 유지된다.
• S-3: daemon 재시작 없이 TZ 일자 경계를 넘기면 다음날 trading_date 슬롯이 자동 생성되고, 중복 생성은 0건이다.
• S-4: 운영자가 TOML 로 타임존을 설정하면 그 타임존 기준으로 trading_date 가 계산된다.

측정 방식 및 데이터 출처

각 성공 기준을 어떻게 측정할지와 어떤 데이터나 문서를 근거로 쓸지 적는다.

• S-1 측정 방식: KST 자정 전후 시점을 고정 clock 으로 주입한 단위 테스트에서 trading_date 일치 확인 / 데이터 출처: 슬롯 row trading_date, 주입 clock
• S-2 측정 방식: 슬롯 생성/전이 후 timestamp 컬럼 UTC 확인 / 데이터 출처: created_at/updated_at/transition_log
• S-3 측정 방식: 일자 경계를 넘기는 clock 주입 테스트에서 다음날 슬롯 1회 생성·재호출 0건(멱등) 확인 / 데이터 출처: preallocation 스케줄러 테스트, 슬롯 count
• S-4 측정 방식: 타임존 TOML 설정 케이스(KST/타 TZ) 테스트에서 trading_date 계산 확인 / 데이터 출처: config 로드, 슬롯 trading_date

8. REQ로 넘기기 전 확인 체크

REQ 초안 작성 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다. 미완료 항목은 후속 결정이 필요함을 뜻한다.

• 범위(In Scope/Out of Scope) 확정
  • 기준: 트리거 시점(OQ-1)·거래일 캘린더(OQ-2)·거버넌스(OQ-3) 모두 확정됨
• 성공 지표의 측정 방식/데이터 출처 확정
  • 기준: S-1~S-4 의 테스트/검증 출처가 실제 실행 가능한 형태로 지정됨
• High 영향 리스크 우선순위 및 해소 책임자 지정
  • 기준: 전환 경계(R-2)의 change-req 대상(REQ-005/048/009, 스케줄러 REQ-030 패턴)이 OQ-3 으로 확정됨. 해소 실무 책임자 배정은 REQ/batch planning 단계로 넘김(비차단).
• 모든 오픈 질문(OQ) Open 상태 없음 확인
  • 기준: OQ-1~OQ-3 모두 Answered, Open 0개
• Freeze 확정 담당자(CONFIRMED_BY) 지정
  • 기준: Confirmed By = Justin Ko (사람 승인자 지정 완료)

9. 파일 처리 결과

이 Discovery 문서 생성/갱신 결과와 참조 문서를 기록한다. 이후 추적과 리뷰 시 근거로 사용한다.

• 처리 결과: 생성
• 생성 경로: docs/discovery/dcy-014_20260608_trading-date-configurable-timezone-kst.md
• 참조 문서:
  • GitHub issue #14 (fourblocks2020/trex-core) — 당일 슬롯 생성 기준 시간 KST 분리
  • docs/discovery/dcy-002_20260603_slot-core-daemon-http-api.md — 데몬 부트스트랩·preallocation 도입 근거
  • trex_core/runtime/daemon.py:291-294 — UTC 날짜 1회 preallocation(현행 갭)
  • trex_core/application/snapshot_scheduler.py — KST 일자당 1회 fire 스케줄러 선례(A-1)
  • docs/runtime-flows.md, docs/data-model.md — 런타임/데이터 baseline 갱신 대상

10. 사용자 결정 필요 항목 요약

사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. 결정, 확인, 데이터 요청을 구분해서 적는다.

DECIDE

• (없음 — OQ-1/OQ-2 확정으로 해소)

결정 완료(2026-06-08): OQ-1 일일 preallocation 트리거 = 기본 00:00(TZ 자정 일자 경계), TOML 설정 가능(타임존도 TOML 일원화) / OQ-2 비거래일 = 매 캘린더일 생성(거래일 캘린더 후속 분리). 결정 항목에서 제외됨.

CONFIRM

• 없음 — 거버넌스 경로는 OQ-3 으로 확정됨(REQ-005/048/009 change-req, 스케줄러는 REQ-030 패턴 준용, 신규 REQ 원칙적 없음).

DATA

• (비차단, REQ/delivery 단계) 기본 타임존 Asia/Seoul 확정과 TOML 키/스키마 명명 규약. 운영 정책·키 명명은 REQ 정제/설계에서 확정하며, 기본값 KST 가 본 Discovery 의 FR/성공 기준을 충분히 정의하므로 confirm 을 차단하지 않는다.

11. Discovery Freeze

REQ 초안 작성 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다.

섹션 참조

• 범위: # 5. 요구사항 목록 > 범위 경계
• 리스크/오픈 질문: # 6. 리스크/가정 목록
• 성공 기준: # 7. 초기 성공 기준
• 인계 전 확인: # 8. REQ로 넘기기 전 확인 체크
• 사용자 결정 필요: # 10. 사용자 결정 필요 항목 요약

Freeze 플래그

• Handoff Decision: 승인
• Handoff Rationale: confirm-discovery 완료. 오픈 질문 OQ-1~OQ-3 모두 Answered (트리거=기본 00:00 TZ 자정·TOML 설정[타임존 포함] / 비거래일=매 캘린더일 생성 / 거버넌스=REQ-005/048/009 change-req, 스케줄러 REQ-030 패턴, 신규 REQ 원칙적 없음). C 유형 플레이스홀더 0개, 저장소 사실관계 일치(TOML 설정 인프라 정정 반영). DATA(기본 TZ·TOML 키 명명)는 REQ/delivery 단계 비차단. REQ 초안 작성 인계 가능.
• Ready for REQ Drafting: true
• Confirmed By: Justin Ko
• Confirmed At (KST): 2026-06-08 14:50 KST