description: Lógica de negocio, reglas de producto y arquitectura técnica de TheFittClub. Fuente de verdad para cualquier implementación. globs: *

Sistema de documentos del proyecto:

Identidad de marca y experiencia emocional: thefittclub-brand.md

Voz y tono de la fundadora: thefittclub-voice.md

Estrategia de lanzamiento y crecimiento: thefittclub-strategy.md

Sistema de diseño visual: thefittclub-design.md

Documentos técnicos complementarios:

Pipeline de catálogo y datos editoriales: thefittclub-private-catalog-data.md

🏆 TheFittClub V2: Master Business Logic & Requirements

This document is the Single Source of Truth for all functional requirements. Any technical implementation must satisfy these business tiers while adhering to the Edge-Native (Cloudflare/D1/RRv7) architecture.

🏗️ LAYER 1: PLATFORM GLOBAL RULES (The Ecosystem)

1. Product Matrix & Upselling

Free Combination: Users can own and mix Rituals, Modules, and Capsules. All must coexist in a unified Dashboard (“Mi Espacio”).
Dynamic Upselling: The Dashboard uses AI-detected tags (e.g., “lumbar pain”) to suggest specific Capsules or Modules (Ticket 5).
Access Control (Ticket 3): Access is strictly managed by user_purchases. Free products (Lead Magnets) bypass Stripe but are registered in D1.

2. Billing, Benefits & Guarantees (Ticket 3 & 9)

Club Discount: Active subscribers get a permanent 5% discount on one-off purchases (Modules/Capsules).
Refund Windows: 14 calendar days, every product, no exceptions. Rituals, Modules, Capsules and unredeemed gift vouchers alike. This is the Spanish statutory withdrawal right (arts. 102 ff. of RDL 1/2007), and it is what the published terms already promise a buyer — public/locales/{es,en}/legal.json § Derecho de desistimiento. Corrected 2026-08-09 (founder: “garantía 14 días, creí que ya estaba corregido”). This line used to read “Rituals (7 days), Modules (3 days), Capsules (0 days — No refunds)”, which was wrong on all three rows and contradicted the live sales page (ritual-core.json → pricing.guarantee, “14 días de desistimiento”). A published promise the internal SSOT disagrees with is the worse of two records, not a second opinion. The art. 103(m) waiver for immediately-accessible digital content is not available: the terms state it is valid only via an explicit checkbox at checkout, and that checkbox does not exist. Until it ships, 14 days applies without exception — do not shorten this line for Modules or Capsules on the theory that digital content is exempt.
Gifting (Ticket 9): Users can purchase products as gifts, generating a unique gift_vouchers code for third-party redemption.

3. Gamification & Global Stats (Ticket 8)

Global Streak: Any completion across any product adds to the “Días Activos” global counter and total minutes.
Isolation: Progress within a Ritual does NOT unlock phases in a Module. Each program track is independent in D1.
Async Processing: All gamification logic (streaks, badges) is handled via Cloudflare Queues to ensure <200ms response times.

🧩 LAYER 2: THE UNIVERSAL ADAPTIVE ENGINE (Building Blocks)

Every program is a “Playlist” of these relational blocks:

1. The Session Canvas (Ticket 2)

Canvas Order: Administrators define the sequence (e.g., PDF Intro → Audio → Routine → PDF Tips).
3-Series Routine: Routines are split into Warmup, Main, and Cool-down blocks.
Playback State: Video/Audio progress is persisted in user_playback_state for cross-device continuity.

2. Progressive Intelligence (Ticket 2 & 7)

Effort rating (founder decision 2026-08-30): after each session she rates her effort from 1 to 10 (optional since T568). The rating moves a session’s level inside the progressive modality, and a level governs series and repetitions only — it never touches phase progression, which is the engine’s (domain-rituals.md §5). The level rows are not decided; T565 owns them and the wiring. The version matrix this line used to describe was never called by application code and is not the model.

AI Overrides: If an exercise is “Banned” in user_exercise_preferences, the loader automatically injects the alternative_exercise_id.

3. Personal Journal & AI Memory (Ticket 5)

Dual Storage: D1 stores the raw text/photo and the NLP-extracted tags (e.g., “high stress”, “diastasis”).
Async NLP: Analysis is performed via context.cloudflare.waitUntil to avoid UI latency.

📜 LAYER 3: PRODUCT-SPECIFIC MECHANICS

3.1 RITUALS (Continuous Transformation)

Ej: Ritual Core, Ritual Tao, Ritual Glúteos.

The method in the founder’s voice — what each phase is, how she advances, which words are hers — is _docs/02-content/ritual-core-metodo.md (T567). Read it before writing anything a member reads; this section is the law, that document is the promise.

