docs(clean-architecture-backend-template): 제1부가 채택한 것만 글감으로 남기고 다시 고른다

글감 1,001개 중 제1부(§3~§11) 앵커를 하나라도 가진 것은 112개뿐이었다. 나머지 889개는 제2부 모듈 분석 65편의 절 제목에서 나온 것이고, 그것이 재판정이 필요했던 이유다. 주제 44 → 16 (43개가 독자 질문 없이 있었다. 지금은 전부 있다) 글감 1,001 → 123 (제1부 앵커 112 + 제1부가 채택했는데 비어 있던 자리 11) 후보 965 → 1,088 · PENDING 905 → 0 error 3,042 → 0 내려온 889개는 후보 대장에 KEEP_IN_SSOT 로 남는다 — 버린 것이 아니라 분석에 남기고 독립 기록으로 만들지 않기로 한 것이다. 그 글감을 받치던 기록 파일 828개는 지웠다. 계약이 정본이고, 파일이 남아 있다는 이유로 계약에서 뺀 주제가 되살아나면 안 된다. 이력에는 그대로 있다 — git checkout a0ca2bb -- <경로>. 제1부가 채택했는데 글감이 없던 자리 열하나를 채웠다: mongo high-water mark 가 재전달 이벤트를 삼킨 P1, admin plane 이 가드만 켜고 서비스는 켜지 않은 것과 그 짝인 결정, 실패 어휘 세 층과 SQLState 매트릭스 병합 규칙, 부하 아래에서만 새는 admission 경계, 발행 증거와 완료 판정의 분리, keyset·JSONB 결정 둘. Concept 17개에 basis-version 을 채우고, 계약 제목과 기록 제목이 갈라져 있던 23건을 기록 쪽에 맞췄다. candidateScope 에 excludedAnchorPattern 을 적어 제2부 앵커만 가진 글감이 다시 올라올 수 없게 한다. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 15:02:25 +09:00
parent a0ca2bb72a
commit 1f04117bbf
851 changed files with 5498 additions and 90638 deletions
@@ -35,7 +35,8 @@ Concept 에 담고 `관계`로 가리킨다. `references/record-kinds.md`
   **`tech-log-tree.json` 에 노드가 없는 글은 쓰지 않는다** — 트리에 먼저 올리고, 그 노드의
   후보가 `PROMOTE` 이면서 `dispositionReview: CONFIRMED` 인지 확인한 뒤에 쓴다. `PENDING` 은
   사람이 다시 읽지 않았다는 뜻이라, 그 위에 쓴 글은 과분류를 그대로 물려받는다. 계약 밖에서 쓴
-   기록은 색인에 `unlisted` 로 남는다.
+   기록은 색인에 `unlisted` 로 남는다. 그 노드의 `ssot-assets`·`ssot-evidence` 도 함께 본다 —
+   SSOT 가 이미 그린 그림과 이미 돌린 측정 가운데 이 글감에 배정된 것이 거기 적혀 있다.
 1. **종류 선택** — 위 표. 애매하면 "재현했나"를 묻는다.
 2. **칸 채우기** — 칸과 게시 조건은 `references/record-kinds.md`.
 3. **본문 작성**(Case·Concept) — **종류마다 무엇을 어떤 순서로 쓰는지는
@@ -45,9 +46,14 @@ Concept 에 담고 `관계`로 가리킨다. `references/record-kinds.md`
   남겨 두고 나중에 걷어내는 순서가 아니다. **문체를 손보기 전에 문장을 고른다** — 설명이 끝난
   뒤에 붙은 평가·예고·되풀이·독자 오해 가정을 먼저 뺀다(`ai-tells.md` 첫 절). 문체 규칙의
   정본은 `ai-tells.md` 다.
