요청 생성 ≠ 실행 보장

§6.5.1 의 마지막 문장이 이 시스템 아키텍처의 요약이다.

"차량 내 HMI 및 모바일 인터페이스는 기능 제어 요청을 생성할 수 있으나, 차량 기능의 실제 수행 여부는 해당 기능의 허용 조건 및 안전 정책에 따라 결정되어야 한다."

잘못된 멘탈 모델을 명시적으로 막는다

✗  HMI 는 명령한다 → 기능은 수행한다
✓  HMI 는 요청한다 → 기능이 판단한다 → 결과를 HMI 에 알린다

§6.2 의 윈도우가 이걸 실증한다. 닫힘 요청은 여섯 개의 관문을 통과해야 한다 — 통신 유효성, 우선순위, Anti-pinch 가용성, 위치 신뢰도, 래치 상태, 멱등 검사. 어디서든 막힐 수 있다.

구현에 주는 제약 — 낙관적 UI 금지

/* ✗ 버튼을 누르는 순간 상태를 바꿔 그린다 */
void on_lock_button(void) {
    send_lock_request();
    ui_set_door_state(UI_LOCKED);      /* 실제로 잠겼는지 모른다 */
}

낙관적 UI 는 웹 앱에서는 좋은 패턴이지만 차량 제어에서는 위험하다. 사용자가 "잠김"을 보고 떠났는데 실제로는 안 잠겼을 수 있다.

요청 상태와 차량 상태를 분리해 표시해야 한다. 도어 상태는 차량이 알려줄 때까지 그대로 두고, 요청은 요청 생애주기 로 따로 보여준다.