MolinoPro

human-layer-checklist

Master Codebase Guidebook
Markdown + HTML Dev-Docs Renderer - Frontend Client Module

Default Index
Open README.md
Root: README.mdtrips
Milestones
H1Trips Human Layer Checklist

source: Human Layer Plan-Commit-Build secuence_vlatest tab: t.696n8fs1wjuo status: active staging checklist last_updated: 2026-04-29

This checklist translates the human review sequence into local staging memory. Use it when reviewing or building the Trips tab one step at a time.

H2Current Use

This is the active next-step sequence for the Trips tab in Molino Stageup. Work through it in order, using the live staging site and the local code together:

  • obey the Codex Offside Rule: update the Plan-Commit-Build document before and after coding
  • use the public staging site for human inspection and collaborator-friendly review
  • use local code and dev-docs/_PRD/trips/README.md for implementation truth
  • move completed notes out to the Closure tab: dev-docs/trips/closure.md
  • stop at the first broken step and classify the issue before deeper coding
  • update this checklist or the Trips README only when the reviewed state changes

Active Plan-Commit-Build tab: https://docs.google.com/document/d/159LXfQ9VZc1gAP_e9juzTlo4RDqwIi300iz4qe40NbI/edit?tab=t.kyxlzfqd5t59

H2Codex Offside Rule

Codex is offside if it starts or continues coding without updating the active planning document before and after the build step.

Before coding, record:

  • intended goal
  • route or feature area
  • expected done condition
  • current status before coding

After coding, record:

  • achieved goal or partial result
  • checked route or behavior
  • remaining open issue
  • next action

If a newly completed note is added before your wording pass, mark it pending revision and still use Done only when the implementation or checked behavior is genuinely complete.

Use Done only after the step has been checked on the staging surface or verified locally. Use Partial when the path exists but still needs visual, data, auth, or real-content verification. Use Open when the step has not been checked. Use Blocked when the fast stop rule catches a break.

H21. Public Trips Front Door
  • Open /trips.
  • Confirm the page renders cleanly.
  • Check the top area for the commercial lanes.
  • Done when the page feels like a real commercial front door.
H22. Lane Visibility And Order
  • Verify ready-made city tours are visible.
  • Verify the featured guided trip is visible.
  • Verify flexible trip planning is visible.
  • Verify collaborations or provider entry is visible.
  • Done when the lanes are easy to scan in under 10 seconds.
H23. CTA Routing
  • Click one CTA from each lane.
  • Confirm each route lands somewhere real.
  • Done when no CTA dead-ends on the same page.
H24. Public Trip Detail
  • Open one trip detail page.
  • Confirm the hero, route, cities, and join or offer-preview action are readable.
  • Done when the page reads as a real trip page, not a data dump.
H25. Schedule View
  • Open one schedule page.
  • Confirm the dated or grouped schedule is readable.
  • Done when the schedule can be understood without opening the planner.
H26. Planner Separation
  • Open the planner surface.
  • Confirm draft creation or inline editing is private.
  • Done when public browsing and private planning stay separate.
H27. Offer Bridge
  • Look for pricing or offer preview.
  • Confirm line item or commercial bridge logic is present.
  • Done when the trip can move from plan to offer without confusion.
H28. Booking And FareHarbor
  • Click one booking button.
  • Confirm it behaves as button/modal execution only.
  • Done when booking stays separate from trip truth.
H29. Footer Bridge Back To Studio
  • Scroll to the bottom.
  • Confirm there is a visible bridge back to /studio.
  • Done when the return path is obvious and low-friction.
H2Fast Stop Rule

If a step breaks, record:

  • route
  • expected behavior
  • actual behavior
  • whether the issue is content, routing, or data
H2Use In Staging

This checklist should guide work before deeper implementation. It is intentionally practical: open the page, inspect what a non-dev reader sees, click the visible path, and only then decide whether the issue is copy, routing, data, or product structure.

H2Session Note
H32026-04-28 - Confirmed as active Trips review sequence

Confirmed this checklist as the current staged sequence for the Trips tab. It should be followed step by step before deeper implementation, with dev-docs/_PRD/trips/README.md used as the stricter implementation reference and the live staging site used as the public review surface.

H32026-04-28 - Codex Offside Rule added

Added the Plan-Commit-Build offside rule: before and after coding, update the active planning document with the goal, status, checked result, and next action. Progress can only be marked done after the staging surface or local behavior has been verified.

H32026-04-28 - Pending revision marker added

Added a small review marker to the offside rule: when a newly completed item is documented before you have reviewed the wording, it can be marked done only if the underlying work is genuinely complete, and it should carry a pending revision note until you revise it.

H32026-04-29 - Landing rebuild and edit-permission pass opened

Active goal for today: blend the older Al-Andalus landing-page cadence back into the current /trips surface without breaking the section editor, repository-backed rendering, or the working trip-planner assistant form auto-completer.

Current inspection result:

  • old reference checked: https://latest-aelib.vercel.app/
  • local /trips checked: renders builder-backed hero, pathways, how-it-works, featured trips, cities, experiences, planner CTA, and final CTA
  • local /trips/1 checked: renders trip detail and pricing preview
  • local /trips/1/edit checked: edit form loads with assistant panel and autosave surface
  • completed 2026-04-28 notes moved to the Closure tab: dev-docs/trips/closure.md

Next open checks:

  • visually adapt the current /trips section order toward the older landing cadence while preserving builder edit mode
  • continue the same criteria on /trips/[tripId]
  • verify FareHarbor modal-click behavior when ready for human-facing review
