XMR native

docs/production-plan.md

@@ -28,7 +28,7 @@ The design must specify what every validator can verify deterministically, which
 
 Mining one new card per roughly 15 minutes is independent of Monero's block schedule, but today's transfers are included in the same Wikideck blocks. Therefore XMR confirmation, Wikideck inclusion, Wikideck confirmation depth and any final XMR disbursement/unlock are **separate timing milestones**. Fast end-to-end settlement or a separate transaction-finality layer would need a reviewed consensus design, not just a faster payment poll. The operator has specified ordering, not yet approved changing Wikideck's block schedule.
 
-Pre-payment lock/reservation transactions might be needed to prevent double-selling. They must not transfer completed-sale ownership, and they would appear on-chain before XMR payment. **Whether such preparatory transactions are acceptable needs explicit confirmation** before implementing escrow. If no preparatory transaction is permitted, research must assess how seller availability and duplicate-sale prevention can work within that constraint.
+Pre-payment lock/reservation transactions might be needed to prevent double-selling. They must not transfer completed-sale ownership, and they would appear on-chain before XMR payment. **The operator approved preparatory locks/reservations for design research on 2026-10-20.** This does not approve an escrow authority, custody model, expiry policy or consensus implementation.
 
 ### P0 — architecture research and decision record (first critical path)
 
@@ -136,6 +136,8 @@ Acceptance: signed release evidence packet; recorded unresolved accepted risks w
 
 First implementation increment: write the M0 threat model/ADR research questions and P1 XMR domain specification, then build exact amount/property tests. Do not spend the next increment adding another disconnected “live” scaffold. Each milestone must integrate with its actual callers, persistence, recovery, UI and failure tests before being described as delivered.
 
+First increment status: [M0 source-grounded investigation/threat model](settlement-feasibility.md) and [M1 amount/migration specification](xmr-domain.md) recorded. Shared exact amount and commission primitives are reused by existing mock/processor-lab callers; no native-XMR public marketplace migration, approved exchange protocol or live payment integration is claimed. Both milestones remain open against their full acceptance criteria.
+
 ## 5. Acceptance evidence and release discipline
 
 For each requirement record: identifier, owner, ADR/policy version, code/schema version, tests and adversarial cases, measured limits, reviewed artifact hash, known residual risk and approving party. A test count alone is insufficient. Historical 122-suite/targeted-doc test results remain useful regression evidence, not proof of current production readiness; rerun against the frozen release.
@@ -156,7 +158,7 @@ Not every value is needed to begin engineering; each becomes a blocking decision
 
 | Decision | Needed by | Why |
 | --- | --- | --- |
-| Allow on-chain pre-payment NFT lock/reservation records without completed ownership transfer? | M0 | Determines viable anti-double-sale/escrow designs and interpretation of payment-first ordering. |
+| Preparatory on-chain NFT lock/reservation without completed ownership transfer | M0 — permission agreed | Approved for design research on 2026-10-20; exact rules and authority remain subject to ADR review. |
 | What exactly is the XMR payment destination and amount condition: seller receives net directly, or gross into approved conditional/custodial structure? How are host/author fees enforced? | M0 | Buyer payment confirmation, seller proceeds and disbursement may be different events. |
 | Acceptable trustless protocol liveness/cancellation delay, privacy disclosures and emergency recovery authority? | M0 | Cryptography cannot resolve an unstated trust/recovery policy. |
 | Author-leg payout costs: charged to seller; what cap/estimate tolerance and quote lifetime? | M1 | Net viability and buyer/seller signatures must agree before money moves. |