DongHyeonkaandClaude Opus 5
a8ce0dda07
건너뛴 참조 다섯을 읽고 나서 다시 썼다 — 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>
4.6 KiB
kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | lastVerifiedOn | sourceRevision | source | |
|---|---|---|---|---|---|---|---|---|---|---|
| CASE | a-list-item-had-to-carry-the-whole-document | 결정에는 상세 화면이 없어 목록 항목이 문서 전체를 실어야 했다 | values-lost-between-boundaries | 값이 경계에서 사라진다 | TechLog | 게시 전 | 2026-09-04 | tech-log@2026-09-02 |
|
결정에는 상세 화면이 없어 목록 항목이 문서 전체를 실어야 했다
공개 결정 화면에서 제목 칸에 결정문 전문이 나오고, 요약이 없고, 줄바꿈이 전부 접히고, 영향과 근거가 늘 비어 있었다. 네 증상이 한 구조에서 나왔다 — 결정에는 상세 화면이 없고 공개 주소가 목록 위의 앵커다. 그래서 화면이 그리는 칸이 전부 목록 항목에 있어야 했다.
관계
- Studio 에서는 보이는데 공개 쪽만 비면 그 사이에 계약이 있다 이 사건이 그 신호의 예다.
- 계약은 앵커라고 적었고 만드는 쪽은 경로를 만들었다 같은 앵커 구조에서 난 주소 쪽 사건이다.
- 관계의 요약이 경계 세 곳을 지나며 사라졌다 같은 시기에 계약의 빈칸으로 난 다른 사건이다.
문제
결정은 상세 endpoint 가 없다. 공개 주소가 /projects/{slug}/decisions#{slug} 로 목록 위의 앵커다.
상세가 없으면 화면이 그리는 칸이 전부 목록 항목에 있어야 한다. 목록 항목에는 title·summary·consequences·evidence 가 빠져 있었다.
결론
네 증상이 전부 목록 항목의 빈칸에서 나왔다.
제목 칸 : statement 를 대신 썼다 요약 : 실을 칸이 없었다 줄바꿈 : 접혔다 영향과 근거 : 프론트가 빈 배열로 고정해 뒀다
DB 에는 작성자가 쓴 제목, 여러 줄 요약, 영향 4건이 그대로 있었다. 목록 항목이 화면이 그리는 칸을 전부 싣게 하고 네 곳을 이었다.
검증 환경
tech-log-design-package : 987c1b8 이후 tech-log-backend : 026460f 이후 tech-log-frontend : 31afb4d 이후 확인 방식 : DB 조회로 저장된 값을 확인하고 공개 화면과 대조
재현 조건
- Studio 에서 결정을 작성하고 제목·요약·영향을 채운다
- 게시한 뒤 프로젝트의 결정 목록을 공개 화면에서 연다
- 저장된 값과 화면에 그려진 값을 대조한다
본문
상세가 없으면 목록이 전부 실어야 한다
결정은 자기 화면을 갖지 않는다. 공개 라우트는 프로젝트의 결정 목록 하나이고, 개별 결정은 그 목록 위의 앵커로 간다.
앞선 종류들과 여기서 갈린다. Case 와 Reference 와 Question 은 상세 화면이 있어서 목록 항목이 가볍고 상세를 부르면 나머지가 온다. 결정에는 상세를 부를 곳이 없으므로 화면이 그리는 칸이 전부 목록 항목에 있어야 한다.
네 증상이 한 원인이었다
목록 항목에 title·summary·consequences·evidence 가 빠져 있었고, 화면 쪽이 없는 칸을 각자 메우고 있었다.
| 화면에서 무엇이 보였나 | 목록 항목에 무엇이 없었나 | 프론트가 무엇으로 메웠나 |
|---|---|---|
| 제목 자리에 결정문 전문 | title |
statement 를 제목 자리에 씀 |
| 요약 줄이 비어 있음 | summary |
아무것도 그리지 않음 |
| 영향과 근거가 늘 비어 있음 | consequences · evidence |
빈 배열로 고정 |
결정문은 한 문장이 아니라 문단일 수 있다. 제목 자리에 전문이 들어가면 목록의 한 줄이 문단 높이로 늘어난다.
줄바꿈은 원인이 달랐다. 마크다운이 아닌 칸의 줄바꿈을 화면이 접고 있었고, 그것은 목록 항목의 문제가 아니라 렌더링의 문제였다.
저장된 값은 그대로 있었다
데이터베이스를 조회하면 작성자가 쓴 제목과 여러 줄 요약과 영향 4건이 있었다. 어느 것도 화면까지 오지 못했다.
Studio 편집기에서는 그 값들이 다 보인다. 두 화면이 같은 데이터를 보는데 한쪽만 비었으므로, 다른 것은 그 사이에 놓인 계약이다.
화면 쪽에서 역으로 확인한다
이 부류는 응답에서 출발하면 보이지 않는다. 응답에 없는 칸을 찾는 일이기 때문이다.
화면이 그리는 칸을 먼저 적고 그 칸이 응답에 있는지 하나씩 맞춰야 한다. 상세 endpoint 가 없는 종류에서는 그 목록이 곧 문서 전체가 된다.
확인하지 못한 것
저장된 값이 그대로였다는 것은 조회로 확인했다. 그 시점의 화면 캡처는 남기지 않았다.