剩余真实化缺口
这页专门回答一个问题：当前主产品里，哪些地方还在用 demo / fallback / reserve 承接。
现在方向已经很清楚：不是到处一起改，而是先把 会影响试点体验的真实写库缺口 一块块收掉。
最后一轮缺口收口顺序
这轮如果要关 fallback / demo，就按这条顺序看缺口，避免多条主线一起动。
- 1先看个人测评真实写库和报告回读，还原主测评真实主链。
- 2再看 Org-OS reserve API 与 handoff，确认组织测评不抢主产品真实写库节奏。
- 3最后再核开放平台三步联调和交付，不把 reserve 交付和真实写库混在一起。
缺口收口前先回总地图
如果现在已经开始关 fallback / demo，先回总地图和 Coach v2.3 总映射，再看这轮缺口到底属于哪条主链，会更不容易漏。
缺口矩阵
先看哪些地方还是演示承接，再决定下一轮真实联调收口顺序。
测评主链
P0半真实当前状态：已能评分、生成报告、写活动，但未登录或未接好 Supabase 时仍会回退到本地展示链路。
下一步：优先验证 assessment_sessions、mindset_profiles、user_activities 的真实写入，再补一层失败提示和重试提示。
工作台与推荐
P0有演示回退当前状态：聚合查询失败时仍会回退到 local-demo 用户、默认推荐和演示阶段状态。
下一步：真实联调时优先看 profile、activities、stats 三块是否都能回流，逐步缩小 fallback 触发面。
资产页
P0有演示数据当前状态：未登录或查询失败时，会直接用 demo 内容资产、销售资产和转换记录承接页面。
下一步：先验证 content_assets、sales_assets、sales_leads 的真实关联，再决定何时关闭演示数据入口。
文帮与销帮写库
P1半真实当前状态：保存内容、录入线索在已登录时会真实写库，但未登录时仍返回 persisted=false 的演示承接。
下一步：联调时把“未登录成功态”改成更明确的真实提示，并补一轮内容保存 → 转销售素材 → 线索判断的串联验证。
Auth 与 Supabase 环境
P0配置依赖强当前状态：环境没配齐时，页面会明确提示，但主产品仍允许以演示态继续浏览。
下一步：真实切换前先把 .env.local、Auth callback、middleware 和 health check 全部跑一遍。
开放平台 `/api/open/*`
P2reserve当前状态：合同、日志、限流、Webhook、支付入口都已可联调，但仍是 reserve 非持久化实现。
下一步：继续保 reserve，不抢主产品真实写库资源；等主产品试点稳住再接 api_keys、api_logs、webhooks 真库。
收口规则
我们后面继续推进时，就按这几条来，避免再把真实链路和 reserve 链路混在一起。
- • 先把会直接影响试点感知的链路切真实，再处理开放平台 reserve。
- • 每次只收一块 demo / fallback，不并行把多个模块一起改成真实。
- • 切真实前先跑 `/api/health/supabase`，避免把环境问题误判成业务问题。
- • 文帮、销帮、资产页要按一条完整主链验，不只看单页是否能打开。