Updated 2026-11-12 · rebuilt from the repo on every deploy

C1 Platform Spec

The build spec for C1: a multi-tenant platform for membership portals, courses, sessions, retreats and their public websites, built as a layer on the Blackline codebase. Any agent can pick up a phase from this file and build it.

• Owner: Nick Nguyen. Engine and core reviews: Evgeny.
• First tenant: The Tranquillity.
• Mockups: round 1 (Tranquillity business admin) and round 2 (platform, account and business scopes). Paths are in Sources.
• Status: planning. Nothing in this file is built yet unless a section says so.

How to use this file

1. Read Vocabulary, Rules and Ruled out before writing any code.
2. Pick the next phase in Build phases. Each phase lists its modules and its done-criteria.
3. Build each module from its entry in Modules. Every entry uses the same template.
4. A decision marked Recommended or Open needs Nick's confirmation before it becomes code. A decision marked Decided is settled; reopen it only with new information.
5. When you change a decision, update this file in the same change and add a line to Changelog.

Repo conventions still apply: CLAUDE.md, docs/coding-standards.md, docs/testing.md, docs/file-structure.md, docs/query-engine.md.

Stack

Every spec change, design and build in this file assumes C1's stack. Check a proposal against it before writing it down.

Rule 0: no feature may need a second frontend framework inside C1. Other frameworks (Astro, Next, Nuxt) are allowed only in custom-tier brand repos that live outside C1 and talk to its API.

Vocabulary

One word per meaning. Use these words in code, UI labels and docs.

Rules

These hold for every change. A change that breaks one is a bug even if the tests pass.

Codebase

1. C1 is a layer on Blackline, not a fork to strip. C1 regularly merges upstream Blackline (see the merge-main skill). Never delete a Blackline file. Hide real-estate features; do not remove them.
2. C1 code lives in its own folders: api/src/modules/c1_*, shared/modules/c1_*, app/src/modules/c1/. Blackline files change only at the hook points listed in Hook points. A script compares changed Blackline paths against that list (Phase 1).
3. New tables use the c1_ prefix in the public schema. Every business-owned table carries project_id.
4. New reads go through the query engine (entities and queries), per docs/query-engine.md. Admin lists are query declarations, not new routes.
5. Project settings follow the blackline-settings-convention skill. C1 settings are declared once in the C1 settings catalog (see Settings catalog).
6. Post Player is untouched. The Blog module is separate from app/src/ui/post-player/ and its invariants. They share only the TipTap dependency.

Tenancy and data

7. No tenant word in code. Brand names, colours, copy and section labels live in seed data and admin records. Test: seed a made-up tenant and grep for "Tranquillity" outside seeds.
8. Every screen a member sees reads from an admin record.
9. Businesses never read each other's tables. Cross-business data flows only through a link, using the other business's published queries and services.
10. A module writes only its own tables. Other modules call its service functions.
11. No kind-specific column on c1_offering. Kind-specific fields live in that kind's details table.
12. Account-level modules hold relationships, never money. Every money record belongs to exactly one business.

Money

13. Money stays with the business that earns it. Each business charges through its own payment provider account. No money moves through C1. (Decided)
14. Money only moves against an order. Access reads entitlements, never payments. Provider messages are verified, stored once, then applied. A new provider never touches the core. (From the billing plan.)
15. Payout routes are frozen onto the order when it is paid. Changing a payee's share later never changes money already taken.

People and access

16. One person, one identity, everywhere. Products and businesses link to the person; they never create their own user table.
17. Seeing and doing are separate. Entitlements decide what a person can see. Role grants decide what they can do. Climbing the ladder adds rows; nothing is replaced.
18. Every super admin and support grant action is written to the audit log.
19. Special-category data (health, diet, brief history) is readable only by facilitator roles on that offering, and every read is logged.
20. An agent acts with the permissions of the person who connected it. Agents never create payments, refunds or payouts without a person confirming.

Websites

21. Code never holds content, and content never holds layout. Block components are code. Block content is data in C1.
22. Brands never hand C1 their infrastructure credentials. Domains point at C1 with a DNS record.

Ruled out

Each of these was considered and rejected. Don't re-propose one without new information.

Tenancy

Platform (C1 super admins)
└─ Account: an organization that pays C1. A brand, or an agency.
   ├─ Business: a project. One legal entity, its Stripe account, staff, members, domain.
   │    └─ Modules switched on for it (Academy, Sessions, Meditation, ...)
   ├─ Business: ...
   ├─ Links between its businesses (identity, catalogue, access)
   └─ Connections to outside systems

• Business = project. (Recommended; the billing plan already assumes it.) Reuses C1's project scoping, domains, portals, roles and project_member.
• Account = organization. The organization table already owns projects (migration 20260603100000) and holds the Postmark server.
• When something is its own business: it has its own legal entity, bank or Stripe account, or a team that must not see the rest. A section of the same business is a module.
• The Tranquillity today (Decided): one account with two businesses.
  • The Tranquillity: Meditation, Live, Academy, Sessions, Library, Blog.
  • Tranquillity Retreats: Retreats, Shop. A separate legal entity.
  • The Academy stays a module of The Tranquillity until a split trigger fires: its own legal entity, Stripe account or books, a team that must not see the rest, or a partner or sale.
• Agencies. An agency is an account that owns client businesses, or holds support grants on businesses owned by other accounts. The scope switcher lists every business a person can reach, grouped by account.

What lives at the account, and what stays with the business

The test: does the thing create an obligation to a customer? Money, consent, contracts and personal data held as a data controller stay with the business, because the business is the legal entity. Tools, assets, credentials and read-only views can rise to the account.

• Campaigns stay with the business (recommended; Nick to confirm). A newsletter is sent by a legal entity to people who consented to that entity. An account-level "send to several businesses" can come later as a fan-out: one draft, sent by each business to its own consenting contacts, de-duplicated across them.
• When the line moves: if two brands share one legal entity, model them as one business with two sites, and campaigns can then reach both audiences.

Links between businesses

A link grants each of these separately:

1. Identity: the same person is the same member in both businesses.
2. Catalogue: a hub business may show offerings from the linked business, read through that business's published queries.
3. Access: a hub portal may check an entitlement held in the linked business.

Money never crosses a link. A member buying from two businesses uses two checkouts.

Consent

Marketing consent belongs to a legal entity. A shared list across two legal entities needs consent that names both, or each business emails only its own consenting contacts. One list is fine within one legal entity.

Roles and the ladder

c1_role_grant(person_id, role, scope_type, scope_id, granted_by, granted_at, expires_at, revoked_at)

• A permission check resolves through the narrowest matching scope.
• The member portal shows Teach, Facilitate or Practise areas only to people holding those roles.
• The admin scope switcher shows only scopes the person holds.
• Promotion and removal are one audited action each, with a Grant Role flow in Account › Team and Roles.
• Existing Blackline project roles (projectPages) keep working for Blackline pages; C1 roles drive C1 screens. (Recommended; reconcile in Phase 1.)

Modules

Module registry

Each module declares a manifest:

// app/src/modules/c1/<module>/module.ts and api/src/modules/c1_<module>/module.ts
{
  key: 'academy',
  scope: 'business',            // 'business' | 'account'
  sellable: true,               // a C1 tier an account can buy
  dependsOn: ['offerings', 'video'],
  adminNav: [...],              // menu entries, labels in Title Case
  portalTabs: [...],            // member portal tabs
  entitlementPrefixes: ['academy:'],
  events: ['enrolment.created', ...],
  settings: [...],              // keys in the C1 settings catalog
}

• A business has a list of enabled modules. A disabled module registers no menu, no portal tab, and no route.
• Always on, as part of the shell: Home, Members, Account, Payments, Brand, Settings.
• If a business has exactly one member-facing module, that module becomes the portal's Home.
• Super admins switch modules per business in Platform › Modules. Selling module tiers through billing comes later (Phase 9).

Module template

Every module below uses these headings: Scope, Records, Admin, Portal, Roles, Events, Depends on, Done when.

