요구(회사별 앵커링 값 업데이트 리스트업 + 이전 값 판별)는 rate_adjustments 한 행에 anchor_rate_before→after 가 박제되어 이미 충족 — 신규 테이블은 동일 정보의 사본만 만들므로 기각하고, 조회를 제품화하는 파생 뷰로 해결: - anchoring.rate_history: 값 변경 이력 리스트업(이전→새 값, delta_permille, success_rate, created_at) - anchoring.current_rates: 칸별 현재값(최신 조정 행 — 없는 칸 = 시작값 10‰) 뷰는 상태가 없어 오염·재구축 이슈 자체가 없고 append-only 보호 대상 아님. 통합 테스트에 뷰 검증 추가(이력 before/after·성공률, 현재값). 운영 문서 §8 쿼리를 뷰 기반으로 단순화, TODO 과제 2 종결(대시보드 페이징 요구 시 스냅샷 테이블 승격 재검토 명시). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1.8 KiB
1.8 KiB
TODO — 앵커링 모듈 후속 과제
남은 과제는 정책 재확정 + 스펙(v1.3) 개정 사안이다. 현재 규범(
docs/개발용.md§12)은 정적 테이블 변경·파라미터 조정을 봉인하고 있으므로, 착수 전 정책 확정 → 문서 개정 → 구현 순서를 지킨다. 운영 데이터(조정 이력)가 쌓이기 전에 확정하는 것이 가장 저렴하다 — negodata 적용 전이 적기.
1. 정적 기본 테이블의 가격구간을 계단식으로 재설계 ✅ 완료 (2026-07-02)
자릿수 계단식 사다리(46칸)로 확정·구현 완료. 폭 = 구간 상한의 10%(선행 자릿수 밴드):
[0, 1,000) 통일 1칸 + 자릿수(1천~1억, 5개)당 9칸 — "1천 원대·2천 원대 … 9천만 원대".
1억 초과는 마지막 인덱스(45) 클램프. 사다리 단일 소스 = constants.UPPER_BOUNDS,
산식 = bisect_right. 조정 이력 0건 시점에 적용해 마이그레이션 없음.
상세: docs/개발용.md §2·§4.1.
2. anchoring_records — 회사별 앵커링 값 전체 조회 테이블 ✅ 뷰로 종결 (2026-07-02)
anchoring_records — 회사별 앵커링 값 전체 조회 테이블신규 테이블 없이 조회용 뷰 2개로 해결. 요구(회사별 값 업데이트 리스트업 + 이전 값 판별)는
rate_adjustments 한 행에 before→after 가 박제되어 있어 이미 충족 — 테이블 추가는 사본만 만든다고
판단해 기각하고, 조회를 제품화하는 뷰를 추가했다:
anchoring.rate_history— 회사별 값 변경 이력(이전→새 값, 변화폭, 성공률, 시각)anchoring.current_rates— 칸별 현재값(없는 칸 = 시작값 10‰)
상세: docs/개발용.md §6.3, 사용법: docs/운영및유지보수.md §8.
추후 대시보드에서 "전체 칸 나열(무조정 칸 포함)·페이징" 요구가 생기면 그때 스냅샷 테이블로 승격을 재검토한다.