Meeting Alignment · Shopping Cart / Checkout · 8 July 2026

What the 8 July shopping cart / checkout meeting settled, and where it sits against the platform-future docs and the shipped billing architecture. The meeting doubled as Glen presenting the platform business thesis, so this is both a ratification record and a delta list. Status: RECONCILIATION · owner Glen · verified against the repo 8 July 2026. Companions: platform-business-thesis.md, cart-checkout-integration-addendum.md, platform-readiness-scorecard.md, writeback-two-way-sync.md, upbeat-data-bridge-map.md, platform-thesis-deck.html (now carries the FAQ and Future Horizons slides drawn from this meeting).

1. The headline: the thesis was ratified

Glen walked the thesis end to end in the room (the five pillars, the four moves, the eleven primitives, the three conditions, what "done" looks like). No one dissented from the direction. Every reservation raised was a "how", not a "whether": how transactions work without WooCommerce, how the 16 bespoke Pro clients migrate, who is authoritative when Upbeat is offline, who is blamed when an agency breaks a front-end. So this memo is not a challenge to the thesis. It is the list of things the meeting added, and the handful that are genuinely at odds with what is already written or already built and must be reconciled before they are folded into any spec.

Where claims were checked against the repo, the finding is cited to the file, spec id, or schema. Two claims from the room understate or invert what is already shipped, and those are called out plainly rather than propagated.

2. New decisions the meeting established

These are additive. They belong in cart-checkout-integration-addendum.md and, where noted, the scorecard.

• Off WooCommerce for new builds. Confirms the addendum (WooCommerce "not recommended for new builds"; the receiver is a legacy bridge for clients mid-migration). WordPress becomes one host among many rather than the system; the addendum keeps WordPress as an entry point, so "off WordPress entirely" is a direction, not yet a decision.
• Shipping is deliberately minimised. Flat fee per country, or a Shopify integration for the few serious sellers. Physical goods live on the storefront app, separate from memberships, events and tickets. This fills the gap the addendum already flagged (finding 3, Delta 4: "shipping / postage absent"); it is a resolution, not a contradiction. It is also a clean instance of the "saying no on the record" condition.
• Product authoring is per-app; pricing flows to a central store. Define the event and its ticket prices in Events, the course price in Learn, and let those flow to one central store that holds tax codes and membership pricing rules and gives the sales manager a single products view. See C3 (this is largely greenfield).
• Multi-item cart, prioritised. Membership plus event (the non-member to member upsell) and company-pays-for-all-staff come first. Broad cross-bucket carts (event plus book plus umbrella plus membership) are deferred until the data justifies them. The cart to single-order mechanism already exists in the ledger (crm_cart / crm_cart_items to crm_orders); the prioritisation is the new part.
• AMS-first pilot sequencing. AMS clients migrate first because Agend controls the whole stack and carries less bespoke baggage. Minor nuance against the scorecard, which names the AHRI pilot specifically; not a conflict.

3. At odds / needs reconciliation

The core of this memo. Each item: what the room said, what already exists, the tension, the recommended resolution, and the owner of the call.

C1 · Source of truth: gateway / Xero versus our own ledger [sharpest, data-model level]

• Room: "the store of truth is Xero or Stripe or whatever payment gateway"; Agend keeps a local transaction copy with a linkage back to the source, and sits above as the intelligence layer.
• Shipped / specced: the local ledger is authoritative, not a copy. SPEC-CORE-20260706 Decision 2.4: "marketplace_transactions is the money record". The payments rule: "amounts are computed server-side from the order ledger (crm_orders.total_cents)". Xero is a per-transaction reconciliation status, not the source (US-2.2 AC5, crm_orders Xero sync fields). The cart addendum states it flatly: "crm_orders + items as the single source of truth".
• Tension: taken literally, "Xero / Stripe is the source of truth and we keep a copy" inverts the shipped model and would rebuild the ledger as a downstream mirror.
• Resolution (recommended): keep the shipped model as canonical. Our ledger is the source of truth; the gateway and Xero reconcile to it; Agend is the intelligence layer above. The FAQ slide already states it this way ("Stripe and Xero are the ledger, not the interface. Agend sits above them"). Glen to confirm this wording so the meeting's phrasing does not harden into a design principle.
• Owner: Glen (wording), then the finance spec.

C2 · The "finance app": a dashboard section versus a standalone finance.agend.dev

