家长管理平台设计调研：社区参考、五个嫁接方案与 Roadmap 提案

0. 摘要（给刚睡醒的你）

你提的四步需求——批量下载 → 批量处理 → 自动上传 COS → 上下架管理——在当前主线里的真实状态是：

1. 前三步的引擎已经造好了，而且工程质量相当高：URL 列表批量入队（单次 ≤100 条）、有界并发下载、自动转码（1080p+480p）、校验、签名分片上传，全部自动化，失败可重试、断点可恢复。缺的不是引擎，是操纵它的界面：现在审批和上下架都只能一条一条点，批量操作界面完全空白。
2. 第四步（COS）需要你做一个授权决策：主线当前所有媒体存在 Cloudflare R2；腾讯 COS 的代码底座已存在（签名直传协议 + COS adapter），但按 ADR 0004 属于「已批准、未激活」候选，激活它涉及真实费用、CAM 授权和主机门禁——这是唯一「不能都做、必须你拍板」的分叉点。
3. 社区答案很成熟：这类「下载-处理-归档-发布」场景在开源社区有大量打磨多年的成品（arr 系列、Tube Archivist、Jellyfin、Payload/Directus 等），它们共同验证了一套模式：**「来源订阅 → 队列暂存 → 审核 → 批量执行 → 归档库」五段流水线 + 内容/任务双视图 + 命名预设/Profile*。
4. 本报告给出 5 个嫁接方案，推荐组合是 方案 D（现代轻工作台）为底座 + 方案 B（片库策展室）的浏览视图 + 方案 A（采集驾驶舱）的队列与审核闸门——理由见 §4.6。
5. Roadmap 提案 6 个里程碑（M0-M5），与 docs/ROADMAP.md 的既定节奏兼容：v0.5 家庭体验基线验收期内不动管理平台，管理平台效率本就是 v0.5 之后的候选方向②。

你睡醒后只需要回答三个问题（详见 §6）：① 设计方向选哪个（推荐「按 §4.6 组合」）；② COS 是继续保持 R2 主线，还是授权启动激活门禁；③ roadmap 排序是否认可 M1（批量操作）先行。

1. 任务与范围

本次调研回答三个问题：

1. 社区里有哪些优秀的成品与设计风格可以参考（§3，共 6 组、20 余个产品）；
2. 把这些风格嫁接到我们的管理平台上，能形成哪几种设计方案（§4，5 个方案）；
3. 管理平台接下来的 roadmap 是什么（§5，M0-M5）。

范围边界：只新增本文档；不修改 apps/admin、apps/api、apps/collector、packages/contracts；不激活 COS、不创建云资源；所有仓库现状结论附代码文件引用，所有社区结论附来源链接。

2. 现状盘点：我们到底已经有了什么

依据 origin/main（22d1add）代码事实，关键结论均可在引用文件中复核。

2.1 链路全景

允许扫描的目标（scan_targets allowlist，扫描间隔 ≥15 分钟）
  → 发现落 pending_review（不自动下载）
  → 家长在 Admin 批准（版权门禁：owned/licensed/open_license/creator_permission）
  → Collector：inspect → download → probe → metadata(AI) → 转码 → 校验 → 上传 → finalize
  → API/D1 元信息 + 私有 R2 媒体
  → Admin 发布/隐藏（published ⇄ hidden）
  → PWA 宝宝端只消费 published & visibleToChild

2.2 管理后台现状（apps/admin）

• 技术栈：React 18 + TypeScript + Vite 6；无路由库、无 UI 组件库，样式为单文件手写 CSS（apps/admin/src/styles.css）；整个后台是单页 + state 切换四个视图（apps/admin/src/App.tsx:680），全文件仅 1339 行。
• 四个视图：
  1. 采集运行：创建采集任务（单 URL / URL 列表 ≤100 行 / 番剧季度 / series:<id>），查看运行队列——8 阶段进度条、字节级下载进度、5 秒轮询、错误码 + 逐条重试（apps/admin/src/collector-runs.tsx）；
  2. 内部资源：R2 自托管资源审核流，按状态筛选（待审核/处理中/待发布/儿童可见/失败/已隐藏），卡片上做批准下载、暂不收录、重新处理、发布、隐藏/重新发布（App.tsx:151-161）；
  3. 外部候选：官方播放白名单初筛、核验、发布/隐藏、版权备注、家庭观看策略（每日分钟数/连续条数/休息重置/自动连播）（App.tsx:467-660）;
  4. 人工导入：manual_file 收件箱（SHA-256、错误码）。
