DongHyeonkaandClaude Fable 5.1
b25357c48a
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다 - 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5 (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를 techviz 로 만들었다 - 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs 돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다. Concept 이 인용한 코드가 SSOT 에 없어 뺐다 - candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
4.2 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | registry-column-too-short-for-its-own-path | 레지스트리 컬럼이 38자 경로에서 짧아 "더 짧은 경로를 적는" 우회를 유혹했다 | schema-ownership-and-capability-streams | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:registry-column-too-short-for-its-own-path | 2026-09-01 |
|
|
|
레지스트리 컬럼이 38자 경로에서 짧아 "더 짧은 경로를 적는" 우회를 유혹했다
능력 스키마 레지스트리의 스트림 경로 컬럼이 32자였다. 실제 스트림 경로가 그보다 길어 거절됐고, 오류 메시지는 컬럼 이름을 부르지 이유를 말하지 않았다.
관계
- 독립 Flyway 스트림과 baseline version 0 이 레지스트리가 기록하는 대상이다.
- 두 트리가 다 V1부터 번호를 매겨 공유 history가 하나를 건너뛸 수 있었다 스트림 경로가 길어진 이유와 연결된다.
문제
능력 스키마 레지스트리는 각 능력의 스키마 스트림 경로를 기록한다. 그 컬럼이 32자였다.
능력별 스트림 경로는 그보다 길다. 능력 이름과 디렉터리 구조가 경로에 들어가기 때문이다.
결론
컬럼이 자기가 기록해야 할 경로보다 짧았다.
이 상태의 위험은 실패 자체가 아니라 우회의 유혹이다. 오류가 컬럼 길이를 말하므로, 가장 쉬운 대응은 경로를 짧게 바꾸는 것이다. 그러면 경로가 구조를 반영하지 않게 되고 다음 능력에서 같은 문제가 다시 난다.
수정은 컬럼을 넓히는 것이었다. 그리고 두 위치가 같은 테이블을 만들기 때문에 양쪽 다 넓혀야 했다.
마이그레이션 헤더가 그 이유를 적는다. 한쪽으로만 마이그레이션한 배포는 여전히 32자를 넘는 스트림 경로를 거절하고, 그 오류는 이유가 아니라 컬럼 이름을 부른다는 것이다.
번호 선택에도 근거가 있다. 두 트리가 샘플 컴포지션에서 하나의 위치 목록으로 병합되므로 버전 공간을 공유한다. 샘플이 이미 몇 개 번호를 갖고 있어서 그것들을 피해야 했다. 중복 버전은 Flyway 가 해결하는 병합 충돌이 아니라 기동 거부다.
검증 환경
데이터베이스 : PostgreSQL 마이그레이션 도구 : Flyway 확인 방식 : 마이그레이션 헤더의 사후 기록 확인 소스 수정 : x
재현 조건
- 컬럼을 넓히는 마이그레이션의 헤더를 읽는다. 번호 선택 근거와 두 위치 문제가 적혀 있다.
- 원래 컬럼 정의를 확인한다.
- 같은 테이블을 만드는 다른 위치를 확인한다.
본문
schema_stream이 varchar(32)였고 작성 당시 모든 스트림에 맞았으며 'db/migration/jpa/notification-platform'(38자)에서 안 맞기 시작했다.
컬럼 폭이 맞지 않기 시작한 경로
:::evidence key="registry-column-too-short-for-its-own-path" alt="분석 문서 final/document.md#a05 에서 이 기록의 근거 절을 그대로 잘라낸 3줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="final/document.md#a05 발췌 — 3줄" zoom="true" :::
실패 모드가 나쁜 종류다
모든 면에서 올바른 등록이 value too long으로 마이그레이션 타임에 실패하고, 뻔한 우회책은 스트림의 실제 경로가 아닌 더 짧은 경로를 기록하는 것이며, 스키마가 어디서 왔는지에 대해 거짓말하는 레지스트리는 없는 것보다 나쁘다.
128로 넓힌 이유
capability_id가 이미 varchar(128)이고 하나의 bound가 두 개보다 추론하기 쉽다.
확인하지 못한 것
32자를 넘는 경로로 삽입해 거절을 재현하지 않았다. 이 기록은 마이그레이션 헤더에 근거한다.
없음