src/pages/planner/index.vue 与 src/domain/travel/local-planner.ts（selectQuickPois 移除空兜底）：当 quick 模式下连第一站都无法塞进时长预算时（例如用户当前定位距所有光明区 POI 很远 + 步行），现在会抛 没有可用于规划的地点（见新增测试 rejects a quick plan when even the first stop cannot fit the budget）。这是更正确的「不产出不可达路线」的行为，但生产中用户身处光明区外时会直接看到该报错。建议在 submit 的 catch 里把这类规划器错误转成更友好的中文提示（如「当前位置距离点位过远，请靠近光明区或在设置中改用自选点位规划」）。
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
我已经完整阅读了整个 diff（4136 行）、CLAUDE.md、构建/测试技能，并针对真实代码库验证了关键行为（例如
getPoiById仅返回已发布的 POI，确认了类型兼容性）。以下是我的审查结论。🔍 审查结论
本次 PR 主要新增「到点打卡」能力（domain/service/storage/页面/校验脚本），并把行程规划固定为本地 POC、移除远程 AI 调用入口，同时增强地图路线展示。整体质量较高：领域逻辑纯函数化、存储做了 schema 版本化 + v1→v2 迁移 + 严格白名单校验，隐私模型（精确坐标不落盘、定位仅用户触发）落实到位，并配有 311 行打卡测试与定位/规划测试。未发现必须修复的阻断性缺陷。 以下为可选改进与验证建议。
严重问题（必须修复）
建议改进
src/pages/planner/index.vue:57-64（locationAvailable新鲜度）：locationFreshnessCheckedAt只在onShow/submit/ 定位成功时刷新，locationAvailable = checkedAt - capturedAt <= 5min。用户在页面停留不动时，checkedAt与capturedAt都不再更新，差值恒为 ~0，导致 UI 上「可用」状态不会随时间变 stale。submit()里重新锚定Date.now()才是真正生效的闸门——功能上没有漏洞，但页面态/按钮文案可能与提交时的实际判定不一致（点了「可用」却弹「请先获取位置」）。建议要么在显示侧也基于实时Date.now()判定，要么明确注释这是「按交互时刻快照」的刻意设计。src/pages/planner/index.vue与src/domain/travel/local-planner.ts（selectQuickPois移除空兜底）：当 quick 模式下连第一站都无法塞进时长预算时（例如用户当前定位距所有光明区 POI 很远 + 步行），现在会抛没有可用于规划的地点（见新增测试rejects a quick plan when even the first stop cannot fit the budget）。这是更正确的「不产出不可达路线」的行为，但生产中用户身处光明区外时会直接看到该报错。建议在submit的 catch 里把这类规划器错误转成更友好的中文提示（如「当前位置距离点位过远，请靠近光明区或在设置中改用自选点位规划」）。src/manifest.json:65（projectname由【prod】改为【dev】）：src/manifest.json与src/pages.json是由manifest.config.ts/pages.config.ts生成的产物（README 明确要求不要手改），其余改动都能对上 config，唯独【prod】→【dev】前缀来自构建模式而非 config。确认这是有意保留（开发态标识）而非误提交某次本地dev构建产物即可；若应跟随模式生成，建议从已提交文件中还原。src/pages/check-in/records.vue:73-90（onShow中loadAvailablePois()未包裹 try/catch）：getCheckInProfile()已有异常处理并落到storageError，但loadAvailablePois()（调用getCheckInTasks()+getPoiRepository()）未保护。虽然都是确定性数据读取、现实中不会抛，但与下方风格不一致，建议同样 try/catch 或合并到同一加载流程里，避免读取异常变成未处理拒绝。server/app/schemas.py/server/app/knowledge.py：删除了duration/adults/children/child_ages/budget_level/extra_requirements字段及family_friendly加分。server/本期为预留、不接入createPlan，改动本身与客户端remote.ts现在发送的字段子集一致（前向兼容良好）。仅提醒：若Duration、BudgetLevel等类型/枚举在 server 侧已无引用，可一并清理以免后续误用；这不影响本期验收。测试与验证建议
corepack pnpm type-check、corepack pnpm lint、corepack pnpm test，重点确认新增test/check-in.test.ts、test/current-location.test.ts、test/map-store.test.ts及test/travel-assistant.test.ts中新增的规划打包用例全部通过；再用corepack pnpm build:mp-weixin+corepack pnpm verify:mp-weixin确认校验脚本对「打卡页隐私授权链、lazyCodeLoading、详情页无条件渲染打卡入口、scope.userLocation含『打卡』」的新增断言能通过。too_far）、精度不足（low_accuracy）、边界不确定（uncertain）、重复打卡（already_checked_in）五种分支文案；③ 首次打卡 +10 积分并解锁explorer，第 2/3 次依次解锁traveller/check_in_master，重启后仍在；④ 「清除本机打卡数据」只删guangming:check-in-profile，不删路线/偏好；⑤ 扫描本机存储确认不含经纬度/精度/轨迹。requirePrivacyAuthorize失败 → 显示「同意并继续打卡」按钮 → 同意后二次进入requestCheckIn能成功取定位；并验证拒绝/超时/权限被拒三类错误的提示分流是否正确。hidePlannedRoute+activePlan=null）。冷启动后再次打开地图时，因起点坐标仅存内存（getSessionPlanningOrigin），起点 marker/折线起点会缺失——确认这是预期行为（文案已写「起点坐标未保留」）。WIP: Merge zhouruizhe into 'main'to Done: Merge zhouruizhe into 'main'