• 鉴权：单一静态管理令牌（Bearer + SHA-256 常时比较，apps/api/src/auth.ts:43-45），无角色体系。
• 已有但未暴露的 API：扫描源管理 GET|POST /api/v1/admin/scan-targets（apps/api/src/index.ts:1806-1842）——API 存在、前端没有任何界面。

2.3 采集与处理管线现状（apps/collector）

• 两级状态机：run（queued/running/succeeded/partially_failed/failed）× item（8 阶段：inspect/download/probe/metadata/process/upload/finalize/cleanup，apps/collector/src/automation/orchestrator.ts:50）。
• 资源状态机由 contracts 强制：discovered → pending_review → approved/rejected → processing → ready → published ⇄ hidden（packages/contracts/src/index.ts:19-36、canTransitionResource 于 :1203）。
• 工程可靠性：SHA-256 快照校验与断点续传、租约心跳、分片直传（每片重试 3 次）、finalize 指纹、1-8 有界并发、单条失败隔离进 failures 不影响整批。
• 转码策略：源 ≥1080p 才出 1080p，始终出 480p，外加音频与封面；ffprobe 复验；低分辨率来源如实记录不放大（apps/collector/src/automation/local-media-processor.ts:187-230）。

2.4 差距分析：对照你的四步需求

一句话：链路已闭环且工程化程度高，管理后台停留在「单条操作 + 任务队列查看」形态；批量审批、批量上下架、资产库浏览、源管理、审计视图是五块清晰空白的拼图——恰好对应 docs/ROADMAP.md 里 v0.5 之后的候选方向②「家长管理效率」。

2.5 一个重要的事实修正：COS 的真实状态

你的需求表述是「处理完自动上传腾讯云 COS 桶」，但主线现状是：

• Cloudflare R2 是唯一活跃存储（apps/api/wrangler.jsonc:21-24，dev/prod 双桶）；架构口径「Cloudflare 是唯一活跃运行时」。
• 腾讯大陆路径（北京 2C2G + 标准 COS 私有桶）是 ADR 0004 已批准但未激活的候选：infra/tencent/ 内旧 LightCOS 实现已冻结（禁止执行）；标准 COS 的创建、费用、CAM 授权、主机修改各自独立门禁，均需人工明确授权（docs/decisions/0004-mainland-fresh-start-runtime.md、infra/tencent/README.md、docs/ROADMAP.md）。
• 好消息：协议层为存储切换做了充分准备——Collector 永远经 API 签名 URL 直传，不持有任何云凭证；renditions.storage_provider 字段天然支持多存储并记。所以「R2 与 COS 并存」在技术上成立，卡点只在费用与授权，不在代码。

这不是需要今天解决的问题，但它是 §6 决策清单里唯一涉及真金白银的一项。

3. 社区调研：六组参考

3.1 下载管线自动化：Sonarr / Radarr / Prowlarr（*arr 系列）

• 定位：PVR 式自动化下载管理——订阅剧集/电影，监控 RSS 自动抓取、重命名、失败自动换源并升级画质；Prowlarr 统一管理索引器。这一族是「下载管线管理」这个品类的定义者。
• 界面与交互：左侧栏导航（库/日历/Activity/Blocklist/Settings），默认深色；内容库有 Poster 海报墙 / Table / Overview 三视图；下载队列是典型状态色表格：灰钟=等待、黄警=无法导入、紫=导入中，每行附移除/黑名单/人工导入动作；失败处理分两层——自动重试其他发布源 + Blocklist 防重复抓取；人工审核以「交互式搜索/导入弹窗」按需出现，能看到某发布源被自动规则拒绝的原因；历史页记录抓取、导入、失败、升级全链路。
• 可借鉴：①状态机+颜色语义的队列表格；②「自动换源+黑名单」的失败兜底；③过滤器（Monitored/Missing/Cut-off Unmet）天然映射为上下架视图；④质量 Profile——把转码参数封装成命名档位（对我们就是「英语启蒙 1080p+480p」档）。

来源：Sonarr、Radarr、Sonarr Activity 文档、Radarr Library 文档

3.2 YouTube 订阅下载器：Tube Archivist / Pinchflat / MeTube

