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>
1.8 KiB
1.8 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, questionStatus, verifiedOn, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | questionStatus | verifiedOn | source | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| QUESTION | widen-doc-contract-assertions | 문서 계약 테스트의 단언 범위를 capability 표까지 넓힐 것인가 | drift-direction | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | open-question:widen-doc-contract-assertions | OPEN |
|
문서 계약 테스트의 단언 범위를 capability 표까지 넓힐 것인가
capability 표는 기계로 검증 가능하다 — 어댑터 이름과 능력 상수와 마크다운 표가 전부 소스에 있다.
사실
capability 표는 기계로 검증 가능하다 — 어댑터 이름과 능력 상수와 마크다운 표가 전부 소스에 있다. 그리고 현재 계약 테스트의 좁은 단언 범위 밖에 발견된 드리프트 세 건이 전부 있다.
미지수
프로젝트가 이 확장을 채택할 것인지. 테스트 javadoc 은 오히려 좁게 유지하는 근거를 적는다 — "Asserting on wording would make every edit a test failure and the check would be deleted."
다음 검증
capability 표 60칸을 코드 상수에서 파생시키는 검사를 시제품으로 만들어 문구 변경에 대한 취약성을 실측한다.
파생 검사가 문구 변경에 취약하지 않다는 것이 실측되면 확장을 채택한다. 그렇지 않으면 좁은 단언을 유지하고 경계를 문서에 적는다.
관계
- 문서 계약 테스트의 단언 경계 밖에 발견된 드리프트 세 건이 전부 있었다 같은 구조에서 실제로 확인된 사건이다.
- 과대 진술 문서를 과소보다 먼저 고친다 여기서 뽑아낸 재사용 기준이다.