trex-core/docs/discovery/dcy-027_20260612_long-term-strategy-slot-operation.md

0. 문서 상태

• 상태: draft
• 문서 ID: dcy-027_20260612_long-term-strategy-slot-operation
• 이슈명: 중장기 매매 전략용 슬롯 운영 도입 — 구현 위치 결정 + 멀티데이 리스크 규칙 + 운영 프로파일 (issue #20)
• 작성 시각(KST): 2026-06-12
• 마지막 갱신 시각(KST): 2026-06-12
• 대체됨: 없음
• 후속 Discovery 참조: 없음
• 생성된 REQ 참조: 없음

1. 계획 상태 요약

• 연계 문서 현황:
  • 관련 점수 파일: 없음
  • 관련 TODO/메모: GitHub issue #20 (중장기 슬롯 운영 — 같은 프로젝트 내 신규 도메인 vs 별도 프로젝트 분리). dcy-020(자산 중심 영구 슬롯 — Out of Scope 로 "중장기 전용 운영의 전체"를 본 주기로 이월), dcy-024(safety_sell_enabled — "중장기 보유 인스턴스는 enabled=false" 용도로 설계), dcy-009(다중 인스턴스 토폴로지)와 직접 연계.
• 해석:
  • issue #20 은 구 pool 모델(daily_slot·일일 preallocation·장 마감 강제 청산) 기준으로 "중장기와 정면 충돌"을 분석했으나, 이후 dcy-020/BAT-027~030 영구 자산 슬롯 cutover 와 dcy-024/BAT-036 safety_sell_enabled=false 출시로 충돌 지점 대부분이 이미 해소되거나 옵트아웃 가능해졌다 — 이슈의 전제를 현행 코드 기준으로 재정렬해야 한다.
  • 본 Discovery 는 (1) 구현 위치(이슈 OQ-1)를 현행 모델 기준으로 재판정하고, (2) 잔여 갭 — safety-sell OFF 시 멀티데이 보호장치 부재, watchdog 의미 재검토, forced_close_at 재해석, 중장기 인스턴스 운영 프로파일 — 의 범위를 확정한다.

2. 요구사항 판정 결과

• 판정: 신규
• 근거
  • dcy-020 이 issue #20 을 입력으로 참조했으나 Out of Scope 에 "중장기 전용 운영(issue #20)의 전체 — 본 모델은 토대만 제공"으로 명시적으로 제외했다. 그 이월 범위를 다루는 독립 주기가 없다.
  • 멀티데이 리스크 규칙(트레일링/타임스톱)·중장기 인스턴스 운영 프로파일은 기존 어떤 REQ 도 다루지 않아 change-req 로 흡수할 대상 REQ 자체가 없다.

3. 문제점의 요약

• 현재 상태
  • 이슈 #20 의 충돌 분석 중 이미 해소된 항목: daily_slot 일일 리셋·preallocation 은 BAT-030 cutover 로 폐기됨(영구 자산 슬롯이 날 경계를 넘어 holding 유지 — trex_core/domain/slot/, (instance_key, portfolio_id) 키). closed→idle 재진입·entry_count 도 폐기됨(BAT-030/034). 장 마감 강제 청산·safety-sell 은 safety_sell_enabled=false(BAT-036, per-instance TOML)로 인스턴스 단위 옵트아웃 가능. 다중 인스턴스 토폴로지(dcy-009)·per-instance TOML(REQ-048)·config-dir(BAT-026)로 instance_key=longterm 독립 데몬 운영이 이미 가능.
  • 잔여 갭 1 — 멀티데이 보호장치 부재: SafetySellService(trex_core/application/safety_sell.py)의 stop-loss·forced_close·market-close 는 전부 safety-sell 워커에 묶여 있고 watchdog-gated(당일 전략 이탈 전제)다. safety_sell_enabled=false 인 중장기 인스턴스는 어떤 코어 보호장치도 없다 — 멀티데이 stop-loss·트레일링 스톱·타임스톱이 존재하지 않는다.
  • 잔여 갭 2 — watchdog 의미 충돌: 워치독 timeout 기본 120s(REQ-034)는 분 단위 폴링 당일 전략 전제다. 하루 1~2회 체크하는 중장기 전략은 watchdog expired 가 일상 상태가 되어 가시화 신호로서 의미를 잃는다.
  • 잔여 갭 3 — forced_close_at 의미: 당일 청산 시각 전제 필드(REQ-032/037)로, 중장기에서는 타임스톱으로 재해석하거나 미사용 처리할지 미정.
  • 잔여 갭 4 — 운영 프로파일 부재: 중장기 인스턴스용 표준 TOML 구성(safety_sell off + market-close 미설정 + watchdog 완화 + max_active_slots)이 문서화·검증된 적 없다. baseline 문서(docs/project-structure.md, docs/runtime-flows.md)는 존재·최신이나 당일 운영 중심으로 기술돼 있다.
• 기대 상태
  • 구현 위치가 확정된다 — 현행 영구 슬롯 모델이 멀티데이 보유를 이미 지원하므로, 이슈 권장안(a)의 "신규 PositionBook 도메인"이 여전히 필요한지, 아니면 기존 슬롯 도메인 + 중장기 운영 프로파일 + 멀티데이 리스크 규칙 추가로 충분한지 판정된다.
  • safety_sell_enabled=false 인스턴스에도 선택 가능한 멀티데이 보호 규칙(stop-loss/트레일링/타임스톱 중 합의된 범위)이 제공되거나, "전략 모듈 전적 책임"으로 명시적으로 선을 긋는다.
  • 중장기 인스턴스 운영 프로파일(TOML 레시피 + watchdog 정책)이 baseline 문서에 기술되고 실 데몬으로 검증된다.
• 이해관계자
  • 운영자/시스템 관리자 (Justin Ko): 당일·중장기 인스턴스 병행 운영, 리스크 정책 결정
  • 중장기 전략 모듈(신규 — trex-orb-v1 와 별개): intent 발신·슬롯 read 소비자
  • 기존 당일 인스턴스: 회귀 없이 무간섭 운영 유지
• 제약사항
  • 검증된 당일 경로(BAT-027~036)에 회귀를 주지 않아야 한다 — 이슈도 "당일 슬롯 머신에 멀티데이 의미를 끼워 넣으면 조건 분기 폭증" 위험을 지적.
  • 플랫폼 계층(브로커/ledger/transport/slots RPC/CLI)은 호라이즌 무관으로 공유한다 — 분리 시 인프라 복제 손해(이슈 분석 유지).
  • 중장기 인스턴스는 별도 instance_key 로 큐·DB 스코프를 분리해 당일 인스턴스와 무간섭이어야 한다(dcy-009 토폴로지 전제).

주요 사용자 시나리오

• 운영자가 instance_key=longterm 데몬을 중장기 프로파일 TOML 로 기동 → 매수 후 슬롯이 며칠~수개월 holding 을 유지하고, 장 마감·자정·재시작을 넘어도 청산되지 않는다.
• 중장기 전략 모듈이 하루 1회 trex.slots.req 로 보유 현황을 읽고 리밸런싱 sell/buy intent 를 발신 → watchdog 가 이를 비정상으로 오인하지 않는다.
• 보유 중 종목이 손절 기준을 하회 → (코어 규칙 제공 시) 멀티데이 stop-loss 가 발화하거나, (전략 책임 시) 전략 모듈이 sell intent 로 청산한다 — 어느 쪽인지 정책이 명확하다.
• 당일 인스턴스와 중장기 인스턴스가 같은 PostgreSQL·RabbitMQ 인프라에서 병행 운영되어도 슬롯·큐·정책이 간섭하지 않는다.

4. 이번에 정의할 변경

• 구현 위치 판정 — 이슈 OQ-1 을 현행 영구 슬롯 모델 기준으로 재평가: (a′) 기존 슬롯 도메인 그대로 + 중장기 운영 프로파일/리스크 규칙 추가(현행 토대 활용, 유력) vs (a) 신규 PositionBook 도메인 병렬 추가(이슈 원안) vs (c) 별도 레포(이슈가 이미 비권장). 판정 결과를 REQ 분할의 전제로 확정한다.
• 멀티데이 리스크 규칙 범위 확정 — safety_sell_enabled=false 인스턴스의 보호장치: 멀티데이 stop-loss·트레일링 스톱·타임스톱(forced_close_at 재해석) 중 코어가 제공할 범위 vs 전략 모듈 전적 책임 경계를 결정한다.
• 중장기 인스턴스 운영 프로파일 정의 — 표준 TOML 레시피(safety_sell off·market-close 미설정·watchdog timeout 정책·max_active_slots) + watchdog 의미 재검토(중장기 폴링 주기 대응) + baseline 문서(docs/project-structure.md, docs/runtime-flows.md) 중장기 운영 흐름 갱신.

영향 범위

• 코드 영향:
  • 구현 위치 판정 (a′) 기준: trex_core/runtime/config.py(중장기 프로파일 관련 설정 항목), trex_core/application/safety_sell.py 또는 신규 멀티데이 리스크 워커(규칙 범위 결정에 따름), watchdog timeout per-instance 정책(trex_core/application/watchdog.py + config)
  • 구현 위치 판정 (a) 기준: 신규 도메인 패키지(trex_core/domain/position_book/ 류) + persistence + 워커 — 범위 대폭 확대
  • 당일 경로(domain/slot/, intents.py, execution.py)는 양쪽 모두 불변 목표
• 문서 영향:
  • docs/project-structure.md·docs/runtime-flows.md: 중장기 인스턴스 운영 흐름·프로파일 추가 (baseline 갱신)
  • 신규 REQ 다수 예상(운영 프로파일·리스크 규칙) + REQ-048(TOML 설정)·REQ-034(watchdog) change-req 가능성
• 운영 영향:
  • 신규 instance_key=longterm 데몬 추가 기동(별도 TOML)— 기존 당일 인스턴스 무중단
  • 멀티데이 보유 포지션의 일일 회계·리포트 해석 변화(실현손익은 청산일 귀속)

5. 요구사항 목록

기능 요구사항

• FR-1: 중장기 인스턴스 운영 프로파일을 정의한다 — 표준 TOML 레시피(safety_sell_enabled=false, market-close 미설정, watchdog 정책, max_active_slots)와 기동 검증 절차를 문서화하고 실 데몬으로 확인한다.
• FR-2: safety_sell_enabled=false 인스턴스는 코어 손절매 루틴을 일절 사용하지 않는다. 모든 보호 규칙(stop-loss·트레일링·타임스톱)은 전략 모듈의 전적 책임이며, 코어는 운영자 CLI exit 백스톱만 제공한다. 이 경계를 운영 문서에 명시한다.
• FR-3: watchdog 의 중장기 의미를 재정의한다 — per-instance timeout 설정 또는 중장기 인스턴스 비활성화 옵션 중 확정안을 적용해, 저빈도 폴링 전략이 expired 로 오인되지 않게 한다.
• FR-4: forced_close_at 의 중장기 의미(타임스톱 재해석 vs 미사용)를 확정하고 운영자 CLI·intent 계약 문서에 반영한다.
• FR-5: docs/project-structure.md·docs/runtime-flows.md 에 중장기 인스턴스 운영 구조와 흐름(병행 인스턴스 토폴로지, 프로파일, 리스크 규칙 경로)을 갱신한다.

비기능 요구사항

• NFR-1: 당일 인스턴스 경로 무회귀 — 기존 단위·통합 테스트 전부 green, 당일 운영 TOML 의 동작 변화 0건.
• NFR-2: 인스턴스 간 무간섭 — 중장기 인스턴스의 슬롯·큐·정책 변경이 당일 인스턴스 DB/큐 스코프에 영향을 주지 않음을 통합 테스트로 검증 가능해야 한다.
• NFR-3: 프로파일 설정은 기존 per-instance TOML 메커니즘(REQ-048)을 재사용하고 새 설정 채널을 만들지 않는다.

범위 경계

• In Scope
  • 구현 위치 판정(이슈 OQ-1 재평가) 및 REQ 분할 전제 확정
  • 중장기 인스턴스 운영 프로파일(TOML 레시피 + watchdog 정책 + 기동 검증)
  • 멀티데이 보호 규칙 경계 문서화 — 전략 모듈 전적 책임 + 운영자 CLI exit 백스톱 명시(코어 구현 없음)
  • forced_close_at 중장기 의미 확정
  • baseline 문서(project-structure·runtime-flows) 중장기 운영 갱신
• Out of Scope
  • 중장기 전략 모듈 자체의 구현(별도 저장소/주기 — 코어는 계약·운영 토대만 제공)
  • 포트폴리오 리밸런싱 엔진·목표 비중 관리(전략 모듈 책임)
  • 일일 회계·리포트 체계 개편(현행 ledger 날짜 필터 해석 유지, 필요 시 후속)
  • {{DECIDE_POSITION_BOOK}}: 신규 PositionBook 도메인 신설 — 구현 위치 판정이 (a) 로 결정될 때만 In Scope 로 승격

6. 리스크/가정 목록

리스크

• R-1 (High): 보호장치 경계가 모호한 채 중장기 인스턴스를 운영하면, safety-sell OFF + 전략 모듈 장애 시 손실 포지션이 무기한 방치된다.
  • 완화 방안: 전략 모듈 전적 책임으로 확정(OQ-2). 코어는 운영자 CLI exit 백스톱만 제공. 보호 규칙 공백 위험은 전략 모듈 설계 및 운영 절차(운영자 수동 CLI)로 완화한다.
• R-2 (Medium): 멀티데이 규칙을 기존 safety-sell 워커에 얹으면 당일 경로와 조건 분기가 얽혀 회귀 위험(이슈가 경고한 "분기 폭증")이 생긴다.
  • 완화 방안: 설계 단계에서 별도 워커/서비스 분리를 우선 검토하고, 당일 경로 테스트 전부를 회귀 게이트로 고정한다.
• R-3 (Medium): watchdog 완화가 과도하면 중장기 인스턴스에서 전략 이탈을 영영 감지하지 못한다.
  • 완화 방안: 비활성화 대신 긴 timeout(예: 일 단위) 설정을 기본안으로 검토하고, slots RPC watchdog.last_seen 가시성은 유지한다.
• R-4 (Low): 멀티데이 보유 중 universe 에서 자산이 빠지면(상폐 등) tombstone/retire 경로가 중장기 보유와 충돌할 수 있다.
  • 완화 방안: dcy-020 의 universe-detached holding(tombstone) 경로가 이미 존재 — 중장기 시나리오로 검증 항목에 포함.

가정

• A-1: 현행 영구 자산 슬롯(BAT-027~030)은 멀티데이 보유를 구조적으로 이미 지원한다 — 슬롯 키에 날짜가 없고 holding 이 날 경계·재시작을 넘는다(dcy-020 OQ-3 결정).
• A-2: 중장기 운영은 별도 instance_key 데몬으로 분리한다(이슈 OQ-3 의 권장 방향) — 단일 데몬 내 호라이즌 혼합은 다루지 않는다.
• A-3: 플랫폼 계층(브로커/ledger/transport/slots RPC/CLI)은 변경 없이 공유 가능하다 — 이슈의 재사용 분석 유지.
• A-4: KIS·portfolio-hub·RabbitMQ 인프라를 그대로 사용하므로 별도 레포 분리(이슈 OQ-1 의 (c))는 손해다 — 이슈 분석 수용.

오픈 질문

• OQ-1: 구현 위치 최종 확정 — (a′) 기존 슬롯 도메인 + 프로파일/규칙 추가 vs (a) 신규 PositionBook 도메인 병렬 신설. 현행 영구 슬롯이 멀티데이를 이미 지원하므로 (a′) 가 유력하나, 중장기 전용 수명주기 요구(트레일링 상태, 리밸런싱 이력 등)가 슬롯 도메인을 오염시킬 수준인지 판단 필요.
  • 상태: Answered (2026-06-12, Justin Ko)
  • 결정: (a′) 기존 슬롯 도메인 유지 + 운영 프로파일/규칙 추가. 현행 영구 자산 슬롯이 멀티데이 보유를 구조적으로 이미 지원하므로(날짜 없는 슬롯 키, holding 날 경계 통과) 신규 PositionBook 도메인 신설은 불필요. {{DECIDE_POSITION_BOOK}} 은 Out of Scope 확정.
  • 반영 위치: # 5 범위 경계({{DECIDE_POSITION_BOOK}} Out of Scope 확정), # 10 DECIDE 항목.
• OQ-2: 멀티데이 보호 규칙의 코어 제공 범위 — 멀티데이 stop-loss / 트레일링 스톱 / 타임스톱(forced_close_at 재해석) 중 코어가 구현할 항목과 전략 모듈 전적 책임으로 둘 항목은?
  • 상태: Answered (2026-06-12, Justin Ko)
  • 결정: safety_sell_enabled=false 인스턴스는 코어 손절매 루틴을 일절 사용하지 않는다. stop-loss·트레일링 스톱·타임스톱 등 모든 보호 규칙은 전략 모듈의 전적 책임이다. 코어는 운영자 CLI exit 백스톱(수동 청산)만 제공한다. R-1(방치 위험)은 전략 모듈 설계 책임 + 운영 절차(운영자 CLI) 로 완화한다.
  • 반영 위치: # 5 FR-2(멀티데이 보호 규칙 경계), # 6 R-1 완화 방안 갱신, # 10 DECIDE 항목.
• OQ-3: watchdog 중장기 정책 — per-instance timeout 연장(일 단위) vs 중장기 인스턴스 비활성화 옵션 중 어느 쪽인가?
  • 상태: Answered (2026-06-12, Justin Ko)
  • 결정: per-instance timeout 연장. OQ-4 최대 폴링 주기(10분/600s) 기준으로 per-instance TOML watchdog_timeout_sec 설정을 지원하고, 중장기 인스턴스는 1800초(30분) 이상으로 설정한다. last_seen_at 가시성은 유지한다.
  • 알림 후속 주석: watchdog 소유권 진입(전략 이탈 감지) 시 사용자에게 외부 알림(예: 슬랙·이메일 등)을 발송하는 기능을 추후 별도 Discovery 로 구현할 예정이다. 현재 주기에서는 로그 경고(watchdog ownership entered) 수준으로 유지하고 알림 채널 연동은 범위 밖이다.
  • 반영 위치: # 5 FR-3(watchdog 재정의), # 10 DECIDE 항목.
• OQ-4: 중장기 전략 모듈의 폴링·intent 발신 주기 전제 — 하루 몇 회 슬롯 read/intent 발신을 가정하는가? (watchdog·프로파일 수치의 입력)
  • 상태: Answered (2026-06-12, Justin Ko)
  • 결정: 최소 1분, 최대 10분 주기로 trex.slots.req 호출 및 intent 발신. 빠른 경우 1분 간격, 느린 경우 최대 10분(600s) 간격을 전제.
  • 반영 위치: OQ-3 watchdog timeout 수치 입력 — 10분 폴링 대비 충분한 여유(권장: 30분 이상).

7. 초기 성공 기준

• S-1: instance_key=longterm 프로파일 TOML 로 기동한 데몬에서 매수→day 경계 통과→보유 유지가 확인된다(장 마감·재시작 후에도 holding 유지, 자율 청산 미발화).
• S-2: 확정된 멀티데이 보호 규칙(코어 제공분)이 발화 조건에서 정확히 동작하고, 미제공 영역은 운영 문서에 전략 책임으로 명시된다.
• S-3: 당일 인스턴스 전체 테스트 무회귀 + 중장기 인스턴스와의 무간섭(슬롯·큐 스코프)이 통합 테스트로 검증된다.
• S-4: baseline 문서(project-structure·runtime-flows)에 중장기 운영 구조·흐름이 반영되어 이후 REQ/batch 가 참조 가능하다.

측정 방식 및 데이터 출처

• S-1 측정 방식: 실 데몬 run-the-app 검증 — longterm TOML 기동 후 paper 매수, 시스템 시각/일자 경계 시나리오로 holding 유지 확인 / 데이터 출처: run-trex-core-daemon skill 경로 + 데몬 로그 + trex-core slots
• S-2 측정 방식: 규칙별 단위 테스트(발화/비발화 경계) + paper e2e / 데이터 출처: tests/application/ 신규 테스트
• S-3 측정 방식: pytest 전체 회귀 + instance_key 격리 통합 테스트(기존 test_instance_topology.py 패턴 확장) / 데이터 출처: 로컬/CI 결과
• S-4 측정 방식: baseline 문서 diff 리뷰 — 중장기 흐름 섹션 존재 + 현행 코드와 정합 / 데이터 출처: docs/project-structure.md, docs/runtime-flows.md

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

• 범위(In Scope/Out of Scope) 확정
  • 기준: OQ-1(구현 위치) 확정으로 {{DECIDE_POSITION_BOOK}} In/Out 판정 + OQ-2(보호 규칙 범위) 확정
• 성공 지표의 측정 방식/데이터 출처 확정
  • 기준: OQ-4(전략 폴링 주기) 수치 확보로 S-1/watchdog 검증 수치 구체화
• High 영향 리스크 우선순위 및 해소 책임자 지정
  • 기준: R-1(보호장치 공백) 경계 확정 담당 Justin Ko
• 모든 오픈 질문(OQ) Open 상태 없음 확인
  • 기준: OQ 목록에 Open 상태 항목이 0개이거나, 잔여 항목 전부 Deferred 처리 완료
• Freeze 확정 담당자(CONFIRMED_BY) 지정
  • 기준: Justin Ko 승인 후 confirm-discovery 수행

9. 파일 처리 결과

• 처리 결과: 생성
• 생성 경로: docs/discovery/dcy-027_20260612_long-term-strategy-slot-operation.md
• 참조 문서:
  • GitHub issue #20 — 중장기 슬롯 운영 도입, 호라이즌 결합 분석 + OQ-1~4 (구 pool 모델 기준 — 본 문서 §3 에서 현행 기준 재정렬)
  • docs/discovery/dcy-020_20260610_asset-centric-slot-model.md — 영구 자산 슬롯 토대(Out of Scope 로 본 주기 이월 명시), OQ-3 trading_date 폐기 결정
  • docs/discovery/dcy-024_20260611_safety-sell-disable-mode.md — safety_sell_enabled per-instance TOML ("중장기 보유 인스턴스는 enabled=false" 용도 명시)
  • trex_core/application/safety_sell.py — 당일 전제 보호장치(watchdog-gated stop-loss/forced_close/market-close), 멀티데이 규칙 부재 확인
  • trex_core/runtime/config.py — per-instance TOML(REQ-048)·market_close_liquidation_time·watchdog timeout 설정 현황
  • stage-pilot/templates/project-structure.md, stage-pilot/templates/runtime-flows.md — baseline 갱신 시 논리 템플릿 참조

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

DECIDE

• {{DECIDE_IMPLEMENTATION_LOCATION}}: 구현 위치 — (a′) 기존 슬롯 도메인 + 운영 프로파일/규칙 추가 확정 (OQ-1, 2026-06-12, Justin Ko)
• {{DECIDE_RISK_RULES}}: 멀티데이 보호 규칙 — 전략 모듈 전적 책임 확정. safety_sell_enabled=false 시 코어 손절매 루틴 미제공, 운영자 CLI exit 백스톱만 유지 (OQ-2, 2026-06-12, Justin Ko)
• {{DECIDE_WATCHDOG_POLICY}}: watchdog 중장기 정책 — per-instance timeout 연장 확정 (OQ-3, 2026-06-12, Justin Ko). 알림 연동은 후속 Discovery.
• {{DECIDE_POSITION_BOOK}}: PositionBook 도메인 신설 — Out of Scope 확정 (OQ-1 결정, 2026-06-12, Justin Ko)

CONFIRM

• {{CONFIRM_PARALLEL_INSTANCE}}: 중장기 운영을 별도 instance_key 데몬으로 분리하는 전제(A-2) 승인
• {{CONFIRM_FORCED_CLOSE_SEMANTICS}}: forced_close_at 의 중장기 의미 — 타임스톱 재해석 vs 미사용 (FR-4)

DATA

• {{DATA_STRATEGY_CADENCE}}: 중장기 전략 모듈의 폴링·intent 발신 주기 계획 (OQ-4 — watchdog·프로파일 수치 입력)

11. Discovery Freeze

섹션 참조

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

Freeze 플래그

• Handoff Decision: 보류
• Handoff Rationale: 초기 Discovery 초안 생성 완료. OQ-1(구현 위치)·OQ-2(보호 규칙)·OQ-3(watchdog)·OQ-4(전략 주기) 4건 Open — confirm-discovery 전 사용자 결정 필요.
• Ready for REQ Drafting: false
• Confirmed By: TBD
• Confirmed At (KST): TBD