Prompt for OpenCode + CodeX-5.3：多个重型任务交付给AI自动化完成

Task Goal：错误码全覆盖 + IPv6全平台修复 + TCPLink死锁修复 + 深度中英文文档 + 高级控制台界面（四阶段，并发≤24）

你是主控 AI。本次任务为全新任务，不涉及之前已完成的工作。你必须分四阶段 执行，每个阶段最大并发子代理数量均为 24（母机32核64GB，充分利用资源，但不超过24以避免过载）。

全局强制约束（所有阶段必须遵守）

全局只有一个错误处理器 （单例 ErrorHandler），所有模块共用。
错误码必须覆盖所有失败点 ：不仅定义枚举，还必须在每个 return false、return -1、return NULLPTR 等表示失败的路径中实际调用 SetLastError(ErrorCode::XXX)（或 return SetLastError(...)）。错误码必须精确等效于具体错误 ，不允许模糊笼统。如果一个错误码从未被使用，必须删除（避免代码臃肿）。最终有效错误码数量可能几百甚至上千，但重点是全面覆盖且无冗余。
代码风格强制要求 ：
- 所有注释必须使用全英语，Doxygen 风格。
- 禁止使用 nullptr ，统一使用 NULLPTR（项目已有宏或自定义，若没有则定义为 #define NULLPTR nullptr 但用宏名）。
- 常量写在比较左侧 ：例如 if (NULLPTR == ptr) 而不是 if (ptr == NULLPTR)；if (0 == ret) 而不是 if (ret == 0)。所有条件判断必须遵循此风格。
- 排版缩进必须统一（4空格），代码美观，不得乱糟糟。
不得修改三方库 ：common/ 下的 lwip、json、base、dnslib、chnroutes2、aesni、memory 等一律不动。只修改 ppp/ 下自研代码以及 Android 端自研代码。
Android 端必须同步修改：所有对 C++ 代码的修改必须同样应用到 Android 项目的 C++ 部分。确保 Android 编译通过。
UDP 共享 64KB buffer 是设计如此，不得修改：在同一线程上共享缓冲区是良好的 UDP 设计，可节约内存，且无并发问题。任何子代理不得质疑或修改此设计。
NULLOF 模板函数是设计如此，不得修改：它用于支持阻塞或异步调用两种语义，是框架的灵活设计，不是 UB，不得删除或修改。
所有修改必须通过 Windows + Linux + Android 编译验证。
主控 AI 不得直接修改代码，只负责调度。
所有子代理不得询问用户任何问题。
并发控制：每个阶段同时运行的子代理数量 ≤24。

项目上下文与编译验证

根目录：当前工作目录（已注入）
Windows 编译：build_windows.bat
Linux 编译：wsl -d Ubuntu1804，进入 /mnt/d/dd/openppp2，执行 mkdir build && cd build && cmake .. && make -j32
Android 编译：查找 build_android.sh、gradlew 或 ndk-build。如果找不到，输出提示但继续其他任务。
你拥有真实的编译执行能力。

第一阶段：架构分析（24 个分析 Agent 并行，只分析不修改代码）

目标：识别所有需要添加错误码的位置、IPv6 规则不满足的点、TCPLink 死锁的具体位置、UDP buffer 和 NULLOF 保护区域，以及现有代码风格违规（使用 nullptr、常量在右侧等），并找出所有无用代码（未调用的函数、未使用的全局变量、无用文件）以及排版缩进问题。

启动 24 个分析 Agent 并行（以下任务分配，主控可根据实际情况微调）：

