小程序 MVP 路线 v2（酒店抓手 → MVP 运行 → 模式复制扩容）

决策：用户 2026-09-17 16:56 拍板——「先以酒店为抓手或者突破口，让小程序可以 MVP 运行，然后再考虑模式复制扩容」。

定位：这是上线工作的指导框架；取代「全量 93 页待补」的心理模型——MVP 范围内做到全绿，范围外坦然延期。

一、MVP 定义（一句话验收）

「一个转山客从看到内容 → 订到温泉酒店 → 到店核销 → 留下评价」全链路零摩擦。

即：酒店是抓手，闭环是目标——不做全站，做一条路。

二、金路径九勾（MVP 验收标准）

#	勾	对应页面/能力	现状
1	首页能进（品牌+入口清晰）	home	✅ A 档已接
2	酒店能看能订	category-hotel → product-detail → hotel-booking	展示/详情 ✅；预订页待补
3	支付能走通	payment-confirm → pay-result	payment ✅；pay-result 待验
4	订单能查	orders / order-detail / status-timeline	order-detail ✅；orders/status-timeline 待补
5	核销能跑	redemption-code / verify	WIP-368 修复中
6	内容能读（衣领/密钥/温泉）	guide-home / guide-detail / culture / local-scene	部分 ✅；detail 页待验/补
7	工具能用（至少：转山清单+安全）	prepare-checklist / safety-check / oxygen-map	待逐页验证工具自洽性
8	福钥能看	fuyue-task-detail / passport / redeem-log	✅ B 档已接
9	客服/联系可达	feedback / settings / emergency-contacts	emergency ✅；feedback 待验

九勾全绿 = MVP 就绪 → 进真机回归。

三、范围（≈32 页·保留清单）

入口：home / selection / local / profile
酒店闭环：category-hotel / category-rental / product-detail / hotel-booking（补）/ package-booking / payment-confirm / pay-result / orders（补）/ order-detail / status-timeline（补）/ order-cancel-reason（补）/ order-refund-preview（补）
内容承接：guide-home / guide-detail / culture / guide-article / local-scene / wish-wall（WIP-375 已在接）
工具：pilgrimage / prepare-checklist / safety-check / oxygen-map / tibetan-calendar / kora-timer
福钥：fuyue-task-detail / passport / certificates / redeem-log / membership
核销：redemption-code / verify（368）
支撑：login / settings / agreement / feedback / emergency-contacts / sos

延期（二期）：demand-* / scene-* / kora-track / commission-ledger / trip-detail / private-route / route-detail / coupons 等——代码保留，后续版本放出。

四、三阶段执行

阶段一（当前）：补齐 MVP 待补页（hotel-booking / orders / status-timeline / order-cancel-reason / order-refund-preview ≈5 页·按台账模式=页面级直连）+ 核销链 368 修复（小冈跑）+ 工具页逐页验证；
阶段二：真机回归（金路径九勾·对象=v2·协调包按台账重写）；
阶段三：提审（MVP 版·app.json 摘除延期页）→ 上线；
之后：模式复制扩容（YOS 第二实例）。

五、复制扩容衔接（纪律·现在就注意）

MVP 的补线实现保持干净（沿用现有模式：页面级直连 + services 封装）——为第二实例复制留好迁移路径（不做一次性胶水）；
白标/多租户体系（tenant/brand 配置）不动——复制时直接复用（335 已证跨实例隔离成立）；
MVP 跑通后的复制评估项：租户配置复制（yaml→实例）→ 内容复制（内容库）→ 此三项已有基础（第一幕 80% 复制能力）。

-- 冈子 2026-09-17（MVP 路线·用户拍板后落档）

六、GPT-6 评审与 v2 修订（2026-09-17 傍晚）

评审核心判断：路线成立，但应定位为「平台的首个履约样板」，不是「缩小版平台」——「当前瓶颈是业务闭环而非页面数量」「『九勾全绿』不足以证明可上线」。

修订一 · 定位口径：首页表达改为「阿里旅行服务，先从转山前后温泉住宿做起」；主行动聚焦订房；暂未交付的服务不放可点击入口（避免「平台承诺、单店兑现」落差）；多商家供给能力不宣称。

修订二 · 验收从「页面」改「业务」（金路径 v2）：

顺向 6 环：找到房型 → 确认日期/价格/可售 → 下单支付 → 酒店确认 → 到店核销 → 售后可达；
必测异常 5 项：支付成功但订单未更新 / 重复回调 / 无房或拒单 / 取消退款 / 重复核销；
明确订单与款项核对负责人；
内容/工具/福钥从「上线门槛」调整为「加分项」（不证明其为住宿成交/履约前置）——但若承载已售权益则不可砍（现无此情况）。

修订三 · 范围口径修正：v1 计数混乱（曾写「≈32/38」均不准）——以程序精算唯一清单为准：41 页（分项：入口 4/酒店闭环 12/内容承接 6/工具 6/福钥 5/核销 2/支撑 6，无重复）：agreement、category-hotel、category-rental、certificates、culture、emergency-contacts、feedback、fuyue-task-detail、guide-article、guide-detail、guide-home、home、hotel-booking、kora-timer、local、local-scene、login、membership、order-cancel-reason、order-detail、order-refund-preview、orders、oxygen-map、package-booking、passport、pay-result、payment-confirm、pilgrimage、prepare-checklist、product-detail、profile、redeem-log、redemption-code、safety-check、selection、settings、sos、status-timeline、tibetan-calendar、verify、wish-wall。合并建议：酒店介绍/温泉说明/交通入住须知合并；转山清单与安全提示做轻量内容。延后：福钥 5 页与非交易必需内容、工具（按修订二口径）。

修订四 · 执行顺序：先查阻断项 → 再贯通纵切 → 最后扩展回归：

先核查：支付链路、隐私与提审要求、可售规则、退款责任、前台核销设备及人员（准备情况待核——没定的先定，否则先补页可能返工）；
用一个房型跑通完整链路（仅补链路必需页）；
真机验证正常+异常双路径；
提审。

修订五 · 复制衔接：先定义「第二实例」=第二酒店/第二目的地/另一小程序（待明确）；本轮只做低成本隔离：酒店标识、房型价格、内容、核销人员与订单归属配置化（勿写死）；记录接店/培训/售后流程——由第二实例验证共性，暂不建完整多商户平台。

只提醒一件事（GPT-6）：「老板验收的应是『一笔订单有人负责到底』，不是『九个入口都能点』。」

-- 冈子 2026-09-17（v2·含评审采纳；计数勘误已如实登记）