Offerings (core)

• Scope: business.
• Records:
  • c1_offering: business, kind (retreat | session | course | workshop | membership | event), code (for example NOR26), slug, name, subtitle, status, date fields, timezone, capacity, currency, booking windows, entitlement keys it grants, page template, route prefix, published flag.
  • Details per kind: c1_retreat_detail, c1_session_detail, c1_course_detail, c1_membership_detail, later c1_event_detail.
  • c1_enrolment: offering, person, stage, booking or order reference, dates.
  • c1_enrolment_stage_set: kind and its ordered stages.
  • c1_offering_staff: offering, person, role (through role grants).
• Admin: Business › Offerings. One list filtered by kind. One editor with shared tabs (Details, Pricing, Staff, Payees and Splits, Forms, Page, Connections) plus a kind tab (Itinerary, Availability, Curriculum, Renewal).
• Portal: the offering's page and its enrolment state.
• Roles: admin and editor manage; teacher, facilitator and practitioner see their own offerings.
• Events: offering.published, enrolment.created, enrolment.stage_changed, enrolment.cancelled.
• Depends on: Billing.
• Done when: a retreat, a session and a course are each created from the same editor; a test proves no kind-specific column exists on c1_offering.
• Source: retreat spec section 34.1.

Billing (core)

• Scope: business.

• Records: the 12 c1_ tables in the billing plan (orders, transactions, subscriptions, prices, entitlements, webhook inbox and the rest). Provider adapters: Stripe first; Razorpay, Revolut and PayU later.

• Admin: Business › Sales: Plans and Prices, Subscriptions, Orders, Transactions, Declines. Business › Settings › Payment Providers.

• Portal: Join, Account › Membership, the single Payments page, the attention badge that can't be dismissed.

• Roles: admin; editor read-only.

• Events: canonical billing events from the plan (payment.succeeded, payment.failed, ...).

• Depends on: none.

• Done when: Meditation Membership can be bought, renewed, failed and recovered on Stripe test mode; access follows entitlements.

• Source: docs/c1-billing-plan.md, the full plan: rules, decisions, tables, lifecycles, flows, declines, routes, jobs, adapter, build plan and open questions. It wins over this summary on billing detail.

• Changes from the billing plan: c1_order_item comes into scope now (the plan left it out until the Shop needed several items per order). c1_product.kind adds item for shop items. Shipping and tax stay out of the MVP; prices are tax-inclusive.

Bundles and Tiers

• Scope: business. Part of Billing. (Decided: Nick wants retreat tiers with digital add-ons.)
• What it is: one price that delivers several things. A tier of an offering (for example Nepal 2027 Standard and Nepal 2027 Sanctuary) can include add-ons: digital items (a recorded course, a guided audio pack, a PDF), shop items (an oracle deck, a gift box), or access to another offering.
• Records: c1_price_component: price, component type (entitlement | shop_variant | offering), reference, quantity. Buying the price creates one order with an order item per component, grants each entitlement, creates fulfilment for shop items, and applies each component's own payee split.
• Admin: the offering editor's Pricing tab shows tiers side by side, each with its included add-ons; a Bundles list under Sales for bundles that are not tied to one offering.
• Portal: a tier picker on the offering page that lists what each tier includes.
• Rules: a bundle never hides its components' payee splits; refunds apply per component.
• Depends on: Billing (c1_order_item), Offerings, Shop, Payees and Splits.
• Done when: Nepal 2027 sells two tiers, the higher one including a digital pack and a shop item, with one order and the right entitlements, fulfilment and splits.

Plans and Tiers (tier builder)

