Molino Index — Master Guidebook

1. Core rules Architecture

• page.tsx = read-only server orchestrator
• actions/ = sole mutation authority
• components/ = dumb UI
• api/route.ts = external integration surface only
• types/ = canonical truth
• no Prisma outside actions
• no mutation in pages
• no business logic in Apps Script
• compute in Next.js, project externally System model
• Prisma = truth
• Entities = canonical business objects
• Virtual Document Instrument = in-app projection/orchestration surface
• Folio = rendering/pagination
• AI = content and structured assistance, not persistence authority
• Projection = external-ready outputs
• Apps Script = stateless office execution layer Final model Truth → Compute → Virtual Document / UI → Intent → Actions → DB → Rebuild → Projection

2. Document terminology — locked clarification The word document must always be resolved into one of these meanings. 2.1 Virtual Document Instrument This is the in-app document system. It is:

• an internal application entity
• editable in the web app
• rendered through Folio
• used as orchestration surface
• used as projection surface
• used as commercial instrument
• used as trigger surface for exports and workflows It is not:
• a Google Doc
• a DOCX file
• an external source document
• the canonical truth for trips, offers, orders, or payments Canonical meaning in code and planning:
• Document
• Document2Data
• Folio document
• virtual document
• document instrument 2.2 Google Documents as external source These are external Google Docs used as content sources for publishing systems. They are:
• external source documents
• imported or synced into database read models
• used by the section index / docs publisher
• used by the single canonical document publisher
• a convenient content source for cloned or redeployed versions of the app They are not:
• the in-app virtual document instrument
• the source of truth for app entities
• part of Folio editing Canonical meaning in planning:
• Google Doc
• external Google document
• source Google Doc
• synced Google Doc 2.3 Google Documents as export target These are Google Docs created from app data through Apps Script. They are:
• projection targets
• generated from internal entities or virtual documents
• part of office automation
• often a step toward PDF, email, calendar, or sharing workflows They are not:
• editable app truth
• equivalent to the in-app document system
• source truth for business state Canonical meaning in planning:
• export to Google Doc
• generated Google Doc
• office document output 2.4 Publishing documents in cached read models These are DB-backed read models used for editorial publishing. They are:
• cached article records
• synchronized from sheet/index pipelines or canonical source docs
• used for public rendering and navigation They are not:
• the virtual document instrument
• operational business truth 2.5 Practical naming rule When discussing development, always name the type explicitly:
• Virtual Document Instrument = the in-app editable document system
• Source Google Doc = an external document synced into the app for publishing
• Generated Google Doc = an external document exported from the app
• Published Article Record = cached DB article used by section/canonical publishers
• Magazine Projection = derived editorial/card output, internal or external

3. Current stable base Stable enough for forward work

• document pagination stable enough for continued work
• AI document generation stable enough for product work
• trip section generation inside virtual documents working
• dynamic trip cost estimation and mapping to line items working
• PDF export working
• page-fit / width-fit behavior usable and improving
• direct wagon page editing stable enough for use Remaining document polish
• section ordering edge cases
• occasional overflow splitting awkwardness
• page-fit / layout polish
• hidden/default section behavior
• section initializer / default visibility cleanup

4. Domain stack 4.1 Core business entities

• Project
• Virtual Document Instrument
• Trip
• Experience
• Offer
• Order
• LineItem
• Sponsor / WeekSlot / Donation / Assignment
• publishing / cache entities where relevant 4.2 Locked trips domain partition Concept / content layer Entities:
• ConceptCard
• CardContent
• ConceptGroup
• SessionStack
• SessionPath
• Deliverable Role:
• knowledge
• study
• training
• onboarding
• scripts
• posters
• guidebooks
• narrative assets Rule:
• defines what is understood and how delivery is supported
• does not define pricing, schedules, capacity, or bookings Experience layer Entity:
• Experience Role:
• reusable commercial template
• canonical internal equivalent of a FareHarbor item template Rule:
• defines what is sold as a reusable unit
• not time-bound
• not attendee-bound
• source for sessions and attachable into trips Session / agenda / operations layer Entities:
• GroupSession
• GroupSessionAttendee
• CalendarEvent
• AgendaNote
• MapLocation Role:
• real scheduled, capacity-bound, operational occurrence Rule:
• GroupSession is the atomic real-world operating unit
• trip participants and independent travellers can attend the same session Trip aggregation layer Entities:
• Trip
• TripCity
• TripCityExperience or TripCityPlan
• TripDay
• Offer
• Order Role:
• bundled multi-city commercial product Rule:
• Trips compose from Experiences and/or GroupSessions
• Trips do not define session existence
• Trips are not the atomic operational unit Locked one-line definition ConceptCards define how it is understood, Experiences define what is sold, GroupSessions define when it happens, and Trips define how it is bundled.