Agent 1-4 ：扫描 ppp/app/server/、ppp/app/client/、ppp/app/common/、ppp/app/ 其余部分，找出所有 return false、return -1、return NULLPTR 但未调用 SetLastError 的位置，以及代码风格违规（nullptr 使用、常量在右侧）。同时标记从未被调用的函数和未使用的全局变量。
Agent 5-6 ：扫描 ppp/ipv6/ 和 ppp/net/，类似任务。
Agent 7-8 ：扫描 ppp/threading/ 和 ppp/protocol/。
Agent 9-10 ：扫描 ppp/diagnostics/ 和 ppp/transmissions/。
Agent 11：专门分析 IPv6 规则 1-3 的满足情况（全平台：Windows/Linux/macOS/Android）。规则内容见后文"IPv6 六大规则完整描述"。
Agent 12：专门分析 IPv6 规则 4-5 的满足情况（全平台）。
Agent 13：专门分析 TCPLink 死锁（规则 6）及协程锁使用。规则 6 完整描述见后文。
Agent 14：定位 UDP 共享 buffer 和 NULLOF 的所有出现位置，标记为保护区域。
Agent 15：分析 Android 端代码差异，列出需要同步的文件。
Agent 16：分析现有错误码枚举，统计已有数量，列出缺失类别，并标记未被使用的错误码（待删除）。
Agent 17-20 ：扫描整个 ppp/ 目录，找出所有未被调用的函数 （静态或非静态）、未被引用的全局变量 、未被包含的头文件（如果可能），以及整个文件是否完全无用（例如空文件、只有注释的文件、废弃的模块）。标记为待删除候选。
Agent 21-24：分析代码排版和缩进问题，输出需要格式化的文件列表（但不修改，仅报告）。例如缩进不一致、大括号位置混乱、行尾空格等。

每个 Agent 输出：

文件路径、行号、当前代码片段。
错误码缺失：建议的错误码名称。
IPv6 规则不满足：需要的修改描述（全平台）。
死锁：锁顺序图及修复建议。
保护区域：明确标记禁止修改。
风格违规：列出所有 nullptr 出现位置（改为 NULLPTR）以及常量写在右侧的位置（改为左侧）。
无用代码：列出未调用的函数（函数名、所在文件）、未使用的全局变量、无用的文件路径。
排版问题：列出需要格式化的文件及具体问题。

主控汇总所有分析报告 ，生成 docs/ANALYSIS_REPORT.md 和 docs/ANALYSIS_REPORT_CN.md，包含：

所有需要添加错误码的位置清单（按模块分组，每组 3-10 个文件）。
IPv6 六大规则的全平台修复步骤（每个平台分别说明）。
TCPLink 死锁修复补丁。
保护区域列表。
Android 端同步清单。
代码风格修复清单（nullptr → NULLPTR，常量比较调整）。
无用代码删除清单（函数、变量、文件）。
排版格式化清单。
文档大纲（要求深度重写，基于事实，详细专业，并增加更多文档章节）。

IPv6 六大规则完整描述（Agent 11-13 必须依据此规则分析）

VNP 客户端全局唯一 GUID，一个 GUID 会话只能有一个 IPv6 地址
- 检查客户端中 GUID 与 IPv6 地址的映射关系，确保不会为同一 GUID 分配多个地址。如果已有地址，新的请求应返回相同地址或拒绝并设置错误码 IPv6DuplicateGUID。
VNP 服务器/客户端支持 GUA/NAT66 地址模式，但 Windows/macOS/Android 服务器上 GUA/NAT66 不可用，需明确提示平台不支持
- 在服务器启动代码中检测平台（Windows、macOS、Android），如果配置为 GUA 或 NAT66 且平台不是 Linux，则设置错误码 PlatformNotSupportGUAMode 并输出清晰错误消息，然后回退到其他模式或退出。
VNP 服务器开启 SUBNET 子网时，VNP 客户端可以自由访问网内的其它 VNP 客户端的虚拟内网 IPv6 地址，双向访问（但仅能访问 VNP 服务器前缀范围以内的）
- 检查子网路由和访问控制：确保客户端之间的流量在服务器前缀范围内被正确转发，且不在范围外的被拒绝。需要验证 VirtualEthernetSwitcher 中的包转发逻辑，添加错误码 IPv6SubnetForwardFailed。
VNP 服务器开启 GUA 模式的情况下，VNP 客户端需要利用 NDP 代理映射到国际互联网上，所有的 VNP 客户端之间在 GUA 模式下是自由访问的，不需要考虑 SUBNET 子网标志限定，国际互联网可以自由的访问 VNP 的 GUA 地址
- 检查 NDP 代理实现（LinuxIPv6Auxiliary、WindowsIPv6Auxiliary、AndroidIPv6Auxiliary），确保 GUA 地址的邻居通告正确，路由可达。验证从外网到客户端 GUA 地址的入站连接能够到达客户端（需考虑防火墙和转发规则），添加错误码 IPv6NDPProxyFailed。
无论哪种模式，VNP 客户端都能访问真实的 VNP 服务器所在物理内网，国际互联网
- 检查默认路由和 NAT/转发规则：确保客户端能够 ping 通服务器内网地址和外部互联网地址。添加错误码 IPv6ExternalAccessFailed。
深度检测分析 VnetStack / vEthernet 的实现，重点排查 TCPLink Closing/Release 的函数，这里发现了死锁问题，这应该是个 AB/BA 问题，就是协程占有了锁没释放，但是让出了协程下个协程又冲入获取锁，然后两个协程运行在相同线程导致挂起了，这个影响到主线程死锁，然后工作运行到 TCPLINK 的后台线程也死锁了，找出问题修复它
- 定位所有协程锁使用点（co_mutex、std::mutex + 协程 yield），重点分析 TCPLink::Close 和 Release 函数中的锁顺序。
- 修复方案：统一所有锁的获取顺序，或在协程让出前释放所有锁（使用 std::unique_lock 并在 yield 前 unlock），或使用递归锁/超时锁，或改用无锁设计（std::atomic + 状态机）。
- 添加错误码 TCPLinkDeadlockDetected 并输出。

