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>
4.3 KiB
kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | lastVerifiedOn | sourceRevision | source | ||
|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | a-link-that-pointed-at-itself | 축 링크가 자기 자신을 가리켰고, 고친 뒤에는 백엔드를 먼저 배포했다 | addresses-frozen-at-publish-time | 주소가 만들어지고 굳어지는 곳 | TechLog | 게시 전 | 2026-09-04 | tech-log@2026-09-02 |
|
축 링크가 자기 자신을 가리켰고, 고친 뒤에는 백엔드를 먼저 배포했다
주제 화면의 네 줄은 링크인데 눌러도 아무 일이 없었다. 축의 주소를 주제 화면 안의 앵커로 바꿨더니, 정작 주제 화면에서는 그 링크가 자기 자신을 가리켰다. 결국 축에 자기 화면을 줬고, 그 화면을 만들고 백엔드를 프론트보다 먼저 배포해 사용자가 네 링크 전부 404 인 화면을 봤다.
관계
- 새 라우트는 프론트엔드를 먼저 배포한다 이 사건에서 정한 순서다.
- 우회를 남길 때는 되돌릴 조건을 함께 적는다 같은 주제 링크를 다루며 굳힌 기준이다.
- 축은 주제가 이름을 정하고, 기록은 종류와 아이디의 쌍으로 축에 걸린다 축에 자기 화면을 주려면 알아야 하는 구조다.
문제
주제 화면의 네 줄(SPA·Mediator·BFF·Forward-Auth)은 링크로 그려져 있었다. 눌러도 아무 일이 없었다.
처음에 /topics/{주제}/{축} 이라 적어 두었는데 그런 화면이 없었다.
결론
주소를 두 번 옮긴 끝에 축에 자기 화면을 줬다.
1차 : 축의 주소를 주제 화면 안의 앵커로 바꿨다 — 주제 화면에서는 그 링크가 자기 자신을 가리켰다 2차 : 축에 자기 화면을 줬다 — 목록 조회에 축 필터를 더해 걸러 낸다
축 slug 는 주제 안에서만 유일하므로 조회에서 주제까지 함께 맞춘다. 주제를 빼면 다른 주제의 같은 이름 축이 함께 걸린다.
같은 시기에 주제가 없는 기록이 이름 없는 주제 링크를 달고 있던 것도 고쳤다. 문서 머리말의 breadcrumb 과 탐색의 「주제 없음」 묶음 둘 다였고, 프로젝트 조각은 처음부터 조건부였는데 주제 쪽만 아니었다.
검증 환경
tech-log-frontend : 8828005 · 67a5491 tech-log-backend : 63eb177 · 6d3b68b tech-log-design-package : 71bab4c · b93d62a 확인 방식 : 배포본에서 주제 화면의 네 링크를 눌러 각각 어디로 가는지 확인
재현 조건
- 주제에 축을 넷 만들고 기록을 각 축에 건다
- 주제 화면에서 축 줄을 누른다
- 주소가 바뀌는지, 화면이 바뀌는지를 따로 본다
본문
주소만 바뀌고 화면은 그대로였다
처음에 축의 주소를 /topics/{주제}/{축} 이라 적어 두었는데 그런 화면이 없었다. 그래서 축의 주소를 주제 화면 안의 앵커로 바꿨다.
주제 화면에서 그 링크를 누르면 주소에 앵커가 붙는다. 화면은 이미 그 주제 화면이므로 아무것도 바뀌지 않는다.
축에 자기 화면을 줬다
목록 조회에 축 필터를 더하고 record_variant 로 거른다. 축 slug 는 주제 안에서만 유일하므로 주제까지 함께 맞춘다 — 주제를 빼면 다른 주제의 같은 이름 축이 함께 걸린다.
배포 순서로 만든 2차 사고
이 건에서 제가 만든 2차 사고: 축 화면을 만들고 백엔드를 프론트보다 먼저 배포했습니다. nginx 설정은 라우트 계약에서 생성되므로, 프론트가 배포되기 전까지
/topics/x/y는 404 입니다. 서버는 이미 그 주소를 내보내고 있었고, 사용자는 네 링크가 전부 404 인 화면을 봤습니다. 순서가 있습니다 — 새 라우트는 프론트가 먼저입니다.
주제가 없는 기록
같은 시기에 주제 없이 게시된 기록이 이름 없는 주제 링크를 달고 있었다. 문서 머리말의 breadcrumb 과 탐색의 「주제 없음」 묶음 둘 다였다. 프로젝트 조각은 처음부터 조건부였는데 주제 쪽만 아니었다.
확인하지 못한 것
축 slug 가 주제 안에서만 유일하다는 전제를 조회에 반영했다. 주제를 빼고 조회하는 경로가 남아 있는지는 세지 않았다.