Silver HITL Policy

HITL 은 다음 3 조건 중 하나 를 만족할 때만 유지한다. 나머지는 자동화하거나 배치 검토로 이연한다.

1. Irreversible — structural 변경, policy 영구 수정 (돌이키는 비용 > 개입 비용)
2. Auto-resolver 실패 — 결정론적·통계적 처리가 먼저 시도되고, 결과가 불확실할 때만 사람에게 넘김
3. Trust boundary crossing — 새 domain / provider / skeleton 등록

이 3 조건은 테스트 질문 으로 쓴다. 새 HITL 을 추가하자는 제안이 나오면 "이 중 어느 조건에 해당하는가?" 를 물어 답이 없으면 거부한다.

Bronze HITL → Silver HITL 매핑 (§14.2 verbatim)

A/B/C 의 제거가 가능한 근본 이유는 plan/collect/integrate 결과는 다음 cycle 에서 critique 가 처방으로 교정한다는 점이다. critique 가 inner loop 의 자동 governance 라면, 매 cycle HITL 은 중복이며 운영 비용만 발생시킨다.

Silver v2 HITL 4 세트 (§14.3 verbatim)

HITL-E 트리거 조건 (5 항, 모두 OR)

should_pause = (
    metrics["collect_failure_rate"] > 0.3
    or metrics["conflict_rate"]      > 0.4
    or metrics["fetch_failure_rate"] > 0.5
    or state.get("cost_regression_flag") is True
    or len(state["dispute_queue"])    > 20
)

이 5 개는 metrics_guard.py 에 명시 — warning-only 가 아니라 실제 graph interrupt 로 연결한다.

효과

• 일반 cycle = 100% 자동 진행 — HITL-S / HITL-R 는 cycle 내부가 아니라 경계 이벤트
• 운영자 개입 빈도: cycle 당 34 회 → **Phase 당 23 회 + 예외 시**
• HITL-D 의 배치 검토는 P5 대시보드의 핵심 view 로 승격 (R10 리스크 연결)

Graph 변경 절차 (P0-C)

변경 전 (Bronze)

# graph.py — 인라인 HITL 3개
g.add_edge("plan", "hitl_a")
g.add_edge("hitl_a", "collect")
g.add_edge("collect", "hitl_b")
g.add_edge("hitl_b", "integrate")
g.add_edge("integrate", "hitl_c")
g.add_edge("hitl_c", "critique")

변경 후 (Silver)

# graph.py — A/B/C 제거, S/R/E 재배치
g.add_edge("seed", "hitl_s")          # phase 첫 cycle 1회만
g.add_conditional_edges("hitl_s", route_after_seed)  # approved → plan, rejected → END

g.add_edge("plan", "collect")          # ← 직결
g.add_edge("collect", "integrate")     # ← 직결
g.add_edge("integrate", "critique")    # ← 직결

g.add_conditional_edges(
    "critique", route_after_critique,  # → plan_modify | audit | END
)

# Outer loop (P2)
g.add_edge("audit", "remodel")
g.add_edge("remodel", "hitl_r")
g.add_conditional_edges("hitl_r", route_after_remodel)  # approved → phase_bump, rejected → plan_modify

# Exception 분기 (모든 노드 후 공통)
g.add_conditional_edges(
    "integrate", route_to_hitl_e_if_breach,
)
g.add_conditional_edges(
    "collect", route_to_hitl_e_if_breach,
)

route_to_hitl_e_if_breach 공통 함수

def route_to_hitl_e_if_breach(state: EvolverState) -> Literal["hitl_e", "next"]:
    m = state["metrics"]
    breach = (
        m.get("collect_failure_rate", 0) > 0.3
        or m.get("conflict_rate", 0) > 0.4
        or m.get("fetch_failure_rate", 0) > 0.5
        or state.get("cost_regression_flag") is True
        or len(state.get("dispute_queue", [])) > 20
    )
    return "hitl_e" if breach else "next"

이 함수는 단일 정의 — node 별로 복제하지 않는다. P0-C4 task 의 핵심.

hitl_gate.py 축소

# Bronze: HITL-A/B/C/D/E 5 케이스 큰 if 분기
# Silver: HITL-S / HITL-R / HITL-E 3 케이스 (HITL-D 는 비차단 → 노드 아님)

def hitl_gate_node(state: EvolverState) -> dict:
    gate_type = state.get("hitl_gate_type")  # "S" | "R" | "E"
    if gate_type == "S":
        return _handle_seed_gate(state)
    elif gate_type == "R":
        return _handle_remodel_gate(state)
    elif gate_type == "E":
        return _handle_exception_gate(state)
    raise ValueError(f"unknown gate type: {gate_type}")

HITL-D 는 node 가 아니다 — integrate_node 안에서 auto-resolve 실패 KU 를 state["dispute_queue"] 에 append 만 한다. 사용자는 cycle 진행과 무관하게 P5 대시보드의 inbox 에서 일괄 처리한다.

dispute_queue ↔ conflict_ledger 관계

두 구조는 동일 KU 를 참조할 수 있지만 독립 이다. 헷갈리지 말 것.

핵심 규칙:

• dispute_queue 에서 pop 되어도 conflict_ledger 의 entry 는 삭제 금지 (status=resolved 로 update).
• 동일 ku_id 가 두 구조에 동시에 있을 수 있다. 별개로 다룬다.
• len(dispute_queue) > 20 → HITL-E 트리거 (큐 적체 = 시스템 차원의 처리 실패).

metrics_guard.py 확장 항목 (P0-C6)

기존 metrics_guard 는 warning-only 였다. Silver 에서는 5 개 임계치 를 추가하고, 그 중 일부는 실제 interrupt 로 연결.

SILVER_GUARDS = {
    "collect_failure_rate": {"warn": 0.15, "interrupt": 0.30},
    "conflict_rate":        {"warn": 0.20, "interrupt": 0.40},
    "fetch_failure_rate":   {"warn": 0.30, "interrupt": 0.50},
    "cost_regression_flag": {"interrupt": True},  # boolean
    "dispute_queue_size":   {"warn": 10,   "interrupt": 20},
}

warn 임계치는 metrics 로그에만 기록. interrupt 임계치는 HITL-E 노드로 분기.

P5 Dashboard 연결 (§14.6)

P5 의 HITL inbox view 는 다음 3 탭으로 구성:

배치 검토는 체크박스 다중 선택 → approve all / reject all / edit selected. Exception 탭은 실시간 push 없음 — 운영자가 대시보드를 열 때 표시. HITL-E 트리거 시에는 CLI 알림 (stderr) 만 추가로 발생.

Anti-Patterns

관련

• masterplan v2 §14 — 단일 진실 소스. 충돌 시 §14 가 옳다.
• masterplan v2 §8 R10 — dispute_queue 적체 리스크.
• silver-implementation-tasks.md §4 P0-C — 8 개 task (P0-C1~C8) 가 이 skill 의 직접 적용 대상.
• langgraph-dev skill — LangGraph interrupt API / 노드 패턴.
• evolver-framework skill — 5 대 불변원칙 (Conflict-preserving 가 ledger 영속화의 근거).