§9 가 "미확정 통신 방식, 센서 임계값, 법규 적용 범위 및 성능 수치는 TBD 로 관리한다"고 규정한다.
번호는 038 까지 가지만 023~026·028·035·037 이 비어 있다. 통합·삭제된 항목의 흔적이고, 번호를 재사용하지 않는 게 옳다 — 과거 회의록·이슈의 참조가 깨지기 때문이다.
왜 임의 값으로 채우면 안 되나
✗ "Anti-pinch 임계값은 2.5 A 로 한다" (근거 없이)
→ 시험 통과 → 기록 남음
→ 나중에 실제 값이 1.8 A 로 밝혀짐
→ 어떤 시험을 다시 해야 하는지 추적 불가
✓ TBD-009 로 남김
→ 시험 명세서가 "TBD-009 확정 후 수행"으로 표시됨
→ 값 확정 시 **변경 영향 분석** 절차가 작동
TBD 는 "모른다"의 고백이 아니라 "언제 어떻게 알게 될지"의 계획이다. §8 의 "초기 제안" 열이 그 계획이다 — "벤치 시험 후", "통합 시험 후", "하드웨어 설계 단계에서".
정책 TBD 는 따로 관리해야 한다
32건 중 넷(010 닫힘 정책 · 019 표시 패턴 · 034 동물 진입 등급 · 036 CV 트리거)은 시험해도 답이 안 나온다. 사람이 결정해야 한다.
기술 TBD 와 섞어 두면 "시험하면 나오겠지" 하고 미뤄져 영원히 안 닫힌다. 결정 주체와 기한을 붙여 별도 안건으로 올려야 한다.
표에 없는 의존이 있다
§8 은 각 TBD 를 독립적으로 보여주지만 실제로는 얽혀 있다. TBD-002(CAN FD) → TBD-001(ESP32 통신)은 하드웨어 제약이고, TBD-020·021 → TBD-022 는 수치 의존, TBD-008 → TBD-009 는 방식 의존이다. 결정 순서를 잘못 잡으면 재작업이 생긴다.