5. Main architectural layers Domain truth layer

• Prisma entities are canonical truth
• all operational states resolve here Virtual document layer Used as:
• projection surface
• orchestration surface
• working buffer
• export trigger surface
• commercial instrument Not used as:
• canonical business truth
• payment truth
• booking truth
• order truth Folio layer Responsibilities:
• block structure
• flow normalization
• pagination
• engine + wagon render
• deterministic edit/render loop Action layer Location:
• app/(entity)/actions/ Rules:
• only actions mutate
• only actions access Prisma
• revalidate after writes Projection layer Pattern:
• computeBundle(entity, id)
• projectEntity(entity, id, targets) Targets:
• Google Doc
• pdf
• sheet/csv
• calendar
• email
• magazine Rule:
• compute in app
• project externally
• outputs are projections, never truth Apps Script layer Role:
• generic atomic external capability layer
• receives payloads
• renders / sends / logs
• returns metadata

6. Active product surfaces Virtual Document Instrument Current strongest internal surface. Use cases:

• AI content generation
• planning
• trip projection
• line item generation
• exports
• structured editorial layouts
• commercial instrument for offer/order support Assistant / AI Visible modes:
• general
• coaching Role:
• generate content
• structure planning flows
• later prefill forms and prepare action payloads Trips Now a first-class public and commercial surface. Role:
• landing page
• planner
• featured trip catalog
• trip detail
• schedule
• bridge to bookings and exports Experiences Role:
• city-level commercial templates
• trip ingredients
• future external booking item candidates
• collaborator / partner draftable products Toolbar + Sidebar Toolbar:
• execution surface Sidebar:
• composition surface
• registry-hosted tools
• AI panel host
• cross-entity control surface

7. Platform layer Positioning Molino Index is three things at once. Product layer

• Trips
• Experiences
• Sponsor system
• public landings
• booking / offer flows Tool layer
• Virtual Document Instrument
• AI-assisted workflows
• editor
• office automation triggers
• projection engine Platform layer
• deployable Next.js + Prisma + PostgreSQL + Apps Script operational framework
• reusable for custom installs and vertical packages Core offering types

1. Core Boilerplate

• Next.js + Prisma structure
• action pattern
• virtual document system
• projection engine
• Apps Script starter layer
• optional sheet/index publishing connectors

2. Vertical Package

• Trips
• Experiences
• planner
• pricing / line items
• landing builder

3. Custom Installation

• tailored setup
• integrations
• deployment
• training / onboarding Access modes
• internal
• approved
• open
• client-instance Deployment modes
• main Molino internal/showcase deployment
• trips-focused public deployment
• boilerplate demo deployment
• client-specific deployments Standardization required
• locked folder contract
• locked action pattern
• locked projection interface
• locked Apps Script payload contract
• reusable pure compute layer
• separation of reusable vs product-specific modules

8. Publishing systems These stay separate from the Folio virtual document engine. 8.1 Multi-section index + docs publisher Role:

• editorial / knowledge / multi-section article system Canonical entities:
• IndexCache
• Document as indexed cached article records Source model:
• section-specific sheet indexes
• linked external Google Docs by id
• sync pipelines populate DB cache Features:
• section landing pages
• indexed document collections
• sidebar navigation
• canonical document permalinks
• section config projection Best for:
• editorial portals
• knowledge sites
• documentation sections
• magazine-style publishing 8.2 Single canonical document publisher Role:
• one-document publishing engine Canonical entities:
• SourceDoc
• Chapter
• Comment Source model:
• one canonical external Google Doc
• synced into DB snapshots / chapter rows Features:
• one canonical source document
• chapter / paragraph projection
• comments by chapter
• DB-first render
• background sync + revalidation Best for:
• books
• essays
• serialized blogs
• commentary editions Rule Keep both publishing systems distinct from the virtual document instrument in planning and implementation.

9. Projection and export model Canonical projection pattern

• computeBundle(entity, id)
• projectEntity(entity, id, targets) Standard targets
• Google Doc
• pdf
• sheet/csv
• calendar
• email
• magazine / editorial Rule
• compute once in app
• project everywhere as needed
• no duplicate business logic in external systems

10. Google Workspace / office document intent Source intake intent External Google Docs may enter the system as source material for public publishing modules. This supports:

