docs: add Andromeda OS research and product plan

[oratis]

What changed

• Added a PC/macOS operating-system landscape report covering open-source and proprietary system families.
• Added five deep-research documents:
  • Windows gaming, Office, enterprise files, Wine/Proton, and Windows VM fallbacks;
  • PC, Intel Mac, T2 Mac, and Apple silicon drivers, firmware, certification, and migration;
  • atomic updates, rollback, isolation, AI-agent security, Codex/Claude Code patterns, and local models;
  • Wayland desktop, KDE Plasma/KWin, portals, remote desktop, installers, image building, and app stores;
  • a consolidated Adopt/Pilot/Watch/Reject open-source matrix.
• Added an Andromeda product development plan with architecture, hardware tiers, compatibility routing, AI capability controls, recovery, backup, migration, milestones, SLOs, and the first 12-week plan.
• Expanded the documentation indexes.

Key decisions

• Linux stable/LTS and hardware-enable channels, with separate Asahi combinations for supported Apple silicon cohorts.
• bootc/OCI delivery with OSTree deployments, independently abstracted behind Andromeda APIs.
• Wayland + Xwayland + KDE Plasma 6/KWin for v1; no compositor fork.
• Steam/Proton as a managed gaming domain, plus a native Windows escape hatch for Game Pass/UWP, unsupported anti-cheat, VR, and specialized peripherals.
• Full Windows RDP desktop as the reliable Office fallback; RemoteApp/single-window integration remains a licensing and engineering Pilot.
• Machine-readable Hardware Compatibility Manifest, physical hardware CI, explicit support tiers, and source-system migration agents.
• Capability Broker, typed tools, deterministic risk levels, sandbox/microVM isolation, evidence, audit, and rollback/compensation for AI actions.

Validation

• Cross-review and independent source/claim audit completed.
• Heading hierarchy and all local Markdown links validated across nine documentation files.
• External URL syntax validated; key dynamic and legal claims use official upstream/vendor sources.
• git diff --check passed.

Impact

No runtime code is changed. This PR establishes the research baseline and executable product plan for the first architecture and prototype phase.

[oratis]

PR #1 文档评审:Andromeda OS research and product plan

总体评价

这是一组质量远超一般"调研文档"水准的研究与规划材料:五份专题研究普遍做到了引用一手资料、区分"上游已有/可产品化/不可承诺"、给出 Adopt/Pilot/Watch/Reject 的可执行决策,并且对反作弊、Office 深度功能、Apple 固件授权、字体再分发等最容易被夸大的领域保持了罕见的克制和诚实。主要问题集中在跨文档一致性上:docs/os-landscape-and-andromeda-architecture.md 作为最早的全景稿,其硬件 Tier 定义和"自研 shell/compositor"建议与后续的产品计划、桌面研究直接矛盾,未做订正或标注"已被取代",会误导读者对已定决策的理解。此外部分外链疑似不可达、12 周计划缺少资源假设,需在合入前修正。

优点

• 决策可执行,不是项目罗列。 docs/research/desktop-platform-and-distribution.md 和 docs/research/hardware-drivers-and-migration.md 对每个组件给出决策、边界和引用(如 wlroots 上游已迁移至 freedesktop GitLab、"不得从旧 GitHub release 判断当前版本";bootc-image-builder 已并入统一 image-builder、"Reject(新依赖)"),这类细节说明调研是真做过的。
• 对不可承诺项异常诚实。 docs/research/windows-gaming-office-formats.md §3.3 明确"中间件支持 Proton 不等于所有使用该中间件的游戏都支持 Proton",§9.2 列出禁止使用的宣传语;hardware-drivers-and-migration.md §12 "不把 T2、M1/M2、M3/M4 合并成 Mac supported"。这直接封死了未来营销夸大兼容性的空间。
• 跨文档的核心量化指标基本对齐。 冷启动 ≥99.5%/200(Supported)、≥99.9%/1000(Certified),suspend/resume 100/500 次,在 product-development-plan.md §10.2、Stage 3 退出门与 hardware-drivers-and-migration.md §11 三处一致。
• AI 安全模型技术上站得住。 reliability-update-ai-agent.md 的 L0–L3 隔离分层、R0–R4 风险分级、"read(secret) + network(send) 组合需新增数据流授权"、"MCP 自报只读不能成为安全边界"、rollback 与 compensate 的严格区分(product-development-plan.md §5.6 强制字段)都是正确且不常见的设计纪律。
• 许可证标注准确率很高。 抽查 Proton(顶层 BSD-3 但多许可聚合)、DXVK(Zlib)、FreeType(FTL/GPL 双许可)、CUPS(Apache-2.0 + 链接例外)、WinApps(遗留代码无许可,Reject 直接复用)等均正确,且多处提醒"表格许可证不能替代逐文件 SPDX 扫描"。
• RemoteApp/许可证风险识别到位。 windows-gaming-office-formats.md §4.2 正确指出 FreeRDP 实现客户端协议不等于 Windows Pro VM 具备受支持的 RemoteApp host 能力,并把完整 RDP 桌面定为唯一可靠基线——这个判断在同类文档中经常被搞错。

