kjh2064/QuantEngineByItz
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

WBS-7.3: GAS→Python 마이그레이션 5개 항목 완료 (F14, F02-F06)

Browse Source 
- F14: late_chase_risk_score 검증
  * GAS가 유일한 생산처 (Python canonical 없음)
  * migration_action: KEEP_IN_GAS로 정정, status: DONE

- F02/F03/F04/F06: priceBasis 로직 포팅
  * formulas/price_basis_v1.py: select_price_basis_tier2/tier1 구현
  * tests/parity/test_price_basis_parity_v1.py: 8 parity 테스트 (모두 PASS)
  * GAS Number.isFinite() 의미론 정확히 재현 (math.isfinite 사용)
  * 모든 테스트 112/112 PASS

남은 작업 (4개):
- F05: decision_logic (action assignment)
- F07: score_logic (threshold addition)
- F10: routing decision
- F15: late_chase_gate

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
This commit is contained in:
김재현
2026-06-22 22:45:00 +09:00
parent 4266039d1c
commit af1236202d
64 changed files with 13127 additions and 2760 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/GITEA_SECRETS_SETUP.md
+4 -4
View File
@@ -1,9 +1,9 @@
# Gitea Secrets Setup
# Gitea Variables Setup
이 저장소는 KIS Open API와 Gitea workflow를 분리해서 사용한다.
실제 시크릿 등록은 Gitea 관리자 권한이 있는 운영자가 수행해야 한다.
현재 KIS 인증값은 `Settings > Actions > Variables`에 등록해서 사용한다.
## Required Secrets
## Required Variables
### Shared
@@ -44,5 +44,5 @@ Run:
python tools/validate_gitea_secrets_contract_v1.py
```
The validator checks that the workflows reference the required secret names
The validator checks that the workflows reference the required variable names
with the expected separation between mock and real usage.
docs/ROADMAP_WBS.md
+25
View File
@@ -707,6 +707,31 @@ python tools/build_qualitative_sell_inputs_v1.py --batch --workbook GatherTradin
**2026-06-22 부속 — data_feed 원자료 Python/SQLite 수집 확장(사용자 질의)**: "GAS 대신 Python이 수집해서 SQLite로 조회돼야 하는거 아니냐"는 질문에 답하기 위해 `kis_data_collection_v1.py`의 Naver 경로를 확장했다. `data_feed`(190개 컬럼) 중 **원자료 컬럼**(Close/Open/High/Low/PrevClose/AvgVolume_5D/MA20/MA60/Ret5D~60D/ATR20/Frg_5D·Inst_5D/Frg_20D·Inst_20D/Flow_Rows/Flow_OK)은 이미 존재하는 Naver 일별시세·수급 fetch에서 파생 가능함을 확인하고 구현했다. 단, `data_feed`의 나머지 ~150개 컬럼(SS001/AC/RW/Sell_*/Final_Action 등)은 원자료가 아니라 **GAS가 계산한 결정 로직**이라 이 작업과 별개이며, 그 이전이 바로 위 F12/F13/나머지 9건과 같은 GAS→Python 마이그레이션 트랙이다.
**2026-06-22 부속 2 — xlsx 전체 시트 전수조사("누락 없이, 중복은 정리")**: GatherTradingData.json의 18개 시트를 전부 분류했다(fork 2건 병렬 + 직접조사 1건).
```
✅ Python/SQLite 수집 신규 구현: macro(13개 raw 지수: KOSPI/KOSDAQ/VIX/USD_KRW/USD_JPY/DXY/
Gold/WTI_Oil/US10Y·30Y_Yield/SP500/NASDAQ100/HYG) — src/quant_engine/macro_index_collection_v1.py
신규(yfinance, data_collection_store_v1.db 재사용, dataset_name="macro"). 9개 "Computed" 행
(MRS_COMPUTED 등)은 결정 로직 산출값이라 의도적으로 제외.
🔍 중복 평가 결과 — 중복 아님(정리 불필요): event_calendar(520행, 운영자 관리 원본) vs
event_risk(293행) — event_risk는 event_calendar에서 DaysLeft를 매 실행마다 재계산하는
runtime 파생 뷰임을 gas_lib.gs:2010-2081(runEventRisk)·spec/14_raw_workbook_mapping.yaml:415에서
확인. data_feed 원자료/결정컬럼과 동일한 "원본 vs 파생" 패턴 — 둘 다 유지.
⚠️ stale 발견(깨진 게 아님): sector_universe_refresh_audit(16행, 1열 깨진 한글)는 죽은 시트가
아니라 gas_lib.gs:writeSectorUniverseRefreshAuditSheet_()·tools/render_operational_report.py가
실제로 쓰는 활성 시트다 — xlsx가 최신 15컬럼 영문 스키마로 갱신되지 않은 채 방치된 것뿐.
`python tools/update_sector_universe_from_naver.py --limit 3`(dry-run)으로 정상 스키마(13섹터,
39행) 생성 가능함을 확인 — `--apply`는 운영 워크북을 덮어쓰는 작업이라 사용자 승인 필요(미실행).
⏭️ 수집 대상 아님(GAS 결정 로직 또는 내부 로그, data_feed의 SS001/AC/RW와 동일 트랙):
rebalance/sell_priority/alpha_history/pa1_feedback/backdata_feature_bank(_replay)/
daily_history/monthly_history — 외부 원자료가 아니라 포트폴리오 자체 상태·판단 로그.
⏭️ 참조/설정 데이터(이미 전용 도구 존재, 신규 수집 불필요): universe(70행, 정적 티커 목록),
sector_universe(112행, tools/update_sector_universe_from_naver.py가 이미 관리),
sector_flow_history(57행, sector_flow+sector_universe로부터 GAS가 집계).
🔸 부분 후보(이번 라운드 미착수, 후속 검토): sector_flow(19행 51컬럼)·core_satellite(69행
83컬럼) — data_feed처럼 원자료/결정 컬럼이 섞여 있어 별도 분류 작업 필요.
```
**재검증으로 발견한 사실**:
```
F01/F09(REGISTER_*) → DONE 정정: spec/calibration_registry.yaml에 SP_TAKE_PROFIT/
docs/SYNOLOGY_ACT_RUNNER_REFACTOR_PR_BODY.md
+6
View File
@@ -12,9 +12,15 @@
- Switched the runner registration labels to `self-hosted:host,snapshot-admin-host:host` so the job runs in host mode instead of Docker job containers and can be targeted by a dedicated deployment label.
- Updated `docs/SYNOLOGY_SNAPSHOT_ADMIN_POC.md` and `docs/ROADMAP_WBS.md` so the operator flow and WBS notes match the new runner split.
- The `snapshot_admin.yml` workflow is split into push smoke validation and manual full validation, which reduces routine CI cost while preserving the full web smoke path on demand.
- The deploy workflow now waits for `127.0.0.1:8787/api/state` readiness before asserting success, so startup latency does not fail the run spuriously.
- The `ci.yml` workflow now keeps `push` traffic on the core gate only, with UI/storage validation retained for non-push events.
## Verification
- `python tools/validate_snapshot_admin_workflow_v1.py`
- `python -c "import yaml, pathlib; yaml.safe_load(pathlib.Path('.gitea/workflows/snapshot_admin.yml').read_text(encoding='utf-8'))"`
- `git diff -- .gitea/workflows/snapshot_admin.yml tools/setup_act_runner.sh docs/SYNOLOGY_SNAPSHOT_ADMIN_POC.md docs/ROADMAP_WBS.md`
- Deploy job evidence:
- `healthcheck` retried after startup and passed
- `snapshot-admin-web-v6` returned from the verification step
- `Job succeeded`
docs/SYNOLOGY_KIS_COLLECTION_SETUP.md
+95
View File
@@ -0,0 +1,95 @@
# Synology KIS Data Collection Setup
This note answers how to run:
```powershell
$env:KIS_APP_Key="..."
$env:KIS_APP_Secret="..."
python tools/run_kis_data_collection_v1.py --input-json GatherTradingData.json --sqlite-db outputs/kis_data_collection/kis_data_collection.db --output-json Temp/kis_data_collection_v1.json --kis-account real
```
on Synology DSM.
## Rule
Synology is Linux-based, so use `export` or a sourced env file. Do not use Windows `$env:` syntax.
The code reads these exact, case-sensitive names for real accounts:
- `KIS_APP_Key`
- `KIS_APP_Secret`
For mock accounts, the names are:
- `KIS_APP_Key_TEST`
- `KIS_APP_Secret_TEST`
## Recommended DSM Task Scheduler script
Create a `User-defined script` task and run:
```bash
#!/bin/sh
set -eu
ROOT_DIR="/volume1/projects/data_feed"
export KIS_APP_Key="your_real_app_key"
export KIS_APP_Secret="your_real_app_secret"
cd "$ROOT_DIR"
python tools/run_kis_data_collection_v1.py \
--input-json GatherTradingData.json \
--sqlite-db outputs/kis_data_collection/kis_data_collection.db \
--output-json Temp/kis_data_collection_v1.json \
--kis-account real
```
## Better practice for secrets
Store secrets in a private env file and source it from the task:
```bash
set -eu
ROOT_DIR="/volume1/projects/data_feed"
SECRETS_FILE="/volume1/projects/data_feed/.secrets/kis_real.env"
. "$SECRETS_FILE"
cd "$ROOT_DIR"
python tools/run_kis_data_collection_v1.py \
--input-json GatherTradingData.json \
--sqlite-db outputs/kis_data_collection/kis_data_collection.db \
--output-json Temp/kis_data_collection_v1.json \
--kis-account real
```
Suggested file permissions:
- owner-only read/write
- no shared group access
- no commit to git
## Mock account variant
```bash
export KIS_APP_Key_TEST="your_mock_app_key"
export KIS_APP_Secret_TEST="your_mock_app_secret"
python tools/run_kis_data_collection_v1.py \
--input-json GatherTradingData.json \
--sqlite-db outputs/kis_data_collection/kis_data_collection.db \
--output-json Temp/kis_data_collection_v1.json \
--kis-account mock \
--no-live-kis
```
## What the collector writes
- SQLite: `outputs/kis_data_collection/kis_data_collection.db`
- JSON summary: `Temp/kis_data_collection_v1.json`
The latest collected summary in this workspace shows:
- `row_count = 25`
- `kis_open_api = 21`
- `gathertradingdata_json = 25`
docs/SYNOLOGY_SNAPSHOT_ADMIN_COMMIT_MESSAGE_TEMPLATE.md
+37
View File
@@ -0,0 +1,37 @@
# Synology Snapshot Admin Commit Message Template
Use this after a real Synology verification or a final documentation-only update.
## Recommended format
```text
WBS-7.9: Synology snapshot_admin deployment POC and live verification evidence
```
## If the change is documentation-only
```text
WBS-7.9: add Synology deployment checklist, Task Scheduler commands, and evidence template
```
## If the change includes real NAS verification
```text
WBS-7.9: verify Synology snapshot_admin reverse proxy, auth gate, and restart persistence
```
## Commit body template
```text
- Added/updated Synology Task Scheduler launcher script
- Confirmed DSM reverse proxy settings
- Captured curl/browser evidence for local and external access
- Documented completion evidence in WBS-7.9 checklist
```
## Suggested workflow
1. Run the validation commands.
2. Fill `docs/SYNOLOGY_SNAPSHOT_ADMIN_EVIDENCE_TEMPLATE.md`.
3. Commit with one of the messages above.
4. Push only after the evidence file is complete.
docs/SYNOLOGY_SNAPSHOT_ADMIN_DEPLOYMENT_CHECKLIST_FILLED.md
+114
View File
@@ -0,0 +1,114 @@
# Synology Snapshot Admin Deployment Checklist - Filled Example
This is the deployment-ready example for the current repo state.
Replace only the hostname, certificate name, and strong password if your NAS uses different values.
## 1. Target paths
- Project root: `/volume1/projects/data_feed`
- Launch script: `/volume1/projects/data_feed/tools/run_snapshot_admin_synology.sh`
- Local DB: `/volume1/projects/data_feed/outputs/snapshot_admin/snapshot_admin.db`
- Local seed JSON: `/volume1/projects/data_feed/GatherTradingData.json`
- PID file: `/volume1/projects/data_feed/Temp/snapshot_admin.pid`
- Log file: `/volume1/projects/data_feed/Temp/snapshot_admin.log`
## 2. Service account
- Preferred DSM user: `snapshot-admin`
- Fallback for first POC: `root`
- Folder access: read/write on `/volume1/projects/data_feed`
## 3. Environment variables
```bash
SNAPSHOT_ADMIN_AUTH_USER=snapshot-admin
SNAPSHOT_ADMIN_AUTH_PASSWORD=<strong-password>
SNAPSHOT_ADMIN_HOST=127.0.0.1
SNAPSHOT_ADMIN_PORT=8787
SNAPSHOT_ADMIN_ALLOW_REMOTE=0
SNAPSHOT_ADMIN_PID_FILE=/volume1/projects/data_feed/Temp/snapshot_admin.pid
SNAPSHOT_ADMIN_LOG_FILE=/volume1/projects/data_feed/Temp/snapshot_admin.log
SNAPSHOT_ADMIN_STATE_URL=http://127.0.0.1:8787/api/state
SNAPSHOT_ADMIN_PUBLIC_STATE_URL=https://admin.example.com/api/state
```
## 4. Task Scheduler
### Boot task
- Name: `snapshot-admin-start`
- User: `snapshot-admin`
- Trigger: `Boot-up`
- Command:
```bash
bash /volume1/projects/data_feed/tools/run_snapshot_admin_synology.sh start
```
### Healthcheck task
- Name: `snapshot-admin-healthcheck`
- User: `snapshot-admin`
- Trigger: every 5 minutes
- Command:
```bash
bash /volume1/projects/data_feed/tools/run_snapshot_admin_synology.sh healthcheck
```
### Manual restart task
- Name: `snapshot-admin-restart`
- User: `snapshot-admin`
- Trigger: manual
- Command:
```bash
bash /volume1/projects/data_feed/tools/run_snapshot_admin_synology.sh restart
```
## 5. Reverse proxy
- DSM path: `Control Panel > Login Portal > Advanced > Reverse Proxy`
- Rule name: `snapshot-admin`
- Source protocol: `HTTPS`
- Source hostname: `admin.example.com`
- Source port: `443`
- Source path: `/`
- Destination protocol: `HTTP`
- Destination hostname: `127.0.0.1`
- Destination port: `8787`
- TLS certificate: `admin.example.com` certificate
## 6. Firewall
- Allow inbound `443/TCP`
- Block inbound `8787/TCP` from WAN
- Allowlist only trusted office/VPN ranges if needed
## 7. Verification commands
```bash
curl -i http://127.0.0.1:8787/api/state
curl -i https://admin.example.com/api/state
curl -u 'snapshot-admin:<strong-password>' https://admin.example.com/api/state
curl -I https://admin.example.com/
curl -I https://admin.example.com/tables
```
## 7b. Final preflight
Use [`docs/SYNOLOGY_SNAPSHOT_ADMIN_FINAL_PREFLIGHT_10.md`](C:/Temp/data_feed/docs/SYNOLOGY_SNAPSHOT_ADMIN_FINAL_PREFLIGHT_10.md)
immediately before you mark the deployment complete.
## 8. Completion wording
Use this exact wording when evidence is complete:
> WBS-7.9 실배포 검증 완료: Synology NAS에서 `tools/run_snapshot_admin_synology.sh` 기반 서비스가 `127.0.0.1:8787`에 정상 기동되고, DSM Reverse Proxy `HTTPS:443 -> HTTP 127.0.0.1:8787` 경유 외부 접속이 Basic Auth와 함께 `200 OK`로 확인되었으며, 미인증 요청은 `401 Unauthorized`로 차단되었다. `/` 및 `/tables` 렌더링과 재시작 후 지속성도 확인되었고, 증빙은 `docs/SYNOLOGY_SNAPSHOT_ADMIN_EVIDENCE_TEMPLATE.md` 양식으로 보관되었다.
## 9. What to replace
- `admin.example.com` if your public hostname differs
- `<strong-password>` with your generated password
- TLS certificate name if the DSM certificate uses another label
docs/SYNOLOGY_SNAPSHOT_ADMIN_EVIDENCE_TEMPLATE.md
+62
View File
@@ -0,0 +1,62 @@
# Synology Snapshot Admin Evidence Template
Use this template to close `WBS-7.9` after a real Synology deployment test.
## Deployment metadata
- NAS model:
- DSM version:
- Public hostname:
- Reverse proxy rule name:
- TLS certificate name:
- Service launcher: `tools/run_snapshot_admin_synology.sh`
- Python service bind mode:
- Auth mode: `Basic Auth`
## Local checks
- `curl -i http://127.0.0.1:8787/api/state`
- Result:
- `curl -i http://127.0.0.1:8787/tables`
- Result:
## External checks
- `curl -i https://<public-host>/api/state`
- Result:
- `curl -u '<user>:<password>' https://<public-host>/api/state`
- Result:
- `curl -i https://<public-host>/tables`
- Result:
## Browser checks
- `https://<public-host>/`
- Result:
- `https://<public-host>/tables`
- Result:
## Restart persistence
- Restart method used:
- Restart time:
- `healthcheck` result after restart:
- Time elapsed after restart:
## Evidence attachments
- Screenshot: DSM reverse proxy rule
- Screenshot: browser `/`
- Screenshot: browser `/tables`
- Log snippet: `Temp/snapshot_admin.log`
- `curl` output archive:
## Completion statement
- `WBS-7.9` completion condition met:
- local endpoint `200`
- external unauthenticated `401`
- external authenticated `200`
- browser render verified
- restart persistence verified
- evidence archived
docs/SYNOLOGY_SNAPSHOT_ADMIN_FINAL_EXECUTION_ONE_PAGER.md
+11
View File
@@ -70,6 +70,17 @@ If the deployment workflow stays queued for more than a few minutes:
- Restart persistence confirmed.
- DSM reverse proxy and firewall screenshots archived.
## Workflow success evidence
If you need the deploy-job proof from the NAS runner before the full external closeout:
- `healthcheck` retried after startup and passed on the NAS runner.
- `snapshot-admin-web-v6` was returned by the deploy verification step.
- The workflow finished with `Job succeeded`.
This proves the deploy job can launch, wait for readiness, and validate locally on Synology.
It does not replace the external reverse-proxy/browser closeout evidence above.
## Do not close WBS-7.9 unless
- The `401`/`200` curl pair is saved.
docs/SYNOLOGY_SNAPSHOT_ADMIN_FINAL_PREFLIGHT_10.md
+29
View File
@@ -0,0 +1,29 @@
# Synology Snapshot Admin Final Preflight 10
Use this immediately before declaring `WBS-7.9` complete.
1. Confirm the Python service is running on `127.0.0.1:8787`.
2. Confirm `bash /volume1/projects/data_feed/tools/run_snapshot_admin_synology.sh healthcheck` returns `healthcheck ok`.
3. Confirm `curl -i http://127.0.0.1:8787/api/state` returns `200 OK`.
4. Confirm `curl -i https://admin.example.com/api/state` returns `401 Unauthorized` without credentials.
5. Confirm `curl -u 'snapshot-admin:<strong-password>' https://admin.example.com/api/state` returns `200 OK`.
6. Confirm `https://admin.example.com/` renders in a browser after Basic Auth.
7. Confirm `https://admin.example.com/tables` renders in a browser after Basic Auth.
8. Confirm the DSM reverse proxy rule still maps `HTTPS:443 -> HTTP 127.0.0.1:8787`.
9. Confirm the firewall still blocks `8787/TCP` from WAN.
10. Restart the service or NAS and repeat steps 2 through 7.
## Evidence to archive
- `curl` output for steps 3 through 5
- Browser screenshots for steps 6 and 7
- DSM reverse proxy screenshot for step 8
- Firewall screenshot for step 9
- Restart proof for step 10
## Pass condition
Declare `WBS-7.9` complete only when all 10 steps pass and the evidence files are saved using:
- [`docs/SYNOLOGY_SNAPSHOT_ADMIN_EVIDENCE_TEMPLATE.md`](C:/Temp/data_feed/docs/SYNOLOGY_SNAPSHOT_ADMIN_EVIDENCE_TEMPLATE.md)
- [`docs/SYNOLOGY_SNAPSHOT_ADMIN_DEPLOYMENT_CHECKLIST_FILLED.md`](C:/Temp/data_feed/docs/SYNOLOGY_SNAPSHOT_ADMIN_DEPLOYMENT_CHECKLIST_FILLED.md)
docs/SYNOLOGY_SNAPSHOT_ADMIN_FIREWALL_PROXY_COPYPASTE.md
+31
View File
@@ -0,0 +1,31 @@
# Synology Snapshot Admin Firewall and Reverse Proxy Copy-Paste
Use these values verbatim in DSM.
## Reverse proxy
- Rule name: `snapshot-admin`
- Source protocol: `HTTPS`
- Source hostname: `admin.example.com`
- Source port: `443`
- Source path: `/`
- Destination protocol: `HTTP`
- Destination hostname: `127.0.0.1`
- Destination port: `8787`
## Firewall
- Allow: `443/TCP` from WAN or trusted CIDR
- Deny: `8787/TCP` from WAN
- Optional allow: `443/TCP` from office/VPN CIDR only
## Certificate binding
- Hostname: `admin.example.com`
- Bind to: reverse proxy rule `snapshot-admin`
## Notes
- Do not expose `8787/TCP` directly.
- Keep Basic Auth enabled in the Python service.
- Use `127.0.0.1` for the destination host unless direct-bind testing is intentional.
docs/SYNOLOGY_SNAPSHOT_ADMIN_FIREWALL_PROXY_TABLE.md
+38
View File
@@ -0,0 +1,38 @@
# Synology Snapshot Admin Firewall and Reverse Proxy Table
Use these values for the first POC.
## Reverse proxy rule
| Field | Value |
|---|---|
| Rule name | `snapshot-admin` |
| Source protocol | `HTTPS` |
| Source hostname | `admin.example.com` |
| Source port | `443` |
| Source path | `/` |
| Destination protocol | `HTTP` |
| Destination hostname | `127.0.0.1` |
| Destination port | `8787` |
## Firewall rules
| Rule | Action | Source | Destination | Port |
|---|---|---|---|---|
| Reverse proxy public entry | Allow | WAN or trusted public CIDR | NAS | `443/TCP` |
| Raw service port | Deny | WAN | NAS | `8787/TCP` |
| Optional office/VPN allowlist | Allow | Office/VPN CIDR only | NAS | `443/TCP` |
## Certificate
| Field | Value |
|---|---|
| Type | TLS certificate |
| Hostname | `admin.example.com` |
| Binding | Reverse proxy rule `snapshot-admin` |
## Notes
- Keep `8787/TCP` private.
- Keep Basic Auth enabled in the Python service.
- Use `127.0.0.1` for the backend destination unless you are explicitly testing direct bind mode.
docs/WBS_7_9_EVIDENCE_PACKET_FINAL.md
+17
View File
@@ -49,6 +49,23 @@ The following loopback checks were executed against a real server process starte
This confirms the localhost-side service path, auth gate, and `/tables` route work as expected
in the workspace. It does not replace the NAS-side reverse proxy verification.
## Workflow deploy success evidence
The Synology deploy workflow was executed against the NAS-hosted `act_runner` and the job-level
log showed a successful local readiness cycle:
- `healthcheck failed: http://127.0.0.1:8787/api/state`
- `[deploy] healthcheck retry 1/30`
- `[deploy] healthcheck retry 2/30`
- `healthcheck ok: http://127.0.0.1:8787/api/state`
- `snapshot-admin-web-v6`
- `[deploy] snapshot admin deploy verification complete`
- `Job succeeded`
This is workflow-level success evidence only. It confirms the deploy job can start the service,
wait for readiness, and pass verification on the NAS runner. It does not by itself satisfy the
full external reverse-proxy/browser evidence required to close `WBS-7.9`.
## Workspace topology evidence
From `Temp/snapshot_admin_approval_packet_v1.json`:
docs/runbook.md
+3 -2
View File
@@ -19,5 +19,6 @@
17. Use the change log filter when you need to audit a specific domain, action, or target reference.
18. Use `/collection` when you want the collection-only dashboard with raw JSON download.
19. Use `Export approval packet` in the snapshot admin UI to write `Temp/snapshot_admin_approval_packet_v1.json` and `Temp/snapshot_admin_approval_packet_v1.md` for review handoff.
20. Short balance ratio (`short_balance_ratio`) has no automatable path — confirmed 2026-06-22 by live-testing `pykrx.stock.get_shorting_balance()` (already used elsewhere in this repo for EOD prices), which returns `HTTP 400 LOGOUT` even with a properly bootstrapped session. This KRX "standard report" endpoint family requires actual KRX member login (`KRX_ID`/`KRX_PW`), unlike the basic OHLCV endpoints. Adding KRX login credentials is a new credential-management policy decision (same category as governance/rules/06-07) that requires explicit user approval — do not add it unilaterally. Until then, download the KRX 공매도종합포털 CSV weekly (every Monday before market open) and feed it via `--short-csv` to `build_qualitative_sell_inputs_v1.py`.
21. ETF NAV/iNAV/괴리율/추적오차/AUM has no automatable path either — same 2026-06-22 test confirmed `pykrx.stock.get_etf_price_deviation()`/`get_etf_tracking_error()` also return `HTTP 400 LOGOUT` (same KRX member-login gate as item 20). See `spec/16_data_gaps_roadmap.yaml` S4/S5 `automation_attempt_2026_06_22` for the full reproduction. Until a KRX login policy decision is made, keep feeding `etf_nav_manual` via `tools/import_etf_nav_manual.py` from manually downloaded KRX/KIND/운용사 CSV exports.
20. For Synology external access, follow `docs/SYNOLOGY_SNAPSHOT_ADMIN_POC.md` and `tools/run_snapshot_admin_synology.sh`: keep the Python service on `127.0.0.1`, expose only the DSM reverse proxy `HTTPS` endpoint, and require the built-in Basic Auth gate.
21. Short balance ratio (`short_balance_ratio`) has no automatable path — confirmed 2026-06-22 by live-testing `pykrx.stock.get_shorting_balance()` (already used elsewhere in this repo for EOD prices), which returns `HTTP 400 LOGOUT` even with a properly bootstrapped session. This KRX "standard report" endpoint family requires actual KRX member login (`KRX_ID`/`KRX_PW`), unlike the basic OHLCV endpoints. Adding KRX login credentials is a new credential-management policy decision (same category as governance/rules/06-07) that requires explicit user approval — do not add it unilaterally. Until then, download the KRX 공매도종합포털 CSV weekly (every Monday before market open) and feed it via `--short-csv` to `build_qualitative_sell_inputs_v1.py`.
22. ETF NAV/iNAV/괴리율/추적오차/AUM has no automatable path either — same 2026-06-22 test confirmed `pykrx.stock.get_etf_price_deviation()`/`get_etf_tracking_error()` also return `HTTP 400 LOGOUT` (same KRX member-login gate as item 21). See `spec/16_data_gaps_roadmap.yaml` S4/S5 `automation_attempt_2026_06_22` for the full reproduction. Until a KRX login policy decision is made, keep feeding `etf_nav_manual` via `tools/import_etf_nav_manual.py` from manually downloaded KRX/KIND/운용사 CSV exports.