--- description: Ailoha iOS 前端递归架构、问题目录与重构决策控制面入口 status: request_changes updated: 2026-08-28 sources: - repo://ailoha-agent-iOS@5e6ac6e41c53780c85808c92290d2bd38f809123 - repo://ailoha-agent-iOS@0b90745ed21438b194f8f9401a47d012cdbe66e5 - repo://ailoha-agent-iOS@6922f359ad08da70242e4ec0c5c4a1486bc2908d - brain://reports/ios-frontend-refactor-map/current-main-accessibility-runtime-baseline-2026-08-28.md - https://reports.cubxxw.com/ios-frontend-refactor-map/ - figma://UR45i9TtpX95auUs46rsHL/2391:25876 - feishu://wiki/OPTZwOQC7ilug3klEPtca8Drnfs - https://app.notion.com/p/3c9a444a6c0080cdab0fc0d7e72f2bd1 - https://app.notion.com/p/3c9a444a6c008109a147d24a3163f227 - https://app.notion.com/p/3c9a444a6c0081babcb9efde51d39619 - https://app.notion.com/p/3c9a444a6c008132a3b9e86536e30bb2 - https://app.notion.com/p/3c9a444a6c00815c8cb1d9807f49dce8 confidence: high sensitivity: internal --- # Ailoha iOS 前端递归架构与重构地图 > **Revision 门（2026-08-28）**：当前完整架构已经固定在 clean snapshot `main@6922f359ad08da70242e4ec0c5c4a1486bc2908d`；[current main 递归架构](current-main-recursive-architecture-2026-08-28.md)、[首启与登录前运行基线](current-main-runtime-baseline-2026-08-28.md)、[启动视觉就绪基线](current-main-startup-visual-readiness-baseline-2026-08-28.md)、[长对话单行更新基线](current-main-chat-update-performance-baseline-2026-08-28.md)与[可探索图](current-main-architecture.html)共同组成当前事实入口。`5e6ac6e` 继续保留为历史机制地图，`main-delta` 只解释 Release → main 的变化，不再承担 current architecture。当前 Release 仍是 `0b90745`，本地 Wave 0 仍只是候选。 > **跨电脑入口（2026-08-28）**：[打开公开交互地图](https://reports.cubxxw.com/ios-frontend-refactor-map/)。已重新发布并复验：总页、Onboarding 合同、登录可访问性运行证据、Talent Signal 实施总包与机器审计资源均可直接访问；[Notion 登录入口可访问性完整案例](https://app.notion.com/p/3caa444a6c0081e692bcf325ba887fdb)内嵌四张 current-main 状态截图，并固定 8 图 3 视频验收。[Notion Onboarding 完整案例](https://app.notion.com/p/3c9a444a6c008104b1cfe11821237e08)、[Notion Ailoha 灵动岛合同对照及 12 图验收](https://app.notion.com/p/3c9a444a6c0081cb8228d9c2ec4e3944)与[Notion 单卡/多卡、锁屏披露共同决策页](https://app.notion.com/p/3c9a444a6c00815c8cb1d9807f49dce8)可供另一台电脑直接执行。独立 Archify 图的 390 px 顶部工具栏会裁掉 Theme 与部分 Style 控件，正文和总页内嵌图仍可读；窄屏修复前建议桌面打开独立图。公开入口解决阅读与交接，不把本地测试、独立审查、合并、Release 或生产验证混成一种完成状态。 ## Outcome 把 `main@6922f359` 的完整代码树、`5e6ac6e` 历史快照、Figma 与飞书产品文档编译为同一套可递归展开、可追溯、可做重构取舍的控制面。它回答四个问题：当前 main 如何运行、架构从历史到现在怎样变化、哪些机制可能影响用户或生产可信度、如何在不中断产品循环的前提下演进。 ## 2026-08-24 可理解性诊断 **Broken invariant**：一个以“找前端问题并决定怎么解决”为入口的控制面，应让目标读者在 5 分钟内完成 `用户/生产症状 → 触发条件 → 因果机制 → 当前状态 → 第一修复动作 → 验收`；当前页面不能稳定支持这条路径。 - `fact`：使用者明确反馈“看不懂、无法理解、也不知道怎样解决”。当前 `index.html` 同时承载架构地图、28 个问题、39 条攻击性审查记录、Wave 0 执行状态、性能优先级、AI 门禁、三源对齐和 17 个证据入口；“全部问题”位于执行、架构和方法之后。页面把基线、last exact、current candidate、local pass、independently closed 与 production unknown 放在同一阅读层，并让 `P0` 同时表示事故严重度、历史问题等级和建议立即投入的工作。 - `fact`：`check_report.py` 当前只验证文件、问题 ID、链接、必需章节、敏感值形状和性能清单存在性；它通过只能证明包结构完整，不能证明读者理解或能选择下一步。 - `inference`：页面的实际目标函数是“审计完整、证据可追溯、AI 不越权”，不是“帮助产品、iOS 工程师或新人快速定位并解决一个前端问题”。标题中的“前端”实际覆盖整个 iOS 客户端控制面，包括账户、日志、跨进程、EventKit、CI 与 Reviewer trust；这与通常按页面、用户旅程和可见症状理解的“前端问题”不一致。 - `inference`：当前递归架构主要提供组件/owner 清单；问题卡主要提供技术机制与代码锚点。两者之间缺少按用户场景组织的因果脊柱，也缺少可执行的 owner、首个动作、依赖、完成定义和当前阻塞，因此读者知道“有很多风险”，却无法判断“我现在从哪一个开始”。 - `hypothesis`：如果先按读者任务拆成 `Frontend Problem Finder`、`Client Causal Architecture`、`Refactor Execution Ledger` 三个表面，并让每条问题采用统一的六步因果卡，目标读者可在 5 分钟内正确选出一个问题、复述其机制并指出第一验证动作。用产品、熟悉 iOS 的工程师、新成员各 1 人完成同一组任务；任一角色失败即反证该信息架构已足够。 最小修订是不删证据，只重排入口：首屏只显示用户可见问题、生产保护问题、推荐下一项和“为什么现在”；把历史审查轨迹、方法与 receipt 移到附录。完整修订则拆分三个表面，并把架构视图从组件库存改为 `触发 → 状态变化 → 边界调用 → 失败机制 → 用户结果 → 修复不变量` 的因果流。新增质量门应验证任务完成率，而不只验证章节和链接存在。 ### 2026-08-28 冷读验证器 `fact`：[5 分钟团队冷读评测器](coldread-runner.html) 已把上述 hypothesis 固定成可执行协议。产品、iOS 工程师和新人各完成一场；计时包含浏览与作答。每人必须选中一个真实 P0/P1，并用原话覆盖问题定位、现场症状、因果机制、revision 身份、责任人/第一验证动作、反证/未知六项。超时、任一项不成立，或把本地候选说成已合并/上线、把目标图说成当前事实，都会失败。 `fact`：评测器只收匿名编号、角色和回答，使用命名空间隔离的浏览器本地存储，不向服务器发送参与者数据；支持 JSON / CSV 导出，并对 CSV 公式注入做前缀保护。固定基线是 historical `5e6ac6e`、Release `0b90745`、main `6922f35`。 `boundary`：工具通过自动合同检查，只证明协议与界面可执行。当前真实结果仍是产品 `0/1`、iOS `0/1`、新人 `0/1`；在三场真实原话和主持人评分产生前，不能把“页面可用”写成“团队已理解”。三场全部通过也只能称形成性冷读门通过，不能外推为整个团队或未来 revision 永久通过。 ## 2026-08-27 七个研究入口 `fact`：用户将前端重构的上游调查入口明确为七类；后续问题、方案与讨论都应标明自己从哪些入口产生，而不是把入口、问题领域和任务状态混成同一个字段。 - **产品手感**：亲自体验每个细节，记录用户场景、问题、原因与解法。 - **架构扫描**：从前端架构自上而下遍历代码、数据流和依赖，寻找系统性问题与解法。 - **Agentic E2E**：自动复现、测试和量化前端问题，并把解法固化为可回归用例。 - **工程体系**：搭建自动化、Evaluation 与 E2E 基础设施，让问题可以持续发现和验证。 - **Linear 历史**：迁移过去的问题，识别重复根因、未闭环事项与已有解法。 - **Onboarding**：从当前最重要的前端用户旅程切入，优先验证首次体验与价值呈现。 - **状态所有权**：从目前最复杂、最痛苦的区域切入，理清谁创建、持有、修改、同步和恢复状态。 `decision`：Notion 控制面采用双层分类。`研究入口` 是可多选的 provenance，回答“问题从哪里被发现、分析或验证”；`问题方向` 是单选的 downstream domain，回答“问题最终落在哪个领域”。主看板仍按问题方向分组，只在卡片上显示研究入口标签，避免形成七列重型看板。该合同的团队协作入口是 [Ailoha Frontend Refactor](https://app.notion.com/p/3c9a444a6c0080cdab0fc0d7e72f2bd1)。 `fact`：用户继续反馈旧子页面“描述太多、太抽象、根本看不懂”。以启动动画卡为例，按“产品规则 / 代码事实 / 候选证据 / 完成定义”组织，仍要求读者自己把现象、阻塞链和新旧设计拼起来。 `decision`：后续 Notion 问题卡标题直接写用户现象，正文先固定回答四个问题：**用户看到什么、代码怎么堵住、之前怎么设计、应该怎么设计**。主线用一条旧链路和一条新链路表达；当前状态与 Done 放在其后；commit、类名、测试数字和历史统一折叠。此规则已先应用到启动动画 `FR-2`，内部阅读合同通过，团队冷读仍待验证。 ## 2026-08-27 前端重构 Policy 的价值与优先级 `fact`：Notion 已有两个直接承接 Policy 的条目。P0 `FR-4` 要把 `e2e/cases` 变成可复现、可自动判定的重构安全网；P1 `FR-5` 要统一 iOS、Agent、Backend、Eval 的 Case、Run、Evidence 与 Review 链路。`FR-3` Onboarding、`FR-6` Dynamic Island、`FR-7` 多图联系人和 `FR-8` 日历翻页也分别涉及状态所有权、生命周期、输入输出基数、分页与缓存不变量，但它们应在各自问题卡内声明规则，不应升级成另一套独立平台。 `decision`：不新建一个 P0 “Policy 平台”。Policy 按成熟度拆成三层： 1. **P0 / FR-4：`RefactorSafetyPolicy v1`**。由 `change_class` 选择必须运行的 8–12 条关键旅程、oracle、hard gate 与 recovery 检查；Case 必须可移植、可隔离，并能比较 baseline 与 candidate。缺少必需 Case、fixture 或断言时直接阻止声称“可安全重构”。 2. **P1 / FR-5：跨仓合同**。在已有 `CaseDefinition / RunEnvelope / EvidenceBundle / GradeResult / ReviewRecord` 之外，显式增加运行前冻结的 `PolicySet`、`ExperimentManifest`，以及运行后的 `ReleaseDecision`；先并行设计合同，不阻塞 P0 建安全网。 3. **P2：受证据约束的自动演进**。只有 Case、Evidence、阈值和权限边界稳定后，才允许系统根据事故、回归和人工复核建议新增规则或调整 suite；机器不能自行降低 hard gate 或扩大外部权限。 `inference`：对前端重构，Policy 的直接价值是把“工程师记得跑哪些测试”升级为“改动类型自动编译为验证计划与放行决定”。最小链路是 `frontend diff → change_class → required cases/oracles → versioned evidence → release decision/recovery`。这比先建设通用 Policy Engine 更接近当前瓶颈，也能让旧代码删除具有证据边界。 `verification`：任选一次 Onboarding 状态所有权改动，系统应自动选中登录、权限、冷启动和恢复 Case；任一必需 Case 缺失或 hard gate 失败时不得生成通过决定；通过产物必须绑定 Case/fixture 版本及 iOS、Agent、Backend、Eval revision。若仍依赖人工记忆挑 Case，或证据无法还原运行环境，则 Policy 尚未生效。 `external projection`：经用户授权，Notion `FR-4` 已改名为“有 39 个 E2E case，前端重构仍然没有可靠安全网”，并用 Onboarding 重构故事解释 P0 安全网、最小 Policy、首批 8–12 条旅程、非目标与 Done；`FR-5` 已改名为“一次前端测试会留下四套对不上的结果”，并把跨仓合同重写为八个通俗问题，显式加入 `PolicySet / ExperimentManifest / ReleaseDecision`。完整基线、数量和技术字段保留在折叠证据区，没有改变 P0/P1、状态或 owner authority。 `usability verification`：两页均已通过 Notion fetch 回读；callout、heading、toggle 与跨页链接存在，旧四列表被移除。公开阅读页在 1440 px 与 390 px 视口均无横向溢出；受数据库页固定属性区影响，首个场景在桌面约 857–885 px、窄屏约 3026–3188 px 后出现。隐藏属性会改变整个任务库布局，本轮未扩大授权范围。当前只能称内部阅读合同通过，团队冷读与真实上手体验待验证。 ## 先看结论 在 `5e6ac6e` 历史快照中，客户端不是“缺少 MVVM”，而是存在多个并行控制面：`AilohaApp`/`RootPage`/`MainTabPage` 负责全局组合与路由，`ServiceLocator` 与大量 `.shared` 同时提供依赖，Task、Home、Contact、Calendar 又各自维护局部真相。这个结构已经承载了复杂的 Task/Chat、ARPC、Live Activity 与扩展恢复链路，但账号作用域、状态所有权、设计 token、可访问性和迁移删除条件没有形成统一契约；这些结论迁移到 Release/main 前必须逐项复核。 本轮最优先的两条风险不是文件长度： 1. **账号切换隔离**：正常登出没有重置联系人、日历和多个进程级缓存；联系人明确保留旧数组直至新请求返回，日历缓存可命中五分钟，而且 `clearCache()` 本身不清空已发布的 `events`。这构成跨账号旧数据短暂或持续显示的高置信风险。 2. **日志数据最小化**：截图 update token、APNs token 与语音服务 API key 的前缀会进入主 App 的持久日志与周期上传；现有 redactor 只识别 Bearer、完整 JWT 和特定 credential key，不识别这些已截断前缀。 其余问题按四条演进主线收口：建立 AccountScope 与 typed composition root；把功能状态归还给明确 feature owner；统一设计 token 与原生可访问语义；建立 app-level 行为测试和迁移删除门禁。 ## 2026-08-12 执行覆盖 Wave 0 已在固定基线派生的隔离 worktree 中形成未提交 remediation 候选：hosted `AilohaTests`、真实 HTTP pre-send/direct cancel、reset tombstone、journal quarantine、Calendar unknown-outcome transaction、system-effect compensation、Screenshot writer drain、strict device revoke/explicit Live Activity owner 与仓级 credential source→known-sink guard 已进入同一保护边界。Last verdict `6faf7396…9b86a` 为 `request_changes`（0 P0 + 6 P1）；它进一步证明旧 credential83/83 会被共享 cache 的无关 schema failure 误杀，因此旧172/172总数失效。Current successor 已以 immutable cache、target-diagnostic attribution、全 fact source binding 与 closure/callable/method-value 边界重跑 credential90/90；合并 account/effect89/89 后的179/179仍只是Chief-local枚举证据。完整Lightweight通过，88-file `2fadb1c1…95e0`已冻结，独立 verdict 尚未产生。Hosted65/65与ARPC6/6继续保留。 独立攻击先后攻破旧候选的 pre-send、logout session、Calendar/system effect、journal、late Activity owner、Screenshot writer、跨文件 credential return 与 guard receipt attribution。Calendar logout/reset P1 已独立关闭；SEC-001 仍被 last exact 的 6 个 P1 阻断。Current successor只有本地定向证据，不能自批。离线/过期登出 recovery UX 和后端 canonical Live Activity owner schema继续作为明示未决策。详见 [Wave 0 Implementation Overlay](wave0-implementation.md)。 ## 阅读顺序 1. [current main 递归架构](current-main-recursive-architecture-2026-08-28.md) 与 [可探索图](current-main-architecture.html)：先看当前产品循环、四个 Xcode 产品、运行脊柱、状态 owner、跨进程合同和测试边界。 2. [首启与登录前运行基线](current-main-runtime-baseline-2026-08-28.md)：看 clean build、首次权限弹窗、登录页真实截图、最大 Dynamic Type 和 shared scheme 测试失败；它把静态判断变成第一批运行事实。 3. [启动视觉就绪基线](current-main-startup-visual-readiness-baseline-2026-08-28.md)：看五次启动视频、登录动作可见/可访问终点、固定品牌 gate 的根因、最小声明式改法和截图/视频验收矩阵。 4. [登录入口可访问性运行基线](current-main-accessibility-runtime-baseline-2026-08-28.md)：看最大 Dynamic Type 未进入品牌字体、Reduce Motion 下视频仍播放、三个核心动作的运行语义基础，以及给新 Agent 的 8 图 3 视频验收合同。 5. [完成度与 Revision 审计](completion-and-revision-audit-2026-08-27.md)：再判断结论属于 Release、main 还是本地候选，以及哪些旧结论已经失效。 6. [P0/P1 Revision Claim Ledger](revision-aware-claim-ledger-2026-08-27.md)：逐条看问题在哪条代码线成立、什么能让它失效、责任角色和当前 verifier 缺口。 7. [Talent Signal → Ailoha 迁移证据账本](talent-signal-to-ailoha-transfer-ledger-2026-08-28.md)：看六类迁移问题能先验证什么、不能外推什么与十张 Talent Signal 系统截图。 8. [current main Live Activity 合同对照](current-main-live-activity-transfer-contract-2026-08-28.md)：把 current code 的已有 guard 与七个 P0 合同原子分开，固定 12 张 Ailoha 状态截图、三段未剪视频和另一台电脑的 Agent 执行顺序。 9. [Live Activity 产品政策决策包](current-main-live-activity-product-policy-decisions-2026-08-28.md)：用 current main 事实拆开单卡/多卡、D0–D4 锁屏披露、直接动作边界，附可编辑共同决策画布、10 图与 2 视频验收。 10. [交互式控制面](index.html)：按架构层级、功能域、严重度、事实类型与执行状态探索。 11. [Release → main 变化说明](main-delta-architecture-2026-08-27.md) 与 [可探索图](main-delta-architecture.html)：解释 Chat 收敛、Home / Onboarding 运行脊柱、六个新 Package 与 token 生成链怎样出现；它不是完整 current architecture。 12. [5 分钟团队冷读评测器](coldread-runner.html)：用三类真实读者验证能否定位、复述并行动。 13. [Wave 0 实现覆盖](wave0-implementation.md)：checkpoint、验证收据、待决策与 recovery。 14. [5e6 历史递归架构](recursive-architecture.md)：从用户循环下钻到当时的运行组件、状态 owner、数据流与热点。 15. [产品/设计/代码对齐](product-design-alignment.md)：按 `main@6922f359` 纠正 Chat、三 Tab、12-route Onboarding、主题与 token 迁移事实；Figma fresh read 仍受 View-seat 限额阻断，因此设计生命周期明确为 unknown。[机器审计 JSON](evidence/current-main-product-design-alignment-2026-08-28/product-design-alignment-audit.json)只证明代码侧合同；跨电脑冷读与验收从 [Notion 控制面](https://app.notion.com/p/3caa444a6c0081d987a0dc871c7e5688)开始。 16. [Onboarding 设计合同调查](current-main-onboarding-design-contract-gap-2026-08-28.md)：只显示姓名、却沿用旧三题问卷 version 的根因、DEV 裁决与 5 图 2 视频验收。 17. [问题目录](problem-catalog.md)：适当颗粒度的问题、机制、证据、验证与修复边界。 18. [重构方案](refactor-strategy.md)：保守、演进、目标三层方案及迁移顺序。 19. [可访问性表面图](accessibility-surface-map.md) 与 [性能风险审计](performance-risk-audit.md)：前者拆开 `5e6` 历史计数，并加入 current-main 登录运行 successor；后者只用 V2 当前链解释 main 性能，不再用已删除 V1 混淆根因。 20. [性能工程认知与改造清单](performance-engineering-checklist.md)：把风险继续拆成用户场景、工程认知颗粒、改法和分层测试门；Chat 的独立执行合同见[长对话单行更新基线](current-main-chat-update-performance-baseline-2026-08-28.md)，Contact 的“改姓名却重算 Notes”页面证据、四个最小颗粒与 0-update Gate 见[联系人字段更新基线](current-main-contact-detail-update-performance-baseline-2026-08-28.md)与[跨电脑 Notion 总包](https://app.notion.com/p/3c9a444a6c00812699c0f17e0d631963)。 21. [覆盖账本](coverage-ledger.md) 与 [证据索引](evidence-index.md)：覆盖账本保留为 `5e6` 历史扫描方法，current-main 结论以递归架构、Revision 审计和 claim ledger 为准。 ## 历史固定事实快照（`5e6ac6e`，不可冒充当前 Release/main） - 观察时间：`2026-08-11T21:28:44+08:00`。 - iOS 修订：`feat/revert-main-latest-two@5e6ac6e41c53780c85808c92290d2bd38f809123`，观察时工作区干净；相对当时的共同祖先 `main@09afd352842e900d176124ff73a20313ee39a0fb` 为 ahead 7。 - 工程基线：4 个产品 target、0 个原生 app test target、6 个本地 Swift Package；共享 scheme 引用不存在的 `ailoha-assistant-sharedTests.xctest`。Wave 0 本地 overlay 新增 1 个 hosted test target 并修复 scheme，但尚未集成。 - 代码：656 个生产 Swift 文件；文件行数、singleton、NotificationCenter 与 UserDefaults 计数只作定位信号，不单独构成问题。 - Figma：可验证节点为 Onboarding 问卷 `2391:25876`；View seat 的后续枚举达到工具调用限制，未据此推断文件没有本地变量或组件。 - 飞书：当前 iOS 索引及十个子文档最后编辑时间均为 2026-06-22；文档内容是产品/协作事实，不覆盖运行代码事实。 ## 边界与状态 - 2026-08-11 调研阶段只读 `ailoha-agent-iOS`；2026-08-12 Wave 0 仅修改隔离 worktree，未修改 Figma、飞书、GitHub、Linear，也未 commit/push/PR/merge/release。 - `5e6ac6e` 历史态与目标态 Archify 图的规格校验收据与 Wave 0 代码批准分层；图可通过不会抵消实现审查的 `request_changes`。 - 性能结论区分**代码/机制风险**与**页面运行事实**：Contact、Chat 已有 Debug Simulator 页面复现，Calendar、多图已有机制实验；没有真机 Release ETTrace/Instruments 与生产分布就不声称线上用户已经卡顿。 - 可访问性已有 current-main 登录页 Simulator 的 Dynamic Type、Reduce Motion 与运行语义树局部收据；spoken VoiceOver、Release 语义树、账号内核心旅程与真机仍未验证。 - 目标架构、优先级和删除旧路径都需要产品/工程 owner 决策。 - 调研/Harness 与页面方法合同独立审查已批准；Wave 0 last exact `6faf7396…9b86a` 的实现 verdict 是 `request_changes`（0 P0 + 6 P1）。页面明确把失效历史收据、本地 remediation、protected CI、真实系统 replay 与集成批准分层。 ## 建议的下一决策 下一决策不是自动进入 Wave 1，而是冻结当前 exact manifest，交同一独立 Reviewer 重放 pre-send、session revoke、Calendar/system owner、durable recovery、notification/Activity owner 与 cross-file return-taint 反例；同时用后端合同确认普通 logout 的 device mapping revocation。任何本地 PASS 都不会自动授权 commit、PR、merge 或发布。