• Tube Archivist：自托管 YouTube 库管理（Django+ES+yt-dlp）。它的 Downloads 页是「人工审核暂存区」的最佳范本：顶部三个动作（重扫订阅 / 开始下载 / 批量粘贴链接）；队列每项带缩略图和 Ignore / Download now 按钮；可按类型（Shorts/直播/普通）、频道、错误态过滤后套批量动作；失败显式展示错误信息且绝不自动重试；被忽略项有独立视图可恢复。内容库 Grid/List/Table 三视图，Table 直接暴露编解码、体积、分辨率，可多选批量重下。
• Pinchflat：极简 YouTube 订阅下载器，「来源+规则」是一级对象：每个频道/播放列表一份配置（画质预设、截断日期、命名模板、post-download 脚本钩子），定时期检查新内容，WebSocket 实时刷新。胜在「配一次，长期免维护」。
• MeTube：yt-dlp 的单页 Web 前端（~14.6k star）：粘贴链接选格式即下，实时进度条任务列表，Advanced 面板提供「Option Presets」把技术参数变成业务预设；状态持久化，刷新不丢。
• 可借鉴：①Rescan 进队 → 家长筛选 Ignore → 才开始下载的审核闸门（与我们的 pending_review 机制同构，但人家的批量操作成熟得多）；②按频道/类型批量筛选动作；③来源规则模板 + post-download 钩子（对应我们「下载后自动转码/上传」）；④Option Presets 业务预设；⑤失败显式 + 手动重试的诚实呈现。

来源：Tube Archivist、TA Downloads 文档、Pinchflat、MeTube

3.3 家庭媒体库：Jellyfin / Plex

• 定位：开源家庭媒体服务器；Dashboard 承担库扫描、用户与播放管理，面向观众是海报墙。
• 界面与交互：海报墙按库/合集组织；Metadata Editor 弹窗逐项改标题、年份、流派、简介，替换主图/背景图，并可锁定字段防止刮削器覆盖人工修改；多 rendition（2160p/1080p）通过命名约定归属同一影片；定时任务扫描刷新，状态可视化。
• 可借鉴：①多副本归属同一条目的模型（我们的 renditions 表已经是这样，UI 可以学它把「1080p/480p/封面」并列展示在详情页）；②人工元数据字段锁定；③图片语义类型（poster/backdrop/thumb）；④入库扫描任务状态可视化。

来源：Jellyfin 元数据、Jellyfin 电影库

3.4 CMS 与 DAM：Payload / Directus（附 Strapi、react-admin、DAM 通用模型）

• Payload CMS 3：TS config 生成的 Admin；Upload collection 列表自动显示缩略图、批量上传；编辑页「左表单 + 右上传卡片」，卡片列出每个生成尺寸的宽高与体积；草稿三态 Draft / Published / Changed（已发布但有未发布修改）+ 定时发布 + revert to published 是最完整的发布工作流范本；存储适配器可插拔接 S3。
• Directus：File Library 网格/表格切换、文件夹层级、详情抽屉编辑标签；Flows 模块「触发器（事件/定时/手动）+ 操作链 + 执行日志」是可视化自动化管线的最佳范式，正好对应我们「资源 ready → 自动转码 → 上传 → 通知」的需求；Insights 模块拖拽搭建运营仪表盘。
• DAM 通用模型（Cloudinary/Bynder/ResourceSpace）：资产 = 原始文件 + 结构化元数据 + 任意 derived renditions + 版本历史；「审批通过才可上架」、限制过时资产访问而不删除、查看/下载统计、权利到期告警。
• 可借鉴：①Payload 的三态发布状态机 + Changed 提示 + 定时上下架；②Directus Flows 的「触发器+操作+日志」管线可视化；③DAM 的「资产/rendition/发布状态三者分离、审批门禁、访问统计」。

来源：Payload Upload、Payload Drafts、Directus Flows、Cloudinary DAM、Bynder Asset Workflow、ResourceSpace、Strapi Media Library、react-admin、Refine

3.5 后台设计系统：shadcn、Ant Design Pro、TDesign、Arco

结论：追求现代感与低维护选 shadcn/ui；偏好国内企业风且重表格选 antd；喜欢腾讯生态选 TDesign 但要多付模板成本；Arco 因维护停滞不建议新项目采用。

来源：shadcn-admin、shadcn dashboard 示例、ProComponents、TDesign Starter、tdesign-react、Arco Design