• section + article publishing
• editorial portals
• book/blog style deployments
• easy cloning and redeployment by linking new spreadsheets and source docs Export intent The virtual document instrument should export to Google Docs in one click whenever useful. Primary export targets:
• Google Docs
• PDF
• email
• calendar Typical sequences:
• virtual document → Google Doc
• virtual document → Google Doc → PDF
• virtual document → Google Doc → PDF + email
• virtual document → Google Doc → calendar support payload
• offer/order/trip → Google Doc package via office server Rule Google Workspace is the main office/manual/automation platform, but never the truth layer.

11. Magazine / editorial projection layer Role A distinct projection target for card-style, editorial, magazine, Pinterest-like, Flipboard-like, or social-sharing outputs. Inputs May project from:

• virtual document
• trip
• experience
• article / indexed content
• later offers or thematic bundles if useful Target page shapes
• cover
• toc
• article pages
• feature pages
• directory pages
• back cover Rules
• magazine is projection, not truth
• source entities remain canonical
• magazine templates are presentation contracts
• editorial/card-style outputs are derived from existing entities
• compute in app
• render internally or externally as needed Canonical pattern
• projectDocumentToMagazine(document)
• projectTripToMagazine(trip)
• projectExperienceToMagazine(experience)
• projectArticleToMagazine(article)
• optional unified entry: * projectEntityToMagazine(entity, id) Internal surface
• /magazine Sharing concerns Magazine sharing is social/editorial oriented, not office oriented. Typical outputs:
• internal shareable link
• WhatsApp sharing link
• email sharing link
• social sharing links
• later editorial/card channel push if desired

12. Offer → Order confirmation pipeline Role A first-class commercial flow, not an incidental export chain. Canonical denominator LineItem connects:

• trip
• experience
• offer
• order
• virtual document
• exports
• confirmations Core flow truth entity / trip / experience
→ compute line items
→ create or update offer
→ optionally project offer into virtual document
→ send / export / share offer
→ confirm / pay / approve
→ promote offer to order
→ project order outputs
→ CRM / client lifecycle update Rules
• virtual document is an instrument in the commercial flow
• offer / order truth does not live in the document
• order remains canonical transaction truth
• promotion from offer to order must always be explicit and canonical
• confirmations and exports are projections of canonical offer / order state Projection outputs around this pipeline
• offer Google Doc
• offer pdf
• confirmation email
• payment link / Stripe checkout
• order confirmation document
• calendar events after confirmation
• office exports through Apps Script
• sheet / log / report projections

13. Generic Apps Script capability layer Atomic office primitives

• create document from payload
• export pdf from document
• send email with attachments
• create calendar event
• append or log export event
• create / update sheet payload
• share file / editor permissions if needed Domain wrappers resolved in app Trips
• export trip offer doc
• export trip offer pdf
• send trip offer email
• create trip calendar invite
• export trip schedule doc
• export trip schedule pdf Experiences / partners
• export experience brief
• export experience draft doc
• send partner packet
• create approval packet Documents / offers
• export virtual document to Google Doc
• export offer sheet / doc / pdf
• send confirmation package Rule
• wrappers belong conceptually to the app layer
• Apps Script stays atomic and generic

14. Stage 1 order Product and control

15. Trips public landing + CTA routing

16. Trips planner + trip detail + schedule

17. Remaining document sidebar tools + canonical tool registry

18. AI assistant visible modes + seamless coaching sub-routing

19. Projection / export system + office server contract

20. FareHarbor external booking and marketing bridge

21. Booking + Stripe + confirmation flows

22. Offer → Order confirmation pipeline

23. CRM layer from paid transactions

24. Magazine / editorial projection layer Supporting continuity

25. publishing modules cleanup

26. CSS homogenization

27. deployment shaping by product/platform split

28. Step summaries

29. Trips public landing + CTA routing Goal:

• ship public trips-facing entry surface Deliverables:
• /trips landing builder
• canonical section registry
• CTA routing
• featured trips / cities / experiences read models
• partner route Locked CTA triad:
• Plan Your Trip
• Join Featured Trips
• For Guides & Partners

2. Trips planner + trip detail + schedule Goal:

• turn trips CTAs into working flows Deliverables:
• /trips/new
• /trips/featured
• /trips/[tripId]
• /trips/[tripId]/schedule
• estimation
• Trip + TripCities persistence
• TripDays generation
• Experiences as route ingredients

3. Sidebar tools + canonical tool registry Goal:

• formalize toolbar/sidebar as execution + composition system Deliver