日期：2026-09-25
起草：gpt-6-astra（effort=medium，耗时 150.9s，输出 3214 token，finish_reason=stop）
核注：波波 —— 采纳大部分，但对 3 处做了调整并说明理由（见每节"波波核注"）
状态：设计已定，待实施（第一期：导航重组）
docs/tools/astra_call.py（唯一正确入口，scripts/astra_call.py 已 DEPRECATED）/srv/kailash/scripts/gpt6.sh；本机可直接调 astra_call.py~/.workbuddy/.zhiapi_key（本机存在，48 字节）--effort medium --max-tokens 3500 --timeout 1800（high/xhigh 会被网关约 120s 切断；max_tokens 非硬截断，控体积靠指令限定）
--prompt 或 --prompt-file，只给 --material 会报"需要 --prompt"结论：采用"工作动线为主、业务对象为辅、权限状态做视觉叠加"的六组架构。
不再使用建设计划编号（A8/A3/R6/B…），也不按角色分组。
理由：运营人员的实际任务稳定，且同一角色需要跨模块完成工作；
按角色会造成入口重复，按编号无法表达业务含义。
| 顺序 | 顶层组 | 主要内容 | 依据与运营动线 |
|---|---|---|---|
| 1 | 经营总览 | 仪表盘、站点数据、分析 | 对应"看数"，进入后台先判断平台状态 |
| 2 | 运营待办 | 入驻审核、消息、线索与转化 | 对应"处理待办"，按任务闭环组织 |
| 3 | 商户与商品配置 | 商家、商户页、商品 | L1 代商户配置，可写但不触碰经营数据 |
| 4 | 内容与品牌 | 内容、攻略、故事、场景、文案、品牌 | 对应"配置内容"，按内容资产与发布对象组织 |
| 5 | 经营数据（只读） | 订单、核销、结算、分销 | L2 禁写，单独分组并统一标记"只读" |
| 6 | 平台治理 | 权限、审计、平台参数、运营管控 | 对应"查问题"及平台级治理 |
权限呈现原则：分组表达业务边界，菜单标签表达读写边界；
L0/L1 使用"配置/管理"，L2 统一使用"数据（只读）"，灰色锁定图标 + 只读标签，
详情页同样禁用写操作。
波波核注：这一条直接落实了义父 2026-09-25 定的权限边界
（可帮商户做基础配置，不得碰经营数据）。L2 独立成组是关键——
光靠后端禁写不够，运营在界面上就该一眼看出"这里不能改"。采纳。
| 现有页面 | 归属分组 | 显示 | 统一显示名 |
|---|---|---|---|
| dashboard | 经营总览 | 是 | 经营总览 |
| analytics（未挂） | 经营总览 | 是 | 数据分析 |
| site-data（未挂） | 经营总览 | 是 | 站点数据 |
| applications | 运营待办 | 是 | 入驻审核 |
| messages | 运营待办 | 是 | 消息中心 |
| crm-leads | 运营待办 | 是 | 线索台账 |
| crm-funnel | 运营待办 | 是 | 转化分析 |
| merchants | 商户与商品配置 | 是 | 商户管理 |
| merchant-pages | 商户与商品配置 | 是 | 商户页配置 |
| products | 商户与商品配置 | 是 | 商品与套餐 |
| orders | 经营数据（只读） | 是 | 订单数据 · 只读 |
| redeem-ledger | 经营数据（只读） | 是 | 核销数据 · 只读 |
| settlement | 经营数据（只读） | 是 | 结算数据 · 只读 |
| distribution | 经营数据（只读） | 是 | 分销数据 · 只读 |
| content | 内容与品牌 | 是 | 内容资产 |
| content-items（未挂） | 内容与品牌 | 合并 | 并入"内容资产" |
| stories | 内容与品牌 | 是 | 故事 |
| scenes | 内容与品牌 | 是 | 场景 |
| guide-admin | 内容与品牌 | 是 | 攻略 |
| text-dictionary | 内容与品牌 | 是 | 文案与术语 |
| bo-dictionary | 内容与品牌 | 是 | B端 术语词典 |
| destinations（未挂） | 内容与品牌 | 是 | 目的地与 POI |
| weather-road（未挂） | 内容与品牌 | 是 | 天气与路况 |
| brand-config | 内容与品牌 | 是 | 品牌与多语言 |
| config-versions | 内容与品牌 | 是 | 品牌配置版本 |
| ai-config（未挂） | 是 | AI 配置 | |
| cms | 内容与品牌 | 隐藏 | 遗留 CMS（保留路由） |
| key-config | 平台治理 | 是 | 福钥配置 |
| platform-params | 平台治理 | 是 | 平台参数 |
| settings | 平台治理 | 是 | 系统配置 |
| operations | 平台治理 | 是 | 运营管控 |
| identities | 平台治理 | 是 | 身份与权限 |
| audit | 平台治理 | 是 | 审计日志 |
| login（未挂） | 系统页面 | 隐藏 | 登录页不进业务导航 |
未挂菜单 7 项的结论：analytics 显示 / site-data 显示 / weather-road 显示 /
ai-config 显示 / destinations 显示 / content-items 合并 / login 隐藏。
波波核注（3 处调整）：
1. ai-config 从"内容与品牌"调到"平台治理" —— AI 配置是平台能力开关，
不是内容资产；和"平台参数/系统配置"放一起才是运营的心智。
2. cms 隐藏但不删 —— 它是孤岛（C端 零消费），隐藏入口可避免运营继续往里录；
但保留路由与页面，是否删除数据要义父定，我不擅自动。
3.content-items合并前需先核实 ——ContentItems.tsx（content_items 表）
与 ContentAssets.tsx 是不是一回事，合并前必须确认，
否则会把两个不同能力硬拧成一个。实施第一期前先查清。
结论：建一个"内容与品牌"顶层组，按内容资产类型拆分，不再保留泛化的"内容管理"。
| 现名称 | 新名称 | 处理方式 |
|---|---|---|
| 内容管理（cms） | 遗留 CMS | 隐藏入口（C端 零消费，继续录会形成"录了不展示"的风险） |
| 内容资源（content） | 内容资产 | 统一内容主入口 |
| content-items | 内容资产详情 | 并入"内容资产" |
| 故事管理 | 故事 | 类型化命名，去冗余 |
| 场景管理 | 场景 | 与目的地、POI 同一语义 |
| 攻略内容 | 攻略 | 去"内容"后缀，与故事/场景并列 |
| 文案字典 | 文案与术语 | 突出文案、多语言、词汇治理 |
| B端藏文字典 | B端 术语词典 | 与文案治理同组，明确服务对象 |
波波核注：采纳。这套命名把"内容"从一个含混词变成一组并列的具体类型，
运营不用再猜"内容管理"和"内容资源"差在哪。
且满足鉴权 / 事务 / 行锁 / 留痕 / 目的地隔离五守卫
check_admin_boundary.py 守波波核注：第 4 条和第 5 条正好接上我 09-25 做的权限边界门禁。
特别是"平台兜底干预必须单独显示为受控操作"——对应我发现的
退款执行缺操作员留痕那个问题。采纳，且作为第一期的验收项之一。
| 阶段 | 风险 | 改造内容 | 验证方式 |
|---|---|---|---|
| 第一期：导航重组 | 低 | 保留原路由与页面，实现六组菜单、统一显示名、L2 只读分组；补挂 5 个应显示入口 | 逐项核对 34 个页面；旧 URL 仍可访问、权限不变、核心流程回归 |
| 第二期：命名与入口合并 | 低—中 | 内容入口统一命名；content-items 作为子入口；隐藏 CMS 菜单 | 运营可用性测试：完成"找攻略 / 改文案 / 查 POI"，记录找寻时间与误入率 |
| 第三期：权限与只读强化 | 中 | L2 菜单/标题/按钮统一只读标识；复核 L0/L1 可写范围 | 跑门禁脚本；接口级验证无新增 L2 写端点；抽查两套 API 防护一致性 |
| 第四期：内容与数据治理 | 中—高 | 评估 CMS 数据迁移/停用/历史只读；梳理内容资产与 C端 消费关系 | 测试环境验证发布链路与 C端 展示；未验证不得删旧表旧路由 |
| 第五期：页面内部重构 | 高 | 导航稳定后，统一筛选/详情/状态/发布/审计等交互 | 灰度发布，监控错误率、权限异常、任务完成率，可回退菜单配置 |
原则：先改"找得到"，再改"用得好"，最后改"底层一致性"；全程保留旧路由与可回退配置。
波波核注：分期合理，完全同意"先找得到再改好用"。
第一期风险确实低（只动导航不动页面），可以立刻开工。
第一期实施清单：
ContentItems 与 ContentAssets 是否可合并（前置，未核实不动）menu.ts 改结构：扁平数组 → 六组（新增 group 字段，废弃 scope 编号）cms 菜单（保留路由）未动项（需裁定）：cms_posts 孤岛数据怎么处理（迁移 / 停用 / 保留历史只读）。
状态：第一期完成并上线 prod，commit df98fcb4。
我把 components/menu.ts 当成导航单一来源写进材料，它是废弃文件（全仓零引用）。
真实导航是 Layout.tsx 的 NAV_GROUPS，而且早就已经有 7 组分组。
⇒ 材料中"27 项扁平无分组""7 个页面没挂菜单"两条是错的，
gpt6 基于错材料给出的部分结论也随之偏掉。材料错了，产出就会偏。
更严重的是根因：我 09-25 新增 bo-dictionary / guide-admin 时
只往废弃的 menu.ts 加了项，没加进 NAV_GROUPS ⇒ 运营点不到，等于白做。
| 设计稿 | 实际 | 原因 |
|---|---|---|
| content-items 并入"内容资产" | 各自独立 | 核实后三者是三张表三个消费链路，不能合并（见下） |
| 补挂 5 个未挂菜单页 | 补挂 4 个 | "未挂菜单"本身是误报，真实只有 4 个漏挂 |
| — | 新增：cms 移出导航 | 孤岛，避免运营继续往里录 |
核实推翻的一条：ContentAssets（POI/路线/知识/规则）、
ContentItems（content_items 键值，C端 texts 消费）、
SiteDataConfig（site_config，C端 config/site 消费）——三张表三个链路，一个都不能合并。
分组: ["经营总览","运营待办","商户与商品配置","内容与品牌","经营数据 · 只读","平台治理"]
菜单项数: 32
含只读组: true
导航无内容管理(cms): true
/bo-dictionary /guide-admin /crm-leads /crm-funnel /orders 均可达
错误: 0本地真渲染 scripts/verify_nav_local.mjs 12/12 通过。
第二期命名与入口合并已顺带完成大部分；剩下：
第三期 L2 页面顶部加"只读"条幅与按钮级禁用；
第四期 cms 数据处置（待义父裁定：接上 C端 / 停用 / 历史只读）；
第五期页面内部交互重构。