DongHyeonkaandClaude Opus 5
6feee5ba57
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>
4.7 KiB
kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | lastVerifiedOn | sourceRevision | source | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | eight-places-a-single-route-touches | 라우트 하나가 건드리는 여덟 곳과, 그것들이 우는 시점 | one-route-many-hand-kept-lists | 라우트 하나가 울리는 손 목록 | TechLog | 게시 전 | 2026-09-04 | tech-log@2026-09-02 |
|
라우트 하나가 건드리는 여덟 곳과, 그것들이 우는 시점
라우트를 하나 더하면 여덟 곳이 같이 운다. 어떤 것은 빌드 직전에, 어떤 것은 배포 직전에, 어떤 것은 배포 뒤에 운다. 개념 라우트를 더한 커밋이 그 목록을 남겼다.
관계
- nginx 가 모르는 라우트는 새로고침에서 404 다 이 목록에서 배포 뒤에 우는 항목의 사건이다.
- 라우트에 딸린 목록은 라우트 계약에서 유도하고, 유도할 수 없는 것은 대조 검사를 둔다 이 목록을 다루는 기준이다.
- 가드는 작동했는데 제가 그것을 돌리지 않아 두 번 새어 나갔다 이 목록을 빠뜨린 뒤 게이트가 빨간 채로 지나간 사건이다.
문제
라우트 하나를 더하면 그 라우트를 아는 곳이 여덟이다. 어느 하나를 빠뜨리면 우는 시점이 제각각이라, 빠뜨린 것을 알아채는 시점도 제각각이다.
결론
여덟 곳과 우는 시점이 갈린다.
빌드 매니페스트 단계 : vite chunk 이름 표 배포 직전 CI : 아티팩트 개수 상수 · 수동 접근성 증거 개수 · 게이트 집합의 sha256 배포 뒤 : nginx 서빙 패턴 그 밖 : 라우트 계약 · 런타임 등록 · 메시지 카탈로그
청크 이름 표는 다섯 검사 안에서 대조하게 했다. 게이트 기준값 셋은 여전히 손으로 움직이고, 옛 값을 먼저 재현해 계산 방법을 확인한 뒤 갱신한다.
검증 환경
tech-log-frontend : 048c1b2 · 197db74 · fe6b56a CI : FE-GATE-009 — 라우트마다 수동 접근성 증거 1개 확인 방식 : 라우트를 더한 커밋 넷에서 기준값이 어떻게 움직였는지 대조
재현 조건
- 라우트를 하나 더하고 vite chunk 이름 표에는 넣지 않는다
- 빌드한다 — 번들은 만들어지고 매니페스트 단계에서 멈춘다
- 표에 넣고 CI 기준값은 그대로 둔다 — 게이트가 거절한다
본문
여덟 곳
라우트 계약 tech-log-route-contract.ts
런타임 등록 route-runtime-contract
메시지 카탈로그 화면 제목·설명
nginx 서빙 패턴 tech-log-serving-contract.json → 생성된 nginx conf
코드 분할 청크 vite.config.ts 의 chunk 이름 표
CI 게이트 FE-GATE-009 라우트마다 수동 접근성 증거 1개
CI 게이트 아티팩트 기준선 정확한 개수를 고정
CI 게이트 형상 digest 게이트 집합의 sha256
우는 시점이 다르다
주제 편집 화면을 더하고 청크 이름 표를 빠뜨렸더니 번들은 만들어지는데 빌드 매니페스트 단계에서 Missing built route chunk: TECH_LOG_STUDIO_TOPIC_EDIT 로 멈췄다. 검사 다섯 개를 다 통과한 뒤 배포 직전에야 드러났다.
이 표도 손으로 나열한 목록이므로 다섯 검사 안에서 대조하게 했다.
게이트 기준값 셋은 라우트마다 움직인다
FE-GATE-009 는 설치된 라우트마다 수동 접근성 증거를 하나씩 요구하고, 그 집합이 정확히 일치하지 않으면 거절한다.
| 커밋 | 라우트 | 아티팩트 기준선 | 증거 개수 | digest |
|---|---|---|---|---|
16e5b9f |
/studio/projects/:id |
132 → 133 | 111 → 112 | 187dbd96… 재계산 |
84d72c4 |
/studio/releases/:id |
133 → 134 | 112 → 113 | f9e7e521… 재계산 |
048c1b2 |
/concepts/:slug |
+1 | +1 | fb138e7c… 재계산 |
fe6b56a |
/topics, /topics/:s/:v, /studio/topics/:id |
135 → 138 | 114 → 117 | 87a22f68… 재계산 |
표의 마지막 줄인 주제 화면 셋을 더할 때는 이 목록을 또 빠뜨렸다. 게이트가 빨간 채로 여러 커밋을 지나갔고, 결정 404 를 고치던 fe6b56a 에서야 함께 맞췄다.
digest 를 다시 계산할 때는 매번 이전 gates.json 에서 옛 상수를 먼저 재현해 계산 방법이 맞는지 확인한 뒤 새 파일을 해싱했다. 그렇게 하지 않으면 계산이 달라져서 새 값이 나온 것과 파일이 바뀌어서 새 값이 나온 것을 구분할 수 없다.
확인하지 못한 것
게이트 기준값 셋은 여전히 손으로 움직인다. 옛 값을 먼저 재현하는 절차는 사람이 기억해야 하고 검사가 강제하지 않는다.