docs(TechLog): 설명 뒤에 붙은 평가·예고·되풀이를 걷어낸다

rewriting-technical-prose-naturally 를 서브에이전트 셋으로 나눠 56편에 적용했다.
ai-tells.md 의 첫 절대로 다른 표현으로 바꾸는 대신 문장을 통째로 지웠다.

  설명한 것의 중요성을 다시 평가하는 꼬리   19
  이미 설명한 것을 추상어로 되풀이           19
  독자에게 읽는 법을 지시하거나 오해를 가정   9
  자료가 뒷받침하지 않는 덧붙인 이득          4

문서군 전체의 문형 편중도 풀었다 — 함께 27→7(한 묶음), 그대로 22→12(두 묶음),
하게 된다 1→0. 한 편에서 세 번 반복되던 「같은 병이 ~에서도 났다」와 두 기록에
같은 문장으로 있던 세 쌍을 갈랐다.

계약 제목 「여덟 자리」가 본문의 「여덟 곳」과 어긋나 있었다. 제목이 spatial-metaphor
규칙에도 걸리므로 계약과 기록을 함께 「여덟 곳」으로 맞췄다.

검사 넷 전부 통과한다 — check_prose 56편 error 0 · check_body PASS ·
check_evidence --repo 문제 없음 · verify-tech-log-tree error 0 warn 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/TechLog/tech-log-studio/an-axis-inside-a-topic/case/case-the-comparison-band-changed-three-times.md

@@ -18,7 +18,7 @@ source:
 
 # 홈의 비교 구역이 세 번 바뀌었다 — 상한을 없애고 요청을 목록 하나와 주제 하나로 고정했다
 
-홈의 비교 구역을 세 번 바꿨다. 처음에는 주제 하나만 펼치고 아래에 다른 주제로 가는 줄을 뒀고, 다음에는 주제 이름을 탭으로 세웠고, 마지막에 탭을 칩 크기로 낮추고 개수 상한을 없앴다. 상한을 없앨 때 요청 구조를 함께 바꿔 주제가 몇 개가 되든 첫 요청이 고정되게 했다.
+홈의 비교 구역을 세 번 바꿨다. 처음에는 주제 하나만 펼치고 아래에 다른 주제로 가는 줄을 뒀고, 다음에는 주제 이름을 탭으로 세웠고, 마지막에 탭을 칩 크기로 낮추고 개수 상한을 없앴다. 상한을 없앨 때 요청 구조를 바꿔 주제가 몇 개가 되든 첫 요청이 고정되게 했다.
 
 ## 관계
 
@@ -35,7 +35,7 @@ source:
 
 ## 결론
 
-세 단계를 거쳤고 각 단계가 앞 단계의 무엇을 고치려 했는지가 남아 있다.
+세 단계를 거쳤다.
 
 | 단계 | 무엇 | 왜 바꿨나 |
 |---|---|---|
@@ -72,11 +72,11 @@ tech-log-frontend : 604ded5 → de4cb8b → 3bb724b · 2b2f443
 
 탭 줄은 목록 호출 하나가 주는 전부다. 상세는 고른 탭만 그때 받아 캐시한다.
 
-그래서 주제가 몇 개가 되든 홈이 처음 보내는 요청은 목록 하나와 주제 하나로 고정된다. 상한을 없앨 수 있었던 이유가 이것이다.
+주제가 몇 개가 되든 홈이 처음 보내는 요청은 목록 하나와 주제 하나로 고정된다.
 
 ## 시각 언어를 두 번 고쳤다
 
-고른 탭의 파란 밑줄을 없앴다. 주제가 스무 개면 밑줄 설 곳 스무 개가 함께 늘어선다.
+고른 탭의 파란 밑줄을 없앴다. 주제가 스무 개면 밑줄 설 곳 스무 개가 나란히 늘어선다.
 
 칩으로 낮추니 목록 위에 글자만 떠 있는 것처럼 보였다. 고른 탭에 알약 형태를 주고, 묶음의 윗선을 목록이 아니라 패널이 갖게 해서 탭 줄이 그 선에 바로 얹히게 했다.
 

docs/TechLog/tech-log-studio/an-axis-inside-a-topic/concept/concept-topic-variant-and-record-variant.md

@@ -9,7 +9,7 @@ status: 게시 전
 basisVersion: tech-log-backend 2026-09-01 의 축 스키마 · record_variant 에 외래키 없음 · studio_validation 과 publication 이 쓰는 방식을 따름
 assets:
   - key: topic-variant-model
-    file: ../../../final/assets/tech-log-studio/topic-variant-model.svg
+    file: ../../../final/assets/diagrams/topic-variant-model/topic-variant-model.svg
 evidence:
   - ../../../final/evidence/raw/db/topic-variant-rows.txt
   - ../../../final/evidence/raw/db/record-variant-links.txt
@@ -62,7 +62,7 @@ topic (주제)
 
 `record_variant` 는 외래키를 갖지 않는다. 기록이 종류마다 다른 테이블에 살기 때문이다 — 문서·열린 질문·프로젝트 결정이 각각 다른 테이블이다. 종류와 아이디의 쌍으로만 가리킨다.
 
-이 방식은 이 저장소에서 처음 쓰는 것이 아니다. 검증 상태와 게시 기록이 이미 같은 방식으로 기록을 가리키고 있었다.
+검증 상태와 게시 기록이 이미 같은 방식으로 기록을 가리키고 있었다.
 
 ## 사람이 쓰는 칸
 
