docs(TechLog): Reference 15편의 규칙 표기를 게시된 기록에 맞추고 주제 6 을 다시 쓴다

게시된 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>

docs/TechLog/tech-log-studio/when-a-guard-can-be-trusted/reference/reference-revert-the-defect-and-watch-the-guard-fail.md

@@ -35,34 +35,40 @@ source:
 
 ## 규칙
 
-**결함을 되돌려 그 가드가 실제로 멈추는 것을 확인한 뒤 커밋한다**
+### 1. 결함을 되돌려 그 가드가 실제로 멈추는 것을 확인한 뒤 커밋한다
+
 계약에서 값을 빼고 대조 검사가 빨개지는지 본다. 매핑을 떼어 보고 그 연산 하나를 짚는지 본다.
 
-**가드가 짚는 대상이 하나인지 본다**
+### 2. 가드가 짚는 대상이 하나인지 본다
+
 전부를 짚으면 어디가 문제인지 알 수 없고, 결과가 곧 읽히지 않는다.
 
-**되돌릴 수 없는 것은 현재 상태를 대신 증거로 남긴다**
+### 3. 되돌릴 수 없는 것은 현재 상태를 대신 증거로 남긴다
+
 이미 마이그레이션으로 고친 데이터는 실패 상태를 다시 만들 수 없다. 그럴 때는 지금 고쳐져 있다는 것을 남긴다.
 
-**가드를 CI 에 묶는다**
+### 4. 가드를 CI 에 묶는다
+
 사람이 기억해서 돌리는 가드는 절반만 존재한다.
 
 ## 적용 조건
 
-재발 방지로 넣는 테스트·아키텍처 규칙·CI 게이트. 결함을 고치는 커밋에서 함께 넣을 때 걸린다.
+- 재발 방지로 테스트·아키텍처 규칙·CI 게이트를 넣을 때
+- 결함을 고치는 커밋에서 가드를 함께 넣을 때
+- 이미 있는 가드가 무엇을 잡는지 확인해야 할 때
 
 ## 예외
 
-결함을 되돌릴 수 없는 것 — 이미 마이그레이션으로 고친 데이터, 지난 배포에서만 나던 상태 — 은 현재 상태가 고쳐져 있음을 증거로 남긴다.
+- 결함을 되돌릴 수 없는 것 — 이미 마이그레이션으로 고친 데이터, 지난 배포에서만 나던 상태 — 은 현재 상태가 고쳐져 있음을 증거로 남긴다.
 
-기존 가드를 옮기거나 이름만 바꾸는 변경은 되돌려 확인하지 않아도 된다. 다만 옮긴 뒤에 한 번은 돌린다.
+- 기존 가드를 옮기거나 이름만 바꾸는 변경은 되돌려 확인하지 않아도 된다. 다만 옮긴 뒤에 한 번은 돌린다.
 
 ## 예시
 
-가드 셋을 각각 결함으로 되돌려 실제로 빨개지는 것을 확인한 기록을 남겼다.
+- 가드 셋을 각각 결함으로 되돌려 실제로 빨개지는 것을 확인한 기록을 남겼다.
 
-계약에서 CONCEPT 을 빼자 백엔드의 계약 대조 테스트가 빨개졌다.
+- 계약에서 CONCEPT 을 빼자 백엔드의 계약 대조 테스트가 빨개졌다.
 
-매핑을 떼어 보고 계약 대조 테스트가 그 연산 하나를 정확히 짚는 것을 확인했다.
+- 매핑을 떼어 보고 계약 대조 테스트가 그 연산 하나를 정확히 짚는 것을 확인했다.
 
-굵기 선언을 빼 보고 제목 급 검사가 실제로 멈추는 것을 확인했다.
+- 굵기 선언을 빼 보고 제목 급 검사가 실제로 멈추는 것을 확인했다.

docs/TechLog/tech-log-studio/when-a-guard-can-be-trusted/reference/reference-what-a-person-must-run-before-deploying.md

