§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>
주소가 게시 시점에 굳어 저장되는 구조, 축 링크를 두 번 옮긴 순서, 한글 slug 가
간헐적으로 보인 두 가지 어긋남을 표로 갈랐다. 화면이 실패를 없음으로 그릴 때 작성
도구에서 왜 더 오래 숨는지, Promise.all 이 거절과 던짐에서 다른 경로를 타는 이유를
채웠다. CSS module 이 왜 전역 규칙에 닿지 않는지, 403 과 404 가 원인을 어떻게
좁혔는지도 적었다.
link-audit.py 를 감사 Case 의 evidence 로 걸어 배정한 증거 하나를 메웠다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
게시된 Reference 15편이 전부 규칙을 `### N. 제목` 으로 쓰고 적용 조건·예외·예시를 항목으로
쓴다. 내 15편은 규칙을 `**굵게**` 로, 나머지 셋을 문단으로 쓰고 있었다 — Studio 의
rules[]·applyWhen[]·exceptions[]·examples[] 는 배열이라 문단으로 두면 항목이 하나로 접힌다.
규칙 68개를 `### N. 제목` 으로 바꿨다 (편당 3~7개, 게시된 것은 4~10개)
적용 조건·예외·예시를 항목으로 갈랐다. 한 항목뿐이던 아홉 편은 조건을 나눠 적었다
주제 6 은 본문을 다시 썼다 — location = 이 정확히 일치하는 경로만 잡아 27개가 얼어붙은
구조, 여덟 곳이 우는 시점을 셋으로 가른 표, digest 를 다시 계산할 때 옛 값을 먼저
재현하는 이유.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
what-the-compiler-lets-through 중앙값 2,096 → 2,590 자
seams-no-test-crosses → 3,091 자
bivariance 가 왜 느슨한 판정을 받는지, never 캐스트가 왜 아무것도 요구하지 않는지처럼
「이름을 댔으면 왜 있는지도 댄다」를 채웠다. 네 가지가 각각 무엇을 통과시키고 어디서
드러났는지를 표로 갈랐다. 검사 넷 중 무엇이 SQL 을 실제로 돌리는지도 표로 세웠다.
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>
writing-as-the-person-who-did-it 을 서브에이전트 셋으로 나눠 56편에 적용했다.
56편 중 20편만 고쳤다 — 나머지 36편은 SSOT 를 절 단위로 대조했을 때 옮길 흔적이
이미 옮겨져 있었거나 없었다. 없는 목소리를 채우지 않는다.
옮긴 것은 전부 SSOT 의 어느 절에서 왔는지 댈 수 있다.
§3.4 「눈으로 찾을 일이 아니었다」— 세 계약을 파싱해 뽑은 이유
§4.3 구현하지 않기로 한 것과 빠뜨린 것은 다르다
§8.5 표의 마지막 줄을 더할 때 이 목록을 또 빠뜨렸다
§9.4 「왜 주제 링크가 탐색으로 가지?」— 우회를 남겨 두면 계속 나온 질문
§11.3 「세 버튼」을 실제 이름으로 되돌리고 두 언어가 섞인 것을 그 자리에
§12.2 막지 않은 대신 메모리에 남긴 것
§13.1 여섯 벌 인용이 어느 커밋이 짚은 말인지
§13.3 고쳐 쓴 첫 안이 거절당한 것과 사용자가 고른 말 두 쌍
§14.3 「문서가 그대로 나온다」는 구조 차이가 아니라 내용 양의 차이라는 정정
§16.1 삭제가 막힌 실제 기록 이름과 그것을 막은 프로젝트 링크
§16.9 주제 논지와 축 결론이 AI 가 써서 DB 에 직접 넣은 미검토 초안이라는 것
§17.5 바운딩 박스로 잘못 지목한 대상이 「판단 기준」이었다는 것
검증 환경의 커밋 해시 하나가 틀려 있었다(ca1cfa2 → ca1fc92). SSOT §13.1 과
부록 A 가 적은 값이고 저장소에 그 커밋이 있다.
검사 넷 전부 통과한다 — check_prose 56편 error 0 · check_body PASS ·
check_evidence --repo 문제 없음 · verify-tech-log-tree 프로젝트 5 error 0 warn 0.
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>