H32026-04-29 - Booking bridge and public trip detail pass verified locally

Local verification on http://localhost:3002 after the current code pass:

  • /trips now shows a dedicated direct-booking band in the featured experiences section.
  • clicking Book Córdoba tour kept the URL on /trips and exposed the FareHarbor lightframe path instead of redirecting away.
  • /trips now shows a visible Back To Studio bridge in the final section even when saved builder content does not include that CTA.
  • /trips/1 now renders publicly again; the page no longer depends on edit bootstrap access just to show read-only trip detail.
  • /trips/1 now shows pricing preview, schedule, join panel, and an offer bridge with project-offer routes.

Still open:

  • saved builder content on /trips still carries older copy and route targets such as /trips/new and /trips/professionals
  • the final visual cadence is still not yet aligned section-by-section with the legacy landing reference
H32026-04-29 - Trip detail loop and access guard pass verified locally

Goal: fix the /trips/[tripId] maximum-update-depth error and prevent private trip detail/edit access for users who do not own the trip project.

Status: Done, pending human wording revision.

Implemented locally:

  • stabilized assistant route-awareness and trip planner provider callbacks to prevent edit-surface effect loops
  • made /trips/[tripId] return notFound() unless the trip is public via shareForOthers, project-owned by the current user, or admin-visible
  • removed the route-level fallback edit bootstrap so the public detail page cannot manufacture planner edit state
  • disabled the trip edit dock edit action unless the route has confirmed edit permission

Checked:

  • targeted ESLint passed for the touched files
  • http://localhost:3000/trips/1 returned 200 OK
  • headless browser hydration on http://localhost:3000/trips/1 completed without maximum-update-depth or page runtime errors
  • unauthenticated http://localhost:3000/trips/1/edit returned 404 Not Found
  • full tsc --noEmit remains blocked by unrelated milestone/md/experience Prisma type drift

Next action: verify a non-owned private trip fixture when one is available in the local dataset.

H32026-04-29 - Trip editor persistence boundary restored

Goal: keep trip edit persistence on the server-action pipeline while making save/refresh behavior explicit enough to debug.

Status: Partial, pending browser edit-session verification.

Implemented locally:

  • trip planner edit fields now stage draft state client-side and save through updateTripFromPlanner
  • blur, select commits, step changes, bottom navigation, explicit Save, and final Done all use the server action path in edit mode
  • successful server-action saves refresh the route
  • failed server-action saves show an inline error instead of failing silently
  • latest draft state is tracked with a ref so blur/save does not send a stale render snapshot

Data-model note:

  • current Trip persistence covers title, date, participants, public/featured flags, hotel standard, and route city rows
  • hotelMode, double rooms, and single rooms are planner/quote fields today and do not have canonical Trip columns yet

Next action: verify an authenticated edit session in browser and decide whether hotel handling/room counts should be added to Trip, saved into a structured pricing/planner snapshot, or removed from canonical trip edit.

H32026-05-02 - Trip→Offer→Order Flow Completed

Goal: Complete commercial flow from Trip to Offer to Order with manual payment.

Status: Done, pending browser verification.

Implemented:

  • createOfferFromTrip() in trip-offer.actions.ts — creates offer from trip with line items
  • checkoutOffer() in app/orders/actions/checkoutOffer.ts — converts Offer → Order (manual payment)
  • Fixed bug: checkout now uses trip.offerId instead of trip.projectId
  • Server component fetches associatedOffer and passes offerId to client
  • Etsy PDF generation: generate-etsy-pdf.ts + /api/trips/[tripId]/export/etsy-pdf?type=itinerary|planner|pricing
  • Etsy PDF buttons added to TripDetailClient (itinerary, planner, pricing templates)
  • Build passes ✅

Checked:

  • npm run build — passes successfully
  • Code flow: Trip → Create Offer → Checkout Offer → Order (manual payment)
  • PDF endpoints return 200

Next action: Browser test full flow; generate 3 Etsy PDFs (Granada 3-Day, Andalusia Route Planner, Travel Pricing Template); create Etsy seller account; list first product. Target: First €20 sale within 7-14 days.

H32026-04-29 - Trip command surface implemented

Goal: convert /trips/[tripId] into a database-backed command surface where title, trip settings, and per-city edits persist through server actions and refresh the server-rendered page.

Status: Partial, pending DB migration deploy and authenticated browser verification.

Implemented locally:

  • added canonical schema fields for legacy trip core values:
    • Trip.targetParticipants
    • Trip.hotelMode
    • Trip.numDoubleRooms
    • Trip.numSingleRooms
    • Trip.mainImage
    • TripCity.choiceMeals
    • TripCity.packageType
  • generated Prisma Client and Zod schemas from the updated schema
  • added command server actions for trip basics, single-city update, city creation, city deletion, and trip projection sync
  • updated the trip detail route to use a Suspense-backed server content boundary
  • made the hero H1 editable in place when edit mode and write access are active
  • added trip settings and city edit command modals
  • kept shareForOthers and featured separate

Checked:

  • targeted ESLint passed for the touched trip command/page/action files
  • filtered TypeScript output showed no app/trips errors
  • full typecheck remains blocked by unrelated milestone/md/experience drift
  • prisma migrate deploy was not applied because it targets the configured remote Prisma Accelerate/Postgres database and requires explicit approval

Next action: apply the staged migration to the intended database, then verify owner edit flows in browser.