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/failure-drawn-as-absence/reference/reference-an-expected-failure-must-not-be-counted-as-a-failure.md

@@ -31,30 +31,36 @@ source:
 
 ## 규칙
 
-**기대된 실패는 조건을 적어 뺀다**
+### 1. 기대된 실패는 조건을 적어 뺀다
+
 미리보기가 아직 없는 문서는 현재 미리보기를 물으면 404 를 답하고, 화면은 그것을 「미리보기를 만드세요」로 바꾼다. 이런 응답은 실패가 아니다.
 
-**뺀 나머지는 전부 실패시킨다**
+### 2. 뺀 나머지는 전부 실패시킨다
+
 조건에 걸리지 않는 4xx 와 5xx 는 모두 스윕을 실패시킨다.
 
-**조건을 적을 수 없으면 빼지 않는다**
+### 3. 조건을 적을 수 없으면 빼지 않는다
+
 조건 없이 빼면 진짜 실패도 같이 빠진다.
 
-**뺀 조건을 사람이 읽을 수 있는 곳에 남긴다**
+### 4. 뺀 조건을 사람이 읽을 수 있는 곳에 남긴다
+
 왜 그 응답이 기대된 것인지 적혀 있지 않으면 다음 사람이 조건을 넓힌다.
 
 ## 적용 조건
 
-배포 뒤 전 화면을 훑는 스윕처럼 결과를 사람이 훑어보는 검사. 정상 동작이 오류 상태 코드로 나타나는 화면이 있는 서비스에서 걸린다.
+- 배포 뒤 전 화면을 훑는 스윕처럼 결과를 사람이 훑어보는 검사를 만들 때
+- 정상 동작이 오류 상태 코드로 나타나는 화면이 있는 서비스에서
+- 같은 빨간 줄이 매번 남기 시작했을 때
 
 ## 예외
 
-기계가 판정하고 사람이 결과를 읽지 않는 검사라면 빨간 줄이 쌓여도 무뎌지지 않는다. 그래도 통과 기준은 정해야 한다.
+- 기계가 판정하고 사람이 결과를 읽지 않는 검사라면 빨간 줄이 쌓여도 무뎌지지 않는다. 그래도 통과 기준은 정해야 한다.
 
 ## 예시
 
-미리보기가 없는 문서의 404 를 스윕이 실패로 셌다. 건강한 배포 아래에 매번 같은 빨간 줄이 남았다.
+- 미리보기가 없는 문서의 404 를 스윕이 실패로 셌다. 건강한 배포 아래에 매번 같은 빨간 줄이 남았다.
 
 > 매번 늑대를 외치는 검사는 읽히지 않게 되고, 진짜 실패가 그 옆에 눈에 띄지 않은 채 앉아 있게 된다.
 
-로그인 전 세션 탐침의 401 도 같은 부류라 같은 조건으로 제외하고, 나머지 4xx·5xx 는 전부 스윕을 실패시킨다.
+- 로그인 전 세션 탐침의 401 도 같은 부류라 같은 조건으로 제외하고, 나머지 4xx·5xx 는 전부 스윕을 실패시킨다.

docs/TechLog/tech-log-studio/failure-drawn-as-absence/reference/reference-say-you-could-not-read-it.md

@@ -32,32 +32,39 @@ source:
 
 ## 규칙
 
-**요청이 실패하면 실패했다고 적는다**
+### 1. 요청이 실패하면 실패했다고 적는다
+
 빈 배열로 삼키지 않는다. 0건과 실패는 다른 문구를 쓴다.
 
-**한 칸의 실패가 옆 칸을 끌고 내려가지 않게 한다**
+### 2. 한 칸의 실패가 옆 칸을 끌고 내려가지 않게 한다
+
 여러 목록을 하나로 묶어 기다리면 한쪽의 실패가 전체를 실패로 만든다. 따로 읽고 실패한 목록에만 적는다.
 
-**거절만 잡는 처리로는 부족하다**
+### 3. 거절만 잡는 처리로는 부족하다
+
 호출이 동기적으로 던지면 그 처리기를 지나지 않는다. 던지는 경로도 잡는다.
 
-**항목을 걸러 낼 때 걸러 낸 것을 세어 둔다**
+### 4. 항목을 걸러 낼 때 걸러 낸 것을 세어 둔다
+
 매퍼가 모르는 종류에 빈 값을 돌려주고 호출부가 거르면, 목록이 한 줄 짧아지는 것 말고는 흔적이 없다.
 
 ## 적용 조건
 
-목록·요약·카운트처럼 「비어 있음」이 정상값이라 실패와 구분되지 않는 화면. 작성 도구에서 특히 걸린다 — 작성자가 자기 작업물과 화면을 대조하기 때문이다.
+- 목록·요약·카운트처럼 「비어 있음」이 정상값이라 실패와 구분되지 않는 화면을 만들 때
+- 작성 도구를 만들 때. 작성자가 자기 작업물과 화면을 대조하므로 오독이 곧바로 작업 판단이 된다
+- 한 화면이 여러 목록을 함께 받아 그릴 때
+- 매퍼가 모르는 값에 빈 값을 돌려주고 호출부가 그것을 거를 때
 
 ## 예외
 
-정말로 0건인 것과 못 읽은 것을 구분할 수 없는 화면이라면 그 구분을 먼저 만든다. 구분 없이 문구만 바꾸면 0건이 실패로 읽힌다.
+- 정말로 0건인 것과 못 읽은 것을 구분할 수 없는 화면이라면 그 구분을 먼저 만든다. 구분 없이 문구만 바꾸면 0건이 실패로 읽힌다.
 
-읽는 사람이 그 데이터를 만들지 않는 화면 — 공개 조회 — 에서는 실패를 화면 전체의 오류로 다뤄도 된다.
+- 읽는 사람이 그 데이터를 만들지 않는 화면 — 공개 조회 — 에서는 실패를 화면 전체의 오류로 다뤄도 된다.
 
 ## 예시
 
-「이 프로젝트에 열린 질문이 없습니다」가 적혀 있는 동안 그 프로젝트에는 질문이 넷 있었고 공개 사이트에도 나오고 있었다.
+- 「이 프로젝트에 열린 질문이 없습니다」가 적혀 있는 동안 그 프로젝트에는 질문이 넷 있었고 공개 사이트에도 나오고 있었다.
 
-탭 하나를 못 받아도 탭 줄과 나머지 탭은 그대로 그리고, 못 받은 탭에는 못 받았다고 적는다.
+- 탭 하나를 못 받아도 탭 줄과 나머지 탭은 그대로 그리고, 못 받은 탭에는 못 받았다고 적는다.
 
-매퍼가 모르는 종류에 빈 값을 돌려주고 호출부가 걸러 내, 질문과 개념이 목록에서 사라졌다.
+- 매퍼가 모르는 종류에 빈 값을 돌려주고 호출부가 걸러 내, 질문과 개념이 목록에서 사라졌다.