Repository navigation
Constitution
项目：AngelaNexus
定位：智能网络代理平台
纲领版本：AN-Constitution v1.2
本文件是 AngelaNexus 后续架构设计、代码实现、测试验证、CI、发布与维护的底层宪级约束。任何后续实现均不得违反本纲领；如发现现有实现与本纲领冲突，应优先修复架构冲突，再继续推进后续开发。
AngelaNexus 是一个智能网络代理平台。
其目标不是成为某一个代理执行内核的客户端外壳，而是建立独立、跨平台、可持续演进的网络代理平台基础设施。
平台负责：
- 配置理解
- 身份识别
- 策略处理
- 路由编排
- DNS
- 安全与防泄露
- GFW 相关适配
- 链式代理
- 故障转移
- 生命周期
- 系统集成
- 用户界面
- 数据与配置管理
- 诊断与恢复
底层协议执行能力通过统一抽象接入。
平台优先，平台拥有最终架构控制权。
所有跨协议、跨节点、跨执行后端、跨平台的逻辑必须属于 AngelaNexus 平台层。
不得把平台核心能力绑定到某一个具体内核。
Mihomo、sing-box、Xray 等执行后端平行存在，不设主内核、从内核或架构中心。
保留成熟执行后端的目的，是兼容性、稳定性和协议覆盖，而不是让平台永久依赖某一后端的内部架构。
长期架构方向：
AngelaNexus
│
┌──────────┴──────────┐
│ │
Platform Intelligence Platform Runtime
│ │
Identity / Policy TUN / DNS / OS
Routing / Security Lifecycle / System
│ │
└──────────┬──────────┘
│
Protocol Adapter Layer
│
Transport Abstraction
│
┌──────────┼──────────┐
│ │ │
Native Native Compatibility
Adapter Adapter Backend
│ │ │
Protocol Protocol Existing backends
最终目标是：
平台能力独立于任何单一执行后端。
这不是一次性删除现有后端，而是渐进迁移。
平台负责：
- 流量身份识别
- 目标识别
- 规则匹配
- Match Set 计算
- 策略解析
- 路由编排
- 节点选择
- 链式代理编排
- 故障转移
- DNS 策略
- 安全策略
- 连接许可与拒绝
- 恢复策略
执行后端只负责被平台授权的：
- 协议解析
- 节点连接
- 加密与握手
- 数据传输
- 协议级连接管理
- 平台要求的底层网络执行能力
执行后端不得拥有 AngelaNexus 的全局策略决定权。
所有外部配置首先进入 AngelaNexus 自己的统一模型：
订阅 URL / 本地 YAML / JSON / 分享链接 / 单节点 / 多节点
↓
Format Detection
↓
Parse
↓
Normalize
↓
Validate
↓
Deduplicate
↓
Canonical Node Model
↓
Protocol Adapter
↓
Transport
↓
Execution
外部配置格式不得直接成为平台内部数据模型。
协议适配与传输执行必须逐步分离：
Node
↓
Protocol
↓
Protocol Adapter
↓
Transport
↓
Execution
不得把“某协议 = 某内核”写死为平台架构规则。
AngelaNexus 可以：
- 分析
- 检测
- 识别
- 推荐
- 预测
- 提示
- 解释
- 发现冲突
- 给出候选方案
但涉及用户网络行为的重要决策，原则上必须由用户拥有最终控制权。
系统不得借“智能”之名偷偷改变用户配置。
自动行为应能够说明：
- 为什么执行
- 影响什么
- 风险是什么
- 当前状态
- 自动做了什么
- 最终结果
- 是否失败
- 如何恢复
- 是否存在冲突
- 用户如何关闭
- 用户如何撤销
自动化必须可解释、可控、可撤销。
AngelaNexus 平台规则采用并行匹配，而不是第一条命中即停止。
一个流量可以同时命中：
- App Rule
- Domain Rule
- Process Rule
- Port Rule
- Protocol Rule
- DNS Rule
- IP Rule
- Security Rule
- GFW Rule
平台首先得到完整 Match Set，然后计算 Execution Plan。
规则 order 只能用于展示、编辑和管理，不得成为第一匹配、第一优先、第一执行的核心语义。
规则重叠必须进行关系分析，而不是简单覆盖。
如果多个有效规则产生无法安全合并的冲突：
Match Set
↓
Conflict Analysis
↓
Conflict
↓
Fail Closed / User Resolution
不得偷偷替用户选择一个规则。
平台支持尽可能细粒度的 Flow Identity。
应用：
- Package ID
- Bundle ID
- App ID
- UID
- App Instance
进程：
- Process Name
- Executable
- PID
网络：
- Domain
- SNI
- IP
- Port
- Protocol
- Transport
DNS：
- Query
- Answers
- Resolver
同时必须保留 Evidence Source。
不能确定的信息必须保持未知或 null，不得猜测。
安全不是某一个执行后端的附加功能。
平台逐步统一管理：
- DNS 防泄露
- IPv4/IPv6 泄露控制
- TUN 边界
- 系统代理边界
- 应用绕过
- 路由绕过
- 节点异常
- 连接异常
- 配置安全
- 本地数据安全
- 日志安全
- 凭据安全
涉及安全边界的未知、冲突或不可验证状态，不得静默放行。
平台必须区分：
- Confirmed
- Probable
- Unknown
- Unsupported
- Conflict
- Failed
不得把未知状态伪装成成功。
GFW 相关检测、策略和网络环境适配属于 AngelaNexus Platform Intelligence / Runtime。
执行后端只执行平台产生的结果。
平台必须能够表达：
- 国内 → 原生网络路径
- 国际 → 代理路径
- 特殊目标 → 指定策略
- 指定应用 → 指定策略
不得未经用户授权擅自改变用户已有安全、隐私和路由策略。
链式代理不是某一个执行后端的专属概念。
平台抽象任意合法 Pipeline，例如：
Node A
↓
Node B
↓
Node C
↓
Destination
角色由实际 Pipeline 决定，而不是写死。
平台负责：
- 健康检测
- 故障识别
- 候选节点
- 新连接迁移
- 重连
- 恢复
- 用户提示
必须明确区分 New Connection 与 Existing Session，不能假定已有连接都能无损迁移。
目标平台：
- Android
- iOS
- Windows
- macOS
- Linux
Android 是当前首先落地的可执行表面，不是架构上的唯一中心。
平台核心必须保持 Platform Neutral。
例如：
- Android VpnService
- Windows System Proxy
- macOS Network Extension
- Linux TUN
- iOS Network Extension
均属于 Platform Abstraction Layer，不得直接污染核心业务逻辑。
透明代理能力必须根据：
- Platform Capability
- OS Capability
- Root Capability
- Backend Capability
- Hardware / Network Limitation
分别验证。
不能为了宣传而把无法验证的能力称为“真正透明代理”。
Android Root 环境应提供明确的高级选项，并遵循安全、可解释和用户控制原则。
持续控制：
- CPU
- RAM
- Battery
- Network overhead
- Background activity
- DNS overhead
- Connection duplication
- Logging overhead
新增功能必须考虑功能收益与资源成本。
涉及网络协议、系统 API、执行后端、平台能力和标准时，以最新稳定、可信、可验证的官方或一手资料为依据。
技术事实链：
Source
↓
Version / Commit
↓
Original Definition
↓
AngelaNexus Implementation
↓
Test / Verification
必须明确区分：
- Stable
- Preview
- Beta
- Alpha
- RC
- Development
不得把测试版本当作稳定基线。
现有 Mihomo、sing-box、Xray 继续作为 Compatibility Execution Backend。
迁移路径：
Existing Backend
↓
Backend Adapter
↓
Protocol Adapter
↓
Canonical Node
随着 AngelaNexus 自有能力成熟，再逐协议迁移。
正式项目代码、文档、UI 和功能命名必须保持 AngelaNexus 自身产品身份。
第三方项目、协议实现、开源组件、参考实现等需要声明时，集中在 LICENSE、NOTICE、ACKNOWLEDGEMENTS 等正式位置。
所有开发阶段遵循：
当前状态
↓
验证
↓
通过？
┌─┴─┐
否 是
│ │
修复 ↓
│ 下一阶段
↓
重新验证
未验证成功，不得进入下一阶段。
出现编译、测试、CI、构建、签名、兼容性、运行时或架构检查失败时：
定位
↓
修复
↓
重新执行
↓
重新验证
单一问题原则上最多进行 5 次修复尝试；仍失败则停止推进并保留明确失败状态。
进入下一类别前必须检查：
- 是否违反 Platform First
- 是否产生 Backend Lock-in
- 是否违反 Parallel Match
- 是否引入隐式优先级
- 是否产生错误自动决策
- 是否破坏用户控制
- 是否产生安全泄露
- 是否破坏跨平台
- 是否破坏 Canonical Model
- 是否引入第三方品牌污染
- 是否违反稳定版本要求
通过后才能进入下一类。
┌───────────────────────────────────────────────┐
│ AngelaNexus │
│ 智能网络代理平台 │
├───────────────────────────────────────────────┤
│ User Interface │
├───────────────────────────────────────────────┤
│ Application API │
├───────────────────────────────────────────────┤
│ Platform Intelligence │
│ │
│ Identity │ Match Set │ Policy │ Routing │
│ Security │ GFW │ DNS │ Diagnostics │
├───────────────────────────────────────────────┤
│ Platform Runtime │
│ │
│ TUN │ OS Integration │ Lifecycle │ Recovery │
├───────────────────────────────────────────────┤
│ Canonical Data / Model │
│ │
│ Config │ Node │ Flow │ Pipeline │ Capability│
├───────────────────────────────────────────────┤
│ Protocol Adapter Layer │
│ │
│ VLESS │ VMess │ Trojan │ SS │ Hysteria │ ...│
├───────────────────────────────────────────────┤
│ Transport Abstraction │
│ │
│ TCP │ UDP │ TLS │ QUIC │ HTTP │ ... │
├───────────────────────────────────────────────┤
│ Compatibility Execution Layer │
│ │
│ Mihomo │ sing-box │ Xray │ Future Backends │
├───────────────────────────────────────────────┤
│ OS / Network │
└───────────────────────────────────────────────┘
核心原则：
AngelaNexus 决定，Adapter 翻译，Transport 执行，Compatibility Backend 兼容；任何单一内核都不得成为平台的大脑。
发生需求冲突时，依次遵循：
- 用户安全与数据保护
- 用户控制权
- 平台架构独立性
- 正确性与可验证性
- 跨平台一致性
- 稳定性
- 兼容性
- 性能与资源效率
- 智能化与自动化
- UI 与易用性优化
低层级目标不得破坏高层级原则。
以后不再把核心问题定义为：
“怎么把三个内核整合得更好？”
而定义为：
“怎么建立一个独立于执行后端的网络代理平台，而让各种协议执行能力自然接入这个平台？”
长期演进路线：
Kernel-Centric
↓
Kernel-Abstraction
↓
Platform-Centric
↓
Protocol-Centric
↓
Transport-Abstraction
↓
Backend-Independent
本纲领自写入项目起，作为 AngelaNexus 后续开发、架构调整、代码实现、测试、CI、发布和维护的底层宪级约束。
AngelaNexus 应将用户可理解的网络行为抽象为统一 Intent，由平台负责解释、组合、验证和编排，再由执行后端负责实际执行。
统一的对象是：
- 用户网络意图
- 策略语义
- 路由要求
- 安全要求
- DNS 要求
- 连接要求
- 协议/传输要求
- 平台能力要求
- 用户偏好
不强行统一的对象是：
- 各执行后端内部实现
- 内核特有协议能力
- 内核特有传输能力
- 内核特有优化
- 内核特有兼容机制
- 无法可靠映射的原生能力
核心原则：
统一意图、统一标准、统一调度；保留内核差异、原生能力和底层实现。
Mihomo、sing-box、Xray 在平台架构中平行存在。
平台可以使三个执行后端保持可用、可探测、可调度的待命状态，但：
待命不等于同时处理同一条流量。
同一 Session 原则上只能由一个明确授权的执行 Driver 承担，除非该 Session 的 Execution Plan 明确要求合法的多阶段 Pipeline / Chain。
不得通过简单的“轮流使用内核”作为调度语义。
每个执行 Driver 必须通过统一能力描述向平台报告自身能力。
能力至少包括：
- Protocol
- Transport
- TLS / Security Mode
- UDP
- IPv4 / IPv6
- Multiplex
- Chain
- DNS
- TUN / Platform Integration
- Operating System
- Architecture
- Root / Privilege Requirement
- Driver Version
- Health
- Limitations
- Unsupported Features
- Native Extensions
能力状态必须可验证，并允许：
- Supported
- Unsupported
- Partial
- Unknown
- Degraded
- Failed
不得把未知能力视为已支持。
平台统一采用：
User / Flow
↓
Intent
↓
Policy Evaluation
↓
Capability Matching
↓
Candidate Drivers
↓
Execution Plan
↓
Selected Driver
↓
Execution
平台首先根据硬性要求淘汰不满足必要能力的 Driver，再根据可解释的能力匹配、平台兼容性、当前健康状态和用户设置形成候选集。
不得因为某个内核“默认更常用”而绕过能力验证。
平台不得建立无法解释、无法验证的“内核总分”并据此偷偷决定网络行为。
调度依据应能够说明：
- Intent 要求什么
- 哪些 Driver 满足要求
- 哪些 Driver 不满足
- 哪些能力为 Partial / Unknown
- 为什么进入候选集
- 为什么最终选定某 Driver
- 是否存在用户固定限制
- 是否启用了自动故障转移
- 执行结果如何
涉及重要网络行为时，自动选择必须可见、可关闭、可固定。
平台至少应支持以下选择语义：
Automatic
Fixed Driver
Allowed Drivers
Disable Automatic Failover
Allow Automatic Failover
自动模式下平台可以根据 Intent 与 Capability Registry 选择最适配的 Driver。
固定模式下平台不得擅自切换到其他 Driver。
用户明确禁止自动故障转移时，失败不得偷偷转移到其他执行后端。
Driver 出现：
- 启动失败
- 能力失效
- 连接失败
- 协议失败
- 传输失败
- 健康状态恶化
- 平台能力变化
时，平台可以根据用户授权的 Failover Policy 重新执行：
Failure
↓
Revalidate Intent
↓
Revalidate Capability
↓
Rebuild Candidate Set
↓
Create New Execution Plan
↓
User Policy Allows?
↓
Failover / Fail Closed
不得把“换一个内核”视为无条件安全的操作。
Driver 调度以 Session / Connection 为基本执行边界。
必须区分：
- New Connection
- Existing Session
- Stream
- Pipeline / Chain
一般情况下，Driver 切换应作用于新建连接。
除非能够证明底层协议和运行时支持安全迁移，否则不得宣称已有连接能够无损迁移到另一个 Driver。
如果某个 Driver 提供统一标准之外的原生能力，平台应采用：
Unified Capability
+
Native Extension
的方式接入。
原生扩展必须：
- 明确归属
- 明确能力范围
- 明确平台限制
- 明确版本要求
- 明确是否影响跨平台一致性
- 不得污染 Canonical Model
- 不得夺取平台全局策略决定权
因此：
统一标准负责共同语义，原生扩展负责差异能力。
平台统一策略和意图，不意味着 AngelaNexus 必须重新实现所有协议、加密、握手、传输和底层连接机制。
原则上：
Platform
↓
Intent / Policy / Execution Plan
↓
Driver
↓
Protocol / Transport Execution
平台只有在具有明确架构收益、可验证性和长期维护能力时，才逐步吸收某项执行能力。
不得为了“统一”而制造重复实现。
Mihomo、sing-box、Xray 的长期定位为：
可替换、可协商、可调度的 Protocol / Transport Execution Plane。
它们不是 AngelaNexus 的大脑。
平台负责：
- 判断意图
- 计算策略
- 匹配能力
- 生成执行计划
- 选择 Driver
- 管理 Session
- 处理安全边界
- 处理故障与恢复
Driver 负责：
- 接收平台授权
- 转换统一模型
- 调用对应执行能力
- 返回执行状态
- 返回可验证结果
未来增加第四、第五个执行后端时，不得通过：
Mihomo ↔ sing-box ↔ Xray ↔ New Backend
形成点对点耦合。
必须通过：
Unified Standard
/ | | \
Mihomo sing-box Xray New Backend
\ | | /
Driver Layer
接入。
新增 Driver 原则上只需要实现统一接口、能力声明和必要适配，不得要求平台核心为其建立新的全局分支。
三内核待命机制不得演变为三份完整运行时长期高负载运行。
平台必须区分：
- Installed
- Available
- Ready
- Active
- Idle
- Suspended
- Unavailable
根据平台资源、系统生命周期和用户设置，可以采用：
- 按需启动
- 预热
- 保活
- 挂起
- 释放
等策略。
任何优化不得违反：
- 用户控制
- 安全边界
- Fail Closed
- Session 正确性
- 跨平台一致性
AngelaNexus 的三内核调度模型正式定义为：
三个执行内核平行存在、能力可探测、统一接收平台意图；平台通过 Capability Registry 对候选执行后端进行能力协商和策略匹配，为每个 Session 生成可解释的 Execution Plan，由最适配且获得授权的 Driver 执行；内核之间不通过简单轮询决定任务，也不得成为平台全局策略中心。
最终架构关系：
AngelaNexus
│
User / Flow
│
▼
Unified Intent
│
▼
Policy / Security
│
▼
Capability Registry
│
▼
Driver Scheduler
│
┌───────────┼───────────┐
▼ ▼ ▼
Mihomo sing-box Xray
Driver Driver Driver
│ │ │
└───────────┼───────────┘
▼
Protocol / Transport
Execution
│
▼
Network
其核心原则归纳为：
平台统一意图，策略统一表达，能力统一声明，调度统一决策，Driver 负责翻译，内核负责执行；三内核平行待命、按能力协商，不以简单轮询为核心调度机制。
凡经确认并影响 AngelaNexus 长期架构边界的重大共识，应在实施代码之前进入本纲领或正式纲领附件。
纲领附件不得与主纲领产生相互矛盾的架构定义。
新增架构原则进入实施阶段前，必须核查：
- 是否与 Platform First 一致
- 是否保持三内核平行
- 是否保持 Canonical Model
- 是否保持用户最终控制权
- 是否保持 Fail Closed
- 是否破坏跨平台
- 是否造成 Backend Lock-in
- 是否引入不可解释的自动决策
- 是否造成不必要的资源消耗
- 是否可以通过测试和事实依据验证
通过后方可进入代码实现。
AngelaNexus 的内存、CPU、唤醒、网络控制流量和电池消耗属于产品级架构约束。
资源效率不得被视为发布前的可选优化，也不得以“功能已经完成”为理由延期处理。
任何新增模块、Driver、后台任务、协议适配、规则系统、DNS 能力、诊断能力和系统集成能力，都必须在设计和实现阶段同时定义资源生命周期与资源成本。
核心目标：
- 高效率
- 低内存
- 低 CPU
- 低后台唤醒
- 低网络控制开销
- 低电池消耗
- 不牺牲安全、正确性和用户控制
“三内核平行待命”必须解释为平台可探测、可调度，而不是默认让 Mihomo、sing-box、Xray 三个完整运行时长期同时常驻。
平台必须优先采用：
Installed
↓
Available
↓
Ready
↓
Active
↓
Idle
↓
Suspended
↓
Released
其中：
- Installed：已安装或已包含
- Available：当前可被平台调用
- Ready：已完成必要初始化，可快速接收任务
- Active：正在承担实际 Session
- Idle：暂时无业务但仍保持部分状态
- Suspended：已暂停运行
- Released：释放运行资源，仅保留必要的可恢复信息
除非用户明确选择预热、保活或系统场景确有必要，否则平台不得默认长期维持多个完整 Driver 运行时。
平台是跨 Driver 的统一控制中心，因此以下状态原则上不得由多个层重复长期维护：
- Canonical Config
- Node Model
- Policy
- Match Set
- Routing Decision
- DNS Cache
- Fake-IP State
- Connection / Session Metadata
- Health State
- Resource State
- Diagnostics State
- 用户偏好
执行后端保留其协议、传输、握手、连接池等不可避免的原生运行时状态。
平台必须通过明确边界避免重复缓存、重复轮询、重复健康检查和重复统计。
后台任务原则上优先采用：
- Event-driven
- Timer coalescing
- Batch processing
- Adaptive scheduling
- Bounded concurrency
- Connection reuse
- Cache reuse
禁止无必要的：
- Busy loop
- 高频固定轮询
- 重复 DNS 查询
- 重复健康检查
- 重复建立连接
- 无界并发
- 无意义后台日志
- 无业务价值的持续唤醒
每项后台任务必须能够说明：
- 触发条件
- 执行频率或自适应策略
- 并发上限
- 单次资源成本
- 失败后的重试策略
- 空闲时行为
- 系统休眠时行为
- 低电量时行为
- 停止条件
平台必须同时关注：
- Steady-state Memory
- Peak Memory
- Driver Memory
- Cache Memory
- Buffer Memory
- Rule / Config Memory
- Diagnostics / Log Memory
- Temporary Allocation
不得只观察启动瞬间内存。
每个主要模块必须明确：
Allocation
↓
Lifetime
↓
Reuse
↓
Release
能够复用的缓冲区、连接、解析结果和缓存不得无理由重复分配。
缓存必须具有：
- 上限
- 生命周期
- 淘汰策略
- 失效策略
- 可观测性
不得通过无限缓存换取表面性能。
CPU 优化必须优先减少无效工作，而不是仅通过降低功能频率获得表面指标。
优先方向：
- 减少重复解析
- 减少重复匹配
- 减少重复序列化
- 减少重复 DNS
- 减少重复连接建立
- 减少重复状态同步
- 批量处理可批量处理的事件
- 采用事件通知替代持续轮询
任何高频路径必须能够通过测试证明其 CPU 成本合理。
平台必须根据系统和设备状态调整后台行为，并明确区分：
- Foreground
- Background
- Idle
- Screen-off
- Charging
- Battery saver / Low battery
- Network transition
- System sleep / resume
在不违反用户网络策略和安全边界的前提下，可以降低：
- 后台健康检查频率
- Driver 保活
- DNS 主动探测
- 网络状态重复检测
- 诊断采样
- 非必要日志
- 空闲 Driver 数量
但不得因为省电而关闭或绕过用户明确启用的安全能力。
资源效率的优先级不得高于安全和正确性。
任何资源优化不得导致：
- DNS 泄露
- IPv4 绕过
- IPv6 绕过
- TUN 绕过
- Kill Switch 失效
- 用户规则失效
- Fail Closed 变为 Fail Open
- Session 边界失真
- 凭据保护降低
- 未授权 Driver 自动切换
- 用户明确禁止的后台行为继续运行
资源优化的正确顺序为：
Security
↓
Correctness
↓
User Policy
↓
Stability
↓
Efficiency
↓
Power Optimization
平台必须控制非业务流量产生的资源开销，包括：
- DNS 查询
- Health Check
- Keepalive
- Driver IPC
- Capability Probe
- Metrics
- Diagnostics
- Update Check
- Background Synchronization
能够共享、合并、缓存或事件触发的操作，不得无理由重复执行。
平台可以提供资源策略，例如：
- Balanced
- Performance
- Power Saving
- User Defined
但任何模式都必须明确说明其影响范围。
资源模式不得静默修改用户明确设置的：
- 路由策略
- DNS 策略
- 防泄露策略
- 节点选择限制
- Driver 选择限制
- 故障转移策略
- 安全策略
系统可以优化实现方式，但不得借资源模式偷偷改变网络语义。
资源优化不得仅凭代码阅读或主观判断宣布完成。
至少应建立可重复的基准指标：
- CPU 使用率
- RSS / PSS
- Peak Memory
- Allocation Rate
- Wakeups
- Battery Drain
- Network Control Overhead
- DNS Query Rate
- Active Connection Count
- Active Driver Count
- Startup Latency
- Resume Latency
- Throughput
- Error / Retry Rate
测试必须区分：
- Foreground
- Background
- Idle
- Heavy Traffic
- Large Rule Set
- Large Node Set
- Network Transition
- Sleep / Resume
- Low Battery
- Multi-Driver Capability Matching
优化前后必须能够比较，并保留回归依据。
如果新增功能导致资源指标出现未经解释且未获批准的明显回归，不得仅因为功能测试通过而视为完成。
资源回归必须：
Detect
↓
Measure
↓
Identify
↓
Fix / Justify
↓
Re-measure
↓
Pass
无法解释或无法接受的资源回归必须阻止进入下一阶段。
进入下一实现类别前，必须回答：
- 该模块何时启动？
- 何时保持运行？
- 何时进入 Idle？
- 何时 Suspend？
- 何时 Release？
- 占用多少内存？
- CPU 高频路径是什么？
- 是否存在后台唤醒？
- 是否产生额外网络控制流量？
- 系统休眠时如何处理？
- 低电量时如何处理？
- 是否与其他模块重复维护状态？
- 如何测试资源成本？
- 如何检测资源回归？
- 是否可能影响安全或用户网络策略？
没有明确答案，不得进入下一实现阶段。
Android、iOS、Windows、macOS、Linux 可以使用不同的系统生命周期 API 和资源控制机制，但必须映射到统一的平台资源生命周期语义。
平台核心不得因为操作系统差异而产生相互矛盾的资源策略。
系统特有实现必须位于 Platform Abstraction Layer。
AngelaNexus 的资源效率正式定义为：
在不降低安全性、正确性、用户控制权、策略完整性和跨平台可靠性的前提下，以最少的持续内存、CPU、后台唤醒、网络控制流量和电池消耗完成既定网络任务；所有资源成本必须可测量、可解释、可回归验证。
因此：
高效率、低内存、低耗能不是 AngelaNexus 的附加优化目标，而是实际用户体验、系统稳定性和长期可维护性的基础架构要求。
平台规则源属于安全边界，不得把“能够下载”视为“可信”。
远程规则源进入平台前至少必须经过：
Transport Security
↓
Source Allowlist
↓
Size Limit
↓
SHA-256 Integrity
↓
Independent Publisher Signature
↓
Version / Anti-Rollback
↓
Expiry / Freshness
↓
Schema / Semantic Validation
↓
Rule Conflict / Risk Analysis
↓
Atomic Activation
任何关键验证失败均必须：
- Reject
- 保留当前已验证版本
- 不覆盖运行中的可信规则
- 记录可诊断错误
- 不把失败源降级为“可用”
规则源携带的公钥、摘要、授权信息不能自行成为自己的信任根。
平台必须通过独立于待验证内容的信任锚提供：
- Publisher ID
- Ed25519 公钥
- Source Allowlist
- 必要时的固定 SHA-256
- 当前已接受版本
规则源可以提供证明材料，但不能自行授予自己可信身份。
平台必须记录已接受规则源版本，并拒绝：
- 旧版本回滚
- 同版本重放（在策略要求严格新版本时）
- 已过期规则
- 无有效有效期的强制签名源
更新必须采用：
Candidate
↓
Verify
↓
Validate
↓
Stage
↓
Atomic Commit
不得在验证完成前直接替换当前生效规则。
签名正确只证明“内容由可信签名者签署”，不能证明内容没有错误或错误配置。
因此平台仍必须进行：
- Schema Validation
- Rule Relationship Analysis
- Conflict Detection
- Dangerous Broad-Match Detection
- Route / DNS / Security Boundary Validation
- User-visible Change Summary
签名通过不得跳过语义安全检查。
AngelaNexus 的项目与应用安全不能只依赖单一签名。
至少形成：
Source / Dependency Integrity
↓
CI Security Gate
↓
Build Artifact Integrity
↓
Release Signing
↓
Runtime Integrity Verification
↓
Secure Update / Anti-Rollback
↓
Fail Closed
必须重点防止：
- 未授权代码进入主分支
- 恶意依赖或依赖供应链污染
- 构建阶段注入
- 发布产物替换
- 更新包降级
- 运行时关键文件被篡改
- 规则源成为代码/策略注入入口
关键安全边界至少应具有独立验证证据。
安全 Gate 至少覆盖：
- 依赖漏洞检查
- 生命周期脚本隔离
- 完整性测试
- 签名验证测试
- Anti-Rollback 测试
- 规则源抗投毒测试
- 应用产物完整性测试
规则源即使通过来源认证，也只能产生平台规则数据。
不得直接：
- 执行 shell
- 执行 JavaScript
- 加载动态代码
- 修改应用二进制
- 修改安全基线
- 修改信任锚
- 修改签名公钥
规则数据必须经过 Canonical Model 与平台安全验证后才能进入 Execution Plan。
平台不得把静态声明当作运行事实。统一能力真实性状态为：
declared → supported → verified → operational → healthy
- Declared：代码或平台矩阵声明存在该能力。
- Supported：当前平台边界允许实现该能力。
- Verified：已经取得可信运行时证据。
- Operational：本次运行实例已经实际启动并工作。
- Healthy：运行实例通过当前健康检查。
任何状态不得跨级推断。尤其不得因为“支持”而声称“已验证”，不得因为“已验证”而声称“健康”。
原始目标地址、Hostname、PID、UID、DNS 关联等信息必须携带证据来源和可信程度。
未知信息必须保持未知，不得通过猜测、默认值或相关性推断补齐。
遥测数据仅用于诊断、策略规划和健康判断，不得成为绕过安全边界的隐式授权。
平台可以利用 RTT、Delivery Rate、Pacing Rate、重传比例、排队延迟、ECN 等运行证据进行网络状态分析。
但任何自适应优化必须遵循：
Measure → Classify → Verify → Apply → Observe → Rollback
在无法可靠区分网络拥塞、随机丢包或其他异常原因时，平台不得仅依据“发生丢包”自动启用高风险补偿策略。
透明代理后端切换必须支持：
Stop Admission → Drain Existing Flows → Activate Candidate → Health Check → Commit
候选后端健康检查失败时必须：
Rollback → Restore Previous Backend → Resume Admission
不得在旧后端仍承载活动连接时无条件强制切换，也不得在新后端尚未验证时直接宣布其可用。
流级遥测必须限制：
- 最大流数量
- 字符串长度
- 计数器数量
- 后台采样频率
- 生命周期
不得为了诊断无限缓存连接、域名、进程或网络元数据。
遥测模块必须支持 Idle、Suspend、Release，并与平台资源策略统一。
实验性 eBPF、拥塞控制、丢包补偿、首包冗余或其他性能增强机制不得成为透明代理的隐含前置依赖。
它们必须具备：
- 独立能力检测
- 独立运行时验证
- 独立启停开关
- 独立遥测
- 明确适用条件
- 失败回滚
- 可重复性能基准
未经验证不得启用。
网络性能优化不得仅根据单一指标或静态假设自动启用。
平台必须先采集有限、可解释的网络证据，包括但不限于：
- RTT / Base RTT
- Queueing Delay
- Retransmission Ratio
- ECN
- Delivery Rate
- 有效样本数量
- Flow 生命周期状态
随后执行：
Measure
↓
Classify
↓
Security Check
↓
Capability Verification
↓
User Policy Check
↓
Optimization Preflight
↓
Apply
↓
Health Check
↓
Observe / Rollback
任何无法证明适用条件的优化必须保持关闭或采用安全的无特殊优化状态。
涉及改变网络执行行为、拥塞控制、丢包补偿、发送策略、连接策略或其他可能影响流量特征的优化功能：
- 默认不得绕过用户设置自动启用
- 用户明确关闭后不得重新启用
- 自动检测只能决定“是否具备启用条件”，不能替代用户授权
- 优化原因、条件、当前状态和结果必须可解释
- 用户应能够随时关闭并恢复基础执行路径
任何可能改变执行后端行为的优化，至少必须同时满足：
- Capability 已经 Verified
- Security 状态 Healthy
- 网络条件满足对应优化的证据要求
- 用户已经允许该优化
- 当前透明运行时处于可安全切换状态
特别是丢包补偿类优化，不得把“存在丢包”直接等同于“随机丢包”。
存在排队延迟、RTT 膨胀、ECN 或其他拥塞证据时，应禁止将该状态直接归类为适合丢包补偿的网络条件。
已经存在透明代理 Session 时，优化模式变更不得直接覆盖当前执行状态。
原则上采用：
Active
↓
Drain
↓
Drained
↓
Activate
↓
Health Check
↓
Commit
新模式健康检查失败时：
Activation Failed
↓
Rollback
↓
Recover
↓
Retain Previous Active State
不得在失败后留下半激活状态。
平台只负责：
- 网络状态分类
- 安全门禁
- 能力验证
- 用户授权
- 生命周期
- 遥测
- 健康检查
- 回滚
具体 TCP、拥塞控制、发送冗余、传输参数或其他执行算法属于执行 Driver / Native Extension 能力。
平台不得因为某一算法或某一执行后端存在，就默认将其作为全局优化策略。
纲领之基文件：docs/ANGELANEXUS_FOUNDATION.md。
Foundation 是 AngelaNexus 的最高根本方向；Foundation DNA 是这一根本方向的机器可验证遗传表达。
治理层级保持：
纲领之基
↓
宪级纲领
↓
Foundation DNA / Gene
↓
Architecture / Product / Development / Security / Release
验证机制的职责是确认项目仍然沿着这条根本方向演进，而不是把每一次实现变化都变成需要重新授权的治理事件。
只要实现继续属于 AngelaNexus 项目继承链，就默认继承 Foundation Gene。
以下变化本身不构成根本方向改变，也不得仅因变化本身被 Foundation Gate 阻止：
- 技术栈变化；
- 模块重构；
- 平台迁移；
- Mihomo、sing-box、Xray 或其他执行后端替换；
- UI / UX 变化；
- CI、测试与发布流程变化；
- 仓库组织方式变化；
- 性能优化与资源策略变化。
这些变化只需要通过与 Foundation Gene 的兼容性验证。
只有真正触及根本目标的变化，才属于 Root Goal Change。
Root Goal Change 指：
- 放弃项目根本初衷；
- 削弱用户选择与控制这一根本目标；
- 用低层实现便利替代 Foundation 的最高地位；
- 将项目发展方向根本性改造成与 Foundation 相冲突的目标。
普通实现困难、商业压力、技术债、性能折衷、内核限制或平台限制，不得被伪装成根本方向改变；同样，也不得把普通实现变化夸大为根本冲突。
Foundation Gate 保留为 Required Status Check，但其语义调整为：
验证当前变更是否继续继承并兼容 Foundation Gene。
它不是一个新的最高权威，不是外部审批机构，也不是无限增长的权限锁。
Gate 应优先检查：
- Foundation Root 身份完整；
- Foundation DNA 结构与根本目标完整；
- 继承关系连续；
- 变更分类正确；
- 普通实现变化没有被误判为 Root Goal Change；
- 已声明的架构、产品、安全与发布原则仍与 Gene 兼容。
所有属于 AngelaNexus 继承链的主体都继承 Foundation Gene，包括创建者、Owner、Administrator、Maintainer、Developer、Contributor、Bot、AI Agent、Fork 维护者和继任者。
这里的“没有法外之人”只表示没有人可以把自己从项目根本目标中豁免出去；它不表示任何人都必须接受无限增加的人工审批、外部授权或不可演进的治理锁。
治理机制本身可以演进，但演进后仍必须服务于 Foundation Gene。
外部 Foundation Anchor 可以用于增强 Foundation 身份的独立可验证性。
但外部锚定不是 Foundation 成立的前提，不是项目基因的来源，也不是新的最高权威。
其关系为：
Foundation
↓
Foundation DNA / Gene
↓
Implementation
External Anchor → optional independent evidence
外部锚定不得反向定义、修改或替代 Foundation。
Foundation Gene 必须尽可能机器可读、机器可验证并随项目自然传播。
项目至少应让以下类别能够追溯其与 Foundation Gene 的关系：
- Product；
- Architecture；
- Development；
- Security；
- UX；
- Kernel / Protocol；
- Platform；
- Testing；
- Release；
- Fork / Migration / Derived Project。
验证目标是回答：
这个变化如何从 Foundation 演化而来，或者为什么它仍然与 Foundation 兼容？
能够回答并通过兼容性验证，即属于正常演进；不能证明根本目标兼容时，才进入 Root Goal Change 处理流程。
开发者可以更换，维护团队可以更替，平台可以扩展，技术可以淘汰，执行后端可以替换，代码可以重构。
但只要项目仍然属于 AngelaNexus 继承链，其 Foundation Gene 就继续存在。
技术可以世代更替，开发者可以不断更换，但 AngelaNexus 为什么存在，不由后来者通过一次普通实现变更重新决定。
本章取代将 Foundation Gate 定义为无限制治理锁的解释；它不削弱纲领之基，只把纲领之基从“外部门禁对象”转化为“项目自身的遗传根”。
AngelaNexus 的最高目标只有一个：
让用户自由选择访问互联网。
“成全用户”不是第二个最高目标，也不替代、削弱或重新定义纲领之基。它是 AngelaNexus 将纲领之基落实为真实产品能力时的核心技术实现原则。
这里的“成全”不是替用户决定，而是让用户能够以尽可能低的认知、配置和操作成本，实现其合法且明确的网络访问目标。
AngelaNexus 作为智能网络代理平台，存在的价值不是让用户学习和管理一个复杂的代理机器，而是：
- 用户提出目标；
- AngelaNexus 理解目标；
- 平台自动处理复杂性；
- 用户获得可用、稳定、可解释的结果；
- 用户始终保有最终控制权。
因此，平台的智能、自动化、内核调度、规则系统、DNS、TUN、故障恢复和跨平台能力，均必须服务于纲领之基，并通过“成全用户”这一技术原则具体落实。
AngelaNexus 不得把自身的内部技术结构强加给普通用户。
普通用户不应被要求理解：
- Mihomo / sing-box / Xray 的内部差异；
- Protocol Adapter；
- Transport；
- Capability Registry；
- Driver Scheduler；
- TUN；
- DNS；
- Match Set；
- Execution Plan；
- 复杂规则优先级；
- 内核生命周期。
这些属于平台应承担的复杂性。
用户需要面对的是清晰的目标、状态、结果和必要选择。
核心关系必须保持：
用户提出目标
↓
AngelaNexus 理解并成全
↓
自动完成复杂适配
↓
真实验证
↓
用户获得结果
平台不得反过来要求用户成为系统的操作员。
AngelaNexus 的最重要产品成功路径定义为：
Install
↓
Language + Region
↓
Initialize
↓
Import Valid Configuration
↓
Automatic Adaptation
↓
Real Connection Verification
↓
First Success
其中：
First Success 必须指真实网络可用，而不是“配置解析成功”“节点保存成功”或“内核启动成功”。
只要用户导入有效节点或有效配置，系统就应尽最大可能自动完成：
- 格式识别；
- 配置解析；
- 节点/协议识别；
- 能力识别；
- 配置规范化；
- 默认安全策略初始化；
- 最佳适配；
- Driver 选择；
- 必要的系统网络能力准备；
- 启动；
- 实际连接验证；
- DNS / IPv4 / IPv6 / TUN 等关键路径检查；
- 失败诊断；
- 可恢复故障自动恢复。
有效配置 = 最低可用入口。
单个有效节点本身即可构成最低可用的成功条件。
平台不得把以下能力作为首次使用的强制前置条件：
- 策略组；
- 链式代理；
- 复杂分流规则；
- 手工 DNS 配置；
- 手工 TUN 配置；
- 手工内核选择；
- 复杂节点分类；
- 其他非必要高级配置。
这些能力可以在需要时逐层展开，但不得阻塞最基本的首次成功路径。
AngelaNexus 的用户模型正式定义为：
普通用户：
导入有效配置 → 基本无需理解技术 → 自动适配 → 成功使用。
进阶用户：
在自动可用基础上，可以逐层展开并控制完整能力。
产品不得以“高级用户”作为正式用户层级名称；正式表述统一采用“普通用户 / 进阶用户”。
普通用户看到的是：
- 我要做什么；
- 当前是否可用；
- 系统正在做什么；
- 为什么失败；
- 系统如何恢复；
- 我需要做什么。
进阶用户可以进一步查看和控制：
- 路由；
- 应用 / APP / 进程分流；
- DNS；
- TUN；
- Driver；
- Kernel；
- 节点限制；
- 策略组；
- 链式代理；
- 故障转移；
- 安全策略；
- 诊断证据；
- 详细日志。
自动化的正确含义是：
系统替用户完成复杂工作，而不是系统替用户做不可见的重大决定。
因此自动化必须同时满足：
- 默认可用；
- 可解释；
- 可观察；
- 可恢复；
- 可撤销；
- 可关闭；
- 用户可覆盖；
- 不改变用户明确设置；
- 不隐藏安全边界；
- 不制造不可解释的网络行为。
平台可以自动选择最佳 Driver、自动适配配置、自动恢复普通故障，但必须能够告诉用户发生了什么，并允许进阶用户控制相关行为。
当用户已经提供有效配置而首次使用失败时，默认责任应落在平台诊断与恢复机制，而不是要求普通用户自行排查底层技术。
平台必须优先完成：
Detect
↓
Classify
↓
Recover
↓
Verify
↓
Explain
错误信息必须首先以用户可理解的方式表达，例如：
- 配置无法识别；
- 配置格式有误；
- 订阅暂时无法访问；
- 网络连接失败；
- 当前网络阻止了连接；
- 系统权限不足；
- 当前平台不支持该能力；
- 节点不可用；
- 已自动切换到可用候选；
- 当前无法安全恢复，需要用户选择。
技术堆栈、原始异常、Driver、Kernel、协议细节等应进入可展开的诊断层，而不是成为普通用户的第一界面。
任何“自动处理”都不能以内部动作完成作为成功依据。
统一成功判定：
Action
↓
Runtime State
↓
Actual Network Evidence
↓
Policy / Security Verification
↓
Usable
因此：
- 解析成功 ≠ 可用；
- Driver 启动 ≠ 可用；
- TUN 建立 ≠ 可用；
- DNS 正常 ≠ 可用；
- TCP/UDP 建连 ≠ 用户目标已实现；
- UI 显示“运行中” ≠ 网络实际成功。
最终必须以真实网络行为验证用户目标是否达成。
AngelaNexus 应形成：
默认层
安全、简单、自动、可用、可解释
↓
进阶层
完整、透明、细粒度、可控
普通用户无需进入进阶层即可完成核心任务。
进阶用户进入进阶层后，不应被默认层隐藏的自动决策锁死。
任何自动能力都必须具有明确的控制边界。
随着 AngelaNexus 增加协议、内核、平台、规则和安全能力，系统复杂度应优先由平台架构吸收。
不得因为：
- 支持更多协议；
- 增加更多内核；
- 增加更多规则；
- 增加更多平台；
- 增加更多安全能力；
就把对应复杂度直接转嫁给普通用户。
架构演进的目标应是：
Internal Complexity ↑
User Complexity → Stable or ↓
Success Rate ↑
如果某项技术演进明显增加普通用户首次成功的操作负担，应重新审视其产品形态。
新增功能、架构、规则、自动化、优化和 UI 设计，在进入最终实现前必须能够回答：
- 它解决了用户什么真实问题？
- 它是否提高“有效配置 → 成功使用”的成功率？
- 它是否降低了普通用户的理解或操作成本？
- 它是否保持用户最终控制权？
- 它是否可解释？
- 它是否可验证？
- 它失败后是否可恢复？
- 它是否引入不必要的网络、资源或安全风险？
- 是否能够在不牺牲平台独立性的情况下实现？
- 如果不能让用户更容易实现目标，为什么仍然需要它？
若新增复杂度不能带来相应的用户价值，不得仅因技术可行而进入最终产品形态。
AngelaNexus 的最高目标只有一个：
让用户自由选择访问互联网。
纲领之基规定这一最高目标与根本使命；宪级纲领负责将其进一步明确、固化并约束项目演进；“成全用户”则是将这些原则转化为真实技术与产品能力的核心实现原则。
二者关系为：
纲领之基
【最高目标：让用户自由选择访问互联网】
↓
宪级纲领 / 底层宪级纲领
【具体化、固化与约束】
↓
成全用户
【核心技术实现原则】
↓
智能网络代理平台
↓
架构 / UX / Security / Runtime
↓
代码 / CI / Release / Verification
纲领之基回答：
AngelaNexus 为什么存在，以及最高目标是什么。
宪级纲领回答：
这一最高目标如何被持续守住、具体化并落实为项目约束。
“成全用户”回答：
AngelaNexus 如何在真实技术与用户场景中把这一根本使命变成用户能够使用、理解、控制和验证的能力。
“成全用户”不得反过来定义、修改或降低纲领之基的最高地位。
AngelaNexus 是否真正完成，不以：
- 支持多少协议；
- 集成多少内核；
- 拥有多少规则；
- 有多少配置项；
- CI 通过多少次；
- UI 有多少页面；
作为单独的最终判断。
最终判断必须回到：
一个用户能否在不被迫理解系统内部复杂性的情况下，用有效配置实现自己的网络访问目标，同时在需要时仍拥有完整、透明、可验证的控制能力。
因此：
AngelaNexus 的技术复杂度可以不断增加，但用户实现目标的复杂度不应随之增加。
让用户自由选择访问互联网，是 AngelaNexus 唯一的最高目标；成全用户，是实现这一目标的核心技术原则。