Use clear paths into Skills, Practice, Experience, and the travel-derived branch, and use /studio/travel as the first revenue-capable booking surface.

Keep the top nav focused on the authored entry surface.

Treat Writing as a secondary reference, not a primary path.

Keep the derived branch explicit.

Use the booking bridge as the first commercial surface.

Check the current structure before changing the authored entry surface.

Keep the primary header limited to the main Studio menu.

Make the booking cards use the same button behavior as the commercial surface.

Preserve explicit planning and collaboration paths.

Keep the Studio bridge in sync with the Trips execution root.

Use /studio/travel as the first revenue-capable booking surface built from native booking cards and clear in-app exits.

Studio

Studio is the authored, editorial, and entry-layer umbrella for Molino's Skills, Practice, Experience, and the derived travel/trips branch.

This feature exists so users can:

• enter the authored Molino surface
• browse practical capabilities
• follow weekly or continuity support
• move into experience, travel, or trips when relevant

Inside Molino App, this feature exists to:

• keep the top-level editorial IA clean
• separate authored surfaces from commercial booking surfaces
• expose a controlled branch into travel-derived flows

• Home
• Skills
• Practice
• Experience

• Writing
• Journey
• Travel
• Trips

• Travel
• Trips
• Collaborations

• keep Writing as a Home card or secondary reference
• use it for articles, portfolio, campaigns, or enquiry-led specialty
• do not make it a primary nav item yet

Role:

• studio home
• philosophical / authored / portfolio-style umbrella
• branch into Skills, Practice, and Experience
• include Writing as a secondary card or reference
• optionally surface a travel or trips teaser card

Must contain:

• clear entry to Skills
• clear entry to Practice
• clear entry to Experience
• optional Writing card
• optional travel highlight card

Must avoid:

• deep booking logic
• full travel planner behavior

Role:

• practical capabilities
• modular one-off service surface

Must contain:

• clear cards for practical initiations or capabilities
• up to 3 downstream actions
• clean enquiry or service CTA structure

Must avoid:

• blending with Practice continuity logic
• travel or trip detail overload

Role:

• continuity, support, and weekly rhythm

Must contain:

• weekly support framing
• cadence options
• up to 3 downstream actions
• enquiry or support CTA

Must avoid:

• acting like a one-off skills catalog
• travel or trips overlap

Role:

• broad experiential and cultural gateway
• parent entry to the travel-derived branch

Main exits:

• Travel
• Trips
• Collaborations

Must contain:

• broad cultural, educational, or guided framing
• concise explanation of the branch
• the three exits above

Must avoid:

• detailed booking catalog
• full planner behavior
• too many product cards

Role:

• curated travel bridge
• route-family explainer
• editorial-commercial handoff into booking and trips planning
• first revenue-capable booking surface

Must contain:

• short contextual intro
• one city tour card and one featured trip card
• direct FareHarbor booking buttons for:
  • Lane 1 city tours
  • Lane 2 featured guided group trip
• non-booking CTA for:
  • Lane 3 flexible trip planning
  • Lane 4 collaborations

Must avoid:

• generic inquiry form as the default outcome for all clicks
• embedded FareHarbor grids or calendars
• duplicating full /trips planner logic

Naming note:

• Lane 1 city tours, ready-made city tours, and city highlight tours are the same commercial lane family as the Trips featured-experiences surface.
• Lane 2 featured guided group trip maps to the Trips featured guided trip lane.
• Lane 3 flexible trip planning, trip plan, trip planner, and plans are the same planning / intent family that feeds Trips.

• use app-native cards
• use FareHarbor booking button only
• open booking in Lightframe modal
• surface in /studio/travel and /trips

• use app-native premium featured-trip card
• use FareHarbor booking button only
• open booking in Lightframe modal
• surface in /studio/travel and /trips

• use in-app planner
• use quote or assisted planning
• use Molino trip-building logic
• surface in /trips

• use dedicated intake flow
• use a dedicated application or request path
• do not use retail booking
• do not use a generic contact form
• surface in /studio/experience, /studio/travel, and /trips

• Explore Travel
• Go to Trips
• Collaborations

• Book City Tour
• Join Featured Guided Trip
• Plan a Flexible Trip
• Collaborations

• Book Ready-Made Tours
• Join Featured Guided Trip
• Start Planning
• Collaborations