问题与建议

P1 — 硬件 Tier 定义在三份文档中互相矛盾(必须修)
docs/os-landscape-and-andromeda-architecture.md §3.2 定义:Tier 0 = QEMU/KVM 虚拟硬件、Tier 1 = 认证机型、Tier 2 = 社区验证、Tier 3 = 尽力支持、Tier X = 不支持;而 docs/product-development-plan.md §6.2 与 docs/research/hardware-drivers-and-migration.md §5 定义为:CI-0 = 虚拟平台、Tier 0 = Blocked、Tier 1 = Community、Tier 2 = Supported、Tier 3 = Certified、Tier 4 = Reference。同一个 "Tier 1" 在一份文档里是"认证机器",在另两份里是"社区验证";"Tier 3" 一边是"尽力启动"一边是"Certified"。该矛盾出现在 os-landscape 的**执行摘要(核心判断 5)**里,属于最显眼的位置。建议统一为 plan/hardware 文档的方案,并在 os-landscape 相应章节修订或加"已被 product-development-plan.md §6.2 取代"的标注。附带问题:os-landscape 的 YAML 示例用 compatibility_tier: 2(数字),hardware 文档 HCM 用 overall_tier: certified(字符串),schema 约定也应统一。

P1 — 桌面架构建议自相矛盾:自研 compositor/shell vs 复用 Plasma/KWin
os-landscape-and-andromeda-architecture.md 的"推荐架构一句话"是 "Wayland/自研 Shell",§6.1 表格"显示/媒体"行的自研重点写着"自研 compositor/shell、跨运行时门户",§12 "建议批准"第 3 条是 "Wayland + 自研 shell";而 product-development-plan.md §5.2 明确"首版采用 Wayland + Xwayland + KDE Plasma 6/KWin……也不自研 compositor",desktop-platform-and-distribution.md §1.1 结论 1 同样是"完整复用 KDE Plasma 6 / KWin,而不是自研 compositor"。读者若只读全景文档会得出与实际决策相反的结论。同样,os-landscape §2.1 把 "Windows VM + seamless window" 作为无条件的二级策略,而 plan §5.4 与 windows 研究已将 seamless window 降级为需过许可证/技术门的 Pilot。建议系统性地把 os-landscape 与后续文档对齐,或在文首声明其架构建议以 product-development-plan.md 为准。另外 plan Stage 2 交付物中的 "Andromeda shell alpha" 与 §5.2 "不自研 compositor" 的边界(shell ≠ compositor?基于 Plasma 定制到什么程度?)也应明确一句。

