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.5 KiB
kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | lastVerifiedOn | sourceRevision | source | |
|---|---|---|---|---|---|---|---|---|---|---|
| CASE | records-disappeared-without-a-trace | 매퍼가 null 을 돌려주고 호출부가 걸러 내, 기록이 조용히 사라졌다 | failure-drawn-as-absence | 실패를 없음으로 그린다 | TechLog | 게시 전 | 2026-09-04 | tech-log@2026-09-02 |
|
매퍼가 null 을 돌려주고 호출부가 걸러 내, 기록이 조용히 사라졌다
프로젝트 기록 목록에서 Open Question 이 보이지 않았다. 이 목록은 탐색의 지식 목록과 응답 모양이 다른데 그쪽 매퍼를 그대로 쓰고 있었다. 그 매퍼는 두 종류가 아니면 null 을 돌려주고 호출부가 걸러 내므로, 질문과 개념은 오류도 빈 줄도 남기지 않고 사라진다.
관계
- 화면은 못 읽은 것을 없다고 말하지 않는다 같은 부류를 다루는 규칙이다.
- 개념을 하나 더하자 열세 곳이 그것을 조용히 삼켰다 이 매퍼가 그 열세 곳 중 하나다.
- 합성 루트에 테스트가 없어 공개 사이트 전체가 오류 화면이었다 스텁 때문에 매핑이 검사되지 않던 다른 사건이다.
문제
프로젝트 화면의 기록 목록에 CASE 와 REFERENCE 만 나왔다. 같은 프로젝트에 게시된 질문과 개념이 목록에 없었다.
오류는 없었다. 목록이 한 줄 짧아질 뿐이라 눈으로는 알아채기 어렵다.
결론
프로젝트 기록 목록은 탐색의 지식 목록과 응답 모양이 다른데 지식 목록의 매퍼를 그대로 쓰고 있었다.
그 매퍼는 CASE 나 REFERENCE 가 아니면 null 을 돌려준다. 호출부가 filter 로 걸러 내므로 그 항목은 목록에서 없어진다.
증상 : 목록이 한 줄 짧아진다 오류 : 없음 빈 줄 : 없음
응답 모양에 맞는 매퍼를 쓰고 모든 종류를 싣게 고쳤다. 요약과 주제와 게시일도 함께 실었다.
검증 환경
tech-log-frontend : 77125d1 tech-log-backend : f0407d9 — 목록이 요약·주제·게시일을 싣게 함 tech-log-design-package : 76a7ccb 확인 방식 : 프로젝트에 종류별로 기록을 게시하고 목록에 전부 나오는지 확인
재현 조건
- 한 프로젝트에 CASE·REFERENCE·QUESTION·CONCEPT 을 각각 하나씩 게시한다
- 프로젝트 화면의 기록 목록을 연다
- 네 종류가 다 나오는지 센다
본문
null 을 돌려주고 걸러 내면 흔적이 없다
매퍼가 아는 종류가 아니면 null 을 돌려준다. 호출부는 그 목록에서 null 을 걸러 낸다.
이 조합에서는 오류가 나지 않고 빈 줄도 생기지 않는다. 목록의 길이만 줄어든다. 목록에 몇 개가 있어야 하는지 아는 사람만 알아챌 수 있다.
응답 모양이 다른 목록에 다른 매퍼를 썼다
프로젝트 기록 목록과 탐색의 지식 목록은 응답 모양이 다르다. 프로젝트 쪽은 관계 항목을 그대로 실어 요약도 주제도 게시일도 없었고, 지식 목록은 처음부터 그 칸들을 갖고 있었다.
모양이 다른데 매퍼를 공유하면서 종류 판정까지 그쪽 것을 따랐다.
고친 것
응답 모양에 맞는 매퍼를 쓰고 모든 종류를 싣게 했다. 목록 항목에 요약과 주제와 게시일을 더해 「제목만 있고 가운뎃점만 남은」 줄을 없앴다.
확인하지 못한 것
null 을 돌려주고 호출부가 거르는 매퍼가 다른 목록에도 남아 있는지는 세지 않았다.