Files
document-haness/docs/clean-architecture-backend-template/tech-log-studio/caching-and-redis/case/case-analysis-finding-a10-f008.md
T
DongHyeonkaandClaude Fable 5.1 b25357c48a docs(clean-architecture-backend-template): fold analysis into final and re-select one topic
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다
- 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5
  (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를
  techviz 로 만들었다
- 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs
  돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다.
  Concept 이 인용한 코드가 SSOT 에 없어 뺐다
- candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905)

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-07 12:39:20 +09:00

4.9 KiB

kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, body, assets, evidence, source
kind slug title topic project status sourceRevision rootTreeNode evidenceCapturedOn body assets evidence source
CASE analysis-finding-a10-f008 permit 정책 이름이 세 곳에 문자열로 존재하고 교차 검사가 없다 caching-and-redis clean-architecture-backend-template 게시 전 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 case:analysis-finding-a10-f008 2026-09-01 case-analysis-finding-a10-f008.body.md
key file
analysis-finding-a10-f008 ../../../final/evidence/rendered/analysis-finding-a10-f008.svg
../../../final/evidence/raw/analysis-finding-a10-f008.txt
원본 분석 절은 final/document.md#a10#L502 이다.

permit 정책 이름이 세 곳에 문자열로 존재하고 교차 검사가 없다

허가 정책 이름의 출처가 셋이다. 두 집합의 차분은 정확히 둘이고 양쪽 다 설명이 있다. 문제는 차분이 아니라 차분을 감지하는 장치가 없다는 것이다. 어느 쪽 오타도 빌드를 깨지 않는다.

관계

  • 패턴 구독의 승인만 호출자가 아니라 배포에 대해 이루어진다 같은 리프의 허가 체계 사례다.
  • 문자열로 이어진 두 세계는 오타에서 조용히 갈라진다 이 사례가 그 규칙의 형태다.
  • catalog drift gate는 서버 메타데이터와 대조하지 Java 상수와 대조하지 않는다 감지 장치가 없는 이유다.

문제

허가 정책 이름의 출처가 셋이다.

연산 문맥의 공개 상수 열여덟 개, 명령 정책 설정 파일의 필수 정책 값 열여덟 개, 검색 확장의 비공개 상수 하나다.

두 집합이 일치하는지 확인했다.

결론

두 집합의 차분은 정확히 둘이고 양쪽 다 설명이 있다.

지속 키 정책은 자바에만 있다. 해당 명령들이 하위 등급이라 목록의 필수 정책이 아니라 연산 문맥의 전용 요구 메서드가 강제한다.

검색 인덱스 정책은 설정에만 있다. 색인 생성 명령의 필수 정책이고, 자바 쪽 짝은 연산 문맥이 아니라 검색 확장 패키지의 비공개 상수다.

즉 차분 자체는 설명된다.

문제는 다른 데 있다. 차분을 감지하는 장치가 없다.

설정에 오타가 들어가면 그 명령은 아무도 발급받을 수 없는 정책을 요구하게 된다.

자바 상수 쪽에 오타가 들어가면 발급 구현이 정책이 활성화되지 않았다고 던진다.

어느 쪽도 빌드를 깨지 않는다.

목록 표류 게이트는 설정을 서버 메타데이터와 대조한다. 자바 상수 집합과 대조하지 않는다.

판정은 P3 다.

확정은 다음 하위 범위로 이월한다. 정책 적재기 테스트가 정책 이름 집합을 검사하는지 그 범위에서 확인한다.

검증 환경

확인 방식 : 세 출처의 문자열 집합 대조 소스 수정 : x

재현 조건

원문은 final/evidence/raw/162 계열에 있다.

  1. 연산 문맥의 정책 상수를 모은다.
  2. 명령 정책 설정 파일의 필수 정책 값을 모은다.
  3. 두 집합의 차분을 계산한다.
  4. 각 차분 항목의 이유를 확인한다.
  5. 목록 표류 게이트가 무엇과 무엇을 대조하는지 확인한다.

본문

정책 이름의 출처가 셋이다.

출처 개수
RedisOperationContextpublic static final String 상수 18
redis-command-policy.ymlrequired-policy: 18
LettuceRedisSearchOperations:31의 private 상수 SEARCH_INDEX 1

RedisCommandPolicyLoaderTest 참조 위치

:::evidence key="analysis-finding-a10-f008" alt="코드베이스에서 RedisCommandPolicyLoaderTest 를 검색한 출력 1줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="RedisCommandPolicyLoaderTest 코드베이스 검색 — 1줄 · exit 0" zoom="true" :::

두 집합의 차분에는 설명이 있다

162-... §8.3 — persistent-key는 Java에만 있다(해당 명령들이 R1이라 catalog의 required-policy가 아니라 RedisOperationContext.requirePersistentKeyPermit이 강제한다, §34). search-index는 YAML에만 있다(FT.CREATErequired-policy이고, Java 쪽 짝은 sdk/extensions/search의 private 상수다).

문제는 차분이 아니라 감지 장치의 부재다

YAML에 required-policy: bounded-collectoin-read처럼 오타가 들어가면 그 명령은 아무도 발급받을 수 없는 정책을 요구하게 되고, Java 상수 쪽에 오타가 들어가면 issueAdvanced가 "policy is not enabled"로 던진다. 어느 쪽도 빌드를 깨지 않는다. catalog drift gate는 YAML을 서버 메타데이터와 대조하지, Java 상수 집합과 대조하지 않는다. P3 — 확정은 sub-scope 05로 이월한다.

확인하지 못한 것

정책 적재기 테스트가 이름 집합을 검사하는지 확인하지 않았다. 다음 하위 범위로 이월한다.