Internal Lab Workspace
First-time setup
这里不会保存任何服务端密钥。Supabase URL 和 anon key 是前端可公开使用的配置；真正的安全边界由数据库 RLS 权限控制。
正式上线时，把这两个值写入 /console/config.js，不要在网页中放 service_role key。
Secure sign-in
推荐你本人使用 owner 权限，少数学生设置为 admin，普通学生默认只能维护自己的页面、提交新闻线索和更新成果材料。
owner / admin 管理公开内容、成员权限和合作线索；student 维护个人页面与提交材料。
待审核、需跟进、可发布的内容汇总到这里，避免素材沉在聊天记录和文档里。
已到 public-ready 的内容进入 GitHub/Decap CMS 发布层，形成可检索的官网资产。
Work Queue
Activity
收集论文、竞赛、项目、系统进展和媒体线索，先沉淀事实，再改写成官网新闻。
记录单位、联系人、场景类型、可用信号和预期价值，后续可转成技术方案或申报材料。
把新闻、案例、前沿精选和学生页面转成可追踪任务，明确状态、优先级和负责人。
owner 管控成员状态和角色，学生维护自己的页面，管理员协助整理公开内容。
把 Cloudflare/Plausible 等聚合统计沉淀成快照，观察哪些页面正在形成真实影响。
owner 可以导出后台关键表，形成轻量备份和阶段性资料包，方便交接和留档。
Operating model
官网负责稳定、专业、可检索的公开表达；控制台负责团队日常维护、学生页面、新闻素材、项目成果和权限审核。这样既有传播效率，也能把敏感材料留在私有数据库里。
Review queue
把需要对外发布的新闻、案例、前沿精选、学生页面和合作材料先变成任务。owner/admin 可以调整状态和优先级，普通成员可以提交自己的素材任务。
Public draft
这里生成的是给公开 CMS 或 GitHub 提交使用的初稿。发布前仍需要人工核对事实、署名、链接和敏感边界。
Frontier curation
自动雷达负责抓取，人工精选负责判断。这里可以把真正值得 MAC-Lab 关注的论文、产业动态和开源项目沉淀成“实验室观点”。
Student profile
学生可以维护自己的研究方向、代表成果、竞赛经历和项目参与情况。发布到官网前建议由 owner/admin 审核，保持对外口径一致。
News desk
新闻可以先作为素材进入后台，再由管理员改写成对外可发布的版本。建议保留时间、参与人、成果类型和可公开链接。
Partner pipeline
合作线索先记录真实场景、用户角色、信号条件和需求边界，再判断适合走联合申报、横向合作、试点验证、平台部署或学生项目。这里保存的是内部工作流，不直接对外发布。
按新线索、需求澄清、方案成型、可公开案例和归档进行推进。
Roles
owner 负责最终发布和权限分配；admin 可以协助维护新闻、成员和成果；student 只能维护自己的资料与提交素材。权限更新只对 owner 开放，避免后台权限扩散。
Projects and outputs
这里用于沉淀可对外包装的素材：国家级项目、高水平论文、学生竞赛、平台系统、产学研案例和阶段性影响。正式发布仍走公开 CMS 审核。
Analytics
公开网站的访问统计适合做匿名聚合观察：哪些页面被真正阅读、哪些方向带来合作兴趣、哪些英文页面更容易被外部访问。具体个人访问身份不在这里追踪。
建议继续使用隐私友好的聚合统计。控制台保存的是阶段性快照，不追踪个人身份。
重点看首页、研究方向、行业方案、前沿雷达、加入我们和合作入口的访问趋势。
访问增长的方向可转成新闻、案例、英文摘要或合作沟通材料。
如增强 SQL 尚未部署，这里会提示需要更新 Supabase schema。
Backup
这里生成的是当前账号按 RLS 权限可读取的数据包。owner 登录时可导出完整后台工作数据；普通成员只能导出自己有权查看的内容。
尚未生成备份。
Audit trail
重要内容的新增、更新和状态变化会进入审计日志。这里用于追踪谁在什么时候改了什么，避免后台多人协作时丢失责任链。
System
本页只使用 Supabase anon key。数据库权限请通过 docs/admin/supabase-schema.sql 部署 RLS 策略后再开放给学生使用。