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>
82 lines
4.0 KiB
Markdown
82 lines
4.0 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: an-operation-you-can-see-but-cannot-call
|
|
title: 타입에는 보이는데 부를 수 없는 연산이 네 번 나왔다
|
|
topic: declared-but-not-implemented
|
|
topicName: 계약에 선언만 있고 구현이 없다
|
|
project: TechLog
|
|
status: 게시 전
|
|
sourceRevision: tech-log@2026-09-02
|
|
source:
|
|
- final/document.md#§4.4
|
|
---
|
|
|
|
# 타입에는 보이는데 부를 수 없는 연산이 네 번 나왔다
|
|
|
|
계약에서 타입이 생성되므로 에디터에서는 그 연산이 멀쩡히 보인다. 기여 목록에 등록하지 않으면 실행할 때 부를 수가 없고, 게이트웨이는 다른 연산으로 떨어진다. 개념 화면이 질문 조회를 부르고 개념 삭제가 질문 삭제를 불렀다. 같은 누락을 네 번 만났다.
|
|
|
|
## 관계
|
|
|
|
- **계약에 선언만 있고 구현이 없어 화면 다섯 곳이 비어 있었다**
|
|
이쪽은 서버에 구현이 없었고, 여기서는 프론트가 등록을 빠뜨렸다.
|
|
- **계약과 구현은 서버와 화면 양쪽에서 전수 대조한다**
|
|
이 누락을 잡는 가드가 그 기준에 있다.
|
|
- **구현이 종류를 좁게 적어도 넓은 포트를 만족했다**
|
|
같은 개념 삭제 경로에서 타입 검사가 통과시킨 다른 결함이다.
|
|
|
|
## 문제
|
|
|
|
관리 계약의 연산은 `tech-log-management-contract-contribution.ts` 에 등록해야 실행 시 부를 수 있다. 계약에서 타입은 생성되므로 등록을 빠뜨려도 컴파일은 통과한다.
|
|
|
|
등록되지 않은 연산을 부르면 게이트웨이가 그 연산을 찾지 못하고 옆의 분기로 떨어진다. 그래서 증상이 「없는 연산」이 아니라 「다른 연산이 실행됨」으로 나온다.
|
|
|
|
## 결론
|
|
|
|
네 번 났고 전부 같은 원인이었다.
|
|
|
|
`getPublicConcept` : 개념 화면이 질문 조회를 불렀다
|
|
`deleteConceptDraft` : 개념 삭제가 질문 삭제를 불렀다
|
|
`listStudioQuestions` · `listStudioProjectDecisions` : 홈 편집기가 빈 목록을 그렸다
|
|
축(variant) CRUD 네 연산 : 축 화면이 데이터를 받지 못했다
|
|
|
|
공개 계약은 전수 대조하고, 관리 계약은 「한 종류만 빠진 항목」을 보는 가드를 뒀다. 깨진 것이 늘 그 모양이었다.
|
|
|
|
## 검증 환경
|
|
|
|
tech-log-frontend : 15e6ea8 이후
|
|
계약 : studio-management-v1 86 operation · public-v1 20 operation
|
|
확인 방식 : 계약이 선언한 연산과 기여 목록을 대조하는 테스트
|
|
|
|
## 재현 조건
|
|
|
|
1. 계약에 연산을 더하고 타입을 생성한다
|
|
2. 기여 목록에 등록하지 않은 채 그 연산을 부르는 화면을 연다
|
|
3. 개발자도구 네트워크에서 실제로 나가는 경로를 본다 — 등록된 다른 연산의 경로가 나간다
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
## 등록하지 않으면 옆으로 떨어진다
|
|
|
|
개념 삭제가 계속 질문 삭제 경로로 나갔고, 배포된 번들에서 서버 로그에 `DELETE /api/v1/studio/questions/{id} 404` 가 찍혔다. 개념 상세 주소도 마찬가지로 질문 조회를 불러 404 를 받았다.
|
|
|
|
게이트웨이가 옆 분기로 떨어지므로 서버는 정상적으로 응답하고, 다만 다른 기록을 다룬다.
|
|
|
|
## 네 번의 누락
|
|
|
|
- `getPublicConcept` — 개념 화면이 질문 조회를 불렀다
|
|
- `deleteConceptDraft` — 개념 삭제가 질문 삭제를 불렀다
|
|
- `listStudioQuestions` 와 `listStudioProjectDecisions` — 홈 편집기가 빈 목록을 그렸다
|
|
- 축(variant) CRUD 네 연산 — 축 화면이 데이터를 받지 못했다
|
|
|
|
## 가드 둘
|
|
|
|
축 CRUD 를 더한 커밋에서 가드를 둘 넣었다. 공개 계약은 전수 대조한다 — 계약이 선언한 연산이 기여 목록에 전부 있는지 본다. 관리 계약은 86 operation 이라 전수 대조가 무겁고, 대신 「한 종류만 빠진 항목」을 본다. 깨진 것이 늘 그 모양이었기 때문이다.
|
|
|
|
## 확인하지 못한 것
|
|
|
|
관리 계약 쪽 가드는 종류가 빠진 것만 본다. 연산 전체를 빠뜨리는 경우는 이 가드가 잡지 않고, 그 상태를 만들어 확인하지도 않았다.
|
|
|
|
<!-- body:end -->
|