用途：把产品需求转化为信息架构，将路由视为产品契约——URL 会被共享、收藏、记录日志，后期难以更改。
主要能力：识别产品区域（公开营销、认证、应用外壳、资源集合、设置、管理、支持、错误路由）；按用户心智模型而非仅数据库实体分组页面；定义稳定的小写 kebab-case 路由层级；区分路由状态与客户端状态（可共享的筛选、排序、分页、选中标签放入 URL 查询参数，未保存表单步骤等私有瞬态状态留在组件状态，绝不在 URL 中编码认证或会话状态）；识别认证与权限边界；推荐导航模式（顶部导航、侧边栏、面包屑、标签页、嵌套设置导航、命令面板或组合）；在影响当前 URL 选择时预留 v2/v3 路由；标记信息架构风险与命名歧义。
使用方式：按固定输出格式产出“站点地图与路由计划”，包含站点地图、导航模型、路由约定、认证与权限边界、需预留空间的未来路由、信息架构风险/问题。示例中给出 /pricing、/docs、/login、(dashboard) 下的 /projects、/projects/:id、/team、/settings/billing，以及 (admin)/users 等结构。
适用场景：需要为新产品或原型规划页面与路由结构、确定导航方式、划分公开与登录后区域时。
限制：不适用于单一任务流程问题（应使用 $user-flow-mapper）；需求未知时应先运行 $requirements-from-brief。最终前需验证站点地图包含相关公开/认证边界、导航建议匹配深度与任务频率、URL 约定明确。避免把所有内容压平到一个仪表盘路由、在 URL 中编码会话或认证状态、使用用户无法预测的模糊导航标签、忽略会迫使后期 URL 重设计的 v2 路由。