Modalities: where a product offers more than one product_modalities row she chooses daily. Ritual Core’s three (express · base · progresiva) are defined in § 3.1.0 below and are not built; Ritual Core Legacy has one row and asks nothing.
Phase ascent (one engine, T429 / T547 / T552): every Ritual advances by banked weeks past both floors, then the level test where the phase has one. A week banks in proportion to her own minimum and her own days floor; the required weeks, the minimum and the floors are derived per woman from her onboarding answers through the product’s engine (products.progression_engine_id → progression_engines, engine_phase_bases, engine_rules, engine_rule_effects) — live, no clamp, tuned in Admin → Motores. This document states the shape, never the values (ADR-0020). The mechanism, statement by statement, is domain-rituals.md §5; read the live configuration with the four statements there. One of them, for the phases:
```
SELECT pp.product_id, pp.sort_order, pp.prep_quarantine_days,
       (SELECT COUNT(*) FROM phase_evaluation_steps s WHERE s.phase_id = pp.id) AS evaluation_steps
FROM product_phases pp ORDER BY pp.product_id, pp.sort_order;
```
Clinical Fail-Fast (Ticket 6): if the phase evaluation fails, the member is placed in «Modo Preparación» with a mandatory compensation exercise for prep_quarantine_days.
Loop Logic (Ticket 7): when a phase’s schedule reaches its end, the sequence loops back automatically using modular arithmetic while she banks the weeks the gate asks for.

3.1.0 What Ritual Core is going to be (product law — founder, 2026-08-30 — not built)

The forward product, prod_ritual_core, is the Legacy programme with a choice of three cuts of the same session each day, in her words:

ritual Core no es más que ritual Core Legacy, dando la opción de tener tres sesiones diferentes por día a elegir
express una versión muy reducida para la que quiera hacer algo ese día y no tiene tiempo
progresiva es la versión base que va progresando en intensidad con cada vez que se vuelva a repetir esa misma sesión
purpose: dar mi método con más flexibilidad y dependiendo de lo que cada una haga avanzará a un ritmo

Three rules a writer or an implementer could otherwise get wrong, stated as rules (R-T562-4 — they change only when the founder changes them here by name, with a date):

base is the Legacy session unchanged. Ritual Core is not a second catalogue.
express and progresiva are derivations of that session, never separate content. progresiva grows in intensity — series and repetitions — each time the same session is repeated (Layer 2 §2, T565); it does not change which session she does.
Legacy completes first. una vez tengamos por Legacy perfectamente hecho, es cuando empezaré a trabajar las derivaciones para desarrollar ritual Core.

Verified against production (2026-08-30, re-read 2026-09-04): none of this exists yet. prod_ritual_core carries four modality rows (three seeded plus one created from the Back Office, T563), its phase 1 holds sixteen seeded sessions of generic catalogue exercises against Legacy’s real programme, and its three modalities hold different exercises rather than three cuts of one session. Scaffold, and this entry says so, so scaffold is not mistaken for design.

Before prod_ritual_core goes on sale (founder, 2026-08-30: es para el producto que aún no está en venta … esto debe de estar reflejado en algún lugar. Tendremos que implementarlo antes de su venta.):

#	Must exist	Ticket
1	The `progressive` modality actually scales series and repetitions from the effort rating — today the player mounts every block at its stored loops and the scaling code has no caller	T565
2	The progress-photo lock the documentation promises, expressed against the single banked-weeks counter, enforced server-side, first photo never blocked	T566

This list lives beside the product, not in a ticket that closes; add a row when a new pre-sale condition is decided, and strike a row when its ticket lands.

3.1.1 Ritual Core Legacy (T204)

A distinct product, not a tier of the new Ritual Core. Canonical id: prod_ritual_core_legacy (T65’s pm_rcl_standard reconciles to this single id).

What it is: the Legacy programme granted to the legacy cohort — one modality (pm_prod_ritual_core_legacy_standard), real content, and the same progression engine as Ritual Core (eng_ritual_core, verified in production 2026-08-30 / 09-01 / 09-04). What separates the two products is modalities and content, not progression. The forward prod_ritual_core (§ 3.1.0, not built) is the same programme with three cuts per day; legacy members do not receive it.

Who gets it (cohort law): only members who bought a “Core y Suelo Pélvico Poderosos – <edición>” edition and paid it in full (Σ of their transactions for that edition ≥ the edition’s program price). Abandoned-installment / partial payers are excluded. “Ritual Core Inicial” also grants access; the discontinued bare “Ritual Core” grants nothing.

Corrected 2026-08-09 (founder: “Ritual Core Inicial murió y ya no existe, no se nombra”). The catalogue today holds exactly two: Ritual Core Legacy (sales never reopen) and Ritual Core (waiting list).

