Plan the RFQ backend SDK path

Record the RFQ backend as a TypeScript SDK and local-reference path before MVP demo backend work begins, while preserving pending PR context for RFQ hardening, E2E, CLI, and BUIDL fixtures.

Constraint: Open PRs #24, #28, #29, #30, and #35 already cover parts of RFQ hardening, protected-router scenarios, live demo, CLI, and BUIDL-like fixtures.
Rejected: Treating an RFQ backend as a Corner Store-operated production server | would blur operator responsibilities for pricing, signer custody, inventory, hosting, and compliance prechecks.
Confidence: high
Scope-risk: narrow
Directive: Implement RFQ SDK interfaces first; any MVP backend must reuse merged E2E/CLI/BUIDL paths instead of creating parallel demo infrastructure.
Tested: git diff --check
Not-tested: services/rfq implementation or runtime tests; documentation-only change

Author: 0xMuang

FEATURES.md

@@ -115,3 +115,26 @@ passing
 
 - Non-goals: partial fill, orderbook, production pricing engine, dealer inventory,
   custody 확장, websocket/order discovery.
+## 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
+
+- Product spec: `docs/product-specs/rfq-backend-sdk-and-demo.md`
+- 이 feature는 문서 계획 작업이며 `services/rfq` 구현은 후속 feature에서 진행한다.

PROGRESS.md

@@ -19,6 +19,7 @@ source of truth로 사용한다.
 - `DOC-001 — Imported Architecture Alignment`
 - `FND-001 — Foundry Product Foundation`
 - `RFQ-001 — Reference RFQ Settlement`
+- `DOC-002 — RFQ SDK and MVP Demo Planning`
 - multi-venue 아키텍처와 책임 문서 작성
 - Corner Store용 Uniswap v3 최소 배포 profile 분리와 테스트
 - ExecutionRouter/VenueRegistry/VenueSelector와 AMM reference adapter skeleton
@@ -29,37 +30,38 @@ source of truth로 사용한다.
 
 ## Next
 