3.6 儿童英语内容运营：Lingokids、Khan Academy Kids 等

• 目录组织：Lingokids（2-8 岁）按学科/技能组织课程单元，家长区有 Progress Center 周报；Khan Academy Kids（2-8 岁）按年龄自适应路径+分主题图书馆；Duolingo ABC（3-8 岁）700+ 课时按读写阶段线性递进；Super Simple Songs 约 157 首儿歌按主题（字母/数字/动物/节日）与系列/合辑组织，每首 1-4 分钟；Little Fox 用 9 级分级体系（约 5760 个故事），级别即难度阶梯，系列/剧集结构（如 72 集连续剧）；BBC CBeebies 按节目 IP 组织，全内容面向 6 岁以下因此产品内不做家长控制。
• 适龄共识：4 岁单集 3-7 分钟为宜；语速慢、避免快节奏剪辑；学前儿童不识字，字幕应以画面+语音为主（单词高亮优于整行字幕）；AAP/Mayo 建议 2-5 岁每天 ≤1 小时高质量节目并鼓励共看。家长管控的共同范式：内容全部适龄之后，控制只剩「时长 + 报告」——这与我们已有的家庭播放策略（每日 30 分钟/连续 3 条/20 分钟重置/不自动连播）完全一致，缺的是内容侧的适龄元数据。
• 推荐元数据模型（在现有 resource_metadata 的内容类型/年龄区间/系列之上扩展）：
  • 标识：标题（中/英）、系列 ID + 系列内集数排序
  • 适龄分级：minAge/maxAge、CEFR（pre-A1/A1）、难度级别（Little Fox 式 1-9）
  • 主题与目标：topics[]（字母/数字/颜色/动物/问候）、目标词汇 vocabulary[]、技能 skills[]（phonics/counting/listening）
  • 媒体：时长、renditions（已有 1080p/480p）、封面、字幕策略（单词高亮）、语速标记
  • 合规（参考 Common Sense Media 维度）：教育价值、惊吓度/暴力标记；无广告、无第三方追踪、无内购（COPPA/GDPR-K 结论性标志）
  • 运营：上线状态（已有）、标签来源（人工/AI，已有 provenance）、审核时间戳

来源：Lingokids 进度报告、Khan Academy Kids、Duolingo ABC、Super Simple、Little Fox 分级目录、CBeebies 家长 FAQ、Common Sense Media 分级、Seattle Children's 屏幕时间、Mayo Clinic 屏幕时间

3.7 跨社区共性结论

20 余个产品交叉验证出同一套骨架：

1. 五段流水线：来源订阅 → 队列暂存 → 筛选/审核 → 批量执行 → 归档库。所有成熟工具都是这个形状，无一例外。
2. 内容与任务分离：内容看缩略图卡片墙（低密度、视觉优先），任务看密集表格（高密度、状态优先）。管理后台应分成「片库」和「处理队列」两个视图，而不是混在一页。
3. 审核是队列里的关卡，不是独立流程：自动化优先，例外（Ignore/黑名单/人工导入）时才介入——与我们的 pending_review 机制同构，社区只是把它做成了批量操作。
4. 失败处理是「显式错误 + 手动重试/黑名单」，不做无限自动重试——与既有 Collector 行为一致，方向正确。
5. 复杂参数一律封装为命名预设/Profile（质量档位、Option Presets）。
6. 发布是一等状态机：草稿/已发布/已修改三态、定时上下架、版本回滚，在 CMS/DAM 里是标配能力。

4. 五个设计方案

每个方案 = 把 §3 中一类风格整体嫁接到现有管理平台。评估维度：信息架构、关键界面、嫁接成本（对当前 React+Vite 无组件库代码基）、优缺点。

方案 A ·「采集驾驶舱」（血统：*arr + Tube Archivist）

一句话：管理平台 = 流水线控制台，深色、高密度、队列中心。

