You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
I Luk Kim 2395a0c0c3 feat: PEAD mid-cap strategy + pipeline hardening + README cleanup
- Implement PEAD 7% Long+Short strategy with mid-cap universe expansion
- Add Stock Oracle screener/company clients, text sentiment features
- Enhance backtest engine: short-side execution, walk-forward CV, MFE/MAE analysis
- Harden pipeline: sequential Oracle API calls, scoring recalibration (event_quality 65%)
- Add experiment configs for 60+ strategy variants and journal tracking
- Add review/analysis CLI tools
- Remove obsolete dev/phase0-4 design documents and analysis scripts
- Clean README to reflect only implemented features (remove unbuilt adapters/engines)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
5 months ago
..
README.md feat: PEAD mid-cap strategy + pipeline hardening + README cleanup 5 months ago
implementation_plan.md feat: PEAD mid-cap strategy + pipeline hardening + README cleanup 5 months ago
ingestion_architecture.md feat: PEAD mid-cap strategy + pipeline hardening + README cleanup 5 months ago
job_catalog.md feat: PEAD mid-cap strategy + pipeline hardening + README cleanup 5 months ago
operator_runbook.md feat: PEAD mid-cap strategy + pipeline hardening + README cleanup 5 months ago
orchestration_and_scheduling.md feat: PEAD mid-cap strategy + pipeline hardening + README cleanup 5 months ago
source_adapter_specs.md feat: PEAD mid-cap strategy + pipeline hardening + README cleanup 5 months ago
storage_layout_and_data_contracts.md feat: PEAD mid-cap strategy + pipeline hardening + README cleanup 5 months ago
testing_checklist.md feat: PEAD mid-cap strategy + pipeline hardening + README cleanup 5 months ago

README.md

Phase 2 개발문서 패키지

이 문서는 Phase 0에서 고정한 전략/리스크/데이터 정책Phase 1에서 고정한 저장소 구조/DB/서비스 계약을 바탕으로, AI 코딩 에이전트가 실제 데이터 수집 파이프라인을 구현할 수 있도록 만든 Phase 2 상세 개발문서입니다.

목표

Phase 2의 목표는 아래 6가지를 실제 코드 수준으로 구현하는 것입니다.

  1. 핵심 무료 데이터 소스 수집기(SEC / Alpaca / FRED / FINRA)를 안정적으로 구현한다.
  2. raw → staging → structured 적재 경로를 완성한다.
  3. 스케줄링, 재시도, 백필(backfill), 재처리(replay) 규칙을 표준화한다.
  4. 데이터 품질 검증 규칙과 장애 대응 기준을 고정한다.
  5. 운영 로그, 작업 이력, 중복 방지, 체크포인트를 구현한다.
  6. Phase 3의 parser/feature builder가 그대로 붙을 수 있는 ingestion contract를 제공한다.

포함 문서

  • ingestion_architecture.md
    • Phase 2 전체 아키텍처
    • raw/staging/structured 흐름
    • 수집기/정규화기/적재기의 경계
    • 체크포인트와 재시도 구조
  • source_adapter_specs.md
    • SEC / Alpaca / FRED / FINRA adapter 상세 명세
    • 입력/출력/예외/체크포인트 규칙
    • rate limit / retry / idempotency 정책
  • storage_layout_and_data_contracts.md
    • 파일 경로 규칙
    • Raw sidecar 메타데이터 규격
    • Structured write 규칙
    • canonical record 정의
  • orchestration_and_scheduling.md
    • 작업 스케줄
    • 백필 방식
    • replay 정책
    • 실패/복구 흐름
  • implementation_plan.md
    • AI 코딩 에이전트용 작업 순서
    • 단위 작업 분할
    • 완료 조건
    • 금지사항
  • testing_checklist.md
    • 단위 테스트
    • 통합 테스트
    • 리플레이 테스트
    • 운영 전 점검표
  • operator_runbook.md
    • 수집기 운영 규칙
    • 장애 대응 절차
    • 일일 점검 항목
    • 데이터 이상 시 조치 순서
  • job_catalog.md
    • 각 배치 작업의 이름, 책임, 입력, 출력, 실행 시점
    • CLI/cron 예시

Phase 2 범위

Phase 2에서는 아래까지만 구현합니다.

  • 핵심 4개 무료 데이터 소스 수집기
  • raw archive 저장
  • staging 정규화 결과 저장
  • structured write
  • 작업 이력/상태/로그 기록
  • 재시도/백필/replay
  • 데이터 품질 검증
  • 최소 운영 runbook

Phase 2에서 일부러 하지 않는 것

  • 본격적인 event scoring
  • LLM 기반 문서 해석 고도화
  • attention layer(YouTube / Yahoo / Wikimedia) 구현
  • 실거래 주문 엔진
  • 포트폴리오 최적화
  • UI 대시보드

권장 실행 순서

  1. ingestion_architecture.md 읽기
  2. storage_layout_and_data_contracts.md 읽기
  3. source_adapter_specs.md 기준으로 adapter 구현
  4. orchestration_and_scheduling.md 기준으로 잡 스케줄 작성
  5. job_catalog.md 기준으로 CLI entrypoint 정리
  6. implementation_plan.md 순서대로 구현
  7. testing_checklist.md로 검증
  8. operator_runbook.md로 운영 절차 확인

완료 기준

Phase 2 종료 시 아래가 가능해야 합니다.

  • 특정 거래일 범위에 대해 SEC / Alpaca / FRED / FINRA 데이터를 백필할 수 있다.
  • 동일 잡을 여러 번 실행해도 중복 적재가 발생하지 않는다.
  • raw 저장 성공 전에는 downstream structured write가 일어나지 않는다.
  • 실패한 잡을 안전하게 재시도할 수 있다.
  • staging/structured 데이터가 canonical schema를 만족한다.
  • 각 source별 체크포인트가 기록되고 다음 실행이 이어진다.
  • 운영자가 runbook만 보고 장애를 재현/복구할 수 있다.