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>
3.3 KiB
id, kind, slug, title, topic, topicName, project, status, studio, questionStatus, source, sourceRevision, evidence
| id | kind | slug | title | topic | topicName | project | status | studio | questionStatus | source | sourceRevision | evidence | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| QUESTION | commit-ambiguity-lane-not-rerun-at-head | 커밋 모호성 레인이 HEAD 에서도 통과하는지는 실행이 아니라 드리프트 0 으로 답했다 | commit-ambiguity-as-a-result | 커밋 모호성 — 「모른다」를 결과로 유지하기 | clean-architecture-backend-template | 게시 전 | OPEN |
|
21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 |
|
커밋 모호성 레인이 HEAD 에서도 통과하는지는 실행이 아니라 드리프트 0 으로 답했다
레인은 실제로 돌았다. 다만 돌린 리비전이 a24ece9c 이고 이 분석이 정본으로 삼은 HEAD 가 아니다. 그 사이를 메우는 것은 재실행이 아니라 변경 파일 수 측정이다.
관계
- pg_terminate_backend 가 57P01 로 도착하고 커밋 레코드는 이미 WAL 에 있었다 이 레인이 고정하는 규칙을 만든 사례다.
사실
다섯 태그 레인을 --rerun-tasks 로 실행해 51 클래스 244 tests 가 0 skipped · 0 failures 로 끝났다. BUILD SUCCESSFUL in 3m 10s 였고 실행 전후의 git status 가 모두 clean 이었다.
그중 jpaPlatformFailureTest 는 2 클래스 6 tests 다. CommitAmbiguityContractTest 가 그 레인에 속한다.
실행 리비전은 a24ece9cf797f7ea647e33bf846b115208ed1ba5 이고 실행 시각은 2026-08-29T14:46:23+00:00 이다.
a24ece9c 와 HEAD 21234e38 사이는 커밋 하나인데, 그 커밋이 건드린 것은 grpc 블록과 공통 파일 둘이다. persistence-jpa 를 포함한 18 개 리프 경로의 변경 파일 수는 0 이다.
가정
변경 파일 수가 0 이면 레인 결과도 같으리라고 전제하고 있다. 이 전제는 빌드 설정과 의존성 해석이 두 리비전에서 같다는 것까지 포함한다.
57P01 관측이 PostgreSQL 의 여러 major 버전에서 같게 재현되리라고도 전제하고 있다.
미지수
HEAD 에서 jpaPlatformFailureTest 를 돌리면 무엇이 나오는가.
57P01 이 PostgreSQL 16 과 17 과 18 전부에서 같은 SQLSTATE 로 도착하는가.
제약
매트릭스는 실행 한 번에 major 하나만 고른다. 다중 선택은 start 단계에서 거부된다.
이 분석은 애플리케이션 소스를 수정하지 않는다.
선택지
1. HEAD 에서 한 major 로 한 번 돌린다
가장 싸다. 드리프트 0 이라는 간접 근거가 실행 결과로 바뀌는데 버전 간 차이는 여전히 모른다.
2. HEAD 에서 major 세 번 돌린다
버전 간 차이까지 확인하는데 비용은 컨테이너 기동 세 번이다.
다음 검증
- HEAD 를 체크아웃하고 Docker 가 있는 환경에서 다음을 돌린다. ./gradlew :adapter:outbound:persistence-jpa:jpaPlatformFailureTest --rerun-tasks --console=plain
- major 를 바꿔 반복하려면 -Pjpa.matrix.versions 로 하나씩 지정한다.
닫는 조건 : 0 failures 가 나오면 이 질문을 닫고 관련 Case 의 확인하지 못한 것에서 재실행 항목을 지운다. 실패가 나오면 드리프트 0 을 근거로 삼은 §6.2 정정을 철회하고 그 실패를 새 Case 로 연다.