Ship the smallest step that reduces ambiguity in the commercial pipeline. Preserve ambition in module specs, but close one pipeline risk at a time.

• Keep the active PRD tree to a maximum of four folder levels wherever practical.
• Preserve the folder structure that already exists manually; do not reorganize folders just to make the tree look cleaner.
• Use archive/ folders for duplicate, impractical, overridden, obsolete, or older versions.
• Keep active module folders geared toward executable specs, current decisions, feature goals, examples, acceptance criteria, and next actions.
• Let detail float upward in two steps: detailed notes in the specific file, critical module summary in that folder README, then only the current cross-module decision or next action in this root.
• Keep the format fast and operational: the PRD is both project documentation and an execution planner for focus, commitment, and closure.
• Treat _internal/, archive material, milestones, and MLV references as lower-priority support material unless an active module README links to them for a current reason.
• When a session touches code, update the closest relevant PRD README or spec first; update this root only when the fact affects overall direction or the next critical step.

Use this order for active README files:

1. Focus Strip.
2. Current closure target.
3. Built / locked facts.
4. Built / partial facts.
5. Docs-ahead pending goals.
6. Critical next step.
7. Full spec and references.

• Active top-level product folders are within the intended depth: trips, document, studio, platform, products, experiences, framework, and tools.
• Existing folders deeper than four levels are concentrated in _internal/dev-archive, _internal/html, old HTML demos, and nested archive references.
• Those deeper folders should remain low-priority reference/archive material for now. Do not add new active specs at that depth.

1. Trip execution: /trips is the commercial hub and execution root. It renders builder-backed trip sections through the trips registry, reads public trip projections, and keeps experiences as supporting inventory. Start here: Trips
2. Commercial economics: LineItem, Offer, and Order are the downstream economic boundary. Trip pricing may feed line items, but UI and documents must not recompute economic truth independently. Start here: Commercial transactions, Offers, and Orders
3. Document projection: documents are composition and projection instruments, not canonical truth for trips, offers, orders, or payment state. Start here: Document and Document tools

1. Studio entry layer: /studio is the authored entry surface. /studio/travel is the first revenue-capable bridge and must stay aligned with /trips booking behavior. Start here: Studio
2. Assistant orchestration: AI supports prompts, structured modes, personas, contexts, idea records, and generated artifacts. It must remain assistive, traceable, and non-authoritative. Start here: Assistant
3. Sponsor support: weekly support, booking, donations, proposals, approvals, and updates stay explicit and action-driven. Start here: Sponsor and Weekly support sponsor
4. Platform rules: auth, users, integrations, API boundaries, and editorial conventions are shared rules rather than domain truth. Start here: Platform
5. Products and experiences: products support catalog/pricing behavior, while experiences are reusable city-linked inventory consumed by Trips. Start here: Products and Experiences

• MD execution router - /md execution surface and module prioritization.
• Framework - architecture, assistant system, seed, and production pattern notes.
• Milestones - support-only execution guidance; keep lower priority than active module roots.
• MLV Versions - low-priority entity-level reference material.
• Legacy dev archive - older notes that should not compete with active product roots.

• /trips/page.tsx is read-only and renders TripsSectionRenderer twice with explicit visible section keys.
• /trips section content comes from the project slug andalusian-trips-lab through app/trips/actions/tripsLanding.actions.ts.
• getTripsPublicData() is the current public projection helper for featuredTrips, publicTrips, featuredCities, and featuredExperiences.
• Featured and public trips now read from Prisma-backed Trip records through app/trips/actions/trips.list.read.actions.ts, then attach pricing through tripEngine.
• Featured experiences read active Prisma Experience records with optional City relation and resolve FareHarbor links from externalId.
• Idea generation currently stores an Idea prompt row, calls OpenAI, then stores the generated response. This is traceable assistant output, not domain truth.
• Structured assistant modes use runStructured() from app/assistant/lib/openai.ts; trip-planner assistant output explicitly forbids bookings, offers, orders, and documents.
• /md/[[...path]] now reads _PRD as the active markdown root and can overlay milestones in the browser shell.
• app/(milestones)/milestones is now a dedicated project-aware control surface for Markdown-ingested milestone rows.

• The whiteboard focus moved toward _PRD as the active docs root, a dedicated milestones control surface, and continued Trips/Studio/Experiences alignment around booking and projection boundaries.
• Keep the current commercial priority order intact while the new markdown and milestones surfaces settle.

