refactor: 문서 개선 중

docs/clean-architecture-backend-template/tech-log-studio/self-disclosure-grading/case/case-a-startup-validator-that-requires-a-key-nothing-signs-with.md

@@ -26,13 +26,13 @@ source:
 - **등급표 13행 중 일곱을 스스로 강등하고 한 행만 관측과 어긋났다**
   등급표가 이 능력을 모형 단계로 적고 있다.
 - **하위 시스템 전체가 미배선인데 그것을 켜는 플래그는 시작 검사를 수행한다**
-  같은 형태가 mongo 어댑터에서 나타난 사례다.
+  mongo 어댑터에서도 startup validator가 요구한 능력과 실제 조립된 실행 경로가 어긋났다.
 - **커서에 서명하는 이유는 기밀성이 아니라 무결성이다**
   이 커서 서명이 지키려는 성질이다.
 
 ## 문제
 
-시작 검증기가 프로덕션 배포에서 커서 서명 키를 요구한다. 없으면 기동을 거절하고 이유를 적는다 — 서명되지 않은 커서는 클라이언트가 편집할 수 있다는 것이다.
+시작 검증기는 프로덕션 배포에서 cursor signing key가 없으면 기동을 거부한다. 오류 메시지는 서명되지 않은 cursor를 클라이언트가 수정할 수 있다는 위험을 설명한다.
 
 이 검증기는 자동설정이 실제로 부른다.
 
@@ -46,7 +46,7 @@ source:
 
 그런데 릴리스 게이트가 읽는 매니페스트는 이 능력을 안정 등급 승인 목록에 넣어 두었다.
 
-즉 결함은 능력이 미완이라는 것이 아니다. 미완인 능력에 대해 플랫폼이 요구하고 승인해 주는 신호를 이미 켜 두었다는 것이다.
+문제는 능력이 미완인 상태 자체가 아니라, 실제 signing path가 없는데도 startup validator와 지원 신호가 이미 signing key를 필수 요건처럼 취급한다는 점이다.
 
 닫는 것은 배선 결정이 아니라 설계 결정이다. 키링 팩토리는 키 재료를 인자로 받는데, 설정은 키 자체가 설정에 나타나지 않는다고 일부러 정해 두었다.
 
@@ -90,7 +90,7 @@ OpenJDK : 21.0.12
 
 커넥션 조립기를 만드는 프로덕션 코드가 0 이다.
 
-배포되는 스키마는 상태 확인 필드 하나다. 그 파일의 주석이 왜 그런지 적는다 — 이 모듈은 기능 없이도 독립으로 부팅해야 하고, Spring for GraphQL 은 빈 스키마로는 시작하지 않으며, 스켈레톤은 기능 타입 이름을 절대 대면 안 된다는 것이다.
+배포되는 스키마에는 상태 확인 필드 하나만 있다. 파일 주석은 모듈이 기능 없이도 독립 부팅되어야 하고 Spring for GraphQL은 빈 스키마로 시작할 수 없기 때문에 이 최소 필드를 둔다고 설명한다. 기능 타입 이름은 여기서 노출하지 않는다.
 
 커서는 발급되지도 소비되지도 않는다. 검증기 문구가 막는다고 말한 상태는 지금 존재하지 않는다.
 
@@ -126,7 +126,7 @@ websocket 어댑터에 재개 토큰 코덱과 키링이 있다. 이 둘도 조
 
 그동안 할 수 있는 일이 없는 것은 아니다. 요구는 남기고 문구를 사실에 맞추면 된다.
 
-테스트의 네 번째 케이스가 그것을 못 박는다. 요구는 지우지 말고 남기라는 것, 요구 자체는 옳고 빠진 절반은 구현이라는 것, 커서 서명이 요청 경로에 닿으면 앞의 두 케이스는 뒤집히고 이 케이스만 그대로 남는다는 것이다.
+테스트의 네 번째 케이스는 signing key 요구 자체를 제거하지 않는다. 빠진 것은 요청 경로의 signing 구현이며, 그 구현이 추가되면 ‘키만 요구하고 사용하지 않는다’는 앞의 불일치는 해소된다. 키가 없을 때 기동을 거부하는 검증은 그 이후에도 유지된다.
 
 ## 확인하지 못한 것