Add production ERC-3643 onboarding review gates

FEATURES.md

@@ -10,6 +10,48 @@
 동시에 하나의 feature만 `active` 상태로 둔다.
 
 
+## DEPLOY-003 — Production ERC-3643 Asset Onboarding
+
+### Behavior
+
+- Production onboarding is separated from local Anvil/demo `toolkit-onboard` and
+  from core deployment. A versioned `corner-store.production-onboarding.json`
+  declares the exact existing ERC-3643 token, IdentityRegistry/Compliance wiring,
+  Corner Store registries/adapters, PII-free legal package hash, Elements, Recipes,
+  Manifest, RecipeBinding[], governance Safe metadata, explicit operator executor,
+  active venues, RFQ makers, signer delegates and read-only inventory requirements.
+- The Toolkit validates the onboarding file with exact-object schemas, rejects
+  unknown fields, duplicate addresses/ids, unsupported codeHash keys, signer-secret
+  shaped fields, raw contact PII and incoherent RFQ/inventory relationships.
+- `production-onboarding-plan` renders deterministic Element/Recipe/Manifest,
+  venue, maker, signer schedule and owner-only delayed signer execution calldata plus Safe-compatible unsigned drafts.
+  It uses collision-free stage IDs, partitions Safe-owner and operator-authority
+  drafts, includes Safe/required approval/proposal identity on Safe drafts and
+  explicit executor/proposal identity on operator drafts, separates governance-owner/governance-delayed/operator
+  authority, refuses output overwrite, and never signs, broadcasts, transfers
+  tokens or generates ERC-20 approvals. Inventory appears as a read-only
+  verification dependency before service open.
+- `production-onboarding-verify` uses RPC read calls only and fails closed on
+  unavailable or mismatched ERC-3643 wiring, Identity Registry dependencies,
+  Element/Recipe registrations, Manifest hash/fields/bindings, ACTIVE Manifest
+  declarer/approver, governance Safe ownership of safe-owner targets, global/asset/venue pause gates, venue config, TokenPolicyRegistry/RFQAdapter operator authorization, maker approval,
+  signer delegate activation and inventory balance/allowance minima. Pending signer
+  authorization is reported but is not production-ready.
+- Example onboarding JSON is syntactically valid but uses obvious placeholder
+  non-live addresses/hashes; issuer/legal/TA evidence remains an external trust
+  boundary and cannot be inferred from a token address.
+
+### Verification
+
+- `npm test --prefix services/toolkit`
+- `npm test --prefix services/cli`
+- `git diff --check`
+
+### State
+
+passing
+
+
 ## RFQ-005 — Production RFQ Host Hardening
 
 ### Behavior

PROGRESS.md

@@ -15,6 +15,33 @@ source of truth로 사용한다.
 
 ## Completed
 