• Room: pull payments and finance out of the CRM into a dedicated app, consolidated into the "dashboard" app; it becomes the finance and intelligence hub, handling offline / external payment reconciliation and pushing data out to WordPress, the website, the CRM and the portal.
• Shipped / specced: two things are already true. First, gateway agnosticism is built and production-grade, not a CRM proof-of-concept: @agend/payments provides resolveGatewayForAccount, the PaymentGatewayAdapter interface, and live stripe-connect.adapter.ts and eway.adapter.ts, enforced by a CI drift gate (SPEC-CORE-002). Second, the finance layer is already specced: SPEC-CORE-20260706 Decision 2.7 locks a read-only @agend/finance package and §11 names a future standalone finance.agend.dev tenant-treasury app; the finance UI is out of scope of that spec, and the four remaining app-local SDK paths plus the finance_transactions read-model are prerequisites (still Draft, open questions not closed).
• Tension: the divergence is location (dashboard app versus its own finance.agend.dev) and sequencing (the consolidation must land first). The meeting also under-credits how much is done: this is not a "build a driver layer" job.
• Resolution (recommended): reframe the work as (a) finish the four-path consolidation, (b) build the finance read-model and UI on the specced @agend/finance, and (c) make the dashboard-section versus standalone-app call explicitly. The existing note "finance-app = tenant-treasury-first, section-before-app" points at a section first. Do not rebuild gateway agnosticism.
• Owner: dev lead (sequencing) and Glen (app-location call).

C3 · Central product catalogue with per-app authoring [genuine greenfield]

• Room: a central store of products and price points with per-app authoring; tax codes and membership pricing rules held centrally.
• Exists: no unified, per-app-authored catalogue. public.marketplace_products is an Agend-admin-curated catalogue, not per-app authoring. Pricing is fragmented per domain: crm_membership_tiers (membership), course price records (LMS), event ticket prices, credit prices (Jobs / Studio). crm_order_items carries loose product_type / product_id refs plus xero_item_code / xero_tax_type. The consolidation spec unifies the transaction ledger only, explicitly not the catalogue.
• Tension: net-new scope no current spec covers.
• Resolution (recommended): write a dedicated spec for a cross-app product and pricing catalogue: per-app authoring surfaces (the event manager stays in Events), a central management view, and the tax-code and membership-rule home. Sequence after consolidation (C2), before any multi-currency work (C4).
• Owner: needs a spec.

C4 · Multi-currency and tax codes for North America [blocked by a DB constraint today]

• Room: build multi-currency and tax codes into the product definition for a North America expansion.
• Exists: the system is AUD-locked by a database constraint, crm_orders_currency_check CHECK (currency = 'AUD'); default_currency defaults to AUD; adapters and rule examples hardcode currency: 'aud'. Tax scaffolding is partial: crm_order_items.xero_tax_type and account_settings.tax_behavior exist, but there is no catalogue-level tax-code model.
• Tension: multi-currency is currently forbidden by the CHECK constraint, so this is genuinely new work, not a config toggle.
• Resolution (recommended): a currency and tax workstream that lifts the CHECK, threads currency through the adapters, ledger and display, and adds a catalogue-level tax-code model. Gate it on the catalogue (C3) and tie it explicitly to the North America go-to-market decision, so we do not fund it before the market is committed.
• Owner: needs a spec; the go / no-go is Glen's (market commitment).

C5 · Inventory / capacity authority under concurrent online and offline selling [sharpest technical gap]

• Room (Garth): who owns "tickets remaining" and event capacity when Upbeat runs offline back-of-house sales while Agend sells online, and how is double-selling prevented? Live quantity and price-point calls to Upbeat are exactly where performance falls over today, and the "Upbeat can be offline" dream depends on answering this.
• Exists: the two-way design solves the two adjacent problems and never lifts either to quantity. Price is handled by the Oracle class (bridge-map §1: cart pricing draws the member-specific price from Upbeat, with a shrink path as rules mirror into the hub). Money is handled by charge-first-record-async (writeback §5.4: the gateway moves the money synchronously, write-back only records the settled payment). But no direction class in bridge-map §1 (Mirror, Ledger, Shared entity, Agend-native, Migrate-candidate, Oracle) models an allocatable or decrementing counter. The conflict policy (writeback §7) is field-level and assumes conflicts are rare; a hot capacity counter is contention by design. Events are Tier 4, blocked on an unbuilt driver, and the sync-versus-migrate question is still open. So between sync cycles each store is stale to the other, and overselling is possible by construction.
• Tension: the design has no owner for the authoritative count and no oversell-safe mechanism. This directly undercuts the "Upbeat offline is pixie dust" claim for anything with capacity (events, limited stock).
• Resolution (recommended): three edits. (1) Add an "Allocatable / Counter" direction class to upbeat-data-bridge-map.md §1, naming which store is authoritative for capacity and how decrements reconcile. (2) Add a section alongside writeback-two-way-sync.md §7 that generalises the §5.4 charge-first-record-async pattern to seat and stock allocation. (3) Add an explicit capacity-ownership entry to the events sync-versus-migrate framework, since event capacity is the concrete case raised.
• Owner: architecture. This gates any "Upbeat can be offline" promise in the thesis for capacity-bearing products.

