QR Coupon Journeys implementation backlog

Status: design draft, 18 September 2026. The documents and mockup describe proposed implementation. They do not enable a campaign or change production billing. The tracking epic is MeshWeaver.Plugins #2066. Every issue below carries astra and design:qr-coupon-journeys.

Design of record

• Essentials architecture and fluent actions
• Phone QR card, prefilled offer and install experience
• LinkedIn post concept and campaign artwork
• Coupon fluent API, configurable features and COURSES3M claim
• Apple Pay, Google Pay, Card via Stripe and optional renewal
• Interactive design source

Implementation sequence

Stages 1a and 1b can proceed independently after architectural review. Phone and historical activity work can proceed in parallel with coupon work after the generic route/descriptor contract is stable. Coupon and Stripe implement against a shared reviewed claim/payment contract; avoid a circular dependency by testing each against contract fakes, then composing the real provider for the acceptance suite. Issues include scoped acceptance criteria, source ownership and prerequisites.

Model and reasoning budget

Recommendation checked against official documentation on 18 September 2026: use Claude Sonnet 5 with adaptive thinking and medium effort as the main implementer when paying metered API rates. Raise it to high for the neutral contracts, authentication/authorization, coupon-claim state transitions, subscription billing, event replay and recovery. For bounded UI, card/PWA, ordinary tests and documentation work, start at medium. These assignments are engineering judgment for this plan, not a measured model benchmark on this repository.

If implementing in Codex with GPT models, use GPT-5.6 Sol at medium, with the same selective move to high. Use GPT-5.6 Terra at medium for isolated, well-specified UI or test tasks when the budget is tighter; review its changes at the same gates. Do not use a low-cost model as an unreviewed owner of financial or authorization invariants just to reduce the per-token price.

For a difficult blocker or the final payment/access review, use GPT-6 Astra at high or Claude Opus 5 at high for a bounded review of the relevant diff and tests. Choose one reviewer; do not routinely run both. Do not default to xhigh, max or app-specific ultra across the project. Escalate only for a concrete unresolved question, then return to the ordinary setting. Reasoning labels are not calibrated to equal computation across vendors.

Standard uncached API prices below are USD per million input/output tokens, not a project-cost estimate. Reasoning consumption, caching, tools, request length and pricing tier affect actual cost; Claude/Codex subscriptions have their own included usage and billing rules.

Sources: Anthropic pricing, Claude effort guidance, GPT-5.6 Terra, GPT-5.6 Sol, GPT-6 Astra. Sonnet 5's provider default is high, so set medium explicitly for the cost-saving starting point. GPT-5.6 Sol's documented default is medium. Re-check prices and account availability when implementation begins.

Start with one bounded issue and inspect its total cost, accepted changes and review rework before extrapolating. Give each implementation task the relevant design node, issue acceptance criteria and source paths instead of repeatedly copying this entire conversation. Keep one implementation owner per issue and bring in a focused reviewer at the risk boundary. Reuse completed investigation evidence, limit unnecessary parallel agents, poll CI once at the prescribed cadence, and rerun tests when changes or failures justify it. Reserve part of the implementation budget for integration and device/payment verification, which no reasoning level replaces.

Fixed decisions from this request

• Reusable GUID action links and a phone QR card; sign-up/login before protected offer/card content; selected site and prefilled destination.
• Generic mechanism belongs in Essentials; coupon fluent API and domain semantics belong under Store/Coupon. Preserve Essentials → Store dependency direction.
• A payment method is collected upfront for the requested campaign, with genuine Apple Pay/Google Pay/Card via Stripe options wherever supported and honest capability fallback.
• Nothing charged to activate. There is plenty of free content. Non-free items require a separate explicit purchase confirmation.
• Coupon redemption can offer extra features. Personal automatic renewal is optional and has its own initially unchecked checkbox, exact price/date/cadence/cancellation terms and stored consent. The mockup can show the recipient's checked state.
• Approving the subscription authorizes its disclosed recurring payments; it does not authorize unrelated purchases. Payment-method saving alone authorizes neither a purchase nor a subscription.
• Current COURSES3M is Personal for up to 90 days, capped by its December 2026 expiry. The draft preserves that behavior and forbids misleading unconditional three-month marketing.
• No live coupon changes, access grants, wallet configuration, subscriptions or payments are created by the design work.

Decisions before campaign activation

Choose the registered destination site, course or catalog, issuer permissions and link-sharing policy. Decide whether to retain the existing cap or authorize a separate offer whose term actually guarantees a full 90 days. Approve authoritative renewal pricing, tax/currency, notices and cancellation terms. Resolve payment-method/consent retention and removal policy, existing-subscriber eligibility, and whether any no-method activation alternative should exist. Review public-route access and minimal core API changes with the maintainer.

Do not invent these values in a seed file or copy a live coupon as repo-owned content. The implementation can ship behind an unavailable/unconfigured state until the campaign has reviewed terms.

Completion evidence

The acceptance owner records an evidence table linked from #2065: exact commits/package versions, core release, test campaign and Stripe mode, device/browser, persona, selected method, renewal choice, accepted quote, expected/observed state and sanitized correlation IDs. Include both a fresh signed-in person with no purchases and anonymous attempts through all alternate read surfaces.

For no renewal, provider evidence must show successful setup and no charge, invoice or recurring subscription. For selected renewal, it must show zero due today, one correctly scheduled trial subscription, explicit accepted terms and cancellation before first charge. Duplicate events and recovery cannot create extra grants, installs or subscriptions. Test the first paid renewal and SCA/failure in controlled test time; test separate non-free item purchases with an explicit new confirmation.

Core changes follow platform CD. Registry consumers follow the supported plugin release pipeline after the compatible core release. Validate node shape, compile affected NodeTypes, execute Tests areas locally, complete required PR checks and review, then perform authorized production verification. Campaign rollback revokes new invitations and cancels pending future billing where required without silently revoking already-earned free or independently purchased access. Reconcile uncertain provider outcomes; never infer success from a redirect.

Review notes conserved with the design

The draft was checked against current source and read-only mesh coupon data. Findings incorporated here include: historical Activity results depend on a live kernel stream; Public differs from Anonymous; Essentials already depends on Store; RedeemFree is unsuitable as a new bounded-plan claim primitive without inspecting its eternal entitlement behavior; trial activation must protect existing paid/manual plans; and saved Apple Pay credentials cannot be treated as a generic reusable on-session card.

These findings are implementation constraints, not claims that the proposed APIs or screens already exist. Provider/browser citations live beside their corresponding design decisions in the payment and phone pages.