-   순서·경계·상태 전이처럼 문장만으로 따라가기 어려운 관계가 있으면 그때
-   `technical-visualizer` 로 그림을 만든다. 손으로 SVG 를 그리지 않고, 모든 글에 그림을 만들지도
-   않는다.
+   순서·경계·상태 전이처럼 문장만으로 따라가기 어려운 관계가 있으면 **`final/assets/` 에 그
+   그림이 이미 있는지부터 본다.** SSOT 를 만들 때 그려 둔 것이 있고 계약의 `ssot-assets` 가 이
+   글감에 배정해 두었으면 그것을 쓴다 — `final/assets/tech-log-studio/` 로 복사하고 기록의
+   `assets` 가 그 사본을 가리킨다. **없을 때만** `technical-visualizer` 로 새로 만든다. 손으로
+   SVG 를 그리지 않고, 모든 글에 그림을 만들지도 않는다.
+   인용할 측정도 같다. `final/evidence/` 에 있는 원문을 가리키고 같은 것을 다시 돌리지 않는다.
+   **그림과 측정을 그 자리에서 만들어 내기 전에 SSOT 가 이미 가진 것을 먼저 찾는다** — keycloak
+   에서는 그러지 않아 정본까지 갖춘 그림 13 장이 남고 이름이 다른 그림 5 장이 새로 만들어졌다.
 4. **검사** — 셋 다 돌린다. 파서와 문장과 증빙은 각각 다른 것을 본다.
   - `scripts/check_body.mjs` — Case 본문이 Studio 파서를 통과하는지. 같은 파서를 그대로 부른다.
   - `rewriting-technical-prose-naturally/scripts/check_prose.mjs` — 문장 규범. **error 0 이 될 때까지 고친다.**
