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>

.agents/skills/writing-tech-log-records/references/tech-log-tree-contract.md

@@ -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