Merge main into Reg D compliance elements

Resolve the stacked PR branch after main advanced with RFQ hardening, Phase 1 architecture baseline, and RFQ SDK work.

Constraint: PR #25 must land after #24 and before the higher stacked manifest/E2E/CLI PRs.

Rejected: Keeping duplicate D008 decision numbering | would make the decision log ambiguous after merging RFQ-002 and CMP-001.

Confidence: high

Scope-risk: moderate

Directive: Continue stacked PR merges in order after #25 lands: #26, #27, #28, #29, #30.

Tested: git diff --cached --check

Not-tested: full local scripts/check.sh for this conflict-only reconciliation; rely on GitHub CI after push

Author: 0xMuang

DECISIONS.md

@@ -255,7 +255,52 @@ Router 밖 경로는 production deployment에서 다음 중 하나로 처리해
 - `ARCHITECTURE.md`
 - `docs/architecture/execution-routing.md`
 
-## D007 — RFQ v2 hardening: maker approval, full-fill, non-custodial, nonce-scoped cancel
+## D007 — PD-1~PD-7 Phase 1 architecture baseline을 확정한다
+
+Date: 2026-07-14
+
+### Context
+
+Phase 1 구현 전에 Manifest schema, Recipe evaluation, post-trade state,
+identity claim, enforcement action, governance와 lifecycle record 보존 방식에
+대한 개발팀 합의가 필요했다.
+
+이 결정들은 BUIDL-like demo나 RFQ/API 구현보다 상위의 아키텍처 baseline이다.
+
+### Decision
+
+PD-1~PD-7을 Phase 1 architecture baseline으로 확정한다.
+
+- PD-1: Manifest는 explicit core + registry-backed `RecipeBinding` 구조를 사용한다.
+- PD-2: Router/Engine은 Manifest-level multi-Recipe binding 모델을 사용한다.
+- PD-3: token transfer 기준 acquisition timestamp와 router execution context를 분리하고, post-trade commit은 idempotent하게 처리한다.
+- PD-4: investor qualification은 ERC-3643/ONCHAINID claim pipeline을 기본 인터페이스로 사용하고, Securitize/TA는 adapter boundary로 연동한다.
+- PD-5: `BLOCK`, `FLAG_ONLY`, `OPERATOR_REVIEW` 중심의 enforcement action 모델과 constrained override를 사용한다.
+- PD-6: governance authority는 외부 Safe-style multisig를 사용하고, compliance relaxation은 timelock을 요구한다.
+- PD-7: Manifest lifecycle은 semantic versioning, append-only history, central pause state와 hash-anchored record preservation을 사용한다.
+
+### Alternatives Considered
+
+- PD별 ADR을 7개로 분리: 현재 결정들이 하나의 Phase 1 구조 freeze를 구성하므로
+  단일 baseline ADR로 묶는 편이 리뷰와 추적에 더 적합해 보류한다.
+- 현행 `issuanceRecipeId + fundRecipeId` 구조 유지: BUIDL-like demo에는 충분하지만
+  future policy 조합과 path option을 표현하기 어려워 transitional 구조로만 남긴다.
+- Corner Store 전용 identity model 신설: ERC-3643/T-REX와 ONCHAINID 호환성을
+  해치고 TA/KYC provider 연동성이 떨어져 제외한다.
+
+### Consequences
+
+- PD-1~PD-7은 더 이상 열린 구조 질문이 아니며, 후속 작업은 구현 명세와 migration issue로 진행한다.
+- 현재 코드의 transitional 구조는 별도 implementation branch에서 `RecipeBinding[]`, compiled plan, lifecycle registry 등으로 이전해야 한다.
+- 실제 Securitize/TA 연동은 공식/current interface 확인 후 별도 refinement issue에서 처리한다.
+
+### Related Files
+
+- `docs/decisions/ADR-007-pd-architecture-decisions.md`
+- `docs/decisions/decision-register.md`
+- `docs/architecture/phase1-structural-decisions-proposed.md`
+
+## D008 — RFQ v2 hardening: maker approval, full-fill, non-custodial, nonce-scoped cancel
 
 Date: 2026-07-04
 
@@ -310,7 +355,7 @@ RFQ venue의 다음 정책을 확정한다.
 - `src/execution/adapters/rfq/RFQAdapter.sol`
 - `FEATURES.md`
 
-## D008 — Reg D 506(c) recipe를 9-element reference set으로 확장한다
+## D009 — Reg D 506(c) recipe를 9-element reference set으로 확장한다
 
 Date: 2026-07-04
 

FEATURES.md

