fix(cabt): 기록이 인용한 것을 SSOT 가 안 담고 있었다
check_evidence --repo 이 clean-architecture-backend-template 에서 141건을 세고 있었다.
124건 전부를 고정 리비전 21234e38 에 대조했더니 날조는 0 이었다 — 인용은 맞고 없던
쪽이 SSOT 였다. 그래서 SSOT 를 보강한다.
넣는 것은 기록이 옮겨 적은 문장이 아니라 저장소 원문이다. 기록을 복사해 넣으면
검사기는 초록이 되지만 옮겨 적기가 어긋나도 더는 못 잡는다. 원문을 넣으면 어긋난
기록은 계속 걸린다.
- 코드 124건 → 리프 절 일곱 곳에 원문 30조각(300줄). 자리는 기록의 source 앵커와
소스 파일의 모듈을 교차시켜 정했고, 둘이 갈린 다섯은 모듈을 따르고 그 사실을 적었다
- 식별자 13건 → spring.factories · MethodSecurityConfig 원문과 줄여 적힌 경로의 전체 경로
- source 앵커 4건 → 계약이 이미 적고 있던 SSOT 앵커를 기록 frontmatter 에 맞췄다.
맨 앵커를 한 줄씩 앞에 둔다 — `_record_sources` 가 `- <공백 없는 한 덩어리>` 만 잇달아 읽는다
- 인용 4건 → concept-signed-cursor-structure 의 `{ ... }` 생략을 저장소 원문 형태로 고쳤다.
생략한 자리는 `…` 로 남기고 무엇을 줄였는지 본문에 적는다
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4vKjQo9KKBBokzxqXLCfk
This commit is contained in:
DongHyeonka
co-authored by
Claude Opus 5
Claude Opus 5
parent
96d89ec6da
commit
05e96b5add
+2
@@ -14,6 +14,8 @@ assets:
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/a-flag-that-validates-an-unwired-subsystem.txt
|
||||
source:
|
||||
- final/document.md#4-2
|
||||
- final/document.md#a06
|
||||
- 분석 문서는 mongo 어댑터 편 §49 다. 플래그가 그대로 바인딩된다는 것은 같은 문서 §6 의 바인딩 관측값이고, 형제 입력의 처리 차이도 그 절에 있다. 반대쪽 실행체가 출하되어 플래그와 무관하게 조립된다는 것은 §65 와 §68 이다.
|
||||
- 같은 문서 §50 은 둘 다 실행체가 없다고 적는다. 그 줄은 sub-scope 06 시점의 요약이고 §68 이 뒤집었다 — 자동설정의 무조건 빈과 드라이버 호출이 그 근거이며, 위 터미널 출력에서 확인할 수 있다.
|
||||
---
|
||||
|
||||
+14
-5
@@ -100,17 +100,26 @@ MAC 이 버전까지 덮는 것이 이 구조의 첫 결정이다. 페이로드
|
||||
|
||||
## 검증 순서
|
||||
|
||||
디코드 경로는 값을 해석하기 전에 형태부터 검사한다.
|
||||
디코드 경로는 값을 해석하기 전에 형태부터 검사한다. `…` 는 던지는 줄을 줄인 것이고,
|
||||
줄이지 않은 줄은 `SignedJsonCursorCodec.java:84-106` 원문 그대로다.
|
||||
|
||||
```java
|
||||
if (encoded == null || encoded.isBlank()) { ... }
|
||||
if (encoded == null || encoded.isBlank()) {
|
||||
…
|
||||
}
|
||||
if (encoded.length() > MAX_ENCODED_LENGTH) {
|
||||
throw new IllegalArgumentException("cursor exceeds the maximum token length");
|
||||
}
|
||||
if (payloadSeparator <= 0 || macSeparator <= payloadSeparator) { ... }
|
||||
if (!VERSION.equals(version)) { ... }
|
||||
if (payloadSeparator <= 0 || macSeparator <= payloadSeparator) {
|
||||
…
|
||||
}
|
||||
if (!VERSION.equals(version)) {
|
||||
…
|
||||
}
|
||||
// Base64 expands by 4/3, so the encoded payload segment's length bounds the decoded size
|
||||
if (decodedLengthOf(encodedPayloadLength) > MAX_PAYLOAD_BYTES) { ... }
|
||||
if (decodedLengthOf(encodedPayloadLength) > MAX_PAYLOAD_BYTES) {
|
||||
…
|
||||
}
|
||||
```
|
||||
|
||||
주석 한 줄이 순서의 이유를 담는다. Base64 는 4/3 으로 팽창하므로 인코딩된 길이로 디코딩될 크기의 상한을 알 수 있다. 즉 디코딩하기 전에 크기를 거절할 수 있다.
|
||||
|
||||
+3
@@ -14,6 +14,9 @@ assets:
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/a-lease-without-an-owner.txt
|
||||
source:
|
||||
- final/document.md#4-3
|
||||
- final/document.md#a19
|
||||
- final/document.md#a08
|
||||
- 분석 문서는 메시징 플랫폼 편 §7.3 이 V2 헤더를 인용하며 시간과 소유권 토큰의 차이를 짚고, outbox 어댑터 편 §12.3 이 두 세대의 술어와 SET 절과 반환 타입을 표로 대조한다. `@Deprecated` 가 없다는 것은 reliability-api 편이 P2 로 다룬다. 옛 경로가 남아 있는 것은 열린 질문이 아니라 P3 결함이고, 권고는 애너테이션이 아니라 제거다.
|
||||
- 같은 형태의 다른 다섯 곳은 JPA 어댑터 편 §70·§71·§89 와 §83.3, mongo 어댑터 편 §55 다. §83.2 는 파일서버 쪽에 남은 구간 — 리스 만료 직후 인수 전에 아직 settle 할 수 있는 창 — 을 finding 으로 올리지 않은 이유와 함께 기록한다.
|
||||
---
|
||||
|
||||
+2
@@ -14,6 +14,8 @@ assets:
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/a-startup-probe-that-never-runs.txt
|
||||
source:
|
||||
- final/document.md#4-4
|
||||
- final/document.md#a10
|
||||
- 분석 문서는 cache-redis 어댑터 편 §6 이다. 그 절이 탐침이 확인하는 넷을 나열하고, 넷째의 javadoc 을 인용하고, 두 탐침의 프로덕션 참조가 javadoc 링크 하나뿐이라는 것과 자동설정이 탐침을 부르지 않는다는 것을 기록한다. 판정은 P2 이고, 수정은 자동설정에 탐침을 실행하는 빈 하나를 더하는 것이다.
|
||||
- 같은 사고의 더 상세한 기록은 저장소 문서 쪽에 있다. 지원 매트릭스가 승격과 강등 시각을 초 단위로 적고, 운영 문서와 런북이 가드를 적용한 뒤 같은 승격에서 무엇이 달라졌는지 적는다.
|
||||
---
|
||||
|
||||
@@ -7,9 +7,9 @@
|
||||
"revision": "21234e38cdb9a926cbc92bb97a2aee2e4a7d2916",
|
||||
"verified": "git rev-parse HEAD 가 이 값과 같다 (2026-09-07 확인)"
|
||||
},
|
||||
"ssotSha256": "74b4986fd8621f6fd61791232777dc0e6c8ef999cbc2343df050bd5921ea03ac",
|
||||
"ssotSha256": "68c09e69b095f50e030a3b7454417d07f9ecb1a9c9ed4c04197b0f406ecc2405",
|
||||
"sourceRevision": "21234e38cdb9a926cbc92bb97a2aee2e4a7d2916",
|
||||
"generatedAt": "2026-09-08",
|
||||
"generatedAt": "2026-09-11",
|
||||
"candidateScope": {
|
||||
"document": "final/document.md",
|
||||
"sections": [
|
||||
|
||||
+2
@@ -15,6 +15,8 @@ evidence:
|
||||
- ../../../final/evidence/raw/a-release-gate-with-no-evidence-producer.txt
|
||||
- ../../../final/evidence/raw/tl-grpc-release-gate-no-producer.txt
|
||||
source:
|
||||
- final/document.md#7-6
|
||||
- final/document.md#a20
|
||||
- 분석 문서는 gRPC 플랫폼 편 §3.2 다. 그 절이 지원 매트릭스의 현재 시제 문장과 게이트의 설계 근거를 인용하고, 생성 지점 넷이 전부 테스트라는 것과 messaging 이 그것을 세 층으로 닫았다는 대비를 적는다.
|
||||
- 같은 절이 근거로 든 검색은 리프의 build.gradle 안에서 태스크 등록 문자열을 세는 것이라 0 이 나온다. 이 저장소는 등록을 컨벤션 플러그인으로 옮겨 두었으므로 그 수는 등록된 태스크 수가 아니다. 위 터미널 출력의 레인 목록이 그것을 보여 준다.
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user