用户隐私声明（Privacy Statement）能力需求文档

状态：需求 / 提案（假设尚未实现，从零立项）仓库：BitFun-OHOS 相关架构入口：

docs/architecture/product-architecture.md（分层与平台适配边界）

docs/architecture/i18n.md（多语言与 locale 治理）

docs/architecture/platform-portability-design.md（未来 HarmonyOS PC CLI/TUI 平台目标）

功能类型

新功能
现有功能增强
用户体验优化
性能优化
接口/集成扩展
其他

优先级

紧急（P0 - 核心需求，强烈期望实现）
高（P1 - 重要功能，期望尽快实现）
中（P2 - 有价值的功能，计划实现）
低（P3 - 锦上添花，有时间再做）

背景与动机

BitFun 作为跨平台 AI Agent，会接触用户代码、对话内容、AI provider 凭据、远程工作区、可选云端语音转写等高度敏感数据，但目前缺少面向用户的统一隐私声明，用户无法清楚了解"我的数据去了哪里"。
多 delivery profile（Desktop / CLI / Server / Web / MobileWeb / ACP）数据收集范围差异大，本地推理、云端 AI provider、远程 relay、云端 ASR、使用指标上报等可选项的数据流向缺少透明告知。
合规红线：中国《个人信息保护法》（PIPL）、欧盟 GDPR、各应用商店上架政策均要求提供明确隐私声明并取得用户同意；缺少声明将直接阻断发布与上架。
缺少版本化的声明管理：声明更新后无法区分"实质变更（需重新同意）"与"编辑性修订"，无法证明用户接受的是哪个版本，合规审计无据可查。
缺少"未同意时的降级模式"：用户拒绝同意后，产品应能以受限模式继续运行（仅本地/离线功能）而非完全不可用，且不得静默收集任何数据。
数据收集路径缺少统一门禁：各遥测/云端/上报路径若各自判断同意状态，易出现遗漏与静默上报。

功能描述

统一隐私声明文档：提供一份面向用户的隐私声明，覆盖：收集的数据类型（本地代码 / 对话 / 凭据 / 设备信息 / 使用指标）、数据存储位置（本地 vs 云端）、数据流向（第三方 AI provider / relay / 云端 ASR）、数据保留与删除策略、用户权利（访问 / 更正 / 删除 / 导出 / 撤回同意）、第三方接收方与目的、安全措施摘要、联系方式。
多语言：声明按 locale 维护，跟随仓库 i18n 治理（locale id / 别名 / 回退由 src/shared/i18n/contract/locales.json 拥有），不硬编码 CJK；MobileWeb / Installer 不导入 Web UI locale catalog。
版本化与变更分级：每个声明版本带版本号、updated_at、effective_at、文档内容 SHA256；变更标记为 material（实质变更，需重新同意）或 editorial（编辑性修订，不触发重新同意）。
同意生命周期：首次启动或存在未读实质更新时展示声明，用户显式接受——记录所接受的版本、文档 SHA256、接受时间、locale、应用版本；未接受时进入受限模式。
未读更新提示：声明有实质更新时，状态标记存在未读更新，在合适入口提示用户查看并重新同意；编辑性修订不强制打断。
降级模式：用户拒绝同意时，产品以受限模式运行——本地推理 / 离线功能可用，云端 AI provider、远程 relay、云端 ASR、使用指标上报等被禁用，并给出清晰的不支持态提示而非静默失败。
数据收集门禁：提供单一的数据收集策略门禁，任何数据收集路径在执行前查询同意状态；未同意或处于受限模式时阻断收集（fail-closed），不静默上报。
可访问入口：在 Settings 内提供"查看隐私声明"入口，可随时查看当前版本与历史版本；提供"撤回同意"入口，撤回后进入受限模式。
平台无关 + 平台适配：声明内容与同意状态管理逻辑平台无关；各 delivery profile 通过平台适配器暴露（桌面 host command、Web UI 适配等）；UI 组件不直接调用 host API，须走 adapter / infrastructure 层。

期望效果 / 使用场景

用户首次安装 / 启动应用时，看到当前隐私声明，明确知道收集哪些数据、去向哪里、自己的权利；接受后才进入完整功能模式。
声明有实质更新时，应用提示"隐私声明已更新"，用户查看并重新同意；编辑性修订不打断使用。
用户在 Settings 随时查看隐私声明当前版本与历史版本，并可撤回同意——撤回后应用进入受限模式，仅本地功能可用，云端能力被禁用并给出明确提示。
任何数据收集路径在用户未同意 / 受限模式下被 fail-closed 阻断，不发生静默上报；同意记录可作为合规证据被用户查看与导出。
多 delivery profile（桌面 / CLI / Web / MobileWeb）下声明内容与同意语义一致，仅暴露方式按平台适配。

设计草案 / 参考示例

行业参照：GitHub Privacy Statement、OpenAI Privacy Policy、微软 Privacy Statement 的版本化与变更说明；中国 App 隐私政策模板（PIPL）；GDPR 透明度与撤回同意要求。
落地分层建议（遵循仓库分层与边界，从零设计）：
1. Contracts（src/crates/contracts/product-domains）：定义平台无关、行为轻量的稳定 DTO——声明视图（版本 / 变更类型 / 生效时间 / SHA256 / 内容）、同意记录（接受版本 / SHA256 / 时间 / locale / 应用版本）、生命周期状态（待选择 / 完整 / 未接受 / 资源错误）、有效模式（完整 / 未接受）、变更类型（实质 / 编辑）。
2. Services（src/crates/services/services-integrations）：声明文档加载与校验、同意记录持久化、同意状态计算、单一数据收集策略门禁（提供"是否允许收集"查询与模式切换）。
3. Assembly（src/crates/assembly）：声明文档作为不可变内置内容随版本发布，按 delivery profile 装配；声明更新随产品版本同步。
4. Interfaces / App / UI（src/apps + src/web-ui）：桌面 host 注册隐私服务并暴露 command；Web UI 提供声明展示 / 同意 / 撤回 UI；UI 走 adapter / infrastructure 层，不直接调 host API。
合规审计：同意记录（版本、SHA256、时间、locale、应用版本）可被用户查看与导出，作为"用户接受了哪个版本"的合规证据。
远程工作场景：远程控制下隐私同意状态以受控端为准；若远程工作区无法满足同意要求，给出清晰不支持态提示而非静默失败。

是否愿意贡献

我愿意参与开发
我愿意参与讨论和测试
仅提出建议

补充说明

隐私声明的存在与首次同意流程对应用上架与多法域合规是 release-gating 的，建议作为发布就绪的前置条件之一（release_ready 语义）。
非目标：不做行为广告、不出售用户数据、不做"暗模式"同意引导、不在未同意时静默收集。
声明文本本身需法务 / 合规审阅；本需求只定义产品能力与契约，不替代法律文本撰写。
HarmonyOS PC CLI/TUI 是未来平台目标，不属当前范围；如后续覆盖，按 docs/architecture/platform-portability-design.md 单独立项。