+- `DEPLOY-003 — Production ERC-3643 Asset Onboarding`: production core deployment과
+  local Anvil demo onboarding을 분리한 production-only asset onboarding Toolkit/CLI
+  surface를 추가했다. `corner-store.production-onboarding.json`은 exact schema로
+  ERC-3643 token→IdentityRegistry→Compliance wiring, Identity Registry dependency,
+  Corner Store registry/adapter/operator addresses, legalPackageHash, Element/Recipe/
+  Manifest/RecipeBinding, governance Safe metadata, explicit operator executor,
+  active venue, RFQ maker/signer delegate and read-only inventory requirements를 받는다. Validator는 unknown fields,
+  duplicate ids/addresses, unsupported codeHashes key, PII/secret shaped input,
+  omitted/empty venue or inventory, active RFQ venue without approved maker/signer
+  delegate/approved-maker inventory, RFQ config without RFQ venue를 fail-closed한다.
+  `production-onboarding-plan`은 deterministic calldata와 Safe-owner/operator-authority
+  drafts를 분리한다. Safe drafts에는 Safe/required approval/proposal identity가,
+  operator drafts에는 explicit executor/proposal identity가 포함되며 immutable output으로
+  쓰고 governance-owner/governance-delayed/operator authority를 분리하고 transfer/approval/
+  broadcast를 생성하지 않는다.
+  `production-onboarding-verify`는 injected reader/JsonRpcProvider로 ERC-3643 wiring,
+  code hash, registry state, exact Manifest hash/fields/bindings, ACTIVE
+  declaredBy/approvedBy, governance Safe ownership of safe-owner targets, global/asset/venue pause gates, TokenPolicyRegistry/RFQAdapter operator executor
+  authorization, maker approval, active signer and inventory balance/allowance를
+  read-only 검증한다. Pending signer는
+  detail로 보고하지만 ready가 아니다. 검증: `npm test --prefix services/toolkit`,
+  `npm test --prefix services/cli`, production onboarding example validation,
+  `git diff --check` 통과. `scripts/check.sh`는 실행했으나 known pre-existing
+  Solidity formatting blocker(`script/DeployProductionCore.s.sol`,
+  `script/DemoScenarios.s.sol`)에서 실패했다. Anvil E2E는 기존 untracked
+  `deployments/` 보호를 위해 이 slice에서 실행하지 않았다.
+
 - `DATA-002 — Provider-Neutral TA/KYC Evidence`: `services/compliance-data`에
   provider-neutral TA/KYC evidence coordinator와 replaceable store port를 추가했다.
   요청/결과는 subject, optional ONCHAINID identity, asset, request/evidence hashes와

QUALITY.md

@@ -2,15 +2,15 @@
 
 | Module | Grade | Reason | Required Improvement |
 | --- | --- | --- | --- |
-| Product documentation | B | SDK/reference DEX, 4-Layer, RecipeBinding Manifest, RFQ와 roadmap이 대체로 정합함 | production RFQ/OrderBook와 법률 승인 기준 보강 |
+| Product documentation | B+ | SDK/reference DEX, 4-Layer, RecipeBinding Manifest, RFQ와 production ERC-3643 onboarding runbook/CLI 흐름이 정합함 | production RFQ/OrderBook 운영 evidence와 법률 승인 기준 보강 |
 | Harness / agent workflow | B | HE-001, DOC-001, RFQ-001 상태·검증 이력이 존재함 | PR/CI 결과와 feature state 지속 동기화 |
 | Product Solidity | B | bounded RecipeBinding Manifest, lifecycle/history, Compliance Core, Router, hardened AMM/RFQ adapter가 컴파일·테스트됨 | production custody/partial fill, LP onboarding과 OrderBook 미구현 |
 | Foundry tests | B | unit/integration, canonical Uniswap v3 callback, RFQ failure path와 live Anvil E2E 존재 | 추가 adversarial/security tests |
 | Compliance data SDK | A- | Provider-neutral acquisition, audit, person-group state and TA/KYC evidence coordinator have smoke/conformance coverage with PII-free fail-closed behavior | Replace reference in-memory KYC store with operator transactional HA/WORM storage and audited provider adapters |
 | RFQ reference service / host | A- | EIP-712 SDK, module conformance, local demo HTTP API/CLI, durable coordinator/reference file store와 별도 production host hardening smoke가 존재함 | HA transactional coordinator store, production signer custody, shared limiter/WORM audit/TLS 운영 통합 필요 |
 | `tools/deploy-v3` | B | profile 단위 테스트와 pinned core artifact integration 존재 | unified production deployment orchestration 추가 |
 | CI / static analysis | B | GitHub Actions와 local check가 동일한 repository-wide gate를 실행해 Foundry, 서비스 smoke, dashboard와 deploy-v3를 검증함 | medium warning budget과 독립 보안 분석 도입 |
-| Security documentation | B | trust boundary, direct venue boundary와 구현 전 보안 규칙을 문서화함 | RFQ/dealer/custody 위협 모델과 production review 체크리스트 보강 |
+| Security documentation | B+ | trust boundary, direct venue boundary, RFQ hardening and production onboarding no-broadcast/no-inventory-mutation verifier semantics를 문서화함 | production custody/incident runbook과 external audit checklist 보강 |
 
 ## Grade Guide
 

docs/deployment-production.md