@@ -35,37 +35,43 @@ CI 에 묶이지 않은 검증이 남아 있으면 그것을 돌리는 것은
 
 ## 규칙
 
-**프론트는 다섯 개를 다 돌린다**
+### 1. 프론트는 다섯 개를 다 돌린다
+
 타입 검사 · lint · 단위 테스트 · 컴포넌트 테스트 · 화면 테스트다. 화면 테스트는 단위 테스트 명령이 돌리지 않는다.
 
-**타입 검사는 프로젝트를 순회하는 명령으로 돌린다**
+### 2. 타입 검사는 프로젝트를 순회하는 명령으로 돌린다
+
 루트 tsconfig 를 직접 부르는 명령은 한 파일도 검사하지 않고 성공한다.
 
-**백엔드는 커밋한 뒤에 빌드한다**
+### 3. 백엔드는 커밋한 뒤에 빌드한다
+
 빌드 산출물 이름에 커밋 해시가 들어간다. 작업 트리가 더러우면 해시가 달라져 stale 산출물 검사가 멈춘다.
 
-**테스트를 npm 이나 npx 로 감싸 돌리지 않는다**
+### 4. 테스트를 npm 이나 npx 로 감싸 돌리지 않는다
+
 `npm_config_*` 환경 변수가 설정되어 CI 워크플로 생성 테스트가 실패한다. 그 변수를 지우고 실행기를 직접 부른다.
 
 ## 적용 조건
 
-CI 에 묶이지 않은 검증이 남아 있는 저장소에서 배포 직전에 하는 일.
+- CI 에 묶이지 않은 검증이 남아 있는 저장소에서 배포 직전에 하는 일
+- 명령이 여럿이고 그중 일부만 도는 것이 가능할 때
+- 빌드 산출물이 작업 트리 상태에 따라 달라지는 저장소에서
 
 ## 예외
 
-CI 가 그 명령을 돌리면 이 목록에서 뺀다.
+- CI 가 그 명령을 돌리면 이 목록에서 뺀다.
 
-환경 때문에 실패하는 것은 실패로 세지 않는다. 하위 프로세스를 띄우는 세 케이스는 이 환경에서 실패하고 같은 리비전의 다른 실행에서도 똑같이 재현되므로 코드 변경과 무관하다.
+- 환경 때문에 실패하는 것은 실패로 세지 않는다. 하위 프로세스를 띄우는 세 케이스는 이 환경에서 실패하고 같은 리비전의 다른 실행에서도 똑같이 재현되므로 코드 변경과 무관하다.
 
 ## 예시
 
-프론트 다섯 명령 :
+- 프론트 다섯 명령 :
 `npm run check:types`
 `npm run lint`
 단위 · 컴포넌트 · 화면 테스트
 
-백엔드 : 커밋한 뒤 stale 산출물을 지우고 빌드한다. 이 순서를 몰라 두 번 헤맸다.
+- 백엔드 : 커밋한 뒤 stale 산출물을 지우고 빌드한다. 이 순서를 몰라 두 번 헤맸다.
 
-설계 패키지 : 계약 자체의 유효성 · 세 계약 사이의 정합 · 프론트와 백엔드가 아는 종류와 오류 코드가 같은지, 셋을 돌린다.
+- 설계 패키지 : 계약 자체의 유효성 · 세 계약 사이의 정합 · 프론트와 백엔드가 아는 종류와 오류 코드가 같은지, 셋을 돌린다.
 
-테스트 JVM 힙이 기본값이면 컨텍스트 캐시와 아키텍처 검사와 컨테이너가 겹치면서 메모리가 모자란다. 증상이 테스트 실패가 아니라 실행기를 완료할 수 없다는 메시지라 원인을 가린다.
+- 테스트 JVM 힙이 기본값이면 컨텍스트 캐시와 아키텍처 검사와 컨테이너가 겹치면서 메모리가 모자란다. 증상이 테스트 실패가 아니라 실행기를 완료할 수 없다는 메시지라 원인을 가린다.