@@ -151,7 +151,7 @@ passing
 
 ### Notes
 
-- 정책 결정: D007(maker approval adapter-local, full-fill, non-custodial,
+- 정책 결정: D008(maker approval adapter-local, full-fill, non-custodial,
   nonce-scoped idempotent cancel).
 - Non-goals: partial fill, dealer inventory, signer key custody, shared dealer
   registry.
@@ -191,15 +191,60 @@ passing
   SwapFlow, Engine)는 shared setup helper로 9-element attestation을 추가해 유지.
 - `forge fmt`.
 
+## DOC-002 — RFQ SDK and MVP Demo Planning
+
+### Behavior
+
+- RFQ backend 운영을 Corner Store가 제공하지 않는다는 제품 경계를 명확히 한다.
+- RFQ backend SDK, local reference example, MVP demo backend를 서로 다른 레이어로 분리한다.
+- 구현 순서는 SDK interface 정리 → local reference example → MVP demo backend로 기록한다.
+- production RFQ hardening(dealer approval, custody, cancellation, partial fill)은 별도 트랙으로 유지한다.
+- roadmap과 product spec index에서 RFQ SDK/MVP backend 후속 작업을 찾을 수 있다.
+
+### Verification
+
+- RFQ venue architecture, product-spec index, roadmap, FEATURES, PROGRESS 교차 검토
+- `git diff --check`
+
 ### State
 
 passing
 
 ### Notes
 