@@ -166,10 +166,39 @@ claims. Those require issuer/TA evidence and separate Safe-reviewed onboarding:
 8. run a compliant settlement and expected-rejection smoke test before opening
    user access.
 
-The current Toolkit validates production core configuration and can package
-generic governance proposal envelopes, but it does not yet generate the full
-ERC-3643 onboarding calldata sequence. It also cannot infer legal requirements
-from a token address. The issuer/legal-approved mapping and reviewed onboarding
+The Toolkit now accepts an explicit, versioned production onboarding file such
+as
+[`services/toolkit/examples/corner-store.production-onboarding.json`](../services/toolkit/examples/corner-store.production-onboarding.json).
+It generates deterministic calldata and Safe-compatible unsigned drafts for the
+reviewed Element, Recipe, Manifest, venue, maker and signer activation sequence.
+The onboarding config must include governance Safe metadata (`safe` and bounded
+`requiredApprovals`), an explicit `operatorExecutor`, at least one active
+venue and at least one read-only inventory requirement. Active RFQ venues additionally require an approved maker,
+a signer delegate for an approved maker and inventory for an approved maker:
+
+```sh
+corner-store production-onboarding-plan corner-store.production-onboarding.json --out safe-onboarding.json
+corner-store production-onboarding-verify corner-store.production-onboarding.json --rpc-url https://approved-rpc.example
+```
+
+The plan command creates an immutable JSON output and refuses to overwrite an
+existing file. Safe-owner drafts are restricted to `authority == safe-owner` and carry `chainId`,
+`safe`, `requiredApprovals`, a deterministic `proposalId`, `expectedArtifactHash`,
+`legalPackageHash` and the stable onboarding identity hash. Operator-authority
+steps are exported separately as `operatorTransactions` with `chainId`, explicit
+`executor`, deterministic `proposalId`, artifact/legal/onboarding identity and a
+label; the tool does not assume the Safe is an operator. It never signs, submits, broadcasts, transfers
+assets or generates ERC-20 approvals. Inventory activation is represented as a read-only verification
+stage that checks balance, allowance and PII-free risk evidence before service
+open. The verify command reads chain state through RPC and fails closed on any
+unavailable or mismatched value: ERC-3643 token wiring, Identity Registry
+dependencies, governance Safe ownership of safe-owner targets, registered Elements/Recipes, exact Manifest hash/fields/bindings,
+ACTIVE Manifest with non-zero declarer/approver, global/asset/venue pause gates,
+venue config, maker approval, active signer delegate and inventory minima. A
+pending signer delay is reported but is not considered ready.
+
+The tool still cannot infer legal requirements from a token address. The issuer/
+legal-approved mapping, PII-free evidence hashes and reviewed onboarding
 transactions are required deployment inputs.
 
 ## Deployment Flow
@@ -188,24 +217,26 @@ transactions are required deployment inputs.
    release `sourceCommit` and `contractsHash`, successful dry-run chain ID, successful fork
    simulation chain ID/block and review timestamp. `production-deploy` rejects
    missing, stale or mismatched evidence.
-8. Build multisig payloads for policy, asset and venue activation.
-9. Review payload target addresses, calldata, nonce, chain ID, config hash and
-   artifact hash.
-10. Execute the core deployment through an external Foundry signer. The script's
+8. Generate immutable onboarding Safe drafts with `production-onboarding-plan`;
+   review target addresses, calldata, stage dependencies, chain ID, Safe address,
+   operator executor, required approvals, deterministic proposal IDs, config hash,
+   artifact hash, legal package hash and onboarding hash.
+9. Execute the core deployment through an external Foundry signer. The script's
    final deployment phase hands all governed contracts to the preflighted Safe;
    it activates no asset or venue.
-11. Verify bytecode, owners, roles and complete Router/Engine bindings against
+10. Verify bytecode, owners, roles and complete Router/Engine bindings against
     the production artifact. Verification compares each deployed runtime
     bytecode hash with the hash written by the reviewed deployment script.
