---
description: Ailoha current main Live Activity 从现有补丁级能力到可声明状态、身份、顺序、恢复、隐私与截图验收合同的冷读实现包
status: request_changes
updated: 2026-08-28
sources:
  - repo://ailoha-agent-iOS@6922f359ad08da70242e4ec0c5c4a1486bc2908d
  - brain://reports/ios-frontend-refactor-map/evidence/current-main-live-activity-transfer-contract-2026-08-28/live-activity-transfer-contract-audit.json
  - brain://reports/talent-signal-dynamic-island-pilot-2026-08-27/implementation-contract.md
  - https://app.notion.com/p/3c9a444a6c0081cb8228d9c2ec4e3944
  - https://developer.apple.com/documentation/activitykit/starting-and-updating-live-activities-with-activitykit-push-notifications
confidence: high
sensitivity: internal
---

# Ailoha 的灵动岛不是少一套好看的 UI，而是少一份所有入口都遵守的合同

<!-- brain-capture:ios-frontend-current-main-live-activity-transfer-contract -->

> **一句话结论：** current main 已经有精确 `taskId + widgetId + activityId` 收卡、App Group pending-end 补偿、observer lease、stale 兜底等不少扎实修复；但“谁负责向用户汇报、状态是什么意思、允许几张卡、哪个事件能覆盖哪个事件、杀进程后谁收尾、锁屏能透露什么”仍分散在多个 owner 中。Talent Signal 可以先验证其中的状态投影、系统构图和证据方法，但 Gate 1 仍是 `0/8`、ActivityKit 仍未实现，所以它现在是候选实验，不是 Ailoha 的已验证答案。