-1. RFQ production hardening은 별도 feature로 분리한다: dealer/operator approval,
-   custody, quote cancellation, partial fill 정책.
-2. production Asset Compliance Manifest lifecycle/schema와 operator approval flow를
+1. RFQ backend SDK interface를 구현한다: signer, nonce store, pricing provider,
+   validation과 local reference example.
+2. MVP RFQ demo backend milestone/user flow를 별도 문서·feature로 구체화한다.
+   PR #29/#30이 머지되면 기존 live-Anvil E2E/CLI 경로를 재사용한다.
+3. pending RFQ/E2E/CLI/BUIDL PR stack(#24/#28/#29/#30/#35)이 머지된 뒤
+   roadmap과 feature 상태를 재조정한다.
+4. 남은 RFQ production policy를 별도 feature로 분리한다: custody, partial fill,
+   production dealer/operator 책임.
+5. production Asset Compliance Manifest lifecycle/schema와 operator approval flow를
    구현한다.
-3. acquisition/lot data source와 holding-period Recipe 활성화 조건을 결정한다.
-4. live Anvil deployment/E2E와 security threat model을 추가한다.
-5. Order Book은 matching/custody/surveillance 모델 결정 후 구현한다.
+6. acquisition/lot data source와 holding-period Recipe 활성화 조건을 결정한다.
+7. Order Book은 matching/custody/surveillance 모델 결정 후 구현한다.
 
 ## Last Session Summary
 
 - 변경한 파일:
-  - RFQAdapter, RFQQuote type, RFQ-specific errors
-  - RFQAdapter Foundry tests
-  - `services/rfq` 최소 TypeScript quote signer reference
-  - RFQ v1 scope/non-goals 문서
-- 실행한 명령:
-  - `forge build`
-  - `forge test --offline --match-path test/unit/execution/RFQAdapter.t.sol -vv`
-  - `cd services/rfq && npm test`
+  - `docs/product-specs/rfq-backend-sdk-and-demo.md`
+  - `docs/product-specs/index.md`
+  - `docs/ROADMAP.md`
+  - `FEATURES.md`
+  - `PROGRESS.md`
+- 완료한 작업:
+  - RFQ backend를 production server 제공이 아니라 SDK + local reference example + 후속 MVP demo backend로 분리한 계획 문서 추가
+  - RFQ SDK interface, local reference example, MVP demo backend의 단계별 deliverable과 non-goal 정리
+  - roadmap near-term issue 순서에 RFQ SDK와 MVP demo backend planning을 추가
+  - product-spec index에 RFQ backend SDK/demo 계획 문서 등록
+  - 열린 PR #24/#28/#29/#30/#35를 RFQ SDK/MVP backend 계획의 pending upstream context로 반영
+  - 전반 문서 점검 결과를 RFQ planning 문서에 기록
+- 실행한 검증:
+  - product-spec index, ROADMAP, RFQ venue architecture, FEATURES, PROGRESS 교차 검토
   - `git diff --check`
-  - `scripts/check.sh`
-- 통과한 검증:
-  - RFQAdapter compile
-  - valid signed quote settlement
-  - invalid signature, expired quote, replay, wrong taker, mismatch, direct bypass,
-    compliance rejection 거부
-  - RFQ service typed-data/smoke check
-  - 전체 repo check 통과
 - 남은 리스크:
-  - production dealer approval, custody, quote cancellation, partial fill은 RFQ v1
-    범위 밖이다.
-  - production Manifest lifecycle과 acquisition/lot source는 아직 결정·구현 전이다.
-  - live deployment/E2E와 static analysis는 아직 부족하다.
-  - production Element와 engine 허용 조건은 법률 승인 전 활성화할 수 없다.
+  - 아직 `services/rfq` 구현 변경은 하지 않았다.
+  - MVP demo backend의 HTTP/CLI/UI 선택은 후속 문서·feature에서 정하되, PR #29/#30이 머지되면 기존 E2E/CLI 경로를 재사용해야 한다.
+  - production RFQ dealer approval, custody, cancellation, partial fill은 별도 hardening track이다.

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
 

docs/product-specs/index.md

@@ -9,6 +9,7 @@
 | [`../architecture/asset-manifest.md`](../architecture/asset-manifest.md) | Asset Compliance Manifest 책임과 lifecycle | Current |
 | [`../ROADMAP.md`](../ROADMAP.md) | 구현 순서와 완료 조건 | Current |
 | [`../MVP.md`](../MVP.md) | 과거 AMM 중심 설계 기록 | Historical |
+| [`rfq-backend-sdk-and-demo.md`](./rfq-backend-sdk-and-demo.md) | RFQ backend SDK와 MVP demo backend 계획 | Planned |
 
 DOC-001에서 연구·회의 입력을 반영했다. 내용이 다를 경우 위 current 문서를 source
 of truth로 사용한다. acquisition registry, Element commit hook과 reject logging은

docs/product-specs/rfq-backend-sdk-and-demo.md

@@ -0,0 +1,207 @@
+# RFQ Backend SDK and MVP Demo Plan
+
+## Status
+
+Planned. This document defines scope before implementation.
+
+## Purpose
+
+Corner Store needs an off-chain RFQ component because a maker must price and sign quotes before a taker submits settlement through `ExecutionRouter` and `RFQAdapter`.
+
+Corner Store should not provide or operate a production RFQ server. The product should provide:
+
+1. TypeScript SDK pieces for integrators to build their own RFQ quote backend.
+2. A local-only reference example that demonstrates those SDK pieces.
+3. A later MVP demo backend that uses the SDK from a user's point of view.
+
+The separation matters: the SDK is reusable product infrastructure; the MVP backend is an application/demo built on top of it.
+
+## Current baseline
+
+Already implemented:
+
+- Solidity `RFQAdapter` with EIP-712 quote verification.
+- Router-only settlement path.
+- full-fill / exact-taker v1 behavior.
+- nonce, expiry, signature and quote-field binding tests.
+- `services/rfq` minimal TypeScript quote signer reference.
+
+Current gap on `main` before the stacked PRs land:
+
+- `services/rfq` is not yet shaped as a backend SDK.
+- signer, nonce, pricing and risk boundaries are not explicit enough for reuse.
+- there is no MVP user-facing RFQ backend flow yet.
+
+Open PR context to preserve when planning implementation:
+
+- PR #24 adds RFQ maker approval and quote cancellation hardening.
+- PR #28 adds protected-router RFQ integration scenarios.
+- PR #29 adds a live-Anvil E2E runner and scripted demo vehicle.
+- PR #30 adds an interactive CLI using the deployed stack and RFQ quote path.
+- PR #35 adds the BUIDL-like ERC-3643 compliance fixture with mock TA facts.
+
+Those PRs should be treated as pending upstream context. The RFQ SDK work should
+not duplicate their contract tests, E2E runner, CLI, or BUIDL fixture; it should
+provide the reusable TypeScript backend boundary those layers can call.
+
+## Layering
+
+```text
+src/execution/adapters/rfq/RFQAdapter.sol
+  -> on-chain settlement, signature verification, replay/expiry checks
+
+services/rfq SDK
+  -> quote construction, typed-data shape, validation, signing abstractions
+
+local reference example
+  -> mock pricing + in-memory nonce + local signer for integration guidance
+
+MVP demo backend
+  -> user-facing quote API built from the SDK for demos only
+```
+
+## Phase 1 — RFQ TypeScript SDK interfaces
+
+Goal: make `services/rfq` usable as the reusable quote-backend integration layer.
+
+Deliverables:
+
+- SDK interfaces:
+  - `TypedDataSigner`
+  - `NonceStore`
+  - `PricingProvider`
+  - `InventoryRiskCheck` placeholder
+- quote request/response validation:
+  - address format
+  - safe integer / bigint / decimal string amount handling
+  - positive amount checks
+  - TTL and expiry checks
+  - chainId and verifyingContract binding
+  - venue binding
+- keep EIP-712 typed-data generation compatible with `RFQAdapter`.
+- keep backend compliance as a non-goal; final compliance remains at fill time in `ExecutionRouter`.
+- local reference implementation:
+  - in-memory nonce store
+  - fixed/mock pricing provider
+  - capture/mock signer for tests
+- tests for:
+  - quote generation
+  - invalid request rejection
+  - unsafe number rejection
+  - nonce uniqueness
+  - typed-data shape compatibility
+
+Acceptance criteria:
+
+- `cd services/rfq && npm test` passes.
+- repo-level check includes the RFQ service test.
+- docs clearly state this is an SDK layer, not a production server.
+
+## Phase 2 — Local reference example
+
+Goal: show how an operator would wire the SDK without implying Corner Store operates the backend.
+
+Deliverables:
+
+- local-only example entrypoint under `services/rfq`.
+- mock pricing.
+- in-memory nonce.
+- test signer or local private-key signer clearly marked as non-production.
+- sample request/response for signed quote generation.
+
+Non-goals:
+
+- no hosted server.
+- no production key custody.
+- no market-making strategy.
+- no inventory management.
+- no compliance final decision.
+- no dashboard.
+
+Acceptance criteria:
+
+- a developer can run a local command to produce a signed quote payload compatible with `RFQAdapter`.
+- documentation explains which parts an operator must replace in production.
+
+## Phase 3 — MVP demo backend
+
+Goal: provide a demo backend that uses the RFQ SDK from a user's point of view.
+
+This is separate from the SDK issue and should be implemented after Phase 1. If
+PR #29/#30 are merged first, this backend should reuse the live-Anvil demo
+runner and CLI configuration instead of creating another deployment/demo path.
+If PR #35 is merged first, the BUIDL-like asset should be the default regulated
+asset scenario for this demo backend.
+
+Target demo flow:
+
+```text
+user requests quote
+  -> MVP backend calls RFQ SDK
+  -> mock maker prices and signs quote
+  -> user receives signed quote
+  -> user submits through ExecutionRouter/RFQAdapter
+  -> on-chain compliance passes or rejects
+  -> UI/CLI shows result
+```
+
+Potential deliverables:
+
+- local HTTP API or CLI wrapper.
+- `/quote`-style request/response shape if HTTP is chosen.
+- BUIDL-like demo asset pair config.
+- integration guide for local Anvil/Foundry deployment.
+- optional later dashboard issue.
+
+MVP backend non-goals:
+
+- no production RFQ operator service.
+- no real market maker.
+- no real custody.
+- no production signer/key-management claims.
+- no backend-side compliance override.
+
+Acceptance criteria:
+
+- demo flow can generate a quote and settle it through the protected Router path.
+- success and compliance rejection cases are both visible.
+- documentation states that production operators must replace pricing, signer custody, nonce persistence and risk controls.
+
+
+## Documentation audit notes
+
+This planning pass checked the product-spec index, roadmap, RFQ venue architecture,
+feature state, progress notes and open PRs #24, #28, #29, #30 and #35. The gaps
+found in current source-of-truth docs were:
+
+- RFQ backend SDK work was not explicitly separated from production RFQ server operation.
+- MVP demo backend was not listed as a later application/demo layer built on the SDK.
+- near-term roadmap issues jumped from RFQ v1 settlement to production hardening, skipping the SDK and demo-backend bridge.
+- pending E2E/CLI/BUIDL PRs were not called out as context for future RFQ backend planning.
+
+This document fills those gaps. Production RFQ hardening remains a separate track
+for dealer approval, custody, cancellation and partial-fill policy.
+
+## Product boundary
+
+RFQ backend responsibilities remain split:
+
+| Area | Corner Store provides | Operator provides in production |
+| --- | --- | --- |
+| Quote format | SDK and tests | integration into their backend |
+| EIP-712 typed data | SDK | signer custody and policy |
+| Pricing | mock/reference only | actual pricing strategy |
+| Nonce | interface + in-memory demo | persistent nonce store |
+| Inventory/risk | placeholder interface | actual inventory and risk controls |
+| Compliance | on-chain final gate | optional precheck only |
+| Hosting | none | operator-owned infrastructure |
+
+## First implementation issue
+
+Recommended first issue:
+
+```text
+feat(rfq): add TypeScript SDK interfaces for quote backend integration
+```
+
+That issue should not implement the MVP backend. It should prepare the SDK foundation the MVP backend will use.