-12. Prepare and execute separate Safe proposals for the legal-approved policy,
-    existing ERC-3643 asset and venue activation.
-13. Verify registry state, Manifest hash and venue
-    registration on-chain.
-14. Activate legal-approved Manifest, then activate venue, maker, signer and
-    inventory in staged transactions.
-15. Start monitoring, indexer finality tracking, alert routing and incident
+11. Execute the reviewed Safe/operator onboarding transactions in order:
+    Element/Recipe registration, Manifest registration, Manifest approval, venue
+    registration, RFQ maker approval, signer scheduling and owner-only delayed signer execution.
+12. Wait the signer authorization delay before executing the signer activation
+    transaction; pending authorization is not production-ready.
+13. Run `production-onboarding-verify` and stop on any failed read, mismatch,
+    safe-owner target owner mismatch, missing operator role, pause/suspension or inventory minimum failure.
+14. Start monitoring, indexer finality tracking, alert routing and incident
     response readiness.
-16. Record immutable deployment evidence and update the production manifest.
+15. Record immutable deployment evidence and update the production manifest.
 
 The evidence file has this minimum shape:
 
@@ -268,7 +299,8 @@ trade flow.
    and allowance evidence exists.
 6. Signer activation: signer is authorized under the maker authorizer policy and
    linked to the maker account.
-7. Inventory activation: maker inventory, approvals and risk limits are set
+7. Inventory activation: maker inventory and allowances are set by the maker/
+   operator outside this tool, then verified read-only with risk-evidence hashes
    before accepting production RFQ requests.
 8. Monitoring activation: event ingestion, finality policy, alerting and
    incident contacts are live before user-facing enablement.
@@ -308,15 +340,16 @@ claim that any mainnet deployment has passed.
 
 ## Remaining Production Integrations
 
-The repository now supplies fail-closed core deployment tooling, but a real
-launch still needs organization-specific implementations and evidence:
+The repository now supplies fail-closed core deployment and ERC-3643 asset
+onboarding plan/verify tooling, but a real launch still needs organization-
+specific implementations and evidence:
 
 1. Safe creation or adoption, owner verification and an approved `N-of-M`
    governance policy;
 2. issuer/TA confirmation of claim topics, trusted issuers, investor ONCHAINID
    claims, expiry and revocation behavior;
-3. a legal-approved Element → Recipe → Manifest package and Safe transaction
-   calldata for the exact token;
+3. a legal-approved Element → Recipe → Manifest package and reviewed
+   `production-onboarding-plan` Safe drafts for the exact token;
 4. production RFQ pricing, risk, durable maker-scoped nonce, signer custody,
    inventory and allowance controls;
 5. target-chain fork simulation, explorer source verification and deployment

docs/security.md

