docs(adr): add ADR-010 element parameter ownership (Proposed)

[lees2345]

무엇

ADR-010(상태: Proposed) 추가. 코드 변경 없음, 검토 요청 문서입니다.

왜

새 설계 제안이 아니라 이미 Accepted된 ADR과 현재 구현 사이의 간극 보고입니다.

• ADR-006 불변식 1·2 — "자산별 값은 Manifest 입력으로만. element 코드에 상수 하드코딩 금지"
• ADR-006 §5 열린 질문 — "Manifest 스키마 확정"이 미결인 채로 구현이 진행되면서 자산별 값이 부품 저장소에 자리 잡음
• ADR-007 PD-6 — "registry replacement는 multisig + timelock", "모든 governance action은 actor·old value·reason code·effective time을 담은 append-only event"

간극 3건

ID	관찰	대응 결정
G-1	Jurisdiction.allowedJurisdiction이 자산 키 없는 전역 매핑. 엔진이 manifest.factsPacked를 Recipe에는 넘기고 Element에는 넘기지 않음	ADR-006 불변식 1·2
G-2	_accumulatePolicyId에 Element 파라미터와 구현 주소가 빠져 판정 재현이 불완전	PD-3·PD-5 commitment hash
G-3	registerElement에 timelock·이력 사슬·확장 event 없음. Manifest 층과 비대칭	PD-6

전제

TokenPolicyRegistry는 PD-6·PD-7 요구를 이미 잘 구현하고 있습니다(timelock, 해시 사슬, declaredBy/approvedBy 분리, LooseningForbidden). 통제를 새로 만들자는 것이 아니라, 그 통제를 우회하는 경로가 셋 있다는 이야기입니다.

mock 주석(Jurisdiction.sol·BuidlMinimumInvestment.sol·RegD506cRecipe.sol)은 확인했고, 각 항목마다 왜 mock 범위 밖인지를 §4에 적었습니다. G-2·G-3은 mock 경로가 아닙니다.

요청

§7의 질문 8개에 답변 부탁드립니다. 특히:

• Q1~Q3 파라미터 소유권과 check 인터페이스 변경 비용
• Q6~Q7 registerElement·RecipeRegistry 교체 권한 통제
• Q8 우선순위 (리걸 판단으로는 Q1·Q3가 부품 25개인 지금 가장 쌉니다)

문서에 인라인 코멘트로 주시면 됩니다. 반대 의견도 환영합니다. 제가 못 본 이유가 있을 수 있습니다.

후속

• 채택 시 decision-register.md에 행 추가
• RedFlagKnowledgeBar.sol(A-12) 미배선 건은 리걸 사유가 있어 별도 제기 예정

[lees2345]

자기 정정 — 「부품 수」 논거를 철회하고 쟁점을 G-2로 좁힌다

올린 뒤 나올 가장 자연스러운 반문이 "ERC-3643도 모듈이 수십 개인데 그게 왜 문제인가" 라고 보고, 먼저 확인했다. 반문이 맞다. 본문 §2-2의 「배포 수 = 규칙 수 × 프로파일 수」 프레이밍은 과했다.

확인한 것 (T-REX 실소스)

ERC-3643도 모듈이 수십 개지만 규칙 수만큼이지 자산 수 곱하기가 아니다. 모듈이 설정을 msg.sender(호출한 per-token ModularCompliance)로 나눠 저장하기 때문이다.

// MaxBalanceModule.sol
mapping(address => uint256) private _maxBalance;              // compliance별
function setMaxBalance(uint256 _max) external onlyComplianceCall {
    _maxBalance[msg.sender] = _max;
}

// CountryAllowModule.sol
mapping(address => mapping(uint16 => bool)) private _allowedCountries;   // compliance별

ModularCompliance._tokenBound가 단수라 compliance = per-token / module = shared·multi-tenant 구조다. 이 조합이 배포 수를 규칙 수에 묶는다.

우리 구조와의 차이

우리는 엔진이 부품을 직접 호출하므로 부품 입장에서 msg.sender가 언제나 엔진 하나다. 즉 3643이 쓰는 테넌트 키가 없다. 남은 수단은 check가 받는 asset 인자뿐인데 Jurisdiction이 그걸 쓰지 않는다.

→ 나가는 길은 둘이다.

• (a) asset을 키로 부품 내부에 자산별 설정을 둔다. 3643과 사실상 동형
• (b) Manifest에서 파라미터를 주입한다 (본문 D-1)

배포 수만 놓고 보면 (a)로 충분히 해결된다. 따라서 본문 §8 Rejected Alternatives에서 (a)를 기각한 근거를 정정한다. (a)의 결함이 아니라 G-2를 어떻게 푸느냐에 종속된 선택이다.

그래서 쟁점은 G-2 하나로 좁혀진다

쟁점	(a)로 해결되나	판단
배포 수·재사용성	✅	실질 문제 아님. 논거 철회
판정 재현성 (G-2)	❌	남는 유일한 쟁점

(a)로 가면 설정값이 부품 저장소에 남아 policyId 재료 밖에 있다. 값이 바뀌어도 policyId·policyVersion이 동일해 판정 재현이 event log 재구성에 의존한다. (b)로 가면 설정값이 Manifest 안이라 이미 해시 재료이므로 자동으로 닫힌다.

ERC-3643이 이 문제를 풀지 않는 것은 결함이 아니다. 자산 발행 표준이지 거래 판정의 재현 증명을 제품으로 삼지 않기 때문이다. 우리는 그것을 판다(ADR-008 · PD-3 · PD-5).

질문 우선순위 조정

§7 기준으로 Q4(결정 해시에 파라미터·구현 주소 포함)가 사실상 1번이다. Q1·Q2는 그 답에 따라오는 구현 선택에 가깝다.

• Q4가 "불필요하다" 또는 "event log 재구성으로 충분하다"면 → (a)로 가면 되고 본 ADR은 대부분 불필요해진다. 다만 그 전제를 docs/architecture/에 명시해 두는 편이 좋다 (Q5)
• Q4가 "필요하다"면 → (b)가 따라오고, Q3(인터페이스 변경 비용)이 실제 결정 포인트가 된다

Q6·Q7(registerElement timelock·이력)은 위 선택과 독립이며 PD-6 정합 문제로 그대로 남는다.