DongHyeonkaandClaude Opus 5
f6c825e858
주제 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>
3.8 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 에서 결정을 작성하고 제목·요약·영향을 채운다
- 게시한 뒤 프로젝트의 결정 목록을 공개 화면에서 연다
- 저장된 값과 화면에 그려진 값을 대조한다
본문
상세가 없으면 목록이 전부 실어야 한다
결정은 자기 화면을 갖지 않는다. 공개 라우트는 /projects/{slug}/decisions 하나이고, 개별 결정은 그 목록 위의 앵커로 간다.
이 구조에서는 화면이 그리는 칸이 전부 목록 항목에 있어야 한다. 상세를 부를 곳이 없기 때문이다.
네 증상이 한 원인이었다
ProjectDecisionItem 에 title 이 없어서 프론트가 statement 를 제목 자리에 썼다. 결정문은 한 문장이 아니라 문단일 수 있으므로 제목 자리에 전문이 들어갔다.
summary 가 없어서 요약 줄이 비었다. consequences 와 evidence 가 없어서 프론트가 그 둘을 빈 배열로 고정해 뒀다.
줄바꿈은 다른 이유였다. 마크다운이 아닌 칸의 줄바꿈을 화면이 접고 있었다.
저장된 값은 그대로 있었다
DB 를 조회하면 작성자가 쓴 제목과 여러 줄 요약과 영향 4건이 있었다. 어느 것도 화면까지 오지 못했다.
화면 쪽에서 역으로 확인한다
이 부류는 응답에서 출발하면 보이지 않는다. 응답에 없는 칸을 찾는 일이기 때문이다. 화면이 그리는 칸을 먼저 적고 그 칸이 응답에 있는지 하나씩 맞춰야 한다.
확인하지 못한 것
저장된 값이 그대로였다는 것은 조회로 확인했다. 그 시점의 화면 캡처는 남기지 않았다.