• 信息架构：左侧栏六项——仪表盘 / 待审队列 / 采集运行 / 片库 / 发布管理 / 源与设置。待审队列是首屏。
• 关键界面：三段队列看板（待审 → 下载处理中 → 待发布），状态色语义（等待灰/运行蓝/失败红/待发布紫）；多选 + 批量批准/否决/重试工具栏；失败项显式错误码 + 手动重试 + 「来源黑名单」防重复抓取；顶部「批量粘贴 URL」入口（对应 TA 的逐行批量添加）。
• 嫁接成本：中。现有采集运行视图升级为 run×item 双层队列；需新增批量 transition 端点；深色主题覆盖现有样式。
• 优点：批量运营效率最高，和你「批量下载几百条」的使用强度最匹配；审核闸门模式与产品红线（不自动下载）严丝合缝。
• 缺点：对内容浏览不友好——片子一多，纯表格找资源很痛苦；视觉偏极客，家庭产品气质弱。

方案 B ·「片库策展室」（血统：Jellyfin/Plex + Netflix CMS）

一句话：管理平台 = 给宝宝选片子的策展室，海报墙、详情抽屉、上下架=策展。

• 信息架构：片库（网格/表格双视图）为一级入口 → 详情抽屉（预览播放器 + 元数据表单 + renditions 清单 + 事件历史）；系列=合辑页；「已隐藏」=从墙面撤下，独立抽屉可召回（ResourceSpace 的「限制访问不删除」）。
• 关键界面：海报墙带状态角标（待审/已发布/已隐藏/失败）；卡片 hover 即签名临时预览（API 已有 preview-ticket）；系列内拖拽排序集数；元数据字段锁定；按主题/年龄/CEFR 筛选。
• 嫁接成本：中。新增库网格视图（API 已有 resources 列表 + 签名预览）；元数据编辑器复用现有实现；需补封面提取（转码已产出封面 rendition）。
• 优点：内容量到几百条后依然「看得见」库存；发布/隐藏变成直觉的策展动作；与宝宝端（#71）的内容组织天然对齐。
• 缺点：不解决批量操作效率；封面质量依赖来源。

方案 C ·「企业内容中台」（血统：Ant Design Pro / TDesign）

一句话：标准企业中后台，表格+表单+高级筛选全覆盖，国内运营习惯，与腾讯云控制台审美同源。

• 信息架构：经典 ProLayout（顶部+侧栏）；内容管理/采集任务/数据统计/系统设置四组菜单；每页 = ProTable（列设置、保存视图、高级筛选组合）+ 批量操作栏 + 操作审计 Tab。
• 关键界面：高密度资源表格（一屏 30+ 行）；组合筛选器（状态×系列×年龄段×内容类型×来源）；批量上下架操作栏；审计日志页（resource_events 可视化）。
• 嫁接成本：高。引入 antd + ProComponents 全量替换现有手写样式体系；umi 脚手架弃用只取组件；包体显著增大。
• 优点：业务组件开箱即用（批量表格、表单校验、审计列表都是现成的）；中文文档与国内使用习惯最贴合；若未来激活 COS，与腾讯生态视觉同源。
• 缺点：全家桶气质重、定制需逆向设计 token；对「单家长 + Agent 维护」的场景偏重；TDesign 的 React 侧模板生态薄（若偏好腾讯风，成本中高）。

方案 D ·「现代轻工作台」（血统：shadcn/Linear/Vercel）

一句话：极简、快、键盘友好；Tailwind + 复制式组件；命令面板直达一切。

• 信息架构：侧栏五项（待办收件箱 / 采集 / 片库 / 发布 / 设置）；页面=少量视图 × 强筛选；⌘K 命令面板可跳任何资源/系列/运行。
• 关键界面：待办收件箱——把「待审批、AI 元信息 needs_review、失败待重试」聚合成一个待办流（Linear 的 Inbox 范式），逐条键盘裁决或批量；行内多选 + 浮动批量操作条（「已选 12 条：批准 / 发布 / 隐藏」）；详情 slide-over；乐观更新 + 5 秒撤销（react-admin 验证过的手感）。
• 嫁接成本：最低。Tailwind 渐进引入，组件按需复制（shadcn-admin 即 Vite+React+TS 模板），无路由强绑定，现有 1339 行单页可逐视图迁移；深浅色主题原生。
• 优点：工程现实最匹配（无组件库现状 + Agent 维护友好）；颜值现代化；待办收件箱范式把「要人处理的事」收敛到一屏。
• 缺点：复杂表格/表单组件需自行拼装（Tremor/TanStack Table 补齐）；风格通用，辨识度靠细节。

方案 E ·「数据运营台」（血统：Directus Flows/Insights + Payload drafts）

一句话：schema 驱动 CRUD + 可视化自动化管线 + 运营仪表盘，看到整条流水线在跑。