@@ -86,6 +86,6 @@ jpa-feed-query-performance  축 이름 「조회 전략」  축 3개
   fetch-join-paging  ← CASE 1
 ```
 
-축마다 기록이 하나씩이고 축 제목을 그 기록 제목과 비슷하게 적으면 「문서가 그대로 나온다」로 보인다. 구조 차이가 아니라 내용 양의 차이다.
+축마다 기록이 하나씩이고 축 제목을 그 기록 제목과 비슷하게 적으면 「문서가 그대로 나온다」로 보인다.
 
 <!-- body:end -->

docs/TechLog/tech-log-studio/an-axis-inside-a-topic/decision/decision-an-axis-inside-a-topic-not-four-topics.md

@@ -38,7 +38,7 @@ source:
 
 주제를 넷으로 쪼개면 PKCE·CSRF·Authorization Code 처럼 네 구조가 함께 쓰는 기록을 어디에 둘지 애매해진다. 어느 한 주제에 넣으면 나머지 셋에서 그 기록에 닿을 수 없고, 넷에 복사하면 같은 글이 넷이 된다.
 
-비교도 어려워진다. 네 주제가 나란히 서면 그것이 같은 질문의 네 답이라는 것을 화면이 말하지 못한다.
+네 주제가 나란히 서면 그것이 같은 질문의 네 답이라는 것을 화면이 말하지 못해 비교도 어려워진다.
 
 축을 주제 안에 두면 공통 기록은 축을 고르지 않고 두면 되고, 여러 구조에 걸치는 기록은 여러 축에 건다. 화면은 축을 나란히 세워 비교로 그린다.
 
@@ -46,10 +46,10 @@ source:
 
 ## 영향
 
-축의 이름·요약·결론이 기록에서 자동으로 나오지 않는다. 주제의 논지, 축의 요약과 결론은 사람이 쓰는 칸이고, 기록을 스무 개 붙여도 그 문장은 누가 고치기 전까지 그대로다.
+주제의 논지와 축의 이름·요약·결론은 기록에서 자동으로 나오지 않는다. 사람이 쓰는 칸이라 기록을 스무 개 붙여도 그 문장은 누가 고치기 전까지 바뀌지 않는다.
 
 홈의 비교 구역에서 줄은 문서가 아니라 축이다. 줄을 늘리려면 Studio 에서 축을 추가해야 한다.
 
 기록이 어느 축에 걸리는지를 담는 표에 외래키를 걸 수 없다. 기록이 종류마다 다른 테이블에 살기 때문이다.
 
-축이 붙은 기록 수가 적으면 「문서가 그대로 나온다」로 보인다. 축마다 기록이 하나씩이고 축 제목을 그 기록 제목과 비슷하게 적으면 그렇게 읽힌다.
+축에 걸린 기록이 하나뿐이면 축 제목과 그 기록 제목이 비슷해져 「문서가 그대로 나온다」로 보인다.

docs/TechLog/tech-log-studio/an-axis-inside-a-topic/question/openquestion-the-conclusion-line-does-not-follow-the-records.md

@@ -17,7 +17,7 @@ source:
 
 # 축의 결론 문장과 기록 수는 기록을 붙여도 따라오지 않는다
 
-홈의 비교 구역에서 줄은 문서가 아니라 축이다. 기록을 스무 개 붙여도 줄 수는 그대로이고, 줄에 보이는 결론 문장은 축에 손으로 쓴 글이라 누가 고치기 전까지 바뀌지 않는다. 주제 화면에는 축마다 기록 수가 붙는데 홈에는 없다.
+홈의 비교 구역에서 줄은 문서가 아니라 축이다. 기록을 스무 개 붙여도 줄 수는 늘지 않고, 줄에 보이는 결론 문장은 축에 손으로 쓴 글이라 누가 고치기 전까지 바뀌지 않는다. 주제 화면에는 축마다 기록 수가 붙는데 홈에는 없다.
 
 ## 관계
 
@@ -30,9 +30,9 @@ source:
 
 ## 사실
 
-홈의 비교 구역에서 한 줄은 축 하나다. 기록을 스무 개 붙여도 줄 수는 그대로다.
+홈의 비교 구역에서 한 줄은 축 하나다. 기록을 스무 개 붙여도 줄 수는 늘지 않는다.
 
-줄에 보이는 결론 문장은 축에 손으로 쓴 글이다. 기록을 붙여도 그 문장은 누가 고치기 전까지 그대로다.
+줄에 보이는 결론 문장은 축에 손으로 쓴 글이다. 기록을 붙여도 그 문장은 누가 고치기 전까지 바뀌지 않는다.
 
 주제 화면에는 축마다 「기록 N」이 붙는다. 홈에는 그 수가 없다.
 
@@ -63,7 +63,7 @@ DB 에 직접 넣은 초안을 누가 언제 검토하는가. 검토 전까지
 ## 선택지
 
 **홈 비교표에 기록 수를 붙인다**
-목록 호출이 이미 그 수를 실을 수 있으면 요청이 늘지 않는다. 결론 문장은 그대로 사람이 쓴다.
+목록 호출이 이미 그 수를 실을 수 있으면 요청이 늘지 않는다. 결론 문장은 여전히 사람이 쓴다.
 
 **결론 문장이 마지막으로 고쳐진 때를 함께 보인다**
 기록이 그 뒤에 늘었으면 낡았다는 것이 드러난다. 화면에 날짜가 하나 더 늘어난다.