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>
5.3 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 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CONCEPT | approval-verification-execution | 승인·검증·실행의 분리와 그것을 타입으로 표현하기 | operator-approval-and-destructive-operations | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:approval-verification-execution | 2026-09-01 |
|
|
|
승인·검증·실행의 분리와 그것을 타입으로 표현하기
운영자 도구가 파괴적 작업을 부를 때 세 능력이 분리되어야 한다. 승인을 발급하는 능력, 그 승인이 진짜인지 검증하는 능력, 작업을 실행하는 능력.
관계
- 위조 가능한 승인이 하필 되돌릴 수 없는 작업 쪽에만 남았다 이 분리가 절반만 적용된 사례다.
- 서명 능력과 검증 능력은 같은 객체에 두지 않는다 세 능력 중 앞의 둘에 대한 규칙이다.
- 권한이 센 절반이 설정 한 줄로 켜지면 안 된다 같은 계열의 기존 규칙이다.
본문
운영자 도구가 파괴적 작업을 부를 때 세 가지가 분리되어야 한다. 승인을 발급하는 능력, 그 승인이 진짜인지 검증하는 능력, 그리고 작업을 실행하는 능력.
승인이 실행에 닿기까지
:::evidence key="approval-verification-execution-diagram" alt="승인 발급에서 가드 검증으로 승인 문서가 건너가고 가드 검증에서 파괴적 실행으로 VerifiedApproval 이 건너간다" caption="승인이 실행에 닿기까지" zoom="false" :::
호출자가 자기에 대해 하던 주장
이 리프가 그 분리를 타입으로 표현한 이력이 javadoc 에 남아 있다 — 예전에는 승인된 계획 타입이 public 생성자를 가진 평범한 record 라서 "이 계획은 승인됐다" 가 호출자가 자기에 대해 한 주장이었고, 실행 메서드에 닿을 수 있는 코드는 무엇이든 승인을 지어낼 수 있었다. 그 수정이 VerifiedApproval 이다 — 검증을 통과했다는 사실 자체를 타입으로 만들어 생성자를 막았다.
VerifiedApproval 참조 위치
:::evidence key="approval-verification-execution" alt="코드베이스에서 VerifiedApproval 를 검색한 출력 12줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="VerifiedApproval 코드베이스 검색 — 12줄 · exit 0" zoom="true" :::
javadoc 목록에 빠진 두 조건
가드는 네 조건이 아니라 여섯을 본다 — 작업 종류 일치와 출처 일치가 javadoc 목록에 빠져 있다. 그중 다섯 번째의 인라인 주석이 이 개념의 요점을 말한다 — "A guard that only checks presence and window lets a verified redrive approval authorise a destination deletion."
:::note
이 표면 전체에 production 소비자가 없어 실행으로 확인한 것이 없다
:::
왜 셋인가
파괴적 작업은 되돌릴 수 없다. 목적지를 지우거나 오프셋을 되돌리면 그 전 상태는 없다.
그러므로 실행하는 쪽이 스스로 승인할 수 없어야 한다. 승인이 별도의 사람이나 시스템에서 오고, 실행 직전에 그것이 진짜인지 확인해야 한다.
승인을 타입으로 만든 이력
이 리프의 javadoc 이 이전 형태와 그 결함을 적는다.
The approved-plan types used to hold a plain AdminApproval record with a public constructor, so "this plan was approved" was a claim the caller made about itself. Any code that could reach the execute method could write new AdminApproval("TICKET-1", "someone", now, later) and the platform believed it.
승인된 계획이 public 생성자를 가진 평범한 record 였으므로, 승인됐다는 것은 호출자가 자기에 대해 한 주장이었다는 뜻이다.
수정은 검증을 통과했다는 사실 자체를 타입으로 만드는 것이었다. 그 타입은 검증기만 만들 수 있고, 실행 메서드는 그 타입을 요구한다. 그러면 승인을 지어내려면 검증기를 통과해야 한다.
가드가 보는 것
가드의 클래스 javadoc 은 네 조건을 든다. 실제 본문은 여섯을 본다. 작업 종류 일치와 출처 일치가 목록에서 빠져 있다.
그 둘이 사소하지 않다는 것을 다섯 번째 분기의 인라인 주석이 말한다.
A guard that only checks presence and window lets a verified redrive approval authorise a destination deletion.
승인이 있고 유효 기간 안이라는 것만 보면, 검증된 리드라이브 승인으로 목적지 삭제를 인가할 수 있다는 뜻이다. 승인의 존재와 그 승인이 이 작업을 인가한다는 것은 다른 사실이다.
이 표면의 현재 상태
이 리프 전체에 production 소비자가 없다. 운영자 도구가 아직 없기 때문이다. 그래서 여기 기록된 것들은 전부 그 도구가 생기는 순간의 모양에 대한 것이다.