refactor: 문서 개선 중

docs/clean-architecture-backend-template/tech-log-studio/redis-command-admission/concept/concept-redis-admission-stages.md

@@ -22,7 +22,7 @@ source:
 
 # 명령 카탈로그와 admission 아홉 단계
 
-모든 Redis 명령이 하나의 승인 지점을 지나고, 그 지점은 정해진 순서로 검사한다. 순서의 기준은 비용이다. 명백히 거부될 명령은 무엇도 인코딩되거나 전송되기 전에 거부된다.
+이 문서는 `CommandPolicyGuard`를 통과하도록 설계된 guarded command path의 admission 순서를 설명한다. 실제 코드에는 semantic adapter가 gateway를 직접 호출해 이 경로를 우회하는 사례가 있으므로 현재 runtime 전체의 모든 Redis 명령이 하나의 승인 지점을 지난다고 말하지 않는다.
 
 ## 관계
 
@@ -39,12 +39,12 @@ source:
 
 이 SDK가 명령 하나를 내보내기 전에 지나는 단계의 설명이다 — 카탈로그 분류(BLOCKED·R3·R4 거부) · capability/최소 버전 확인 · permit provenance 검증 · 네임스페이스 검사 · Cluster 동일 슬롯 검사 · 요청 예산 · 정책 기반 레인·타임아웃 유도 · 실패 번역 · 관측.
 
-## 명령 입장의 단일 지점
+## 의도된 guarded command path의 입구
 
 :::evidence key="redis-admission-stages-diagram" alt="CommandPolicyGuard 에서 카탈로그를 통과하면 실행이고 미분류나 BLOCKED 이면 거절인 두 갈래가 나온다" caption="명령 입장의 단일 지점" zoom="false"
 :::
 
-그 위에 얹힌 계약은 gateway가 "everything routed through it has already passed `CommandPolicyGuard`"를 전제한다는 것이다 — 그래서 정책·permit·예산·타임아웃·관측을 자기 관심사로 두지 않는다.
+gateway 계약은 자신에게 도달한 호출이 이미 `CommandPolicyGuard`를 지났다고 전제한다. 그래서 guarded path 안에서는 정책·permit·예산·타임아웃·관측을 guard 쪽 책임으로 둔다. 다만 직접 gateway 호출이 존재하면 그 전제 자체가 깨지므로 이 그림은 전체 runtime topology가 아니라 의도된 guarded path를 나타낸다.
 
 ## CommandPolicyGuard 참조 위치