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.6 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source, module
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | module | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CONCEPT | messaging-admin-api-c03 | 서명 대상 객체가 존재한다는 것이 4-eyes 통과를 뜻한다 | schema-and-wire-models | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:messaging-admin-api-c03 | 2026-09-01 |
|
|
|
messaging-admin-api |
서명 대상 객체가 존재한다는 것이 4-eyes 통과를 뜻한다
8개 필드. 그중 requestedBy 가 생성자에서 4-eyes 를 강제한다.
본문
ApprovalGrant 는 8개 필드다. 그중 requestedBy 가 생성자에서 4-eyes 를 강제한다. "우회할 수 없는 자리에 표현했다" — 검사기가 아니라 record 생성자에 두었으므로, 서명 대상 객체가 존재하는 것 자체가 4-eyes 통과를 뜻한다.
canonicalForm 이 길이 접두 인코딩인 것
버전 접두 "v1" 이 앞에 있어 형식 교체 여지를 남긴 것도 의도적으로 보인다. 이 규칙이 계획 다이제스트 쪽에는 적용되지 않았다 — §12.3(b).
승인 검증이 도는 순서
:::evidence key="messaging-admin-api-c03-diagram" alt="다이제스트 대조에서 윈도우로 일치가 건너가고 윈도우에서 서명 파싱으로 기간 안이 건너가고 서명 파싱에서 HMAC 으로 형식 통과가 건너간다" caption="승인 검증이 도는 순서" zoom="false" :::
다이제스트 대조 → 윈도우 → 16진 파싱 → HMAC. 다이제스트를 먼저 보는 이유가 주석에 있다.
ApprovedReplayPlan 참조 위치
:::evidence key="messaging-admin-api-c03" alt="코드베이스에서 ApprovedReplayPlan 를 검색한 출력 11줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="ApprovedReplayPlan 코드베이스 검색 — 11줄 · exit 0" zoom="true" :::
검증하는 쪽은 반드시 서명할 수도 있다
sign(...) 이 같은 클래스에 public 으로 있고, javadoc 이 그 위험을 스스로 명시한다. 이 문장과 대칭키 선택이 만드는 구조적 결과가 §17 의 한 항목이다.
javadoc 이 세지 않는 두 검사
실제 분기는 여섯이다. 5번에는 별도 인라인 주석이 있어 의도된 검사임이 분명하다. "검사는 있는데 클래스 javadoc 이 세지 않는" 두 항목이, 동시에 어떤 테스트에도 도달하지 않는 두 항목이다(EVD-303, §12.1).
dry run 을 항상 허용하는 근거
"the way to make operators plan before they act is to make planning free". 이것은 보안 완화가 아니라 행동 설계다.
토폴로지를 두 번 보는 이유
ApprovedReplayPlan 생성자(:19-52)와 requireExecutable(now, currentTopologyVersion)(:54-85)이 토폴로지를 두 번 본다. 승인이 서명된 토폴로지와 계획이 계산된 토폴로지가 다를 수 있으므로 둘 다 현재와 대조한다.
진행처럼 보이는 루프
ApprovedRedrivePlan 은 같은 네 검사에 더해 loopAcknowledged 를 별도 필드로 갖고, requireExecutable 의 마지막 분기가 그것을 강제한다. "진행처럼 보이는 루프" 는 이 리프에서 반복되는 관점이다 — 대시보드에서 옳아 보이는 실패를 타입으로 막는다.