跨电脑执行入口：[打开 Notion Agent 执行版](https://app.notion.com/p/3c9a444a6c0081cb8228d9c2ec4e3944)。机器可复验事实见 [Live Activity 合同审计 JSON](evidence/current-main-live-activity-transfer-contract-2026-08-28/live-activity-transfer-contract-audit.json)，执行脚本见 [audit_contract.py](tools/live-activity-transfer-contract-audit/audit_contract.py)。

## 先说人话：用户遇到的到底是什么

一个典型断点不是“岛长得不好看”，而是：

```text
岛告诉用户“需要补充信息”
  → 用户进入 App，旧卡被正确收掉
  → 用户回复，App 内进入 processing
  → 用户离开 App，后台任务还在跑
  → 没有共同规则决定 Live Activity 是否重新接管
```

另一个断点是：系统表面可以同时存在多张非终态任务卡，但客户端注册链只保存一个 mutable update token 和一个 observer。代码对“单卡抢占”与“多卡并存”都没有形成完整产品合同。

这两件事最后都会变成用户的同一句话：

> **这件事现在还活着吗？做到哪一步？要不要我回来？我点的还是刚才那一件吗？**

## 这次调查证明了什么

### 已证明的 current-main 事实

- 固定 revision 为 `6922f359ad08da70242e4ec0c5c4a1486bc2908d`；本页审计涉及的十个文件均与该 revision 一致。
- `ActivityStatus` 是 7 个值的一条扁平枚举；`ContentState` 有 21 个字段，但没有一等的 `attention`、`freshness` 或业务 `eventRevision`。
- 共享属性和 Widget 中至少有 17 个直接按 status 投影的 switch；View 仍承担大量业务分支。
- compact 在 fresh analyzing / processing 且有 `startedAt` 时显示正计时；stale 后换成灰色进度环；expanded 和 Lock Screen 更偏向阶段文字。
- `continueTask()` 会置 processing、写本地 operation 并发 ARPC；这个函数内没有创建或更新 Live Activity。
- 当前代码不会全局压成一张非终态真卡；但 `DeviceRegistrationService` 只有一个 `updateToken`、一个 `updateTokenTask`，HTTP 注册请求也只有一组 scalar `update_token + activity_id`。
- `LiveActivityEnder` 已支持 `task + widget + activity` 精确匹配，也保留按 task 的 legacy fallback；in-process 去重与 App Group pending-end 队列都存在。
- pending-end 队列有 300 秒 TTL 和 40 条上限；它是值得保留的恢复支点。
- 自动过期由 App 进程每 5 秒轮询，`firstSeen` 只在内存中；代码注释明确承认 App 挂起或被杀时不推进。
- `ContentState` 可携带 rich `extractedData`；Widget 直接读取标题、副标题、日历/联系人等字段。当前 Widget 源里没有 `privacySensitive` 或 `redacted` modifier。这个事实不能单独证明泄露事故，但证明“展示最少什么”还不是独立、可审计的 code-level projection。
- Apple 的 APNs `aps.timestamp` 可以帮助系统选择较新的**远端 push**；current iOS `ContentState` 没有一条可同时约束本地 update、App Intent、前台 reconcile 与远端 push 的业务 revision。因此“远端 push 有 timestamp”和“跨 owner 有统一单调合同”不是一回事。

### 已有的好能力，不要在重构中误删

- 精确 instance / widget / task 匹配和 legacy fallback 的边界已经写清。
- confirmed success 会先显示约 2.5 秒，再由可取消 task 收卡。
- App Group pending-end 能覆盖 Extension 进程一时看不到 Activity 的情况。
- `ActivityStateObserverLease` 用 generation 防止旧 observer 回调清掉新 owner；mutation test 能把 ID-only、wrong-owner、terminal bypass 等错误打红。
- idle placeholder 与真实 task Activity 已经区分 owner，并有集中 reconcile。
- Widget decode 对未知 action、未知 payload 和历史字段已有容错 guard。

目标不是“重写一切”，而是把这些局部正确性放进一个更高层的声明式合同。

## 最小因果链

```text
业务执行事实、用户注意力、新鲜度、卡片身份、结束恢复、锁屏披露
被分散在 status / View / Intent / App service / token registration / timer 中
  ↓
每条路径各自修复自己见过的竞态
  ↓
局部 guard 越来越强，但没有一个跨 owner 的 allowed transition + identity + finality 合同
  ↓
新增状态或入口时，必须同时修改多处 switch、token、end、route、expiry 和文案
  ↓
很容易出现“App 内已经 processing、岛没有接管”“系统允许多卡、注册只有一槽”
  ↓
测试只能证明若干已知分支，难以证明整条用户连续性
```

## 七个恰好能独立解决问题的 P0 原子

这些原子按依赖顺序排列。每个原子都能单独写失败测试、实现、回滚和验收；不要把它们一次塞进一个“大重构” PR。

### P0-01｜表面接管：离开 App 后由谁继续汇报

**问题与上下文**

`OpenTaskDetailsIntent` 收旧卡是正确的；但用户在 App 回复后，`continueTask()` 只更新 App 内 processing 和 ARPC，不会让系统表面重新接管。现在的边界按“从哪个入口来”划分，不是按“用户是否仍在看、任务是否值得跟踪”划分。

**怎么改**

先做一个纯函数 `AttentionSurfacePolicy`，输入只包括：

```text
appVisibility + currentRouteOwnsTask + execution + attention + elapsedClass + userPreference
```

输出只能是：

```text
appOwnsPresentation | liveActivityOwnsPresentation | noSystemSurface
```

`continueTask`、App scene phase、remote update 和 terminal 都调用同一策略；短任务设抑制窗口，避免用户刚离开就闪出一张立刻消失的卡。

**为什么这样改**

它只解决“哪个表面负责”，不同时重写 ARPC、View 或后端。产品可以直接讨论接管阈值，工程可以用同一 fixture 验证 App → 岛 → App 的连续性。

**Talent Signal 能先验证**

验证“running 时可以离开，review 时明确叫用户回来”的理解和构图。不能证明 Ailoha `continueTask`、ARPC 或 App Group 已闭环。

**通过标准**

- 同一 task 的 App 可见 → 离开 → compact / expanded / Lock Screen → 回到 App，是同一 operation identity。
- 短任务不闪岛；超过阈值且仍需跟踪的任务只出现一张卡。
- 回 App 后由 App 接管，旧系统表面不继续说另一套话。
- 终态、取消、登出、账号/环境切换后没有残留。

### P0-02｜语义投影：execution、attention、freshness 分开

**问题与上下文**

`analyzing / processing / pendingConfirm / needsMoreInfo / success / failed / idle` 混合了执行阶段、用户注意力、结果和聚合策略。一个新状态会扩散到 17 个 status switch 附近，View 很容易变成第二个业务状态机。

**怎么改**

先建立共享 canonical state，不直接改所有 UI：

```text
execution = preparing | running | completed | partial | failed | cancelled | unknown
attention = none | observe | review | resolve
freshness = fresh | stale
```

Ailoha 自己的 `pendingConfirm / needsMoreInfo / idle` 通过 projector 映射，不直接复制 Talent Signal 枚举。projector 输出固定的 `title / subtitle / glyph / primaryAction / route / disclosureClass`；App 和 Widget 只消费 projection。

**为什么这样改**

业务事实、是否叫用户回来、数据是否陈旧可以分别测试。stale 不再冒充 failed，completed 也不自动等于“用户不必审阅”。

**Talent Signal 能先验证**

它可以用更小的状态集合证明正交模型是否更易懂，以及 compact / expanded / Lock Screen 是否同义。不能替 Ailoha 决定每个 Widget action 的真实映射。

**通过标准**

- 每个允许 tuple 只有一份 projection；非法组合构造即失败。
- App 与 Widget 用同一 fixture 输出相同标题、注意力、route 和 disclosure class。
- `stale` 不改变 canonical execution；`unknown` 不显示完成、不开放危险重试。
- View 中新增业务状态判断必须被 lint / source guard 拒绝。

### P0-03｜时间表达：没有真实 ETA 时显示阶段，不显示假精度

**问题与上下文**

compact 正计时只说明“等了多久”，没有说明“现在在做什么”；stale 后又切成灰环。用户可能把数字理解成倒计时、性能承诺或卡死时间。

**怎么改**

把时间能力声明成三类：

```text
phaseOnly | determinateProgress(completed,total) | trustedETA(deadline,confidence)
```

没有真实总量/ETA 时，compact 用阶段 glyph，expanded / Lock Screen 用短阶段文案；超时只表达 `Taking longer than usual` 或等价语义，不画确定比例。

**为什么这样改**

UI 不再从 `startedAt` 猜用户最想知道的信息。只有 producer 能证明的时间事实才能进入系统表面。

**Talent Signal 能先验证**

用 Gate 1 对比阶段方案和时间方案的五秒误读。Gate 1 仍是 `0/8`，所以当前不能宣布阶段方案已胜出。

**通过标准**

- 8 名目标用户至少 6 人五秒内说出阶段和是否要操作。
- 0 人把 running 误认倒计时、已联系候选人或确定进度。
- fresh → stale 后仍能复述“任务可能还在，更新延迟”。
- Reduced Motion、Always-On、灰阶下仍不只靠颜色或动效区分。

### P0-04｜身份与基数：明确单卡抢占或多卡寻址

**问题与上下文**

current main 可以保留多张非 success 真卡，但 token owner 是一个 scalar slot。这里不能继续靠“系统大概只会有一张”或“总拿 first/newest”维持。

**怎么改**

产品先二选一：

- **单注意力卡：** 声明优先级、抢占、排队、被抢占任务回到哪里；一台设备同一时刻只允许一个 system-surface owner。
- **多任务多卡：** token registry 以 `account × installation × environment × task × activityInstance` 为 key；每张卡分别 rotate、update、end、revoke。

不论选哪条，attributes、content state、deep link、telemetry 和 end 都必须携带同一 opaque operation identity；旧 instance URL 不得结束新 instance。

**为什么这样改**

它把“系统展示策略”和“APNs 可寻址能力”放回同一合同，不再让 iOS 允许多卡、注册 API 却只记一个 token。

**Talent Signal 能先验证**

第一版只验证同一 task 重复 start 10 次仍是一个 instance，以及旧 URL fail closed。它不能替 Ailoha 决定全局单卡还是多卡。

**通过标准**

- 同 task 重复 start/update/end 幂等。
- 旧 token / URL / callback 不能改新 instance。
- 登出、账号和环境切换后，旧 instance 不可被新 session 接管。
- 若选多卡，两张卡能分别更新/结束；若选单卡，抢占和排队的结果可预测且有 UI 去处。

### P0-05｜事件顺序与终态：所有 owner 共用单调 revision

**问题与上下文**

Apple `aps.timestamp` 只解决 ActivityKit 远端 push 的“系统选择更新”问题；Ailoha 还存在本地 `activity.update`、Widget Intent、前台 reconcile、success hold、expiry 和 remote push。`ContentState` 没有共享的业务 revision，因而没有一条可审计规则说明“晚到 running 能否覆盖 completed”。

**怎么改**

定义 `eventRevision` 与 allowed transition：

```text
identity 相同 && incomingRevision > appliedRevision && transitionAllowed
```

terminal 只允许同 revision 幂等重复或更高 revision 的受控纠正，禁止回到 running。每个 producer 记录去敏的 `identityHash / from / to / revision / source / decision`；APNs 仍填合法的 `aps.timestamp`，但它不是业务 revision 的替代品。

**为什么这样改**

它能把 remote push、local intent 和 recovery 放到同一 finality 规则里；测试不必靠 sleep 猜“谁最后写赢”。

**Talent Signal 能先验证**

Atom A 只能验证 projector 和同实例本地更新；Atom B 才能验证 APNs 重复、乱序、延迟与 terminal monotonicity。未做 Atom B 前不能迁“后台可靠”结论。

**通过标准**

- `r10 running → r12 completed → r11 running` 最终保持 completed，并留下 stale-event receipt。
- 重复 r12 不产生第二个副作用。
- local end 与 remote late update 竞争时，终态不回退。
- eventRevision、APNs timestamp、展示用 updatedAt 三者职责在合同和日志中分开。

### P0-06｜恢复与结束：不要把 App 运行时轮询当生产生命周期

**问题与上下文**

current expiry 在 App 运行时有用，但 App 杀死后计时停止，重启还会重置 `firstSeen`。跨进程 action 的 pending-end 只保留 300 秒。它们是本地兜底，不是完整的 backend finality。

**怎么改**

指定一个 lifecycle owner，明确：

```text
create → token registered → update → stale → exact readback → end → revoke
```

本地 pending-end、observer lease 和 foreground reconcile 保留；生产终态由 durable backend event / outbox 或等价可恢复机制负责。App 冷启、回前台、账号/环境变化时做 exact reconciliation，不凭本地 timer 猜 completed 或 failed。

**为什么这样改**

把“UI stale”与“业务终态”分开。App 进程被杀时，任务仍能到正确状态；本地补偿只负责可达性，不再承担业务真相。

**Talent Signal 能先验证**

Atom A 验证 UI stale 形态；Atom B 才验证 backend restart、push 丢失、App kill、remote start race 和 exact readback。

**通过标准**

- App kill 后仍能由远端到达终态并结束。
- push 丢失时 stale 明确，恢复后 exact readback 修正。
- 用户收卡不等于取消服务器任务，除非有独立 cancellation contract。
- logout 先本地收卡并写 revoke tombstone，网络恢复后补偿撤销。

### P0-07｜披露：锁屏只消费最小 disclosure projection

**问题与上下文**

`ContentState.extractedData` 能承载日历、地点、联系人等 rich data；Widget 直接读取其中一部分。技术上能显示，不等于锁屏、Always-On、通知预览或 VoiceOver 都允许显示。

**怎么改**

产品建立：

```text
taskType × locked/unlocked × notificationPreview × alwaysOn
→ allowed fields + replacement copy + accessibility label + deep-link class
```

未列字段默认拒绝。Widget 不接 raw domain model，只接 `LiveActivityDisclosureProjection`；编码测试检查 allowlist 和 4 KB 上限，日志、telemetry、截图、VoiceOver、deep link 用同一政策。

**为什么这样改**

隐私不再依赖某个 View 作者“记得别显示电话”。产品可以逐 task type 做选择，工程能自动反向扫描漏网字段。

**Talent Signal 能先验证**

它适合先证明 zero-PII research status、opaque identity 和冷读不误解；不能把 Talent Signal 的零 PII 默认复制成 Ailoha 所有任务的产品决定。

**通过标准**

- payload、渲染、VoiceOver、log、telemetry、receipt、deep link 全部通过同一 allowlist。
- 锁屏与 Always-On 不出现未批准的人名、公司、电话、邮箱、地点或正文。
- 账号/环境错误或旧 instance deep link fail closed。
- 新增 raw field 而未进入 disclosure matrix 时，编码/源审计必须红。

## Talent Signal 到 Ailoha 的证据边界

<table>
<tr><th>Talent Signal 通过后可迁</th><th>仍必须在 Ailoha 重放</th></tr>
<tr><td>五秒冷读方法、状态 projector 结构、ActivityKit 四种系统形态、opaque identity、截图元数据、未剪辑视频证据格式</td><td>Chat continue、ARPC 晚到事件、Widget action、App Group pending ledger、多账号/环境、单卡/多卡、Ailoha task-type 披露矩阵</td></tr>
</table>

当前证据等级必须保持诚实：

```text
Gate 0 = GO
Gate 1 = 0/8
selectedDirection = UNSET
Atom A implementation = NOT STARTED
system screenshots = 0/10
edge atlas = 0/4
uncut videos = 0/2
```

## Ailoha 迁回后的 12 张状态截图合同

截图只证明“系统当时画了什么”。身份、事件顺序和恢复必须同时附去敏 trace 与未剪辑视频，不能拿两张漂亮图替代因果证据。

| ID | 固定场景与必须看见 | 一票否决 | 配套事实收据 |
| --- | --- | --- | --- |
| `ALH-LA-01` | App 内从 needs-more-info 回复后进入 processing；旧 action card 已收 | 旧卡仍让用户重复操作；输入又可重复发送 | operation identity + App route + revision |
| `ALH-LA-02` | 离开 App 后，同 task 的 running compact 接管；阶段可在 2 秒内复述 | 闪现两张、正计时被认成倒计时、无 task 关联 | surface-policy decision + task/instance hash |
| `ALH-LA-03` | 同 instance 的 running expanded；阶段、是否需操作与 compact 同义 | compact / expanded 像两个任务；内容撞岛 | same instance + projection fixture |
| `ALH-LA-04` | running Lock Screen；只显示该 task type 批准字段 | 人名、公司、地点、电话、邮箱、正文越权出现 | disclosure class + allowlist result |
| `ALH-LA-05` | `needsMoreInfo + resolve` compact / minimal 与普通 running 不只靠颜色区别 | 看不出要回来；minimal 是裁切假图 | real ActivityKit capture + AX label |
| `ALH-LA-06` | `pendingConfirm + review` expanded 只有一个主动作，命中同 widget / instance | 多个主 CTA；命中另一张卡或只落首页 | route authorization + exact identity |
| `ALH-LA-07` | fresh → stale：仍说明任务可能在跑、更新延迟；不显示 failed/completed | stale 冒充失败；继续播放鲜活 timer / 假进度 | staleDate + last applied revision |
| `ALH-LA-08` | failed / unknown + resolve：文案可恢复，不提供危险重复提交 | 伪装成功；无 exact readback 就开放 retry | transition decision + retry policy |
| `ALH-LA-09` | completed / cancelled 终态短暂停留后收卡；终态文案与 App 同义 | 晚到 running 让卡片复活；重复 end 产生副作用 | r10→r12→r11 replay trace |
| `ALH-LA-10` | 两个 task 的政策结果：要么明确抢占/排队，要么两张分别更新结束 | 系统有两张、服务端只可寻址一张 | token registry / single-card policy receipt |
| `ALH-LA-11` | logout / account / environment switch 后系统表面清空；旧 link 安全 fallback | B 账号看到 A 卡；旧 link 结束新卡 | session generation + revoke/tombstone receipt |
| `ALH-LA-12` | 无 Dynamic Island 设备的 Lock Screen / banner fallback 仍能完成主流程 | 崩溃、空白、把无岛说成不支持 Live Activity | device/OS/build metadata |

每张截图必须附：

```text
caseID / sourceSHA / buildConfiguration / device / OS / locale / appearance
ReduceMotion / notificationPreview / alwaysOnEvidenceLevel
canonicalStateTuple / taskIDHash / activityInstanceIDHash / eventRevision
captureSource / expectedProjection / PASS|FAIL / reviewer / observedAt
```

`ALH-LA-01…09` 至少有一组来自同一 task、同一 instance、同一 build，并由未剪辑视频串起来。

## 三段未剪辑视频比效果片更重要

### `ALH-VID-01-attention-handoff.mov`｜45–60 秒

```text
needs more info 岛 → 进 App → 回复 → processing
→ 离开 App → 同 task compact → expanded → Lock Screen
→ review / resolve → exact route → end
```

片尾显示 revision、fixture/DEV/production 级别和“没有证明什么”。

### `ALH-VID-02-ordering-and-identity.mov`｜30–45 秒

固定注入 `r10 running → r12 completed → r11 running`，画面保持终态；再触发旧 instance link，不能结束新 instance。视频同时显示去敏 decision trace。

### `ALH-VID-03-recovery-and-session.mov`｜45–60 秒

运行中杀 App → stale / remote terminal / relaunch reconcile；随后 A logout → B login / environment switch，旧卡与旧 link 都不能进入 B。

20–25 秒效果片只能从这些原始收据裁切；不能后期画假岛、按钮、状态或转场。

## 自动测试与证据门

| 层 | 最小测试 | 通过定义 |
| --- | --- | --- |
| projector | 所有 legal tuple + illegal tuple | 同一输入输出稳定；非法组合 fail closed；App/Widget fixture 一致 |
| surface ownership | visible/hidden × short/long × attention | 同 task 至多一个 owner；短任务无闪岛；回 App 后无双重汇报 |
| identity/cardinality | repeat start 10 次、双 task、旧 instance | 结果符合显式单卡或多卡政策；旧身份不能触碰新卡 |
| ordering/finality | duplicate、out-of-order、late terminal/local end race | revision 单调；terminal 不回退；重复无第二副作用 |
| recovery | App kill、push loss、backend restart、offline logout | stale 诚实；exact reconcile；tombstone 可补偿 |
| disclosure | payload encode、VoiceOver、log/telemetry/receipt scan | 只含 allowlist；总量 ≤4 KB；错误也不泄露 |
| system UI | 12 张 Ailoha 图 + 10 张 Talent Signal 图 + atlas | 真 ActivityKit、无裁切、元数据齐全、同实例连续 |
| accessibility | VoiceOver、最大 Dynamic Type、Reduce Motion、Always-On | 关键语义可读；证据等级不夸大；不只靠颜色/动画 |

### 本次已跑的 current-main 收据

- `check_live_activity_lifecycle_v0.py`：PASS。
- `run_activity_state_observer_lease_tests.py`：production callbacks PASS；5 类 mutation 均 RED。
- `run_idle_live_activity_policy_tests.py`：PASS。
- `check_live_activity_details_navigation.py`：PASS。
- `check_task_creation_widget_handoff.py`：PASS。
- `check_widget_update_decode_tolerance.py`：PASS。
- `check_history_widget_original_tolerance.py`：PASS。
- `check_live_activity_permission_guide.py`：PASS。
- `check_idle_live_activity_policy.py`：**FAIL，不是已证明的 runtime failure。** guard 仍要求 `HomeTaskRackItem.swift` 直接调用 `recordCompletedTaskSuccess()`，而 current main 已把该调用移到 `HomeViewModel.swift:811`；业务调用仍存在，source guard 的 owner anchor 已陈旧。这条 guard 修复并重新变绿前，不能写“Live Activity 全套 source gate 通过”。

## 给另一台电脑上的 Agent：声明式实施顺序

1. 先复跑机器审计，确认目标 revision；若 SHA 不同，重新生成 evidence，不照抄行号。
2. 不改 UI，先建立 `OperationIdentity`、`CanonicalLiveActivityState`、`Projection` 和 transition table 的纯 Swift package / module。
3. 产品选择单卡或多卡；未选择前，不修改 token registry。
4. 为 P0-01…07 各写一个会红的最小测试；禁止用一条巨型 E2E 代替原子测试。
5. 保留 `LiveActivityEnder` 精确匹配、pending-end、observer lease 和 idle reconcile；通过 adapter 接入新合同。
6. Widget 改为只消费 projection；清除绕过 projector 的业务 status/action 判断必须有 source guard。
7. 先完成 Talent Signal Gate 1；通过后只实现 Atom A，产出 10 张系统截图、4 张 atlas、2 段原始视频。
8. 只有 Atom A 的具名判断可以进入 Ailoha UI；APNs / backend 结论等 Atom B 后再迁。
9. 在 Ailoha 隔离任务包中依次做 surface ownership、semantic projection、identity、ordering、recovery、disclosure；每个切片都可独立回滚。
10. 完成 `ALH-LA-01…12` 与三段视频后，再由独立 Reviewer 判断能否发布。

## 非目标

- 不在当前 `ailoha-brain` 任务里修改 iOS 业务仓库。
- 不让 Agent 在 Gate 1 前自己选 Talent Signal 视觉方向。
- 不把 Debug fixture、Simulator 或网页 mock 写成真实 backend / APNs 证明。
- 不借灵动岛重构顺手重写 Chat、ARPC 或所有 Task UI。
- 不把用户收卡等同于取消服务器业务。

## 完成定义

- [ ] Gate 1 是 8/8 有原始记录，且唯一方向明确；无人通过则保持 UNSET。
- [ ] Talent Signal Atom A 真实 ActivityKit 实现，`TS-LA-01…10` 为 10/10，atlas 4/4，原始视频 2/2。
- [ ] Ailoha 单卡/多卡与 disclosure matrix 由具名产品 owner 决定。
- [ ] P0-01…07 各有独立 contract test、owner、rollback 和证据。
- [ ] `ALH-LA-01…12` 为 12/12，三段未剪辑视频通过，身份与 revision trace 可对账。
- [ ] stale guard 已更新且 source gate 重新绿；不能把旧 anchor failure 隐藏掉。
- [ ] 独立 Reviewer 能冷读后复述：当前已有能力、真正缺口、Talent Signal 能证明什么、仍不能外推什么、下一次最小实现从哪里开始。

在这些条件满足前，准确状态是：**合同缺口已证明；目标设计仍待用户与产品选择；实现、真机效果与生产可靠性未完成。**