• 信息架构：数据模型浏览 / 流水线（Flows）/ 仪表盘（Insights）/ 片库 四区。
• 关键界面：管线视图——把 collector 的 8 阶段 × run×item 画成实时流程图（节点绿/红/灰），失败节点点击即重试；发布三态 Draft / Published / Changed + 定时上下架 + 回滚到已发布（Payload 范式，落我们现有状态机需扩展）；仪表盘——库存量、转码积压、失败率、上下架数、宝宝端日观看聚合（产品契约只存日聚合，合规）。
• 嫁接成本：中高。不引入 Directus 本体（架构冲突：我们已有自研 API 与状态机），只借范式：jobs 表已有基础，Insights 需新增聚合端点 + Tremor 图表；定时发布需新增调度能力（Cloudflare Queues/Cron 或 collector 轮询）。
• 优点：对「系统在干什么」的透明度最高；仪表盘给「运营感」；定时上下架是真实需求（如周末上新）。
• 缺点：对单家庭规模可能过重；流程可视化开发量大；聚合端点要做逐日统计查询。

4.6 对比与推荐

推荐组合：D 为底座 + B 的片库视图 + A 的队列与审核闸门。 理由：

1. 你的自述痛点是「思路匮乏、不知道需要哪些能力」——社区答案是：你需要的是批量操作（A/D 提供）+ 看得见的片库（B 提供），而不是一套更重的框架。
2. D 的落地成本最低且与现有代码基零冲突，可以逐视图迁移、每步可交付，符合仓库「短分支、小步走」的交付规则。
3. C 全盘引入的包体与维护代价对单家庭产品不划算，但其表格交互习惯可作为 D 中 TanStack Table 的配置参考；E 的仪表盘与定时上下架是有价值的，放 roadmap 后期按需取用。

这不是排他决定：五个方案的界面元素可以混搭（D 骨架上放 B 的海报墙、A 的队列、E 的仪表盘各一页），推荐组合本身就是这么构成的。

5. Roadmap 提案

5.1 前置约束（来自 docs/ROADMAP.md，必须尊重）

• 当前里程碑 v0.5 家庭体验基线进行中，验收期内明确不做管理平台重设计——所以 M0 之前的一切都只是设计与登记，不动代码。
• 管理平台效率是 v0.5 之后候选方向②（「批量审核、标签、任务状态与源管理」）——本 roadmap 就是把候选②展开成可执行的里程碑，排序仍需你确认。
• 每个里程碑走独立 Issue + 短分支 + PR，遵循现有交付规则；D1 变更只追加兼容 migration。

5.2 里程碑

5.3 横切红线（所有里程碑适用）

新发现资源不自动下载（allowlist + 审批闸门）；1080p 如实标注不放大；D1 迁移只追加；媒体对象不自动删除；元数据人工字段可锁定防 AI 覆盖；不引入遥测、账号体系、付费能力。

6. 待你决策的分叉点（睡醒后看这里）

1. 设计方向（§4）：五选一或组合。我的推荐是「D 底座 + B 片库 + A 队列」。回复「按推荐」即可，我会登记 M0/M1 实现需求；想换方向直接说编号。

2. COS 激活节奏（§2.5、M4）——唯一涉及真实费用的分叉，三选一：

   • ① 维持 R2 主线（零成本，什么都不用做，COS 保持已批准未激活）；
   • ② 授权启动激活门禁链（先做精确费用确认，每一步再单独向你要授权）；
   • ③ 双存储并行（成本最高，当前不建议）。

   说明：①和②不冲突——可以先①跑着，哪天国内访问速度成为真实痛点再启动②；这条我按你的规则只做方案不执行。

3. Roadmap 排序：M1（批量操作）先于 M2（片库）是否认可？两者也可并行分派。

7. 附录：本报告的证据基础

• 仓库现状：origin/main @ 22d1add 代码盘点（apps/admin、apps/collector、apps/api、packages/contracts、docs/decisions/0004、docs/ROADMAP.md），关键引用见 §2 各节。
• 社区来源：已分列于 §3 各小节末尾，共 30+ 条链接。
• 姊妹调研：KB-71（宝宝端体验，5 版设计方向 + MVP 原型）——两份报告共同构成「宝宝看到什么」×「内容如何进来、如何管理」的完整决策输入；§3.6 的元数据模型是两边共享的地基。