Phase 3：iFay 派生接管软件应用

Phase 3 把扩展方向从终端硬件转到软件应用——本地应用、云端服务、In-APP 嵌入式场景。

软件应用与硬件终端有一处关键差异：硬件终端的状态相对集中，一台无人机、一台机器人就是一个被监护对象；而软件应用的边界往往是进程化、模块化、跨网络的。一个被 iFay 接管的电商客户端可能同时跨多个域名、多个 API、多个第三方服务在协作。Phase 3 的难点不在于"接管"，在于接管的边界是否被清晰描述。

与 Phase 2 同源的派生结构

Phase 3 与 Phase 2 在结构上对称，仍然不引入"人类原型 ↔ 软件应用"这种直接关系：

该软件应用通过对应人类原型的 iFay 进入 Faying State。

责任端仍然是人类原型。iFay 通过 Faying State 派生地接管软件应用，与 Phase 2 中接管终端的机制同源。软件应用本身不在 Faying State 中独立存在。

三处关键差异

Phase 3 在 Phase 2 的结构基础上多了三处需要被特别处理的复杂性。

接管粒度更细。iFay 可能只接管软件中的一部分功能——例如允许它代为下单，但不允许代为修改账户安全策略。Phase 3 因此必须在协议层面表达"接管范围"的精细化，与第十二章中"Faying Action 必须是有限范围的"原则同源。

跨边界协作更密集。被接管的软件可能在内部调用多个外部服务、第三方 API、远端云函数。Phase 3 必须确保：iFay 通过被接管软件向外发起的任何调用，归责仍然落在原人类原型身上，不允许责任在跨服务调用链中悄悄丢失。这一要求直接呼应第一章描绘的"调用链上数据经手哪些主体无人能说清"的现实痛点。

副作用更隐蔽。相比物理动作，软件副作用（数据写入、订阅变更、第三方账号联动）更不容易被人类原型直觉地察觉。Phase 3 必须把第十一章 Human View 的"信息可达"要求落得更显式——副作用必须以人类原型能在合理代价内得知的方式被披露，而不是埋藏在调用链深处。

与本期范围的关系

Phase 3 不在本期协议设计范围内。本章描绘 Phase 3 的存在，是为了说明 Faying Protocol 的演进方向，而不是承诺本期交付。Phase 3 的具体协议形态由后续独立 spec 承担。

Phase 3 完成后，Faying Protocol 已经覆盖了 Fay 与硬件、软件两类执行端的关系，但所有讨论仍然围绕"一个人类原型 + 一个 iFay"展开。下一阶段 Phase 4 把视角扩展到组织：当 Fay 不止一个、当责任端不再是单一自然人时，Faying 关系如何依然保持一致归责。