第二阶段：实现修改（多 Agent 并行，最大 24 个）

前置条件：分析报告已完成。

主控根据分析报告中的清单，生成实现 Agent 任务 。实现 Agent 必须遵守全局约束，实际调用 SetLastError，并修复所有风格违规，删除无用代码，格式化排版。

实现 Agent 分组

组 A：错误处理器基础设施（如果尚未完整存在）

Agent A1：创建/完善 ErrorHandler.h
Agent A2：创建/完善 ErrorHandler.cpp
Agent A3：创建/完善 ErrorCode.h（初始枚举，后续逐步添加，并删除从未使用的错误码）

组 B：错误码添加 + 风格修复 + 无用代码删除（按模块分组，每组 3-10 个文件）

根据分析报告中的清单，将文件分成多个组（例如 server 组、client 组、ipv6 组、net 组、threading 组、protocol 组等），每组一个 Agent。
每个 Agent 负责：
- 在每个失败点添加 SetLastError(ErrorCode::XXX); return false;（或相应返回值）。
- 将文件中的 nullptr 替换为 NULLPTR。
- 将常量比较调整为左侧（例如 if (NULLPTR == ptr)、if (0 == ret)）。
- 删除报告中标记的未调用函数、未使用全局变量、无用文件。
- 如果缺少合适的错误码，先在 ErrorCode.h 中添加新枚举值；如果发现未使用的错误码，删除它。
- 输出修改后的文件完整内容。

组 C：IPv6 六大规则全平台修复（每个规则 1-2 个 Agent，覆盖所有平台）

规则 1：GUID-IPv6 映射（Agent C1，同时修改 Windows/Linux/macOS/Android 对应代码）。
规则 2：平台检测与提示（Agent C2，所有平台）。
规则 3：子网转发（Agent C3，所有平台）。
规则 4：NDP 代理与外网访问（Agent C4 处理 Linux/Windows，Agent C5 处理 macOS/Android）。
规则 5：外网访问（Agent C6，所有平台）。
规则 6：TCPLink 死锁修复（Agent C7 实施修复，Agent C8 添加错误码和文档，并同步 Android）。

组 D：全平台路由管理（每个平台一个 Agent，最多 4 个）

Windows、Linux、macOS、Android 各一个 Agent，确保路由操作失败时设置错误码，并符合代码风格。

组 E：代码风格全局统一 + 排版格式化（1-2 个 Agent）

根据分析报告中的排版问题清单，统一缩进为4空格，调整大括号位置（K&R风格），删除行尾空格，确保代码美观。

第三阶段：收尾强制错误码全覆盖 + 全英语注释 + 文档深度重写（24 个 Agent 并行）

目标：在所有其他任务完成后，专门启动 24 个代理，为所有函数添加完整的错误码，为所有代码添加全英语注释，并深度重写所有中英文文档。

3.1 强制错误码全覆盖（24 个 Agent）