@@ -144,6 +144,27 @@ venue/adapter에만 실행을 위임하며, 성공 후 stateful compliance `comm
 - partial fill은 새 quote/adapter version과 별도 accounting/replay 검증 전까지
   활성화하지 않는다.
 
+## Production Onboarding Safety
+
+- `production-onboarding-plan`은 unsigned calldata/Safe draft export 전용이다.
+  private key, Safe owner signature, broadcast, token transfer 또는 ERC-20 approval을
+  생성하지 않는다.
+- onboarding config는 exact schema를 사용하고 unknown field, signer-secret shaped
+  key/value, raw contact PII와 중복 address/key를 fail-closed한다. Governance Safe, bounded required approvals,
+  explicit operator executor, at least one active venue and at least
+  one inventory requirement are mandatory. Active RFQ venues additionally require approved maker,
+  signer delegate and approved-maker inventory evidence. Legal/TA evidence는 PII-free
+  hash로만 참조한다.
+- `production-onboarding-verify`는 ERC-3643 token→IdentityRegistry→Compliance
+  wiring, Identity Registry dependencies, Element/Recipe registry state, exact
+  Manifest hash/fields/bindings, global/asset/venue pause gates, maker approval,
+  governance Safe ownership of safe-owner targets, active signer delegate,
+  operator executor authorization on TokenPolicyRegistry and RFQAdapter, and inventory balance/allowance minimum을 read-only로 확인한다. Unavailable RPC/read mismatch, safe-owner target owner mismatch, pending signer authorization, paused
+  global/asset/venue state or missing inventory evidence is not production-ready.
+- Inventory mutation은 maker/operator custody process의 책임이다. Corner Store
+  tooling은 inventory-before-service-open 조건을 plan dependency와 verifier evidence로
+  표현할 뿐 transfer/approval/custody transaction을 합성하지 않는다.
+
 ## Logging
 
 - RFQ host audit events must hash principals, request bodies and idempotency keys;

docs/testing.md

@@ -60,8 +60,10 @@ idempotent replay를 검증한다.
 
 Backend smoke는 injected scenario loading, ephemeral HTTP server의 health/quote
 API, fixed-rate pricing, maker signature, monotonic nonce와 numeric amount
-거부를 검증한다. CLI smoke는 backend quote request path와 기존
-quote-file/서명 검증 경로를 함께 검증한다.
+거부를 검증한다. CLI smoke는 backend quote request path, 기존 quote-file/서명
+검증 경로, `production-onboarding-plan --out` immutable export/overwrite
+refusal and `production-onboarding-verify` fail-closed nonzero behavior를 함께
+검증한다.
 
 Standalone SDK integration smoke:
 
@@ -74,8 +76,15 @@ Toolkit smoke는 unified `create`가 생성하는 `library-only`,
 `reference-service`, `existing-backend` 세 mode의 manifest, `.env.example`,
 vendored `vendor/rfq-service`, optional Docker files, overwrite refusal과
 standalone package scripts(`doctor`, `deploy`, `verify`, `test:module`)를
-검증한다. SDK-002 문서 또는 packaging 변경에서는 CLI help, `doctor`, dry-run
-`deploy`, `verify`/preflight와 `test-module` command path도 별도로 확인한다.
+검증한다. Production onboarding smoke는 exact schema/unknown-field rejection,
+PII/secret rejection, deterministic Element/Recipe/Manifest/Venue/RFQ calldata,
+Safe/operator draft governance/proposal metadata, authority partition, explicit
+operator executor metadata, safe-owner target owner checks, stage dependency including governance-delayed signer execution, mandatory active venue/inventory
+gates, RFQ activation coherence, AMM-only coherent mode, read-only
+inventory stage, ACTIVE Manifest field verification, pause gate verification and
+pending-vs-active signer and safe-owner target owner mismatch/unavailable and operator role mismatch/unavailable fail-closed behavior를 포함한다. SDK-002 문서 또는 packaging 변경에서는 CLI help, `doctor`,
+dry-run `deploy`, `verify`/preflight와 `test-module` command path도 별도로
+확인한다.
 
 Generated consumer projects should keep this local gate:
 

scripts/check.sh

@@ -45,36 +45,36 @@ echo "==> Running production RFQ host hardening smoke test"
   npm test
 )
 
-echo "==> Running CLI build + smoke test"
+echo "==> Running Toolkit config build + smoke test"
 (
-  cd services/cli
+  cd services/toolkit
   if [ ! -x node_modules/.bin/tsc ]; then
     npm ci
   fi
   npm test
 )
 
-echo "==> Running RFQ demo backend build + smoke test"
+echo "==> Running CLI build + smoke test"
 (
-  cd services/rfq-demo-backend
+  cd services/cli
   if [ ! -x node_modules/.bin/tsc ]; then
     npm ci
   fi
   npm test
 )
 
-echo "==> Running public-testnet RFQ demo build + smoke test"
+echo "==> Running RFQ demo backend build + smoke test"
 (
-  cd services/testnet-rfq-demo
+  cd services/rfq-demo-backend
   if [ ! -x node_modules/.bin/tsc ]; then
     npm ci
   fi
   npm test
 )
 
-echo "==> Running Toolkit config build + smoke test"
+echo "==> Running public-testnet RFQ demo build + smoke test"
 (
-  cd services/toolkit
+  cd services/testnet-rfq-demo
   if [ ! -x node_modules/.bin/tsc ]; then
     npm ci
   fi