docs: clarify product roadmap

[kapustazh]

Summary

The original roadmap began with implementation mechanics and mixed product decisions with delivery estimates. This PR makes it product-first, defines the B2B paid-API-job flow, names the implementation stack, organizes work only through dependencies and evidence gates, and documents how every domain component and A/B/C lane contributes to the complete system.

Scope and acceptance criteria

• The roadmap begins with global product vision, primary flow, product surfaces, and system context.
• Delivery phases and all 18 A/B/C packets contain ownership, dependencies, acceptance evidence, and handoff contracts without effort or calendar estimates.
• The shared stack and each coder lane's technology focus are explicit.
• The roadmap distinguishes P0-P6 delivery from later production-pilot stages.
• Domain records, state ownership, runtime components, ports, success, recovery, and A/B/C convergence are shown visually.
• No unrelated product-code change is included.

Product and security invariants

• Settlement cardinality remains 1 Business Intent / N Attempts / <= 1 committed Settlement.
• Privy remains the authorization boundary, Arc the settlement rail, and The Graph non-authoritative recovery/history evidence.
• UNKNOWN never grants permission to submit another payment.
• The diagrams preserve the same authority boundaries as the frozen v1 contract pack.
• No secret, token, production identifier, or personal data is included.

This is a documentation-only planning change. It does not modify runtime behavior or weaken the frozen v1 contract pack.

Architecture documentation

• plan.md: product context, runtime architecture, and delivery dependency graph.
• docs/DOMAIN_ARCHITECTURE.md: system context, domain relationships, state machine, component responsibilities, successful settlement, ambiguous recovery, port/adapter boundaries, and A/B/C convergence.

Validation

Local Markdown links: PASS
Packet count: PASS (18)
Planning estimate scan: PASS (none found)
Mermaid CLI 11.17.0: PASS (all 10 diagrams)
git diff --check: PASS
repository-policy: PASS on 47d289fab6c09338cc0bcd117a501203ad7bedd8

Independent review evidence

Gate A — candidate review

• Reviewer: Antigravity / Gemini 3.8 Flash (High)
• Verdict: PASS
• Candidate tree: b59511865357a40d77abce7377c074d1e137918a
• Findings: none
• Evidence: complete base diff reviewed; all 10 Mermaid diagrams rendered; acceptance criteria, frozen contracts, and security invariants passed.

Gate B — exact PR review

• Reviewer: fresh Antigravity / Gemini 3.8 Flash (High)
• Verdict: PASS
• Base: develop at 5ef6a66313614e67b476f56c98f47c65344fb6ec
• Head: 47d289fab6c09338cc0bcd117a501203ad7bedd8
• Head tree: b59511865357a40d77abce7377c074d1e137918a
• Gate A tree match: PASS
• Findings: none
• Milestone readiness: PASS

The optional Cloudflare Workers deployment check fails because the repository has no deployable site or Worker yet. The repository policy check is green, and both reviewers treated the Cloudflare result as external integration noise for this documentation milestone.

Risk and rollback

• Residual risk: named framework choices still require compatibility confirmation in A01/B01 before dependency versions are pinned.
• Residual risk: the Cloudflare deployment check will remain noisy until an application exists or the integration is detached from this PR flow.
• Rollback: revert this PR.

Human merge

• Human owner performs final review and merge.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	oneshot	47d289f	Sep 06 2026, 08:39 PM