-- 정책 결정: D008(9-element in-place 확장, operator-gated setter, Lockup은
+- 정책 결정: D009(9-element in-place 확장, operator-gated setter, Lockup은
   fixture-only mock acquisition source).
 - Deferred follow-up: ungated legacy mock element(A-01/A-03/QP)의 operator-gate
   정렬, production data source 연결, acquisition/lot data source와 holding-period
   활성화 조건 결정.
 - Non-goals: production legal 활성화, direction-aware element application.
+
+- Product spec: `docs/product-specs/rfq-backend-sdk-and-demo.md`
+- 이 feature는 문서 계획 작업이며 `services/rfq` 구현은 후속 feature에서 진행한다.
+
+## RFQ-SDK-001 — RFQ Backend SDK Interfaces
+
+### Behavior
+
+- `services/rfq`가 RFQ backend를 만들기 위한 TypeScript SDK helper를 제공한다.
+- integrator는 `createRFQService(...).quote(...)` high-level API로 taker/token/amount/venue만 넣고 `RFQAdapter` 호환 signed quote를 받을 수 있다.
+- SDK는 EIP-712 typed-data shape, chainId/verifyingContract binding, nonce, expiry, amount validation과 signature flow를 처리한다.
+- signer, nonce store, pricing provider, inventory/risk check는 교체 가능한 interface로 제공한다.
+- local reference component는 `InMemoryNonceStore`, `FixedRatePricingProvider`, `NoopInventoryRiskCheck`로 제한한다.
+- production server, hosted backend, pricing strategy, signer custody, inventory management와 compliance final decision은 범위 밖이다.
+
+### Verification
+
+- `cd services/rfq && npm test`
+- `scripts/check.sh`
+- `git diff --check`
+
+### State
+
+passing
+
+### Notes
+
+- SDK README: `services/rfq/README.md`
+- Product spec: `docs/product-specs/rfq-backend-sdk-and-demo.md`
+- MVP demo backend는 이 SDK를 기반으로 후속 feature에서 구현한다.

PROGRESS.md

@@ -22,6 +22,8 @@ source of truth로 사용한다.
 - `RFQ-002 — RFQ v2 Hardening`
 - `CMP-001 — Reg D 506(c) 9-element Recipe`(illustrative element library + recipe
   9-element 확장, version 2)
+- `DOC-002 — RFQ SDK and MVP Demo Planning`
+- `RFQ-SDK-001 — RFQ Backend SDK Interfaces`
 - multi-venue 아키텍처와 책임 문서 작성
 - Corner Store용 Uniswap v3 최소 배포 profile 분리와 테스트
 - ExecutionRouter/VenueRegistry/VenueSelector와 AMM reference adapter skeleton
@@ -30,50 +32,44 @@ source of truth로 사용한다.
 - RFQ-002: operator-curated maker approval allowlist(`setMakerApproved`,
   `RFQMakerNotApproved`), maker-initiated nonce-scoped idempotent cancellation
   (`cancelQuoteNonce`/`cancelQuoteNonces`, `RFQQuoteCancelled`), venueType binding
-  fix, `docs/rfq-threat-model.md` 위협 모델과 D007 결정 기록
+  fix, `docs/rfq-threat-model.md` 위협 모델과 D008 결정 기록
 
 ## Blocked
 
 - 없음
 
 ## Next
 
-1. Manifest lifecycle/operator approval flow를 구현한다. (Element library와 Reg D
-   506(c) Recipe 9-element 확장은 CMP-001로 완료.)
-2. ungated legacy mock element(A-01 sanctions, A-03 accredited, QP)를 새 element와
+1. MVP RFQ demo backend milestone/user flow를 별도 문서·feature로 구체화한다.
+   PR #29/#30이 머지되면 기존 live-Anvil E2E/CLI 경로를 재사용한다.
+2. pending RFQ/E2E/CLI/BUIDL PR stack(#25/#26/#27/#28/#29/#30/#35)이 머지된 뒤
+   roadmap과 feature 상태를 재조정한다.
+3. production Asset Compliance Manifest lifecycle/schema와 operator approval flow를
+   구현한다. (Element library와 Reg D 506(c) Recipe 9-element 확장은 CMP-001로 완료.)
+4. ungated legacy mock element(A-01 sanctions, A-03 accredited, QP)를 새 element와
    동일하게 operator-gate로 정렬한다 — CMP-001 deferred follow-up.
-3. RFQ integration-test 시나리오(router-path maker-approval/cancellation coverage)를
-   추가한다 — RFQ-002에서 deferred된 follow-up.
-4. acquisition/lot data source와 holding-period Recipe 활성화 조건을 결정한다
+5. 남은 RFQ production policy를 별도 feature로 분리한다: custody, partial fill,
+   production dealer/operator 책임.
+6. acquisition/lot data source와 holding-period Recipe 활성화 조건을 결정한다
    (C-01 Lockup은 현재 fixture-only mock acquisition source).
-5. live Anvil deployment/E2E를 추가한다.
-6. Order Book은 matching/custody/surveillance 모델 결정 후 구현한다.
-7. CI hardening(static analysis 등)을 강화한다.
+7. Order Book은 matching/custody/surveillance 모델 결정 후 구현한다.
 
 ## Last Session Summary
 
-- CMP-001 (Reg D 506(c) 9-element Recipe)을 landing했다.
-- 변경한 파일:
-  - product: `src/compliance/recipes/RegD506cRecipe.sol`(2→9 element, version 2)
-  - test: `test/unit/compliance/Recipes.t.sol`, `test/unit/compliance/Engine.t.sol`,
-    `test/integration/IntegrationBase.sol`, `test/integration/SwapFlow.t.sol`,
-    신규 `test/integration/RegD506cElements.t.sol`
-  - bookkeeping: `DECISIONS.md`(D008), `FEATURES.md`(CMP-001), `PROGRESS.md`
-- 6개 새 illustrative element(A-02/A-04/A-05/B-01/B-02/E-01)는 앞선 리뷰된
-  브랜치에서 landed; 이번 세션은 recipe 확장 + fixture wiring + bookkeeping.
-- 실행한 명령:
+- #25 merge preparation includes CMP-001 (Reg D 506(c) 9-element Recipe) on top of current main.
+- CMP-001 changes RegD506cRecipe to the illustrative 9-element set and adds integration coverage for element-family rejection cases.
+- RFQ SDK and RFQ-002 hardening are already on main and preserved during this stacked merge reconciliation.
+- 실행한 검증:
   - `forge fmt`
-  - `forge test --offline`
-- 통과한 검증:
-  - `forge test --offline` 195/195(pre-task 189 + 신규 6).
-  - recipe unit test로 9-element/version 2/always-applicable 확인.
-  - element family별 rejection(A-02 disallowed/unset, A-04, A-05, B-01)은 정확한
-    reasonCode로 assert.
+  - `forge test --offline` on the original PR
+  - `scripts/check.sh` during #24 reconciliation
 - 남은 리스크:
-  - ungated legacy mock element(A-01/A-03/QP)와 새 operator-gated element 사이
-    hardening divergence — follow-up으로 정렬.
-  - C-01 Lockup은 fixture-only mock acquisition source에 의존; production
-    acquisition/lot data source와 holding-period 활성화 default는 미결정.
-  - production data source(OFAC/ONCHAINID/ERC-165/EDGAR) 연결과 legal 활성화는
-    approval-gated로 열려 있다.
-  - engine은 direction-aware가 아니다(기존 문서화된 concern).
+  - MVP HTTP/CLI backend는 아직 구현하지 않았다.
+  - production signer custody, persistent nonce store, pricing, inventory/risk는 integrator/operator 책임이다.
+  - ungated legacy mock element(A-01/A-03/QP)와 새 operator-gated element 사이 hardening divergence는 follow-up으로 정렬한다.
+  - C-01 Lockup은 fixture-only mock acquisition source에 의존한다.
+
+## RFQ-002 Merge Note
+
+- RFQ-002 hardening from PR #24 is included in this branch update: maker approval, maker nonce cancellation, venueType binding, and RFQ threat-model documentation.
+- Deferred follow-up remains router-path maker-approval/cancellation integration-test coverage after stacked PRs are reconciled.

README.md

@@ -97,13 +97,14 @@ forge fmt
 anvil
 ```
 
-### RFQ Reference Service
-
-`services/rfq` is a minimal quote signer reference for RFQ v1. It builds the
-same EIP-712 typed data that `RFQAdapter` verifies, assigns expiry and nonce,
-and returns a signed quote. It is not a production dealer, pricing engine,
-inventory manager, custody service, websocket feed, orderbook, or compliance
-decision engine.
+### RFQ TypeScript SDK
+
+`services/rfq` provides TypeScript SDK helpers for RFQ quote backends. It builds
+the same EIP-712 typed data that `RFQAdapter` verifies, assigns expiry and
+nonce, signs quotes through a caller-provided signer, and exposes pricing, nonce
+and risk-check interfaces for integrators. It is not a hosted production RFQ
+server, dealer, pricing engine, inventory manager, custody service, websocket
+feed, orderbook, or compliance decision engine.
 
 ```shell
 cd services/rfq

docs/ROADMAP.md

@@ -251,6 +251,8 @@ Deliverables:
 - signature, nonce, expiry와 taker binding
 - Router-only RFQ Adapter와 latest compliance evaluation
 - 최소 TypeScript quote signer reference service
+- RFQ backend SDK interface와 local reference example 계획은 `docs/product-specs/rfq-backend-sdk-and-demo.md`를 따른다.
+- MVP demo backend는 SDK 정리 이후 별도 feature로 구현한다.
 - partial fill policy는 v1 non-goal로 유지
 
 Completion:
@@ -317,16 +319,27 @@ SDK와 reference DEX를 반복 배포하고 Manifest/권한 상태를 검증 가
 
 ## Near-Term Issues
 
+Open PR context:
+
+- #24 covers RFQ maker approval and quote cancellation hardening.
+- #28 covers protected-router RFQ integration scenarios.
+- #29 covers live-Anvil E2E/demo runner.
+- #30 covers interactive CLI over the deployed demo stack.
+- #35 covers BUIDL-like ERC-3643 compliance fixture with mock TA facts.
+
 가까운 후속 이슈:
 
-1. `design(rfq): dealer/operator approval, custody, cancellation, partial-fill policy 확정`
-2. `security(rfq): direct venue, signer, custody, replay, quote-cancellation threat model 작성`
-3. `feat(compliance): production Asset Compliance Manifest lifecycle/schema 구현`
-4. `design(compliance): acquisition/lot data source와 holding-period Recipe 활성화 조건 결정`
-5. `test(e2e): live Anvil deployment와 regulated RFQ/AMM settlement smoke 자동화`
-6. `feat(orderbook): matching/custody/surveillance 모델 결정 후 Order Book adapter 구현`
-7. `chore(ci): deploy-v3 CI, static analysis, lint/warning budget 추가`
-8. `docs(ops): Manifest activation/suspension runbook과 incident drill 문서화`
+1. `feat(rfq): add TypeScript SDK interfaces for quote backend integration`
+2. `docs(demo): define MVP RFQ backend milestone and user flow`
+3. `feat(demo): add MVP RFQ backend using the RFQ SDK` — PR #29/#30이 머지되면 해당 E2E/CLI 경로를 재사용한다.
+4. `docs(roadmap): reconcile roadmap after pending RFQ/E2E/CLI/BUIDL PR stack merges`
+5. `design(rfq): remaining production RFQ policy beyond PR #24` — custody, partial fill, production dealer/operator 책임.
+6. `security(rfq): direct venue, signer custody, replay, quote-cancellation threat model 보강`
+7. `feat(compliance): production Asset Compliance Manifest lifecycle/schema 구현`
+8. `design(compliance): acquisition/lot data source와 holding-period Recipe 활성화 조건 결정`
+9. `feat(orderbook): matching/custody/surveillance 모델 결정 후 Order Book adapter 구현`
+10. `chore(ci): static analysis, lint/warning budget 추가`
+11. `docs(ops): Manifest activation/suspension runbook과 incident drill 문서화`
 
 ## Decision Backlog