• lock header to Home | Skills | Practice | Experience
• remove Writing from primary nav
• keep Travel and Trips derived from Experience

• build FareHarborBookAction
• create local FH link config
• wire one working city-tour booking card
• wire one featured-trip booking card

• refactor /studio/travel around booking cards plus planner and collaboration exits
• remove generic inquiry as default outcome

• EditorialHeader exposes the primary Studio path as Home, Skills, Practice, and Experience; Writing, Journey, and Tourism links are currently commented out.
• /studio/travel renders FareHarbor booking cards through FHBookingCard and fareHarborPresets.
• FHLightframeButton loads the FareHarbor autolightframe script and builds booking hrefs from explicit href, account, item, and flow values.

• /studio/travel currently shows a featured guided group trip card plus Córdoba and Granada city tour cards.
• The travel page still includes older session/bundle sections from SESSIONS, so it is a bridge plus legacy route-family content rather than a fully reduced four-lane surface.
• FareHarbor presets still include grid/calendar presets, but the active travel page is using lightframe booking cards.

• The Studio travel page is not yet reduced to exactly one city tour card, one featured trip card, planner exit, and collaboration exit.
• Trips and Studio booking cards should be audited together so FareHarbor behavior stays consistent across both entry points.

After the commercial Offer -> Order snapshot path is locked, align /studio/travel with /trips by keeping only the intended booking cards and explicit planner/collaboration exits.

• Checked EditorialHeader at desktop, narrow desktop, iPad Mini portrait, and iPad Mini landscape dimensions.
• The logo DOM was not duplicated: probes found one .qr-img link and one /qr-w.svg image.
• The iPad-only visual fuzz came from two nearby causes: the Next.js development indicator defaulted to bottom-left, visually colliding with the bottom-docked tablet header, and the logo inherited old global .qr-img styling from styles/themes/editorial.css.

• next.config.ts moves the development indicator to top-right.
• styles/qr.css now scopes the EditorialHeader logo box and image size, opacity, and overflow under body[data-layout="editorial"].

• lib/data/skills.ts is the current first-list skills catalog for /studio/practice.
• The public order is now: personal systems, tools and execution, travel and experience, travel professional and sustainable tourism, systems and automation, then AI-assisted workflows.
• The order starts with human and practical one-to-one sessions, makes travel the main commercial field, then moves into professional tourism onboarding, systems, and AI as the final support layer.
• Travel & Experience is for regular travellers, trip planning, city walks, and cultural routes.
• Travel Professional & Sustainable Tourism is for Al-Andalus Experience onboarding, local tourism professionals, incoming operators, booking channels, guide scripts, group operations, and custom tourism/project development.
• AI has its own category at the end, framed as an assisted workflow layer that supports and accelerates the previous skills rather than replacing the human layer.
• Business and monetization support is intentionally not advertised as a standalone public category; it remains implicit inside travel professional, systems, tools, and custom project sessions when needed.
• The catalog uses a simple two-tier price shape for now: core personal/creative/document sessions at EUR 50, and higher-leverage systems, travel, AI, and technical setup sessions at EUR 60.

Keep the first-list skills narrow enough for a new visitor to scan. Add new items only when they represent a distinct session a person could book or request, not every possible tool or internal capability.

Decide whether the free Travel Planner Onboarding item should remain inside the public skills list or become a separate help/onboarding card linked from /trips/new.

A later staging mission is to replace the current hardcoded skills and sessions sources with a sheet-driven items pipeline.

Keep this as a parallel pipeline, not a getIndex() extension:

• spreadsheet input via new skills and sessions tabs in the existing registry spreadsheet
• separate sync-items.ts flow
• IndexCache reused with section = "skills" and section = "sessions"
• getSkills() and getSessions() server actions
• read-only projection components only

Do not touch the currently working Molino Docs Apps Script just to start this mission. If script support is later needed for item ingestion, prefer a separate deployment and separate env var such as MOLINO_ITEMS_API.

This is deferred by development order. Reach it after the current Google Doc sequence and nearer ship-path work are complete.

• /studio/craft/api/qr/[id] now resolves QR target origins from configured app/site URL env vars or request deployment headers before falling back to localhost.
• The shared resolver also covers /concept-cards/api/qr/[id], which had the same image-request origin gap.
• Local development still resolves to http://localhost:3000; deployed requests should encode the current public host such as the custom domain or Vercel preview host.