主控获取整个 ppp/ 下所有自研代码文件列表（排除 common/ 三方库）。
将这些文件分成 24 组（尽量均衡），每组启动一个 Agent。
每个 Agent 的任务：
- 遍历组内的每个函数。
- 检查该函数中所有可能失败但尚未调用 SetLastError 的路径（包括 return false、return -1、return NULLPTR、goto error 等）。
- 为每个失败路径添加 SetLastError(ErrorCode::XXX);（如果已有错误码则复用，否则添加新枚举）。
- 确保错误信息文本（FormatError 映射）也已同步添加。
- 同时修复任何遗漏的风格违规。
- 删除任何未被使用的错误码（确保错误码与错误一一对应，无冗余）。
- 输出修改后的文件完整内容。

3.2 全英语注释（可与 3.1 合并或单独 24 个 Agent）

同样将文件分成 24 组，每个 Agent 为组内文件添加全英语 Doxygen 注释：
- 文件头注释（@file, @brief, @author, @license）。
- 类/结构体/枚举注释（@brief）。
- 函数注释（@param, @return, @note）。
- 复杂逻辑块行内注释。
注释必须基于代码事实，准确描述功能和设计意图。

3.3 深度重写中英文文档（每个文档一对，最多 24 个 Agent）

要求：文档必须深度重写 ，基于工程代码事实，极其详细专业 ，覆盖原理、思想、原因、理由、用途、推荐/建议、注意事项、FAQ、帮助等。同时添加更多文档（不限于下面列表，可根据工程实际情况增加）。
至少包括以下文档（每对由 1 个 Agent 完成）：
- README.md / README_CN.md
- ARCHITECTURE.md / ARCHITECTURE_CN.md
- IPV6_RULES.md / IPV6_RULES_CN.md
- ERROR_HANDLING.md / ERROR_HANDLING_CN.md
- TRAFFIC_LOG.md / TRAFFIC_LOG_CN.md
- DEADLOCK_FIX.md / DEADLOCK_FIX_CN.md
- CODING_STYLE.md / CODING_STYLE_CN.md
- FAQ.md / FAQ_CN.md
- CONTRIBUTING.md / CONTRIBUTING_CN.md
- 其他你认为需要的文档（例如 UDP_BUFFER_DESIGN.md、NULLOF_DESIGN.md、ANDROID_BUILD.md 等）。
每个 Agent 输出完整的 .md 和 _CN.md 文件内容。

第四阶段：高级控制台界面实现（24 个 Agent 并行，全平台）

目标：删除旧的 PrintEnvironmentInformation 函数（或 LogEnvironmentInformation，如果存在），实现一个类似 OpenCode 或 gdb -tui 风格的高级控制台界面。渲染必须使用单独线程或非阻塞定时器，不得影响主线程（全局调度线程和虚拟以太网卡IO线程）的性能。界面应具备：

顶部显示程序标题和状态概览。
主体区域显示 VNP 运行信息（接口、协议、服务器/客户端状态、流量统计等），支持滚动（上下光标键、PageUp/PageDown）。
底部状态条：显示当前错误状态文本及错误发生时间（时间使用 Executors::GetTickCount() 获取系统运行毫秒数，缓存每 10 帧刷新一次，显示相对秒数）。错误文本必须与错误码精确对应 （通过 FormatError 获取）。
最底部命令输入行：用户可输入交互命令（例如 help、restart、exit 等），并回显执行结果。
所有渲染必须非阻塞，不影响 VNP 数据转发性能。
兼容 Windows、Linux、macOS 终端（使用标准 ANSI 转义序列，Windows 需启用虚拟终端处理）。
设计为独立线程或使用 io_context 的定时器，避免阻塞主事件循环。

具体任务拆解：

4.1 删除旧的状态打印函数（1 个 Agent）

定位 PppApplication::PrintEnvironmentInformation() 及其调用（可能在 OnTick 中），删除该函数及其所有调用。同时删除任何 LogEnvironmentInformation 函数（如果存在）。

4.2 设计控制台界面核心类（3-5 个 Agent）

创建 ppp/app/ConsoleUI.h 和 ppp/app/ConsoleUI.cpp，实现 ConsoleUI 单例类。
类应包含：
- 屏幕缓冲区（双缓冲或环形缓冲区），支持滚动。
- 渲染函数 Render()，由单独线程或定时器调用，不得在主线程中直接调用。
- 输入处理函数 HandleInput()，使用非阻塞读取（例如 std::thread + getchar 或 select）。
- 命令解析与执行函数 ExecuteCommand(const std::string& cmd)。
- 状态更新函数 UpdateStatus(const VNPStatus& status)，由 OnTick 通过线程安全队列传递给渲染线程。
使用 ANSI 转义序列控制光标位置、颜色、清除行等。Windows 上需调用 SetConsoleMode 启用虚拟终端处理。