P2 — 若干外链疑似虚构或不可达,与 PR 描述的"验证"口径不符
PR 描述只声明"External URL syntax validated",但至少以下链接高度可疑:os-landscape-and-andromeda-architecture.md §13 的 "OpenAI Codex:Agent approvals and security → https://learn.chatgpt.com/docs/agent-approvals-security"(learn.chatgpt.com 不是 OpenAI 文档域名);reliability-update-ai-agent.md §2.3 及 §8.4 引用的多条 support.microsoft.com 链接缺少真实文章 slug/ID(如 .../windows/deployment/install-upgrade/delete-your-previous-version-of-windows、.../edge/export-passwords-in-microsoft-edge),格式像是拼出来的;desktop-platform-and-distribution.md §7.5 引用的 https://systemd.io/ROOTFS_DISCOVERY/ 需确认是否存在。既然这批文档的核心价值之一是"一手资料可追溯",建议合入前做一次真实的 HTTP 可达性校验并修复。

P2 — 硬件认证数量目标在两份文档间冲突
hardware-drivers-and-migration.md Phase H1(3–9 个月)承诺 "Certified 5–10 台 PC,Supported 20–30 台";而 product-development-plan.md Stage 2(第 19–36 周)只交付 "5 款 Tier 2 Supported 候选硬件",Stage 3(第 37–60 周,约 8.5–14 个月)才到 "10–15 款 Tier 2 Supported 机型和少量 Tier 3 Certified 候选"。硬件研究文档的节奏明显激进于产品计划,二者应以其中一个为准。

P2 — 12 周执行清单与整体计划缺少任何资源/团队规模假设
product-development-plan.md §12 要求在第 5–6 周同时打通 Steam/Proton、Flatpak、KVM Windows Workspace、完整 RDP、Office 往返测试、双系统迁移扫描器和 agent dry-run,§7.2 列了约 10 个必须覆盖的专业方向,但通篇没有人数、预算或"若只有 N 人则砍掉什么"的假设。这份计划对一个大团队是紧凑的,对小团队是不可行的;作为"可执行产品计划",建议补一节资源假设与按团队规模的降级方案,否则里程碑承诺无法评估可信度。

P3 — 术语与编号类小错

• product-development-plan.md §5.7 标题写"'无缝切换'拆为四层",实际列出 Layer 1–5(第五层"安全共存与卸载")。
• §6.3 已明确规定 "HCM = Hardware Compatibility Manifest……capability 不作为另一种 manifest 名称",但 os-landscape-and-andromeda-architecture.md §3.2 仍使用 "Hardware Capability Manifest",违反了自己定的术语规则。
• product-development-plan.md §3.3 "北极星任务"列出 10 项,而 Stage 0 交付物写 "20 个北极星任务"(os-landscape Phase 0 也是 20 个),数量对不上。
• os-landscape §10 硬件成功指标写 "suspend/resume 1000 次循环成功率",与 plan §10.2 的 100/500 次发布门未对齐(实验室跑 1000 次可以,但作为"成功指标"应与发布门统一口径)。

P3 — 对话残留与悬空承诺
os-landscape-and-andromeda-architecture.md §7 写"用户后续会提供具体列表;在此先建立归类框架"——这是聊天上下文的残留物,不应出现在仓库文档中;且 §14 承诺的 windows-pain-points.md 没有出现在 product-development-plan.md §13 的 16 份后续规格清单里,该任务事实上被丢失了。建议改写措辞并把 pain-points 文档补进 §13 或明确取消。

P3 — 时效性强的上游状态声明建议加"需复核"标记
如 hardware-drivers-and-migration.md §1.1 "NVK 已是 Vulkan 1.4 conformant,并覆盖 Kepler 至 Ada 以及消费级 Blackwell"、desktop-platform-and-distribution.md 对 GNOME 50/Plasma 6.4/COSMIC Epoch 1(2025-12-11)的描述——这些结论随上游快速变化。research/README.md 已有"检索日期 + SBOM 锁定"的好规则,建议对这类硬件/驱动覆盖声明再统一加上"进入 Adopt 前须按当日上游状态复核"的显式标记。

结论

Request changes — 内容质量很高、方向判断可信,但 os-landscape 与产品计划之间的 Tier 定义冲突和"自研 vs 复用 Plasma/KWin"矛盾出现在执行摘要与"建议批准"清单这类会被直接引用的位置,合入前必须消解;其余为可快速修复的一致性与链接问题,修完即可合并。

---

Review by Claude Code