trex-core

40 Commits 1 Branch 11 Tags

2 Commits

Include renames

Author SHA1 Message Date

Author	SHA1	Message	Date
genichinandClaude Opus 4.8	c8174e8bb6	docs(release): REL-001 released → feedback-captured (BAT-001~008 released) 운영자(Hermes Agent) 실 환경 배포 evidence(revision `71faa23`, host 86ba33f2997a, broker=kis LIVE, 2026-06-06T11:18:16Z) 반영: - Release Execution Evidence 기재(배포 facts + app-service profile checks + 동일 revision `71faa23` pre-deploy 게이트 재현 보강). - Rollback Outcome 의미 정정: 운영자 보고 "rollback yes"는 배포 롤백이 아니라 휴장일(현충일) KIS 거절에 따른 slot pending_buy→idle 정상 복구(매수 거부 경로 smoke 성공). - capture-release-feedback: release feedback-captured 전환, 포함 batch BAT-001~008 released 전환. - 잔여(차기 거래일 실증): ledger flush(fill→ledger), 마이그레이션 명시 로그, 포지션 정합/warning 마스킹 결과 로그 — Feedback Handoff 기록. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-07 00:26:08 +09:00
genichinandClaude Opus 4.8	ac6061f510	Deliver BAT-005: KIS token Redis cache (REQ-016, minor-change) Port the trex-orbit Redis token-cache pattern so the KIS access token survives daemon restarts and is shared across processes, avoiding KIS token-issuance rate limits. KISBroker._ensure_token now resolves L1 in-memory -> L2 cache -> issue, storing issued tokens back to the cache. - adapters/broker/token_cache.py: TokenCache protocol + RedisTokenCache (key trex:broker:kis:{account_ref}:token, token+expiry+app_key suffix JSON, ex=ttl, best-effort with graceful fallback) + InMemoryTokenCache. - kis.py: optional token_cache injection. - runtime config/daemon: TREX_KIS_REDIS_URL wires a RedisTokenCache. - pyproject: redis>=5. Verification: 96 passed, ruff clean — cache hit avoids issuance, cache is shared across instances (restart/multi-process survival), backend errors fall back to issuance (no regression), and app_key-suffix mismatch invalidates a stale cache. Tested deterministically with an in-memory double (no Redis server required). Processed via the minor-change fast path: REQ-016 -> Implemented, BAT-005 (batch-lite) -> release-candidate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-04 18:44:09 +09:00

genichinandClaude Opus 4.8

c8174e8bb6

docs(release): REL-001 released → feedback-captured (BAT-001~008 released)

운영자(Hermes Agent) 실 환경 배포 evidence(revision 71faa23, host 86ba33f2997a,
broker=kis LIVE, 2026-06-06T11:18:16Z) 반영:
- Release Execution Evidence 기재(배포 facts + app-service profile checks +
  동일 revision 71faa23 pre-deploy 게이트 재현 보강).
- Rollback Outcome 의미 정정: 운영자 보고 "rollback yes"는 배포 롤백이 아니라
  휴장일(현충일) KIS 거절에 따른 slot pending_buy→idle 정상 복구(매수 거부 경로 smoke 성공).
- capture-release-feedback: release feedback-captured 전환,
  포함 batch BAT-001~008 released 전환.
- 잔여(차기 거래일 실증): ledger flush(fill→ledger), 마이그레이션 명시 로그,
  포지션 정합/warning 마스킹 결과 로그 — Feedback Handoff 기록.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-07 00:26:08 +09:00

genichinandClaude Opus 4.8

ac6061f510

Deliver BAT-005: KIS token Redis cache (REQ-016, minor-change)

Port the trex-orbit Redis token-cache pattern so the KIS access token
survives daemon restarts and is shared across processes, avoiding KIS
token-issuance rate limits. KISBroker._ensure_token now resolves L1
in-memory -> L2 cache -> issue, storing issued tokens back to the cache.

- adapters/broker/token_cache.py: TokenCache protocol + RedisTokenCache
  (key trex:broker:kis:{account_ref}:token, token+expiry+app_key suffix
  JSON, ex=ttl, best-effort with graceful fallback) + InMemoryTokenCache.
- kis.py: optional token_cache injection.
- runtime config/daemon: TREX_KIS_REDIS_URL wires a RedisTokenCache.
- pyproject: redis>=5.

Verification: 96 passed, ruff clean — cache hit avoids issuance, cache is
shared across instances (restart/multi-process survival), backend errors
fall back to issuance (no regression), and app_key-suffix mismatch
invalidates a stale cache. Tested deterministically with an in-memory
double (no Redis server required). Processed via the minor-change fast
path: REQ-016 -> Implemented, BAT-005 (batch-lite) -> release-candidate.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-04 18:44:09 +09:00