• Recap pass: the repo is still centered on Trips, Commercial, and Experiences, with _PRD as the active docs root and a broad in-flight branch covering markdown shell work, route updates, FareHarbor bridge tweaks, and commercial schema regeneration.
• The immediate whiteboard priority stays the same: preserve the Trip -> LineItem -> Offer -> Order boundary and keep docs close to the module touched.

• Whiteboard recap refreshed from the current docs and git state.
• The newest visible work is still broad and parallel: markdown routing, milestone surfaces, Trips, Studio/FareHarbor, Experiences, and Prisma/Zod regeneration.
• No product priority changed; the next closure remains one canonical Offer -> Order snapshot action, then document projection alignment.

• This recap pass confirmed the active center of gravity is still the same: Trips/commercial boundary first, with _PRD now serving as the live docs root and /md gaining an inline milestone panel.
• The working tree shows broad in-flight edits across app/md, app/trips, app/studio, app/experiences, QR generation, and deploy env handling, plus the large dev-docs to _PRD documentation migration.
• No priority shift: keep the next closure focused on the canonical Trip -> LineItem -> Offer -> Order path, then align document projection with that snapshot flow.

• Recap update: the repo is still centered on Trips as the commercial root, Studio as the authored entry layer, Document as projection only, and Experiences as supporting inventory.
• The active working tree is dominated by the _PRD migration plus in-flight edits to app/md, app/trips, app/studio, app/experiences, FareHarbor/QR handling, and Prisma/Zod regeneration around the milestone/commercial schema work.
• No product priority changed: keep the next closure on the canonical Trip -> LineItem -> Offer -> Order path, then align document projection to that locked commercial snapshot.

• Whiteboard pass: no new commits since 2026-04-24, but the working tree is still very active and broad.
• The current live focus remains the same: Trips/commercial pipeline first, with Studio booking bridges, Document projection boundaries, Experiences, markdown/milestones surfaces, and Prisma/Zod regeneration all in flight.
• The repo now also shows a large _PRD-first documentation footprint, so future sessions should keep updating the closest module README plus this root only when cross-module priority changes.

• built/locked: existing code is implemented enough that future work must preserve it unless deliberately replacing it.
• built/partial: existing code works as a slice, but the contract is not complete enough to treat as final.
• docs-ahead: the PRD describes a goal that is not fully implemented yet.
• code-ahead: code already does more than the older documentation said.
• critical-next: the next best step by current priority rules.

Commercial pipeline integrity comes first:

1. Trips execution and public read projection.
2. Trip pricing and trip join snapshots.
3. LineItem commit and clone behavior.
4. Offer snapshot and editor behavior.
5. Order creation and locked transaction behavior.
6. Document projection of commercial data.
7. Studio booking bridge and FareHarbor buttons.
8. Assistant, sponsor, integrations, and other support layers.

When two possible next steps compete, choose the one that reduces risk or ambiguity in Trip -> LineItem -> Offer -> Order first.

• built/locked: Trips has a builder-backed landing page, Prisma-backed public trip reads, active experience projection, and trip-engine pricing attachment for cards.
• built/partial: Trip planner create/update actions persist Trips and TripCities with owner checks and route revalidation.
• built/partial: TripJoin creation stores a pricing snapshot and totals; recompute can refresh existing join snapshots.
• built/partial: LineItems have server actions for create, update, clone, delete, and bulk update, plus a client-safe pure computeLineItem() normalizer.
• built/partial: Offers can create/update/delete and can read normalized offer line items with totals.
• docs-ahead: the canonical Offer -> Order path is not fully locked; confirmOffer() is marked legacy and mutates line items, while documentToOrder() copies line items but recomputes totals/tax during copy.
• docs-ahead: app/documents/actions/commitDocumentToOffer.ts currently contains pagination commit logic, not a document-to-offer commercial commit.
• critical-next: lock one canonical commercial conversion path that clones Offer line items into Order snapshots without recomputing totals, then update Documents to project that canonical path.

1. Lock the canonical Offer -> Order snapshot flow and deprecate or replace legacy conversion paths.
2. Make document commercial projection consume canonical offer/order reads instead of recomputing totals in UI components.
3. Confirm /trips renders from the builder-backed section registry without hardcoding business content into the page.
4. Audit the Trips public read projection against actual Prisma seed/data and remove obsolete temporary-read notes where they still exist.
5. Align /studio/travel cards with the same FareHarbor button/modal behavior used by Trips.
6. Keep assistant routes and actions from silently mutating canonical domain records.
7. Keep PRD updates close to the module touched, then float only current critical facts to this root.

Use the existing deployment scripts when redeploying. Do not store literal production API keys in PRD files; keep environment values in the deployment platform or local secret management.