• Scope: platform and business. One builder, used twice. (Decided: Nick wants it in C1's back end, and brands use the same tool.)
  • Platform › Plans: C1's own plans that accounts buy (for example Core, Studio, Events, Agency). C1 is "tenant zero": it sells through the same Billing system as every business.
  • Business › Sales › Plans and Prices: a brand's member tiers (for example Free, Meditation, Full Membership).
• Model (plans as data, never in code):
  • A tier is a c1_product of kind plan, with one c1_price per interval and currency (monthly, yearly, GBP, USD, INR).
  • c1_product_feature: product, feature key, type (included | limit | metered), value. Examples: module:academy (included), funnels = 5 (limit), funnel_emails (included), storage_gb = 100 (limit), businesses = 3, staff_seats = 10, custom_domain, custom_repo, app_store_listing, video_minutes (metered).
  • Buying a tier grants entitlements with the feature values. Limits are checked by reading the entitlement, never the plan.
  • Versions: editing a live tier creates a new version. Existing subscribers stay on their version (grandfathered) until moved, with a preview of who changes and by how much.
  • Add-ons: extra storage, extra seats or one module, priced on their own and stackable.
  • Trials and promotions: trial_days on a price; coupons come with the billing plan's coupon table.
• Builder screen: a matrix with tiers as columns and features as rows; tick included features, type limits, set prices per interval; a "Most Popular" highlight; draft, preview and publish; a customer-facing pricing table generated from the same data.
• Customer of C1: for tenant zero the customer is an account (organization), not a member. c1_customer gets an optional organization_id, and exactly one of user_id or organization_id is set.
• Rules: a price change never alters a paid period; downgrades that would break a limit (for example more businesses than the new tier allows) show what must change first.
• Depends on: Billing, Bundles and Tiers.
• Done when: C1's four plans and Tranquillity's member tiers are both edited in the builder, a new version is published, and existing subscribers stay on the old one.

C1 Website and Sign-Up

• Scope: platform. C1 is tenant zero: its own public website and sign-up run on the same site engine, Pages, Blog, Forms, Email and Billing that brands use.
• Site Pages: the marketing site (home, features per module, templates gallery, agencies, about, legal), edited as blocks like any business's pages.
• Pricing Page: generated from Plans and Tiers, so a tier or price change in the builder updates the public page. Monthly and yearly toggle; add-ons listed.
• Sign-Up Flow: self-serve onboarding for a new brand or agency: create an account, pick a plan (with trial), name the first business, choose a site template and modules, connect a domain (one DNS record), connect Stripe, invite the team. It writes the same records as Platform › Onboarding, which super admins use for assisted set-ups. An optional step offers Website Import.
• Leads and Trials: every sign-up started, where it stopped, trials and their end dates, conversions to paid, and the source link that brought each lead (Links and Attribution). Email automations nudge stalled sign-ups and ending trials.
• Admin: Platform › C1 Website: Site Pages, Pricing Page, Sign-Up Flow, Leads and Trials.
• Depends on: Plans and Tiers, Pages and Sites, Forms, Email, Links and Attribution, Billing.
• Done when: a made-up brand signs up on C1's site, picks a plan with a trial, and lands in its new business's admin without staff help.

Payees and Splits

• Scope: business.
• Records:
  • c1_payee: person or vendor, Stripe connected account id, status.
  • c1_split: offering or item, payee, share (basis points or fixed), release rule (on_payment | after_refund_window | after_event | manual).
  • c1_transfer: order, payee, amount, Stripe transfer id, status. Reconciled nightly.
• How it works: separate charges and transfers on the business's own Stripe account. One charge per order, then one transfer per payee tied to the charge (source_transaction, transfer_group). Processing fees are allocated across payees. Every write uses an idempotency key and is read back from Stripe.
• Admin: Business › Sales › Payouts. Offering editor › Payees and Splits tab. Business › Settings › Payment Providers › Connected Accounts.
• Portal: a payee sees their earnings and payout dates in their Teach, Facilitate or Practise area.
• Roles: admin manages; a payee sees only their own.
• Events: transfer.created, transfer.paid, transfer.reversed.
• Depends on: Billing, Offerings.
• Done when: a session sale pays the practitioner their share after the release rule; refunding reverses the transfer.
• Source: the Norway shop's lib/shop/transfers.js at commit 8ffd687 (policy separate_transfers_actual_fee_v1). Compare it with the version deployed on the Tranquillity Retreats Cloudflare account before porting.

Meditation (video library)

• Scope: business. Sellable.
• Records: video source (youtube | vimeo | wistia | bunny | loom | c1), channel connection (YouTube channel, sync on or off), video (source, source id or file, title, length, format, tags, draft-tag flag, short link), tag group (Kind, Intention, Effect, Topic) and values, hosting usage per business.
• Sources:
  • Linked: videos stay on the platform the brand already uses (YouTube, Vimeo, Wistia, Bunny Stream, Loom) and play in that platform's official embed, so views count there.
  • Hosted on C1: upload to C1's own storage, streamed from C1. Each plan includes a storage allowance; more can be bought.
  • Backup: optionally keep a C1 copy of linked videos the brand owns, so a channel problem never empties the library.
• How linking works per host: connecting an account syncs automatically where the host has an API for listing videos (YouTube channel or playlists, Vimeo folders, Wistia projects, Bunny Stream libraries): new uploads arrive as drafts with suggested tags. Hosts without one (Loom, Google Drive, any other link) take pasted links one at a time, read through oEmbed where available. Each video records its source, and the player uses that source's official embed or C1's own player for hosted files. (Check each host's API terms before building its sync.)
• Components: the portal's Meditation library (search, filters, floating player, playlists) is a module component, built once in C1 and used by every business with the module. Sites get a Video block (one video, any source) and a Video Library block (a filtered grid from the module).
• YouTube channel management: connect a channel with Google sign-in; see subscribers, recent uploads and views; edit titles and descriptions from C1 (YouTube Data API); add a tracked C1 short link to a video's description in one click, so viewers who join can be traced back to that video.
• Admin: Video Library: Meditations, Echoes Talks, Tag Groups, Sources, Hosting.
• Portal: searchable library, floating player, member playlists, preset playlists by tag. Videos never autostart.
• Roles: editor.
• Depends on: Links and Attribution (tracked links).
• Done when: both Tranquillity channels sync; one Vimeo video plays from a link; one uploaded video streams from C1 within the allowance; tags filter; a member builds a playlist.

Live

• Scope: business. Part of Meditation, also sellable on its own.
• Records: live product (name, schedule, price, plan it's included in, banner on or off), live session (date, time, host, Zoom meeting id, access key, recording link), Zoom connection.
• Zoom: each business connects its own Zoom account (OAuth). C1 creates a Zoom meeting for each scheduled session, and members join inside the portal and the member app through the Live Room block, gated by the session's access key (for example meditation).
  • Desktop: Zoom's Meeting SDK for web in its component view, embedded in the page.
  • Phone and the Capacitor app: the SDK's full-page client view, or opening the Zoom app, because the component view is designed for desktop browsers.
  • Authorization: since 2 March 2026 Zoom requires apps that join meetings outside their own account to be authorized by that account (ZAK or OBF tokens). Connecting the business's own Zoom account covers this; check Zoom's current authorization docs before building.
  • Recordings: Zoom's recording.completed webhook brings each cloud recording into the Video Library (hosted on C1, members only). Check the current webhook payload and download tokens before building.
• Admin: Live: Sessions, Recordings, Zoom Connection, Settings.
• Portal and site: a Live page and a Live Room block for any page (countdown before, the embedded room during, the recording after).
• Done when: a member with Meditation joins Sunday's session inside the portal on desktop, and its recording appears in the library the next morning.

Academy

• Scope: business. Sellable (the C1 LMS tier).
• Records: offerings of kind course and workshop; c1_course_detail; module, lesson (recording, chapters, homework, summary, links), resource, practice, course page (info sections, FAQ).
• Admin: Academy: Courses, Modules and Lessons, Resources, Practice, Course Pages.
• Portal: Academy tabs (EOC, Workshops, Echoes Talks, Articles). A lesson is a pinned video with tabs underneath. Practice lives inside a course.
• Roles: teacher (own courses), moderator, editor.
• Depends on: Offerings, Meditation (for Echoes).
• Done when: the EOC and the Remote Viewing Intensive run end to end, including enrolment by entitlement.
• Boundary rule: Academy data lives in c1_academy_* tables and is changed only through the Academy module's services, so a later split into its own business is a data move, not a rewrite.

Sessions

• Scope: business. Sellable. Can be a business's only module (a practitioner business).
• Records: offerings of kind session; c1_session_detail (length, formats, questionnaire); practitioner (approved flag, calendar connection); availability (synced or manual); bookings as enrolments with a time slot.
• Admin: Sessions: Offerings, Practitioners, Availability, Bookings.
• Portal: Sessions tab, booking flow, Payments.
• Roles: practitioner (own bookings), admin.
• Depends on: Offerings, Billing, Payees and Splits.
• Done when: a member books and pays; the practitioner receives their split.

Retreats

• Scope: business. Sellable. Grows into general event management.
• Records: offerings of kind retreat; c1_retreat_detail; itinerary days and slots (public, participant and facilitator visibility); packing lists; FAQ; payment options; checklist; shared content (agreement, always-bring list, contact, shop).
• Operations (later in this module): suppliers and venues with comparison, tasks and task templates, expenses, kit lists, obligations. Built generally so it serves any event kind.
• Admin: Retreats: list, then a retreat page with Details, Itinerary, Packing, Questions, Payment Plans; Shared Content.
• Portal: retreat pages with a stage (Before, During, After) and a full-width wallpaper.
• Roles: facilitator (own retreat), admin.
• Depends on: Offerings, Billing, Forms, Payees and Splits.
• Done when: Nepal 2027 runs before, during and after in the portal.
• Open: build Retreats inside C1, or keep the separate Payload build connected? (Recommended: inside C1. See Open decisions.)
• Source: retreat spec v2.0 (sections 1, 27, 29, 33 to 37 first).

Shop

• Scope: business. Sellable. A standalone module, separate from Offerings. (Recommended)
• The rule: if buying it gives someone a place, access or a time slot, it is an offering (it has an enrolment). If it is a thing they own, shipped, picked up or downloaded, it is a shop item (it has stock and fulfilment). Both sell through the same Billing catalogue, orders and payee splits.
• Records:
  • c1_shop_item: name, description, images, type (physical | download), status, collection, linked offering (optional).
  • c1_shop_variant: item, options (size, scent, colour), SKU, stock, weight.
  • c1_shop_collection: a group of items with its own sales window, buyer rule (anyone, members, or holders of an entitlement such as retreat:nepal-2027) and payout release rule.
  • c1_fulfilment: order item, method (ship | pickup | download), address or pickup point, status, tracking.
  • Item-level splits in c1_split: each item or variant can pay a different maker.
• Connecting to other modules: a collection can link to any offering. The Retreat Shop is a collection linked to a retreat: only its participants can buy, items are picked up on site, and maker money is held until payouts open. A course can link a workbook; a membership can unlock a members-only collection.
• Admin (mirrors the Norway shop's admin): Shop: Orders (All, To Pack, Ready for Pickup or Shipped, Collected or Delivered, Needs Attention), Products (Catalogue, Collections, Offers, Low Stock), Makers (Profiles, Ledger, Payouts, Reconciliation, Stripe accounts), Storefront (the shop page: All Pieces, Our Makers, Questions), Settings (window, delivery, fees).
• Product page editor (Norway's structure): photos, name, product type, maker, variants with price and stock, content boxes (About, Benefits, Ingredients, Care, How to Use), delivery (ship, pickup, download), visibility and collection, with the live product page in the preview panel.
• Each business has its own shop: The Tranquillity's mirrors her current WooCommerce shop (11 products, read from WooCommerce's public Store API: the Oracle Deck £75, five incenses £8.50, the copper bottle £55, four handbags £45 to £55; Sandalwood shows £0 and is flagged for review). Tranquillity Retreats' mirrors the Norway retreat shop (36 items from four makers). Both use the Norway shop's structure.
• Portal and site: a Shop tab or a collection page; Shop blocks on the site engine.
• Roles: admin; maker (sees own items and earnings).
• Depends on: Billing (needs c1_order_item, see below), Payees and Splits.
• Done when: The Tranquillity's 11 WooCommerce products sell with shipping, and a retreat collection sells to participants with maker payouts held until release.
• Source: the Norway shop code (per-vendor routes, fee allocation, payout lock).
• Seed from the live Norway shop: its catalogue (scripts/shop-catalog-seed.mjs on the shop branches) becomes Tranquillity Retreats' Retreat Shop: 37 products (journals, a copper bottle, incense, Hilda's pendants and bracelets, Savinder's book, enamel pin sets) from four makers. Each maker keeps its payout route: Nikki's items settle to the shop itself, Sharan and Hilda through Stripe connected accounts (Hilda in USD), and Savinder is paid at pickup outside Stripe. The test vendor (Noir 9) is not imported.

Library

• Free gifts are tracked: every gift gets its own short link (Links and Attribution). Its page shows clicks, claims, free sign-ups, paid members and revenue, by source.
• Scope: business. Free gifts claimed through a social link (creates a free account), saves, playlists.

Blog

• Scope: business. Sellable.
• Modes: Synced (read from an outside blog feed) or Native (written in C1).
• Records: post (title, slug, body as Portable Text, excerpt, cover image, status, publish date, scheduled date), revision, category, tag, byline (person or guest, bio, avatar), SEO fields.
• Editor: TipTap with a slash menu and Markdown shortcuts, image picker from the media library, YouTube and offering embeds as blocks, draft separate from live with Publish Changes, scheduled publishing, SEO panel, categories and tags, bylines, revision history with restore. Later: revision diff, visual editing on the live page, translations.
• Import: WordPress (WXR export or REST API), including Gutenberg blocks converted to Portable Text. Tranquillity's blog is WordPress today (61 articles).
• Roles: contributor (own drafts), author (publish own), editor (all).
• Done when: Tranquillity's 61 articles are imported and render on the shared site engine.
• Reference: EmDash (Sources). Reuse its MIT code where it fits, with attribution.

Pages and Sites

• Scope: business.
• Records: c1_site (domain, kind: public | portal | both, modules shown, linked businesses shown), c1_page (site, path, template, ordered blocks, SEO fields, status), c1_block_type (key, field schema, which module provides it).
• Blocks to start: Hero, Rich Text, Offering Grid, Offering Card, Testimonials, FAQ, Join Button, Video, Itinerary, Image Gallery.
• Admin: Business › Sites (domains, which modules each shows, "Give Academy its own address") and Website, the site editor.
• Website editor (inspired by Squarespace's editor): the live page fills the workspace; panels slide over it only when needed.
  • Top bar: page picker and address, Plain or Styled, the theme picker, device (desktop, tablet, phone), Preview (full screen, as visitors see it; Esc exits), Save Draft, Publish. The page header's own Preview and Publish buttons are hidden here.
  • Icon rail on the left opens one panel at a time: Pages (Main Menu, Footer Menu, Not in a Menu, Linked Sites, System Pages; drag between groups to change the menus, drag onto a page to nest it; a gear per page for its address, SEO and visibility), Styles (themes, colours, fonts, wrapper CSS), Blocks (theme, module and custom blocks, plus the Block Store and Make a Block), Legal (below), Templates.
  • Canvas: hovering a block outlines it and shows a + above it to insert a block there. Clicking a block selects it and shows a toolbar on the block: Edit, Design, move up, move down, Duplicate, Delete. Clicking the header or footer opens their settings.
  • Right panel opens for the selection: the block's Content, Design and Code tabs plus its Style; the header or footer; page settings; a wrapper CSS rule; a legal page.
  • Open panels push the canvas aside instead of covering it, so the selected block stays visible.
  • There are no separate menu editors: the page tree is the menus.
• Themes and block styles:
  • A theme is tokens (colours, fonts, spacing, radius, buttons) plus numbered styles per block type: for example Tranquillity FAQ 1 Accordion, 2 Two Column, 3 Boxed; Retro FAQ 1 Index Cards, 2 Numbered.
  • Each block stores { theme, style }. Switching the page's theme keeps each block's style number where the new theme has one, and falls back to style 1.
  • Plain shows the content blocks with no theme, to check content on its own; Styled puts the theme and its wrapper CSS back on.
  • Mix and match: one block may use another theme's style. It is marked as a one-off on that block; the rest of the page follows its theme.
  • Records: c1_theme (name, source: imported | store | custom, version), c1_theme_token, c1_theme_block_style (theme, block type, style number, name, scoped CSS), and on each page block theme_id and style_no (null means the page's theme).
  • Theme Store and Block Store (later phase): buy or install themes and blocks, or make and save your own. A store item is a versioned package of the records above. Installing copies it into the business, so a store update never restyles a live site without a publish.
• Legal pages (the Website editor's Legal panel):
  • Terms and Conditions, Privacy Policy, Cookie Policy, Refund Policy, Accessibility Statement. Imported ones are kept; missing ones are flagged Needed.
  • Generated from a template with the business's legal name, address and contact email from Settings › Business; edited as a document, not as blocks; versioned with a "last updated" date; linked from the footer menu.
  • Site-wide: the cookie banner (asks before analytics cookies).
  • Templates are a starting point, not legal advice; the editor says so.
• How styling layers on a block (top to bottom):
  1. Content: the block's fields, edited by the brand in C1 (Content tab).
  2. Block: the component code, from the site engine (theme and module blocks) or the brand's custom repo (custom blocks). Never edited in C1.
  3. Theme: the site theme's tokens (colours, fonts, spacing, radius), from Brand and the chosen template. A block uses tokens, not fixed values.
  4. Custom CSS wrapper: optional brand styles, scoped to one class per block (for example .tq-cloud-hero), stored with the site and applied after the theme. Brands on the theme tier get a small style panel; the custom tier can add full stylesheets in its repo. The editor and preview panes are separated by a draggable divider (keyboard arrows too; double-click resets). The editor's block inspector has three tabs: Content (always editable), Design (theme tokens and the wrapper class), Code (read-only: where the component lives, its version and its field schema). With Show Blocks on, the preview labels each block with its kind and wrapper class.
• Done when: thetranquillity.co.uk (hub), academy. (Academy only) and the Retreats site render from one shared engine.

Inbox (Chatwoot)

• Scope: business.
• How it works: C1 uses Chatwoot's Platform API (self-hosted installs only) to create one Chatwoot account per business and its staff as Chatwoot users, then asks for a single sign-on link so Inbox opens already signed in. The chat widget goes on sites and the portal. A contact sync shows conversations on the member's record.
• Roles: support role on the business.
• Open: which server has Chatwoot; which features need its enterprise edition; link lifetime; whether it can be framed or must open in a tab.

Analytics and SEO

• Scope: business.
• Connections: Google sign-in once per business to choose a GA4 property and a Search Console site.
• Admin: traffic (visitors, top pages, sources, conversions), search (queries, impressions, click rate, index status, sitemap health), and C1's own funnel: visitors to sign-ups to paid members to revenue.
• Per page and offering: SEO fields, automatic sitemap, structured data from offerings (Course, Event).
• Optional: self-hosted Plausible or Umami.
• Note: Google's Indexing API is for job postings and livestream pages only. Use the sitemap and Search Console.

Sponsorships

• Scope: account. Sellable. Holds no money.
• Records: sponsor company (qualification fields from the pipeline spec), deal (stage, linked offerings in any of the account's businesses, deliverables, gift or paid partnership, discount code, items shipped), templates (eight, in the sponsorship voice).
• Stages: Source and Qualify, Outreach and Pitch, Collaborate and Structure, Logistics, On-site Kitting, Nurture and Retain.
• Money: a paid sponsorship is invoiced by one chosen business.
• Roles: partnerships scoped to the module at account level. Never sees member data.
• Source: Tranquillity Retreats/specs/sponsorship-pipeline.md (v3.1).

Audiences

• Scope: account. Lists drawn from several businesses' contacts, filtered by consent per legal entity. Sends through C1 Campaigns.

Channels

• Scope: account. Social accounts (YouTube, Instagram, Facebook, TikTok) are connected once, with one OAuth sign-in, and given to the businesses that use them. One Instagram account can serve two businesses.
• Used by: Video Library (YouTube channels feed it), Links and Attribution (clicks per channel), Analytics, and the account Overview.
• Admin: Account › Channels: each channel's followers or subscribers, views or link clicks for 28 days, which businesses use it, and its connection status (Connected, Reconnect).

Account Overview

• Scope: account. The owner arranges it: Customize adds, removes and reorders widgets; the order is saved per person.
• Widgets: Where Traffic Goes, Key Numbers, Needs Attention, Revenue by Business (read-only: each business is paid through its own Stripe account), Modules at a Glance, Channels, Coming Up, Businesses.
• Where Traffic Goes: a flow chart from source (Google Search, YouTube, Instagram, Newsletter, Direct and Referral) to first page (home, a free gift, blog posts, videos, session pages, the Retreats site), to first step (claimed a free gift, joined free, viewed an offering, left), to outcome (paid membership, session booked, retreat deposit, shop order, still deciding).
  • Filters in one row: business (all or one), 7, 28 or 90 days, Paths to a Purchase or All Visits; Flow or Table.
  • Click any bar to follow its traffic; hover for counts and shares.
  • Data: Links and Attribution (first touch), the site's analytics, and orders. Each path is counted once.
  • Sources are coloured from a validated categorical palette, with every source labelled, so colour never carries meaning alone.

Email (Automations and Templates)

• Scope: business. Core: every plan has it.
• What it is: emails that send themselves when something happens, in every module. Built on C1's existing email builder, templates and sender (Campaigns, Postmark or SES per organization). C1's existing "sequences" are sales follow-up tasks, not emails; this is new.
• Records: c1_email_automation (trigger event, filters, status), c1_email_step (wait, send template, branch on an entitlement or a field), c1_email_run (one person moving through an automation), templates shared with Campaigns.
• Triggers: any module event, for example enrolment.created (welcome to a course), payment.failed (card declined), subscription.canceled (win-back), gift.claimed (free gift nurture), enrolment.stage_changed (retreat countdown), link.clicked.
• Admin: Engage › Email: Automations, Templates, Sender. Each automation shows sent, opened, clicked and converted.
• Rules: marketing emails respect consent per legal entity; payment and booking emails are transactional and always send.
• Done when: a free gift claim starts a three-email nurture that stops when the person joins.

Links and Attribution

• Scope: business. Core.
• What it is: tracked short links for every post, video and bio, and a trail from the first click to a sale.
• Builds on: C1's existing short_link module (code to target). It needs outside targets, campaign fields and click tracking added.
• Records: short link (code, target, source such as YouTube or Instagram, campaign, content item it belongs to), c1_link_click (link, time, anonymous visitor id), and first-touch and last-touch source stored on the contact at sign-up.
• Attribution: link click, then visit, then free sign-up, then paid order. Reports by source, campaign and content: for example "this YouTube meditation brought 41 sign-ups and 9 paid members".
• Admin: Engage › Links: Links, Attribution.
• Done when: a link in a YouTube description shows clicks, sign-ups, paid members and revenue.

Forms

• Scope: business. Core.
• What it is: C1's existing form builder (Forms, Form Responses, and the step-by-step portal forms) exposed as a module any other module can use.
• Used by: offering intake and questionnaires (sessions, retreats), page blocks (a Form block), portal sign-up, free gift claims, sponsorship applications, and email automation triggers.
• Admin: Engage › Forms: list with "Used in", a form editor (fields, steps, conditions), and links to Form Responses.
• Rules: a form that collects special-category data is marked so, and only facilitator roles can read its responses.

Funnels

• Scope: business. Every plan gets some; the tier builder sets how many (funnels limit: Core 1, Studio 5, Events 15, Agency unlimited) and whether they include email sequences (funnel_emails, Studio and up).
• What it is: standalone pages for one offer, separate from the website. People reach them from a link in a post, a video or a bio. They use the site's theme without its menu, stay out of the sitemap, and can end on a date and redirect.
• How others do it: Kajabi builds a funnel from landing pages, an email sequence and an offer, separate from the website's pages. HubSpot keeps landing pages apart from website pages on the same theme: out of the sitemap, without the global menu, with their own reporting (Sources).
• A funnel is: ordered steps (opt-in, thank you, sales page, questionnaire, live class, checkout, upsell, deposit), one form, one email sequence (an Email automation that starts when the form is sent and stops on purchase), one tracked link from Links, and a goal (the offering, product or bundle it sells).
• Records: c1_funnel (business, name, status, path, ends_at, redirect, goal), c1_funnel_step (funnel, order, kind, page blocks), with form_id, automation_id and short_link_id pointing at the existing modules.
• Templates: Free Gift, Sales Page, Live Sign-Up, Waitlist, Product Launch, Retreat Booking. Each creates its pages, its form and its emails in the site's theme.
• Admin: Marketing › Funnels: a list with steps, visits, conversion and revenue; a funnel editor with steps and their conversion on the left, the step's page in the middle, and Traffic, Form and Emails, and Page Rules on the right. Step pages are edited with the Website editor's canvas.
• Why not under Website: funnel pages are not part of the site's structure (no menus, no sitemap, own reporting), and each one is tied to a form, emails and an offer. Keeping them in Marketing keeps the page tree clean.
• Done when: the Free Chakra Guide runs as a funnel: Instagram link, opt-in, gift delivered, three emails, Meditation offer, with visits and revenue per step.

Member App (portal)

• Scope: business. Core: every plan gets a member portal.
• What it is: the signed-in member experience, made of the business's enabled modules. Its tabs come from the modules; its Home sections and tiles come from admin records.
• Website sync: the public home page can double as the app's welcome screen, so a brand that moves its website to C1 keeps one design.
• Mobile apps: the same Vue and Quasar code builds iOS and Android apps through Quasar's Capacitor mode, published to the App Store and Google Play. Per business: app name, icon, splash, bundle id, store listings and build status.
• Admin: Website and App › Member App: Layout, Home Screen (the tiles members see on Home, per audience), App Stores. Home Tiles is no longer its own menu entry.
• One app across linked businesses (Decided): a business's app can include modules from businesses it is linked to, through the link's catalogue and access shares. The Tranquillity's app shows Meditation, Academy, Sessions and Shop from its own business, and Retreats and the Retreat Shop from Tranquillity Retreats. Money still goes to the business that sells. Tranquillity Retreats has no app module of its own; a standalone app for it is an add-on.
• Store listings (Decided): one listing per business that has the app module.

Website Import

• Scope: business.
• What it is: a guided move from WordPress (and later other builders) into C1.
• Steps: scan the site's sitemaps; map each type to a C1 destination; import; set 301 redirects from every old address; check SEO titles and descriptions carried over.
• Mapping: WordPress pages to Pages (as blocks), posts to Blog, WooCommerce products to Shop items, product categories to collections, service and course pages to offerings, terms pages to Legal, authors to bylines. Cart, checkout, my-account and thank-you pages are replaced by C1's own flows.
• How a page becomes blocks:
  1. Read the layout. Elementor stores each page's layout as JSON in the _elementor_data post meta; with WordPress admin access (an application password, a small export plugin, or WP-CLI) C1 reads it exactly. Without access, C1 parses the rendered HTML (elementor-widget-* classes and data-ids), which is less exact.
  2. Map widgets to blocks with a rule table: a container with a background image and a heading becomes a Hero; heading plus text becomes Rich Text; image carousels and videos of clients become Testimonials; WooCommerce product lists become Shop Grid; WPForms become C1 Forms plus a Form block; YouTube feed plugins become Video Library; icon boxes linking to services become an Offering Grid linked to the imported offerings. Anything without a rule (third-party add-ons, custom HTML) is listed as a custom block to build.
  3. Move content: text, images (into C1's media library, with alt text), links, and SEO titles and descriptions (from Yoast).
  4. Extract the theme: Elementor's global kit (--e-global-color-*, --e-global-typography-*) becomes the theme's tokens.
  5. Generate wrapper CSS: per-widget overrides that differ from the kit (fonts, sizes, colours, offsets) become scoped wrapper rules for that block, each commented with the Elementor element it came from.
  6. Compare: a side-by-side of the original page and the C1 render, with a visual difference score per section, before anything is published.
• The import is saved as a theme: the extracted tokens and the generated wrapper rules become one Theme record, "Tranquillity (imported from WordPress)", version 1. Pages hold content and block choices only; every style lives in the theme, so restyling one theme restyles every page, a new version can be drafted and previewed before it goes live, and older versions can be restored. A page can still carry a rare one-off rule ("this page only"), shown as an exception.
  • Records: c1_theme (business, name, source such as import:wordpress, version, status), c1_theme_token (colours, fonts, buttons, spacing, radius), c1_theme_block_style (block class, scoped CSS, source note such as the Elementor element id).
• Where the wrapper changes the look: the site engine renders each block as <section class="c1-block c1-<block> <brand>-<block>">. The stylesheet loads in four layers: engine base, theme tokens (CSS custom properties from Brand), then the site's wrapper CSS. A sanitiser prefixes every wrapper selector with its block class, so a rule can never leak to other blocks or to the admin. Theme-tier brands edit wrapper CSS in the Design tab; custom-tier brands keep it in their repo.
• Example, The Tranquillity (scanned 2026-11-11): 58 pages, 62 posts, 11 products in 5 product categories, 2 authors (Yoast-style sitemap index, WooCommerce). Elementor kit 6: colours #8EC9F9, #F16A3A, #1D5443, #1F392D, #0B4684, text #181717; the kit names Roboto, but pages override it with Libre Baskerville (body), Allura (script lead-ins), Cinzel (the home title, 48px, weight 900, #1D5443) and Jost. Those overrides become the wrapper CSS.
• The Tranquillity's whole site, mapped (round 7, from her live WordPress on 2026-11-11):
  • Menus kept as they are: Home, About Me, Services (5 healings), Retreat, Academy (Courses: Course 2027, Course 2025-2026; Workshop: Infinite Soul, Remote Viewing Intensive, Psychic Masterclass; 100 X Ascension; The Alchemy of Ancestral Healing), Live Online Meditation, Blog, Shop, Login. Footer: the five services, Contact Me, Privacy Policy, Terms. A link that sits in both menus shows in both groups of the Pages panel.
  • Rebuilt as blocks (16 pages): each service and course page becomes a Hero, its own sections as Rich Text, its questions as an FAQ, and an Offering Card linked to the imported offering, so price, dates and booking come from the offering.
  • Shared section: "What Customers Say About The Tranquillity?" repeats on 14 pages, so it imports once as a shared section and every page uses it.
  • Module pages: Blog becomes a Blog Index block reading the Blog module (61 posts, categories as filters); Shop becomes a Shop Grid reading the Shop module (11 products, mirrored from WooCommerce until the domain moves); Live Online Meditation uses the Live module's sign-up and room.
  • System templates: Blog Post Template and Product Page Template (layouts filled from the modules), Account and Sign-In (replaces My Account), Checkout (replaces WooCommerce Cart and Checkout), 404.
  • Legal: her eight terms pages import as legal documents, each with what it applies to. The retreat terms (Retreat, Norway, Norway user agreement, Participant Advisory) belong to Tranquillity Retreats, which sells the retreats, so they move to that business.
  • Archived with redirects: booking-success pages (replaced by C1 confirmations), thank-you pages (become funnel steps), the newsletter page (becomes a Free Gift funnel), past retreats (redirect to the Retreats site), past course years (redirect to the Academy), Energy Healing, the empty Oracle page, Cart, Checkout and My Account.
  • Not rebuilt yet: Meet Your Facilitators, The Tranquillity Principles.
• Module blocks show where their data lives: selecting a module block opens a Connected To card in the editor (for example the offering with its price and an Open button, or the Blog module with its latest posts), so a brand edits records in the module and every page updates.
• Admin: Content › Import Website, with an "Every Page and Where It Went" table.
• Done when: every old Tranquillity address either has a C1 page or redirects to one, with titles and descriptions kept.

Contacts and Campaigns (curated C1 screens)

• Scope: business (and C1 itself). Built on Blackline's Contacts, Interactions, Campaigns, Audiences and Email Builder, restyled as curated C1 screens.
• Contacts: one list of everyone the business knows (members, leads, students, alumni, sponsors' people), with saved segments, search, filters (plan, tag, source, consent, last activity), bulk actions and pagination. A contact page shows a single timeline (link clicks, gift claims, form responses, enrolments, orders, emails, Inbox conversations), first and last touch, consent per legal entity, and roles held.
• Campaigns: list with status (Draft, Scheduled, Sent) and results; an editor in four steps (Audience, Content, Schedule, Results), with the email shown in the Live Preview panel. Audiences are saved segments, shared with Email automations.
• Members is the subset of Contacts with an account or entitlement; it stays as its own screen because it is used most.

Live Preview panel

• One panel, everywhere: whenever someone edits something people will see (a page, the member app, a post, an email, a campaign, the C1 website), a live rendering panel opens on the right. The editor stays on the left.
• Toolbar: device (Desktop, Tablet, Phone), Draft or Live view, Show Blocks, Save Draft, Publish, and the time of the last save. Drafts save automatically; the live version changes only on Publish.
• Block overlay: with Show Blocks on, each block in the preview gets an outline and a label. Clicking a block in the preview selects it in the editor and opens its fields.
• Three kinds of block, shown differently:
  • Theme blocks (neutral outline): general blocks every site has (Hero, Rich Text, Testimonials, FAQ, Team, Contact Info, Map, Image Gallery).
  • Module blocks (accent outline): blocks a module provides, reading live data (Offering Grid, Video Library, Itinerary, Shop Grid, Free Gifts, Live Sign-Up, Course Cards, Pricing Options, Form).
  • Custom blocks (dashed violet outline, "Custom" label with where its code lives): brand-specific components, built in the brand's custom repo or commissioned into C1's block library. Their fields are edited like any block; their code is not.

Website transfer (The Tranquillity)

• What it shows: each page of thetranquillity.co.uk rebuilt as C1 blocks, so the brand sees its own site in C1 before switching the domain.
• Pages (from the live site, scanned 2026-11-11): Home, About Me, Psychic Mediumship Readings, Academy, Shop, Contact Us on The Tranquillity's site; Norway Retreat on the Retreats site.
• Custom blocks it needs: Aurora Hero (the northern lights animation already built for the member portal), Google Reviews (from the Google Business Profile; a candidate for C1's own block library), Story Scroll (the About page's quote reveal), Cloud Hero (the home page's layered clouds). The rest maps to theme and module blocks, including the YouTube feed (Video Library block), "Our Givings" (Free Gifts block) and the live meditation pop-up (Live Sign-Up block).

C1 as a business (tenant zero)

• C1 runs on its own platform: its customers, contacts, Inbox (Chatwoot), campaigns, email, links, forms, website, blog, plans, sales and analytics use the same modules as any business. Its customers are the accounts that pay C1.
• Two modes, one anchor: C1 sits pinned at the top of the switcher with two entries, C1 Business (the business-shaped admin for C1 itself) and Super Admin (tenants, operations and build tools). A toggle at the top of the sidebar moves between them.

Agent (MCP and CLI)

• Scope: business, with OAuth per person.
• Tools: content read and write (offerings, pages, blocks, posts, media), search, revisions, run queries within their aiAccess limits.
• Never without a person confirming: payments, refunds, payouts.
• Custom tier: the brand starter repo ships with a CLAUDE.md, agent skills, and typed block schemas generated from C1.
• Check first: Blackline's MCP and CLI work in progress, so C1 builds on it. Model the tool names on EmDash's (content_create, content_update, content_schedule, search, revision_list, media_create).

Reused Blackline modules

Contacts, Form Responses, Emails, Campaigns, Portals, Reporting, the query engine, the audit log and the media library are used as they are. C1 screens link to them through Advanced links until a curated C1 screen earns its place.

Websites (site engine)

Constraint (from Evgeny): C1's frontend is Vue 3 with Quasar and ivue (class-based reactivity, imported from src/utils/ivue2), built by the Quasar CLI as a single-page app. Astro cannot run inside it. Astro can render plain Vue 3 components through @astrojs/vue, but C1's components depend on Quasar, whose server rendering is supported only through its own CLI, and on Pinia stores, which Astro islands do not share. So an Astro site could not reuse C1's components; it would be a second frontend stack.

• The shared site engine stays in C1's stack. (Open: options below; Evgeny decides.)

  • Option A: a second, small Quasar app in this repo (site/) in SSR mode, for public pages only. Same Vue 3, Quasar and ivue as C1; shares shared/; block components written once in Vue. The admin and portal app stays a single-page app. Lowest risk.
  • Option B: turn on Quasar SSR in the existing app and list every signed-in route in ssr.clientSideRenderingRoutes (for example ['/project/**', '/super-user/**']), so only public routes render on the server. One app and one deploy. Needs @quasar/app-vite 3.1 or later (installed: 2.2.0), and every boot file, store and ivue singleton that runs on a public route must be safe on the server.
  • Option B became realistic after checking Quasar's docs. Evgeny decides between A and B; A is the safer start, B the simpler end state.
  • Ruled out: Astro (second stack, no component reuse) and Nuxt (a third framework).

• Verified in the official docs (2026-11-11):

  Capability	Status	Source
  Lazy hydration per component (hydrateOnIdle, hydrateOnVisible, hydrateOnMediaQuery, hydrateOnInteraction)	Vue 3.5+, server-rendered apps only. Installed: 3.5.14.	vuejs.org/guide/components/async.html
  Server rendering with hydration (createSSRApp)	Yes	vuejs.org/guide/scaling-up/ssr.html
  One Quasar codebase for SPA, SSR, SSG, PWA, Capacitor, Electron	Yes, as Quasar CLI modes	quasar.dev/quasar-cli-vite/quasar-config-file
  Route data loaded on the server before render (preFetch)	Yes, Quasar CLI only	quasar.dev/quasar-cli-vite/prefetch-feature
  Title, meta, link and script tags written on the server (useMeta)	Yes, SSR and SSG	quasar.dev/quasar-plugins/meta
  Some routes server-rendered, others client-only (ssr.clientSideRenderingRoutes)	Yes, @quasar/app-vite 3.1+	quasar.dev/quasar-cli-vite/developing-ssr/configuring-ssr
  Client-only parts of a server-rendered page (QNoSsr)	Yes	quasar.dev/vue-components/no-ssr
  Server-rendered site that becomes an installable PWA after load	Yes (ssr.pwa)	quasar.dev/quasar-cli-vite/developing-ssr/configuring-ssr
  SSR server on Express, Hono, Fastify or Koa	Yes	quasar.dev/quasar-cli-vite/developing-ssr/ssr-context
  iOS and Android apps published like any native app	Yes, through Capacitor	capacitorjs.com/docs/ios/deploying-to-app-store, capacitorjs.com/docs/android/deploying-to-google-play

• Server-rendering rules that apply to C1 code (Vue's SSR guide): module state is shared across requests, so stores and ivue singletons (instances that outlive a component) must be created per request; browser APIs are read only inside client-only hooks such as onMounted; mounted and updated never run on the server.

• Capacitor note: Quasar always uses hash routing in Capacitor builds, so app deep links are #/... paths unless configured otherwise.

• Public pages (landing, offering pages, posts) are server-rendered by the site engine for search engines. Signed-in pages (portal, admin) stay in C1's app. Dynamic pieces (prices, places left, Join, sign-in) hydrate on the client and call C1's API.

• One engine serves every tenant, chosen by domain. It reads content from C1's API on each request with cache hints; publishing clears the cache. No rebuild per publish.

• Astro and EmDash patterns, rebuilt in Vue 3, Quasar and ivue:

  • Islands: Vue 3.5 lazy hydration (defineAsyncComponent with hydrateOnVisible, hydrateOnIdle, hydrateOnInteraction) hydrates each interactive block only when needed. Static blocks stay plain HTML and CSS. C1 already runs Vue 3.5.
  • Content loader: an ivue Reactive() class per page reads the page, its blocks and offerings from C1's API, prefetched on the server with Quasar's preFetch.
  • Blocks: a registry maps each block type to one Vue component and one Zod field schema in shared/. The admin editor and the site renderer read the same schema.
  • Content: Portable Text bodies rendered by a small Vue renderer; drafts beside the live version; revisions; scheduled publishing; preview through a signed draft link.
  • SEO: Quasar's Meta plugin writes titles, descriptions, canonical links and structured data on the server; a sitemap route per site.
  • Caching: the edge caches each page; publishing purges its URLs. (Check whether Cloudflare purge by tag is on C1's plan; purge by URL works on every plan.)
  • Agents: MCP, CLI and agent skills are back-end features and need no framework.
  • Trade-off: pages ship the Vue runtime, so they are heavier than Astro's zero-JavaScript pages. Keep public blocks light, split code per block, and lean on edge caching.

• Tiers:

  • Theme tier: the shared engine plus templates. No code.
  • Custom tier: the brand's own repo, outside C1, reading C1's API. Any framework is allowed there, Astro included, because it runs outside C1's codebase. C1 provides a starter, typed block schemas and the MCP. May deploy to the brand's own Cloudflare.

• Mobile apps: the member portal ships to the App Store and Google Play from the same Vue and Quasar code through Quasar's Capacitor mode. (Recommended; confirm with Evgeny. Not set up yet: quasar.config.ts holds only the template defaults.)

• Domains: a brand points a DNS record at C1. Today domains are zones in C1's Cloudflare account; domains kept in a brand's own account use Cloudflare for SaaS custom hostnames. C1's nginx already routes any host and the API decides per domain (see the c1-servers skill).

• Templates: site templates per business kind (Retreat site, Academy site, Practitioner site, Membership hub) and page templates (Landing, Offering, About, Post). Enabling a module makes its templates and blocks available.

Admin experience

Scope switcher

The top of the sidebar is a switcher listing Platform (super admins only), then each account the person can reach with its businesses underneath.

Platform screens pulled from Blackline

The Platform scope reuses existing super user screens instead of rebuilding them. Each one is restyled into the C1 shell, and nothing is deleted.

Business-level reuse follows the same idea: Contacts and Interactions feed Members; Forms and Form Responses become the Forms module; Campaigns, Audiences and the Email Builder feed Email; Admin (Members, Roles, Teams) becomes Settings › Team; API Keys, Webhooks and Webhook History go to Settings › Developers; Reporting (Dashboard, Query, Reports, Schedules, Exports) feeds Analytics; Portals and Present › Onboarding (Branding, Configuration, Portal tabs) feed the Member App. Grid, Siteplan, Siting, Sales, Transactions, Inventory, Lot Rules, Pricing History and Cashflow are real-estate modules, hidden for membership businesses.

Built for 100+ businesses

C1 will hold hundreds of accounts and businesses. Every Platform and Account screen is designed for that from the start.

• Lists, not columns or sections per business. Businesses are rows, never columns or one section each. Anything per business (modules, health, storage, plans) is a row in a searchable table.
• Every list has search, filters (account, plan, module, status, health, country, created), sort, saved views, and server-side pagination through the query engine. Counts show the filtered total.
• Bulk actions on selected rows: switch a module on or off, change plan, send an announcement, export.
• Exceptions first. Health, Storage and Billing open on what needs attention (failing, degraded, over limit, past due), with "Everything else is healthy" collapsed below.
• Charts show totals or the top five businesses plus "Other", never one series per business.
• The scope switcher opens with C1 anchored at the top (C1 Business and Super Admin), then Pinned, Recent, and accounts. Clicking an account's name opens the account; its arrow shows its businesses. A search box finds any of them. It never lists every business at once.
• Global search (⌘K or Ctrl K, and a search button in the header) works in every scope. It finds screens and settings, accounts, businesses, people, members, offerings, posts, orders and help, across every business the person can reach, ranked by the current scope and labelled with the business each result belongs to. Results respect roles: a person only finds what they can open. Backed by OpenSearch, which C1 already runs.
• Every record has a stable address, so a search result, a link in an email or an audit entry opens it directly.

Curated screens, then Advanced, then Labs

• Each C1 screen shows the five to seven settings people change most.
• An Advanced link at the bottom opens the related Blackline page inside the C1 shell.
• New settings start in Labs and are promoted when proven.
• Raw tools (imports, Run Job, Provision Infra) stay in Platform only.

Settings catalog

Each C1 setting is declared once: key, label, description, scope (platform | account | business), group, level (basic | advanced | labs), type, default. Screens render from the catalog. Promoting a setting is a one-word change.

Look

The ObsidianUI pieces Nick chose: the dashboard shell (frame), the analytics dashboard (overview pages), status bars (integration health), active sessions (Security) and the discover button (Open Member Portal). Neutrals from Obsidian, the tenant's accent colour, Instrument Serif for page titles. Tabs are tinted text, not pills. Labels in Title Case. The back button names the previous screen.

Market and gaps

Researched 2026-11-11 (vendor pages unless noted).

• Closest all-in-ones:
  • Kajabi covers courses, community, funnels, email, a branded app and an MCP server; it lacks retreats, a maker shop and an agency layer.
  • HighLevel is the only true agency multi-tenant product (sub-accounts, snapshots, SaaS resale); it lacks creator depth.
  • Simplero covers courses, coaching, community and funnels at 0% fees.
  • Circle and Mighty Networks are community-first.
• C1's openings:
  • A branded app per business is included (others charge about $360 to $500 a month).
  • Retreat money flows and maker payouts sit in the same product.
  • It has both the agency layer and creator depth.
  • Its agent can work across every business an agency runs. MCP alone is no longer rare: Kajabi, Circle and Mighty already ship it.
• Must-haves not yet specced:
  • App Store payment rules per offering type: Apple requires in-app purchase for digital memberships, courses and group live classes (3.1.1). 1:1 live sessions are exempt (3.1.3(d)); retreats and physical goods pay outside (3.1.3(e)).
  • Template apps: under Apple 4.2.6, each business publishes under its own developer account, or C1 ships one app that lists businesses.
  • Tax: UK VAT (threshold £90,000) and EU VAT where the customer lives for virtual live events (since 1 January 2025).
  • Product gaps: community and discussion; one member calendar across Live, Sessions and Retreats; drip and sequential unlock for courses; instalments for any offering; offline audio and push notifications; free trials on paywalls.
• Nice-to-have: affiliates (retreat referrals), certificates, gift memberships, waitlists.
• Skip: gamification and leaderboards, TV apps.
• Patterns to borrow:
  • Circle: access groups reused across paywalls.
  • Simplero: drip, certificates and completion in one builder.
  • Uscreen: offline downloads that expire after 30 days.
  • Practice Better: an intake form sent per service at booking.
  • WeTravel: deposits and payment plans on the trip's Pricing tab, with auto-billing.
  • HighLevel: snapshots for agencies, first and latest attribution side by side.
  • Squarespace: section themes generated from a palette.

Hook points

The only Blackline files C1 may change. Keep this list current.

Add a row before touching any other Blackline file, with the reason.

Build phases

Each phase ends with focused tests, the validation-pipeline gate, and a manual-test checklist.

Open decisions

Sources

Copy an outside source into docs/ when the phase that needs it starts, so the repo stays self-contained.

Changelog

• 2026-11-11 (later): The Tranquillity's whole public site mapped into the Website editor from her live WordPress: her real menus, 16 pages rebuilt as blocks, module-backed Blog and Shop pages, system templates, eight imported legal documents (retreat terms move to Tranquillity Retreats), archived pages with redirects. Module blocks show a Connected To card. Added Market and gaps, with open decisions 16 and 17.

• 2026-11-11 (later): Website editor reworked toward Squarespace: full-width live canvas, slide-over panels that push the canvas, a toolbar on the selected block, + to insert between blocks, full-screen Preview, Plain or Styled. Themes carry numbered styles per block type, with mix and match per block, and a Theme Store and Block Store for later. Added Legal pages, Funnels (Marketing), Channels and an arranged Account Overview with Where Traffic Goes. Home Tiles moved into Member App › Home Screen. Recorded what lives at the account versus the business.

• 2026-11-11 (later): Added C1 Website and Sign-Up under Platform (tenant zero): site pages, pricing page from the tier builder, self-serve sign-up, leads and trials.

• 2026-11-11 (later): Each business has its own shop with the Norway shop's structure (Orders, Products, Makers, Storefront, Settings; product page editor); The Tranquillity's shop seeded from her WooCommerce Store API. The import is saved as a versioned Theme. Pages, Site Map and menus merged into one Website editor modelled on Squarespace's three-pane editor.

• 2026-11-11 (later): Website Import: the six steps from Elementor layout to blocks, theme extraction from the Elementor kit, generated and sanitised wrapper CSS, side-by-side comparison; resizable editor and preview panes.

• 2026-11-11 (later): Added Live with Zoom (embedded room, per-business Zoom accounts, recordings to the library), the Site Map with page tree and menus, the four styling layers and the block inspector (Content, Design, Code), account-first switcher rows and the account's business cards.

• 2026-11-11 (later): Decided Capacitor and one store listing per business; one app can include linked businesses' modules. Added Contacts and Campaigns, the Live Preview panel with theme, module and custom blocks, the Tranquillity website transfer, C1 as a business with Super Admin on top, the Norway shop seed, video sync per host, and tracked free gifts. Business menu regrouped.

• 2026-11-11 (later): Added "Built for 100+ businesses": lists over per-business columns, filters and pagination, bulk actions, exceptions first, switcher search, and global search.

• 2026-11-11 (later): ivue direction from Evgeny: v2 uses the upstream package without the hot-reload engine; v1 stays.

• 2026-11-11 (later): Mapped existing Blackline super user and project screens into the C1 Platform and Business scopes; Platform menu gains People, Imports, Email, Storage and Data.

• 2026-11-11 (later): Updated the ivue skill to upstream 2.6.0 with a C1 note; recorded the engine version gap in Stack.

• 2026-11-11 (later): Added Plans and Tiers: one tier builder for C1's own plans (tenant zero) and for each business's member tiers, with features, limits, versions and add-ons.

• 2026-11-11 (later): Added Email (Automations and Templates), Links and Attribution, Forms, Member App, Website Import, and video sources with C1 hosting and YouTube channel management. Billing plan copied into docs/c1-billing-plan.md. Business menu updated to match mockup round 3.

• 2026-11-11 (later): Verified Vue, Quasar and Capacitor capabilities in their docs. Option B (SSR in the existing app with client-only signed-in routes) is now realistic.

• 2026-11-11 (later): Added the Stack section and Rule 0 (Vue 3, Quasar and ivue). Bundles and Tiers decided.

• 2026-11-11 (later): Shop is a standalone module beside Offerings, sharing Billing; c1_order_item now in scope. Astro and EmDash patterns mapped onto Vue 3, Quasar and ivue.

• 2026-11-11 (later): Astro removed from C1's own stack after Evgeny's review (C1 is Vue 3, Quasar and ivue). The site engine stays in that stack; Astro is allowed only in custom-tier repos outside C1. Added open decisions 9 and 10.

• 2026-11-11: First version. Tenancy, roles, modules, websites, admin experience, hook points, phases, open decisions. Business menu aligned with mockup round 2.