@@ -116,6 +122,8 @@ SSOT 에 없는데 필요한 인용이라면 순서가 반대다 — `final/docu
 | 문서마다 같은 문형·같은 길이 | `references/ai-tells.md` |
 | 표를 `:::table`로 감쌈 | 그냥 파이프로 쓴다 |
 | `![](https://…외부)` | Asset으로 올려 `/api/v1/public/media/…` |
+| SSOT 에 있는 그림을 두고 새로 그림 | `final/assets/` 를 먼저 본다. `ssot-assets` 가 배정한 것을 쓴다 |
+| SSOT 에 있는 측정을 두고 다시 돌림 | `final/evidence/` 의 원문을 가리킨다 |
 | Decision에 근거 없음 | 관계 1개 이상 연결 |
 | 측정 안 한 검증일 | 비워 둔다 |
 | 설명 직후에 「~증거다」「~가 아니다」로 평가 | 지운다. 앞 문장이 사실을 말했으면 거기서 끝낸다 |
@@ -10,6 +10,8 @@
 |---|---|
 | 코드·설정·실행 증거 | 사실의 근거 |
 | `final/document.md` | **글감 범위의 SSOT** — 후보를 발견하는 유일한 입력 |
+| `final/assets/` · `final/.techviz/` | 이미 그린 그림과 그 정본. 새 후보를 내지 않고 글감에 배정된다 |
+| `final/evidence/` | 이미 실행한 측정의 원문. 마찬가지로 배정된다 |
 | `analysis/**/*.md` | final이 이미 채택한 주장을 상세히 확인하는 보조 근거 |
 | `tech-log-tree.json` | 사람이 고른 글감. 분해 계약이자 색인이고 이 파일이 정본이다 |

@@ -36,6 +38,37 @@

 범위 밖의 앵커는 후보가 아니라 근거다. 제1부에서 나온 글감의 `source`로 건다.

+## 그림과 증거는 후보가 아니라 배정 대상이다
+
+`final/assets/`의 그림과 `final/evidence/`의 측정은 글감을 새로 만들지 않는다. 이미 정해진
+글감에 붙는다. 그래서 처분을 매기는 자리가 아니라 **배정하는 자리**이고, 계약의
+`ssot-assets`·`ssot-evidence`가 그 자리다.
+
+글감을 다 고른 뒤 두 폴더를 한 번 훑는다. 물음은 하나다.
+
+> **이 그림이나 이 측정은 어느 글감의 것인가. 붙을 글감이 없으면 왜 없는가.**
+
+```json
+"ssot-assets": ["ap3-bff-session-flow"],
+"ssot-evidence": ["raw/explain/l3-cartesian-join-plan.txt"]
+```
+
+배정한 것은 기록의 `assets`·`evidence`가 실제로 가리켜야 한다. 배정해 놓고 쓰지 않으면
+`verify-tech-log-tree.py`가 error로 센다.
+
+**배정하지 않으면 글을 쓸 때 같은 그림을 새로 그린다.** keycloak이 그렇게 됐다. SSOT에
+`ap3-bff-session-flow`, `ap4-edge-forward-auth-flow`를 포함한 그림 13장이 `.techviz` 정본까지
+갖춘 채 있었는데, 기록 24편은 그중 한 장도 가리키지 않고 이름이 다른 그림 5장을 새로 만들어
+썼다. 새로 만든 5장에는 정본이 없어서 고칠 수도 없다.
+
+붙을 글감이 없는 그림도 있다. 패턴 넷을 나란히 놓고 비교하는 그림은 Reference에 붙어야 맞는데
+Reference에는 본문이 없다. 그런 그림은 그대로 두고, 왜 두는지 계약에 적는다 — 「Reference에만
+쓸 자리가 있어 본문 있는 종류에 담지 못한다」처럼. `verify-project-layout.py`가 「기록이 쓰지
+않는 SSOT 그림」으로 세므로, 센 숫자가 설명되지 않은 채 남지 않게 한다.
+
+증거도 같다. 재료로만 쓰고 인용하지 않기로 한 측정은 정상이다. 「기록이 인용하지 않는 raw 증거」가
+전부 설명되는지만 본다.
+
 ## 왜 먼저 나누는가

 긴 글을 앞에서부터 잘라 기록으로 만들면 절 하나가 기록 하나가 된다. 그러면 Case의 칸도
@@ -127,4 +127,6 @@
 - [ ] Decision 에 근거가 하나 이상 있고, 무엇을 보고 정했는지가 적혀 있는가
 - [ ] 지어낸 경험·실패·동기·감정이 없는가
 - [ ] 그림이 실제 asset 파일을 가리키고, 있어야 할 이유가 있는가
+- [ ] `final/assets/` 에 이미 있는 그림을 두고 같은 것을 새로 그리지 않았는가
+- [ ] 계약이 `ssot-assets`·`ssot-evidence` 로 배정한 것을 기록이 가리키는가
 - [ ] 그림이 관측하지 않은 사건을 만들어 내지 않았는가
@@ -83,7 +83,55 @@ whose candidate is `PROMOTE` and `CONFIRMED`.
 `readiness` · `source` · `code` · `evidence` · `classification` · `relations` and the rest
 of each kind's fields are written by a person. `build-tech-log-tree.py` never touches them.
 It refreshes only what it can read from the record files — `file`, `publication`, `status`,
-`studioId`, `assets`, `evidenceFiles` — and lists records that have no node in `unlisted`.
+`studioId`, `assets`, `assetFiles`, `evidenceFiles` — and lists records that have no node in
+`unlisted`.
+
+### `ssot-assets` · `ssot-evidence`
+
+The SSOT is not only `final/document.md`. `final/assets/` holds diagrams that were already
+drawn, each with its canonical `final/.techviz/<name>/`, and `final/evidence/` holds
+measurements that were already run. Neither produces candidates — both are **assigned** to
+candidates that already exist, and these two fields hold the assignment.
+
+```json
+"ssot-assets": ["ap3-bff-session-flow"],
+"ssot-evidence": ["raw/explain/l3-cartesian-join-plan.txt"]
+```
+
+`ssot-assets` names diagrams by file stem; the file must exist somewhere under
+`final/assets/`. `ssot-evidence` takes paths relative to `final/evidence/`. Both are
+written by a person and both are optional — a node that needs no picture and cites no
+measurement leaves them out.
+
+What they are not optional about is follow-through. Once a node is assigned a diagram and
+its record is written, the record's `assets` must point at that file and its `evidence` at
+that path; `verify-tech-log-tree.py` reports the gap as an error. Assigning and then not
+using is the failure these fields exist to catch — without them a writer draws the picture
+again instead of finding the one that is already there.
+
+`verify-project-layout.py` counts the other direction: SSOT diagrams and raw evidence that
+no record cites at all. Some of that count is correct — a four-pattern comparison diagram
+belongs to a Reference, and Reference has no body to render it in. The count is meant to be
+explained, not driven to zero.
+
+### `assetLedger`
+
+That explanation lives at the top level of the index, next to `candidateScope`. It names
+what was assigned and, for everything left over, why it is left over.
+
+```json
+"assetLedger": {
+  "assigned": ["ap3-bff-session-flow", "ap3-csrf-boundary"],
+  "unassigned": [
+    {"asset": ["four-pattern-request-boundaries"],
+     "reason": "네 패턴을 비교하는 그림이라 붙을 자리가 Reference 인데 Reference 에는 본문이 없다"}
+  ]
+}
+```
+
+A diagram left out for a reason is a normal outcome, the same way `KEEP_IN_SSOT` is. What
+is not normal is a leftover nobody looked at — that is the state where the next writer
+draws the picture again. Write the ledger when the count first appears, not when it grows.

 ### Case