What Ritual Core Inicial actually was, per the vault’s Capa-0 record (CONTEXTO_SESION_2026-05-17.md, slug membresia-ritual-core): the **≈ $8/ m o n t h s u b scr i pt i o n * *, a l soso l d a s * " M e mb res \overset{ı}{ˊ} a R i t u a lC ore " * . * * Cl ose d 2026 - 11 - 20 * * — a d e l ib er a t e a d mini s t r a t i v ec l os u re b y t h e f o u n d er a f t er am o n t h^{'} s n o t i ce, 51 c an ce ll a t i o n s t ha t d a y — an d i t h o l d s * * 0 a c t i v es u b scr ib ers * * a g ain s t \approx$ 5.0K lifetime revenue (14% of legacy). It is a retired product name: never in member-facing copy, a price table or a menu. The same vault entry records that confusing it with “Core y Suelo Pélvico Poderosos” (the €400-500 one-off, 86% of revenue) was one of the errors already corrected once — they are unrelated products.

It is NOT deleted from this rule, and must not be. The line reads as naming a product because it is really an entitlement rule over historical Zenler purchase strings, and ritual-core-inicial is a member of ACCESS_GRANTING_MEMBERSHIPS in app/lib/domain/legacy-membership.ts. Retired as a name, load-bearing as a record.

One stale label in that classifier, and it is cosmetic. The def still carries active: true, false since the 2026-11-20 closure. Its whole reach is presentational: admin.payments.tsx groups the membership filter into active/inactive, and admin.payments.$id.tsx appends a ”· inactive” suffix. It does not decide which rows appear, who is counted, or who gets access.

What it does NOT do — recorded because an earlier draft of this section got it wrong (2026-08-09). That draft warned that ACCESS_GRANTING_MEMBERSHIPS containing ritual-core-inicial meant an expired ≈$8/month subscription would grant Ritual Core Legacy in the T386 wave. It does not, on two independent counts. isLegacyProduct (the only function that reads that set) has no production caller — the seed’s tests are all that reach it. And the actual Legacy entitlement runs through a different, much narrower predicate: LEGACY_PRODUCT_MEMBERSHIP is "core-suelo-pelvico" and nothing else, so the cheap membership is already excluded by construction. The founder’s correction was the right one: the Back Office holds the correct cohort, extracted by the scripts. Do not re-raise this as a migration risk without first re-reading both predicates.
Eligibility SSOT: the cohort classifier + the canonical per-edition price map (PRICE_PER_EDITION) live in app/lib/domain/legacy-membership.ts; the paid-in-full math is summariseFulfilment (payment-fulfilment.ts). The same price map backs the Back-Office paid-in-full badge (T203).
Content: real legacy content (clips/sessions) is T65. T204 defines the product shell + entitlement only.

3.2 MODULES (Targeted Recovery)

Ej: Cesárea (MVP), Diástasis, Postura, Caderas Libres.

Duration: 4-8 weeks (20-40 effective days).
Flow: On-demand progress. No blocking evaluations.
Active Components: Context, Techniques, Bitácora (Metrics), and Journal (AI).

3.3 CAPSULES (Rescue Pills)

Ej: SOS Lumbar, Despertar Pélvico (Free), Reto Hipopresivos 30D.

Duration: 1-21 days.
Flow: Direct consumption. Clinical metrics (Bitácora) and Journal are DISABLED to reduce friction.
Rewards: Contribute to Global Streak and grant a completion Badge.

🛠️ ARCHITECTURAL GUARDRAILS (The Architect’s Code)

Loader-First: Data fetching belongs in RRv7 loaders. No client-side useEffect for initial data.
D1 Relational Purity: No JSON arrays for core relations. Use junction tables and normalized rows (e.g. member_conditions keyed off physical_profiles, exercise_materials, phase schedule links).
Compound Keys: Use composite primary keys where appropriate for idempotency (e.g. product_user_progress: user_id + product_id; onboarding: product_id + question_id).
Edge runtime in Workers: Request handlers and loaders must stay Edge-safe: no Node-only fs / path / Node crypto in app code bound to Workers. Tooling (catalog sync, seeds, Drizzle kit) may use Node locally; keep those scripts out of Worker bundles (see drizzle/seeds/*).
Spec-driven development: No implementation without an approved spec under _docs/03-tickets/02-active/ (then _docs/03-tickets/04-done/ when locked). _docs/03-tickets/03-qa/ is reserved for strict QA contracts when a spec explicitly requires them—not a prerequisite for every feature.

Catalog note (implementation detail)

Editorial content is relational in D1 (training_sessions and related tables). The legacy routines table for Ritual Core Phase 1 is still populated from TypeScript (app/lib/catalog/data/ritual-core/phase-1) until TD-007 is retired — this is handled automatically by npm run db:seed (Phase 2 of drizzle/seeds/run.ts). See thefittclub-private-catalog-data.md.

Architectural Decision Log:

[2026-04-04] V2 Pivot: Catalog moved from TS files to D1 Relational Schema.
[2026-04-04] Async Logic: Gamification moved to Cloudflare Queues; AI NLP moved to waitUntil.
[2026-04-24] Schema split: Drizzle definitions live under app/db/schema/ (domain modules + barrel index.ts).
[2026-04-26] Docs: Dual catalog pipeline documented — relational canvas + legacy routines TS sync (thefittclub-private-catalog-data.md).
[2026-04-26] Docs: Brand identity documentation system established — see thefittclub-brand.md and related files.

TheFittClub Vault

Explorer

Producto