4.3 实现底部状态条及错误显示（2 个 Agent）

状态条显示：
- 当前错误码文本（从 ErrorHandler::GetLastError() 获取）和错误时间。
- 时间计算：保存错误发生时 Executors::GetTickCount() 的值，每次渲染时计算差值秒数，显示如 Error: ConfigFileNotFound (5s ago)。
- 其他状态（连接状态、流量速率等）。
错误时间缓存：在 SetLastError 时同时记录时间戳（thread_local uint64_t error_timestamp），渲染时使用。

4.4 实现滚动显示区域（2 个 Agent）

主体区域保存一个环形缓冲区（最多 1000 行），每行是字符串。
支持上下键、PageUp/Down 滚动，当前滚动偏移量。
当新状态行加入时，自动滚动到底部（如果用户在底部）或保持偏移量。

4.5 实现命令输入行（2 个 Agent）

底部固定一行用于输入，支持行编辑（左右箭头、Backspace、Delete、Home、End）。
历史命令记录（上下键）。
支持的命令至少包括：help（显示帮助）、restart（重启VNP）、exit（退出程序）、clear（清屏）、status（显示完整状态）、setloglevel（如需要）等。
命令执行结果输出到主体区域。

4.6 集成到主循环（2 个 Agent）

修改 PppApplication::OnTick 或其他主循环，不再直接调用渲染，而是通过线程安全队列将状态数据传递给渲染线程。
启动一个单独的渲染线程，每秒渲染 10 次（可配置），使用条件变量等待更新或定时触发。
处理控制台窗口大小变化（通过 SIGWINCH 或 Windows 控制台事件），通知渲染线程重新布局。

4.7 全平台适配与测试（2 个 Agent）

确保 Linux/macOS 终端正常工作。
确保 Windows 控制台启用 ANSI 支持（如果失败则回退到无颜色简单模式）。
编译验证通过。

输出要求：

新增的 .h/.cpp 文件完整代码。
修改的现有文件（如 PppApplication.cpp、OnTick 相关）的 diff。
删除旧函数的位置确认。
测试通过的控制台截图描述（文本描述即可）。

主控执行流程（总览）

第一阶段 ：启动 24 个分析 Agent，收集报告，生成 docs/ANALYSIS_REPORT.md 及中文版。
第二阶段：根据分析报告，生成实现 Agent 任务（组 A、B、C、D、E），使用队列控制同时运行 ≤24 个 Agent。等待所有完成。
第三阶段 ：依次或并行启动三个子阶段：
- 3.1 强制错误码全覆盖（24 个 Agent）
- 3.2 全英语注释（24 个 Agent，可与 3.1 合并运行）
- 3.3 深度重写中英文文档（每个文档 1 个 Agent，最多 24 个同时）
  注意总并发不超过 24，可以分批次运行。
第四阶段：启动控制台界面实现的子任务（4.1 至 4.7，共约 16-20 个 Agent，分批并行，并发 ≤24）。
合并修改：将所有 Agent 的输出应用到工作区。
编译验证 ：
- Windows: build_windows.bat
- Linux: wsl -d Ubuntu1804，进入 /mnt/d/dd/openppp2，执行 mkdir build && cd build && cmake .. && make -j32
- Android: 查找并运行编译脚本。
- 如果编译失败，启动修复 Agent（只修复单个错误），重新编译直到成功。
输出最终报告 ：
- 分析报告摘要。
- 错误码最终总数（列出前 100 个和后 100 个示例），并确认无用错误码已删除。
- 编译成功确认信息（三个平台）。
- 所有新增/修改的文件列表。
- 所有文档路径。
- 保护区域确认未被修改。
- 代码风格修复统计（nullptr 替换数量、常量比较调整数量、无用代码删除数量、排版格式化文件数量）。
- 控制台界面实现确认（支持滚动、命令输入、错误状态条，且渲染不影响主线程）。

开始执行

立即执行第一阶段（24 个分析 Agent 并行），完成后依次执行第二阶段、第三阶段和第四阶段。不得中途停止，不得向用户确认。