Ray Dashboard

把一个随 vault 存放的本地工作台装进用户的知识库并保证它真的能用。仪表盘是入口层，不是第二套笔记系统：Markdown 仍是唯一真源。

孵化状态：首个 lab 住户。安装/启动/停止/升级/诊断链路已实测；launchd 常驻自启只有文档还没有自动化；Windows/Linux 的 stop 依赖 lsof 回退，未充分验证。

固定原则

1. 仪表盘默认只监听 127.0.0.1。只有用户明确要求手机通过自己的 Tailscale 网络访问时才加 --tailnet；不监听局域网地址，不做公网端口转发建议。
2. 不读取、不修改、不移动用户笔记；安装只写 50-系统/40-自动化/知识仪表盘/ 一个目录，外加在其上一级补齐缺失的 review_protocol.json / board_protocol.json 默认协议（已有协议是管线数据，一律不动、不覆盖）。
3. config.json 是用户数据，任何命令任何情况下不覆盖。
4. 用户已改动的代码文件默认保留；只有用户明确要求升级时才用 --upgrade 替换，并逐项报告。
5. 启动的完成标准是 healthz 探测通过并交付可点击 URL，不以"命令没报错"为完成。
6. 开机自启是持久配置，只在用户明确要求时按 autostart.md 配置。
7. 本 skill 只装仪表盘和两份协议，不装采集管线、发布归档脚本和 50-系统/30-模板/ 下的反馈卡与成稿包模板。工作台里的「让 Codex 起草」依赖 知识采集/knowledge_ingest.py，「登记发布」依赖 发布归档/record_published.py 和 内容反馈.md、口播视频反馈.md、内容成稿包.md 三份模板；只装本 skill 的库这两个动作会报「找不到脚本」。反馈卡上的网页复盘（下结论、填平台数据）依赖 反馈复盘/feedback_snapshot.py，缺它时入口自动隐藏，不报错。用户要用它们时，明确告知需要完整的 rays-brain-kit，不在本 skill 内补写这些脚本。

1. 确定知识库根目录

与 ray-obsidian 同一套定位顺序：用户明确给出的目录 → .ray-obsidian.json → 同时存在 10-创作/、20-知识/、30-资料/、50-系统/ 的兼容库 → 只问一个问题。确定后先报告绝对路径。