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>
96 lines
4.3 KiB
Markdown
96 lines
4.3 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: a-summary-vanished-at-three-boundaries
|
|
title: 관계의 요약이 경계 세 곳을 지나며 사라졌다
|
|
topic: values-lost-between-boundaries
|
|
topicName: 값이 경계에서 사라진다
|
|
project: TechLog
|
|
status: 게시 전
|
|
lastVerifiedOn: 2026-09-04
|
|
sourceRevision: tech-log@2026-09-02
|
|
source:
|
|
- final/document.md#§5.2
|
|
- final/document.md#§5.3
|
|
---
|
|
|
|
# 관계의 요약이 경계 세 곳을 지나며 사라졌다
|
|
|
|
관계 목록의 라벨을 고쳤는데 요약은 여전히 비어 있었다. 한 경계를 고치고 확인했더니 다음 경계가 버리고 있었고, 그것을 고치니 그다음이 버렸다. 세 번째는 계약에 담을 칸 자체가 없었다.
|
|
|
|
## 관계
|
|
|
|
- **공개 화면 한 줄이 그려지기까지 값이 지나는 경계 열한 개**
|
|
세 경계가 그중 어디인지가 그 개념에 있다.
|
|
- **한 경계를 고쳤으면 값의 여정 끝에서 확인한다**
|
|
이 사건에서 굳힌 규칙이다.
|
|
- **결정에는 상세 화면이 없어 목록 항목이 문서 전체를 실어야 했다**
|
|
같은 시기에 계약의 빈칸으로 난 다른 사건이다.
|
|
|
|
## 문제
|
|
|
|
관계 목록은 한 줄에 대상의 종류와 작성자가 쓴 이유와 대상의 요약을 보인다. 라벨은 고쳤는데 요약 칸이 계속 비어 있었다.
|
|
|
|
계약에는 요약이 있었다. DB 에도 값이 있었다. 화면까지 오지 못했다.
|
|
|
|
## 결론
|
|
|
|
값이 세 경계를 지나며 사라지고 있었다.
|
|
|
|
flattenRelations : 담지 않음 — 1차로 고침
|
|
렌더 모델로 변환 : 담을 칸 자체가 없었음
|
|
화면 목록으로 전달 : 또 버림
|
|
|
|
렌더 모델 계약(`ResolvedRelation`)에 요약 칸이 없었고 `additionalProperties: false` 라 실을 수도 없었다. 계약에 `summary` 를 더하고 — 이미 나가 있는 응답을 깨지 않으려고 required 에는 넣지 않고 — 세 경계를 모두 이었다.
|
|
|
|
그 과정에서 한 칸에 뭉쳐 있던 셋을 갈랐다. 대상의 종류는 `label`, 작성자가 쓴 이유는 `note`, 대상의 요약은 `summary` 다.
|
|
|
|
## 검증 환경
|
|
|
|
tech-log-frontend : a3ed23e 이후
|
|
tech-log-design-package : fa67a64 이후
|
|
tech-log-backend : 92679f5 이후
|
|
확인 방식 : 공개 화면의 관계 목록에서 세 값이 각각 나오는지 확인
|
|
|
|
## 재현 조건
|
|
|
|
1. 기록 둘을 관계로 잇고 이유를 적는다
|
|
2. 게시한 뒤 공개 화면에서 관계 목록을 본다
|
|
3. 라벨·이유·요약 세 값이 각각 나오는지 본다 — 하나라도 비면 그 값이 어느 경계에서 사라졌는지 역순으로 따라간다
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
## 세 번 버려졌다
|
|
|
|
```text
|
|
계약(요약 있음)
|
|
└─ flattenRelations 가 담지 않음 ← 1차로 고침
|
|
└─ 렌더 모델로 바꿀 때 버림 ← 담을 칸 자체가 없었다
|
|
└─ 화면 목록으로 넘길 때 또 버림
|
|
```
|
|
|
|
첫 번째를 고치고 화면을 봤을 때도 요약은 비어 있었다. 두 번째를 고치려고 보니 렌더 모델 계약에 담을 칸이 없었고, `additionalProperties: false` 라 계약을 고치지 않고는 실을 수 없었다.
|
|
|
|
## 계약에 칸을 더할 때 required 를 따로 판단한다
|
|
|
|
`ResolvedRelation` 에 `summary` 를 더하면서 required 에는 넣지 않았다. 이미 나가 있는 응답에는 그 칸이 없어서, required 로 올리면 배포 순서에 따라 검증이 깨진다.
|
|
|
|
## 한 칸에 셋이 뭉쳐 있었다
|
|
|
|
값을 잇고 나서 다른 문제가 보였다. 관계 한 줄이 답해야 하는 것이 셋인데 `reason` 한 칸을 지나고 있었다.
|
|
|
|
| 무엇 | 뜻 | 경로별로 어떻게 나왔나 |
|
|
|---|---|---|
|
|
| 대상의 종류 | 「근거」「관련 기준」 같은 분류 | 렌더 모델 경로: 작성자의 문장이 이 칸에 눌려 나옴 |
|
|
| 작성자가 쓴 이유 | 「다음에 무엇을 읽을지」의 답 | 공개 조회 경로: **아예 버려짐** |
|
|
| 대상의 요약 | 대상이 무엇인지 | — |
|
|
|
|
셋을 `label` · `note` · `summary` 로 갈랐다. 설명 칸에는 작성자가 쓴 문장이 있으면 그것을, 없으면 대상의 요약을 보인다. 요약은 대상을 설명하고 문장은 왜 지금 이것을 읽어야 하는지를 설명한다.
|
|
|
|
## 확인하지 못한 것
|
|
|
|
세 경로에서 무엇이 나오는지는 화면으로 확인했다. 세 경로 전부를 자동 검사로 고정하지는 않았다.
|
|
|
|
<!-- body:end -->
|