§1.4 로 세운 도메인·비즈니스 규칙을 그것이 실제로 설명하는 기록에 넣었다.
프로젝트가 문서 게시 파이프라인을 안 타는 이유 → 화면 다섯이 비어 있던 Case
홈 focus 설정이 FK 없이 사는 설계 → 「열린 질문이 없습니다」 Case
결정이 자기 화면을 안 갖는 이유 → 목록이 문서 전체를 실어야 했던 Case
게시가 단계마다 다른 코드로 거절하는 설계 → 화면이 추측 셋을 출력한 Case (반대 사례)
종류마다 애그리거트와 테이블이 다르다 → 매퍼가 종류를 판정해야 하는 Case
축을 지우면 연결만 끊고 주제를 지우면 거절하는 이유 → 축 Concept
개념이 문서 테이블에 얹힌다 → 열세 곳 Case
화면 상태와 도메인 상태가 원래 갈려 있었다 → 이름을 두 번 바꾼 Case
Case 본문 중앙값 675 → 1,342 자. 검사 넷 전부 통과한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SSOT 를 저장소에서 확인해 더 보강하고 그것으로 다시 썼다.
§7.2 참조 검사 SQL 을 문자열로 조립하는 실제 코드 — 컴파일러가 표 이름도
컬럼 이름도 보지 않는다는 것이 그 모양에서 드러난다
§11.2 section-heading-rank 가 미디어 쿼리 값을 먼저 걷어내는 이유(테스트 주석)
§16.1 질문 삭제는 참조가 둘뿐이라 같은 문제가 덜하다는 대조
Case 열 편과 Question 셋을 다시 썼다. Question 은 사실·가정·미지수·제약을 갈라
채우고 선택지마다 무엇을 감수하는지 적었다 — 오류 코드를 나누면 계약과 반입한 두
저장소가 함께 움직인다는 것처럼.
SSOT 62,643 → 68,319 자. 검사 넷 전부 통과한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
주제 11~13 을 다시 쓰고, Case 가 얇은 것들을 저장소에서 실물을 확인해 채웠다.
§13.4 ManagementClientSafeMessages — 삭제 관련 코드 여섯의 고정 문구와
원문 메시지를 내보내지 않는 이유(javadoc)
§16.1 다섯 참조가 전부 DOCUMENT_IN_USE 하나로 나가고, SSOT 가 인용한 영어 문장은
DeleteDocumentDraftUseCase 안에 남는 진단 메시지라 밖으로 나가지 않는다
§13.6 romanizeSyllable 실물과 음운 변동을 뺀 이유, 문서 slug 와 같은 정규식을 쓰는 이유
§15.4 check:types 가 도는 tsconfig 여섯 — app·node·test·recipes·web-worker·service-worker
SSOT 62,643 → 67,526 자. 인용한 코드는 전부 저장소에서 찾아 대조했다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
건너뛴 참조 다섯을 읽고 나서 다시 썼다 — from-ssot-to-records.md 의 「그림과 증거는
배정 대상이다」, code-tables-diagrams.md 의 표·코드 규칙, explaining.md 의 「이름을
댔으면 왜 있는지도 댄다」.
**SSOT 를 먼저 고쳤다.** §3.3 의 코드블록이 저장소와 달랐다 — PATH_PREFIX_KINDS 는
Record 표가 아니라 튜플 배열이고, 진짜 경로 표는 EXPLORE_KIND_PATHS 다. 저장소에서
확인해 실물로 바꾸고, javadoc 이 적어 둔 이유를 함께 옮겼다. §16.7 에 BRANCH_FIELDS 와
pathOf 실물을, §4.3 에 ContractRouteCoverageTest 의 javadoc 과 면제 상수 둘을 더했다.
62,643 → 65,737 자.
**계약에 ssot-assets·ssot-evidence 를 배정했다.** 그 절차를 건너뛰어서 SSOT 가 이미
가진 그림과 측정이 글감에 배정되지 않은 채였다. TechLog 12 글감, keycloak-session-store
는 그림 21장·증거 19건을 배정하고 붙일 글감이 없는 그림 4장은 이유를 계약에 적었다.
배정하자 검사기가 「배정한 증거를 기록이 쓰지 않는다」 4건을 드러냈다.
**주제 셋을 다시 썼다.**
hand-listed-kinds 중앙값 1,925 → 3,760 자
declared-but-not-implemented → 2,608 자
values-lost-between-boundaries → 2,602 자
게시된 기록은 keycloak 4,546 · n+1liner 3,190 이다. 표와 코드를 SSOT 에서 옮기고,
Reference 에 담을 수 없던 표(§5.5 의 여덟 자리)를 짝이 되는 Case 로 내렸다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
주제 13개 · Case 28 · Concept 5 · Reference 15 · Question 4 · Decision 4.
계약의 노드마다 종류가 요구하는 칸을 채우고, 본문이 있는 두 종류에는 SSOT 가 이미
그려 둔 도식 셋(value-boundaries · decision-path-404 · topic-variant-model)을
tech-log-studio/ 로 옮겨 붙였다. 새로 그린 그림은 없다.
검사 셋 전부 통과한다.
check_body.mjs 56 편 중 본문이 있는 33 편 PASS
check_prose.mjs 56 편 error 0
check_evidence.mjs --repo 포함 문제 없음
verify-tech-log-tree.py 프로젝트 5 · error 0 · warn 0
인용한 코드블록은 전부 SSOT 에서 찾아 대조했다. check_evidence.mjs 가 본문의 각 줄과
source 앵커와 계약 제목을 다시 확인한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
keycloak-session-store 와 TechLog 는 SSOT 만 있고 분해 계약이 없었다. 두 프로젝트
모두 후보를 처분과 함께 남기고 PROMOTE 만 주제로 올린다.
keycloak-session-store 주제 6 · 글감 33 · 후보 42 (제외 9)
TechLog 주제 13 · 글감 56 · 후보 91 (제외 35)
TechLog 는 저장소가 셋이라 sourceRepository 를 목록으로 적는다. 설계 패키지는 이
기계에 체크아웃이 없고 반입한 쪽의 MANIFEST.sha256 이 세 계약의 원본 리비전을
고정하므로 그것을 리비전으로 적었다. 검사기 둘이 그 모양을 읽게 고친다 —
verify-tech-log-tree.py 는 목록의 항목마다 path·revision·verified 를 보고,
check_evidence.mjs 는 체크아웃이면 git 으로, 매니페스트면 그 파일이 리비전을
적고 있는지로 대조한다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
DongHyeonka