feat: complete wikification of War Commander batch 1&2 and final grey dot cleanup

10_Wiki/Topics/Design & Experience/API 응답 및 상태 모델링 (State Modeling and API Responses).md

@@ -1,6 +1,6 @@
 ---
 id: P-REINFORCE-AUTO-09EEF3
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
+category: "10_Wiki/💡 Topics/Design & Experience"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
@@ -30,11 +30,11 @@ github_commit: "[P-Reinforce] Continuous Worker - API 응답 및 상태 모델
 - **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[완전성 검사 (Exhaustiveness checking)]], [[Result 타입 (Result Type)]]
-- **Projects/Contexts:** [[상태 머신 (State Machine)]], [[오류 처리 아키텍처 (Error Handling Architecture)]]
+- **Related Topics:** 식별 가능한 유니온 (Discriminated Unions), 완전성 검사 (Exhaustiveness checking), Result 타입 (Result Type)
+- **Projects/Contexts:** 상태 머신 (State Machine), 오류 처리 아키텍처 (Error Handling Architecture)
 - **Contradictions/Notes:** API나 시스템의 에러 응답을 모델링할 때 'Result 타입'을 사용하는 방식에 대해 개발자 간의 이견이 존재한다. 예상된 실패를 Result로 강제 반환하면 실행 흐름이 예측 가능해진다는 찬성 측 주장이 있는 반면, 전역 예외 처리기(Global Exception Handler)를 사용하는 쪽이 예외를 단순히 위로 올려보낼 수 있어 불필요한 보일러플레이트 코드 및 과도한 제어 흐름 분기(`switch`문 등)를 줄이고 컨트롤러를 더 깔끔하게 유지할 수 있다는 반대 주장도 팽팽하게 맞선다 [7, 20, 26-31].
 
 ---
 *Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/API 응답 및 상태 모델링 (State Modeling and API Responses).md]]
+
 ---