C6 · The intelligence hub: report builder and chat-with-data versus the templated-reports decision

• Room: the dashboard app becomes finance plus reporting plus a dynamic report builder plus Orchestrate plus, in time, chat with your data.
• Prior decision: the AI-insights direction was "build narrow templated board reports, not a free-form canvas" (SPEC 007 direction). A free-form report builder and chat-with-data is a broader ambition.
• Tension: mild direction drift rather than a hard contradiction, but the builder and chat ambition should be reconciled against the templated-reports call so a closed decision is not reopened by accident.
• Resolution (recommended): when the finance and insights surface is specced, state plainly whether it stays templated (per SPEC 007) or deliberately opens the builder and chat-with-data ambition.
• Owner: Glen / PM.

4. Future elements to capture

Raised in the room, mostly by Glen, worth preserving. Recommended folds noted; the canonical platform-business-thesis.md is owner-Glen, so these are proposed edits for his approval rather than changes made unilaterally.

• ISO 9001 and 27001 within 12 months. Committed through the APNA contract, roughly 20 to 30 thousand dollars plus annual recertification, with a quality management system, and a partner angle: partners can certify through Agend's process. Fold into the "Trust is the whole product" condition as a concrete, dated commitment. Aligns with the existing QMS and security-certification tracks.
• New geographies. North America is a real goal, with Canada, Europe and South East Asia behind it, reached by being the platform (agencies build) rather than by opening local dev houses. Depends on C4. Fold into the multi-CRM wedge and headless moves as a geographic axis.
• Partner economics. Train, certify and badge agencies through Agend Learn, then take a referral share; AI tools let them build front-ends on the MCPs and APIs while Agend owns the data, security and workflows. This is a revenue model for the Learn partner play and a concrete input to O5 (the commercial layer, still unwritten).
• Resilience as advantage. Dynamics today is a single VPS with no disaster recovery, failover or high availability. A true SaaS hub that keeps serving when Upbeat is offline turns that weakness into a differentiator. New framing, in no current doc; fold into pillar 1 (minimise Upbeat friction). Depends on C5 for anything capacity-bearing.
• Revenue milestone. Licensing has just crossed 50 percent of revenue for the first time. Concrete proof for the revenue-bridge condition; add as a datapoint (already on the Future Horizons slide).
• Hosting stance. Agend does not want to do hosting; clients own their environment and Agend provides the platform, plugins and tools ("Product Rob, not Project Rob"). A "saying no on the record" datapoint; fold into condition 2 / the scope-gravity rule.

5. Recommended folds (summary)

Item	Fold into	Type
Off WooCommerce, shipping resolution, multi-item priority	cart-checkout-integration-addendum.md	New decision
C1 source of truth	thesis / finance framing (keep ledger canonical)	Reconcile wording
C2 finance app location + sequencing	SPEC-CORE-20260706 follow-up	Reconcile + decide
C3 product catalogue	new spec	Greenfield
C4 multi-currency + tax	new spec, gated on C3 and market	Greenfield
C5 inventory / capacity authority	upbeat-data-bridge-map.md §1, writeback-two-way-sync.md §7, events sync-vs-migrate	Design gap
C6 report builder / chat	finance-insights spec	Reconcile with SPEC 007
ISO, geographies, partner economics, resilience, revenue, hosting	platform-business-thesis.md conditions / moves	Future element

6. Open decisions for Glen

1. C1: confirm "our ledger is the source of truth, the gateway and Xero reconcile to it" as the canonical statement (recommended: yes).
2. C2: is the finance surface a dashboard section or a standalone finance.agend.dev (recommended: section first), and is the four-path consolidation funded next?
3. C4 / new markets: is North America committed enough to fund the currency and tax workstream now, or is it staged behind the catalogue?
4. C5: who owns the inventory-authority design? It gates the "Upbeat can be offline" promise for events and limited stock.
5. C6: does the insights hub stay templated (SPEC 007) or deliberately open the report-builder and chat-with-data ambition?