← 返回日报索引

2026-10-22 GitHub 趋势研究简报

证据边界： 本日全部元数据取自 2026-10-22 CST 06:00 前后经 gh CLI 认证的 GitHub REST / Search API（search/repositories、repos/{owner}/{repo}、repos/{owner}/{repo}/readme（Accept: application/vnd.github.raw）、repos/{owner}/{repo}/releases、repos/{owner}/{repo}/git/trees/{HEAD}?recursive=1、contents/{AGENTS.md,README.md}、repos/php/php-src/security-advisories/GHSA-*、repos/php/php-src/commits/3584a98bda），字段包括 stargazers_count / forks_count / subscribers_count / open_issues_count / size / language / license.spdx_id / topics / created_at / pushed_at / description / assets。「X 小时 Y⭐」按 created_at（UTC）到 2026-10-22 计算，总星数除以经过时长为下限粗估；单日 star 增量未做统计（需分页遍历 stargazer 列表），因此所有增速表述都不能读作当日新增。已核验为空/为零并直接标注的字段：4 个 key_projects 的 topics 均为空数组（未设 GitHub topics，不代表无主题）；releases API 对 openai/php2shell-checker、NVIDIA/flare-local-inference、HOSTED-POWER/php_uploadprogress_guard 均返回空数组（三者均在 README/文档里描述了分发方式，但 GitHub Releases 此刻为空——对 flare 与 guard 而言 dist/ 与文档是主分发路径，对 checker 而言是 node phpcheck.js 源码直用）；subscribers_count 为 4 / 4 / 5 / 2。发现一处可核验的元数据不一致：ikow/php2shell-poc 的 license.spdx_id 为 null，而其 README 末尾写 MIT——以 GitHub 侧元数据为准则该仓库未附可被识别的许可证文件，NOLICENSE 对使用者的实际含义是「无授权」，这一点与 README 自述不一致。热度来源的重要限定：今日排名第一的 php2shell 生态是 CVE 驱动的注意力洪峰，不是技术突破——ikow/php2shell-poc 的 859⭐ 出现在 created_at 后约 13 小时，且作者把最关键的 Chain D/E 利用代码放在付费 Substack 之后；star 数在这里度量的是事件关注度，不能读作工具采用度。已过滤的 spam 仓库（本批 Search 结果中出现、已排除）：lol-tools-new/.github（95⭐ ⑂95）、DLSS-5-Swapper-Download-2026/.github（86⭐ ⑂50）、DLSS-5-Swapper-Update-Download/.github（76⭐）、cs-tool-s/.github（244⭐ ⑂216）、val-tools/.github（242⭐ ⑂238）、rbl-tools/.github（240⭐ ⑂196）、shareshellrelease/Cinema-4d（82⭐）、ThresholdSummoner/Camtasia（80⭐）、slaterockweb/BorisFX（80⭐）、Torrentthefoundry/KMS-Pico（80⭐）——前 6 个与昨日已过滤的 *-tool(s)/.github 属同一可核验模式（.github 作仓库名 + *-tool(s)/.github 命名 + fork/star ≥ 0.5），后 4 个为同一模式（80–82⭐ ⑂0 + size 2 KB + 统一「Full working installer…Ready to run」描述的破解软件仓库）。未纳入 key_projects 的候选及原因：eness/php2shell-CVE-2026-109618-CVE-2026-109619-PoC（530⭐ ⑂94，Shell 215 KB，无 license）、9bie/php2shell-bypass-aslr-exp（356⭐ ⑂130，21.5 MB，description 为 null，无 license）、Zer061/CVE-2026-109618（52⭐ ⑂39）、junaire/CVE-2026-109618-exploit（74⭐ ⑂49）、wakemeiflose/php2shell（34⭐ ⑂14）、JoasASantos/php2shell-scanner（44⭐ ⑂15）、syhunt/php2shell-protection（62⭐ ⑂6）——均为同事件的 PoC/检测变体，作为「生态规模」的证据被引用，但与 ikow/php2shell-poc 内容重叠，本报不重复建档；eagle-hq/EAGLE-4（713⭐ ⑂18，Official Inference Code of EAGLE-4，NOASSERTION，本窗口未取 README 内容，模型与许可均无法核验）；lesnolie/Tigris（222⭐ ⑂20，Kotlin MIT，中文 tvOS 26 风格 Android TV 桌面，声明已在索尼 BRAVIA XR-55A80J 验证）、op7418/guizang-tv（137⭐ ⑂22）、Jimu888/home-tv-cn（41⭐，明确写着「基于 Aerial 定制」）——Android TV 桌面赛道连续第 5 天有新项目，但赛道已在 10-19/10-20/10-21 三份日报完整记录（free-my-tv / aerial-tv 等），今日不重复建档，仅作为赛道延续性记录；eagle-hq/EAGLE-4 与 flare 同属「官方开源推理代码」形态，属另一条观察线。延续跟踪：本日不新增延续跟踪条目（simbasjungles/free-my-tv、pengchujin/aerial-tv、vercel-labs/fx0 等昨日已建档项目的今日状态留给下一次日报统一处理，避免重复计入趋势指数造成失真）。

今日重点趋势（按排名）

趋势 1：php2shell —— 一个 PHP 补丁被拆成四层职责，各自认领（趋势分 92）

先固定事实基线（全部来自 GitHub 官方接口）：

事实 来源
CVE-2026-109618 / GHSA-w8hw-w9fx-j79w，severity critical，summary RCE via OOM corruption，published 2026-10-21T13:34:25Z repos/php/php-src/security-advisories/GHSA-w8hw-w9fx-j79w
CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp，severity critical，summary RCE via stale global state，published 2026-10-21T13:34:13Z repos/php/php-src/security-advisories/GHSA-6wmf-4rv5-p3rp
官方补丁 commit 3584a98bda，作者日期 2026-10-18T15:26:39Z，标题 Avoid state corruption via bailout，改动 300 个文件 repos/php/php-src/commits/3584a98bda
首个发布标签 php-8.5.12，published 2026-10-21T14:06:46Z repos/php/php-src/releases
官方判定受影响 < 8.2.35 / < 8.3.36 / < 8.4.27 / < 8.5.12（四条分支各一个 patched 版本） 两条 advisory 的 vulnerabilities 数组

advisory 发布（13:34Z）到 release 发布（14:06Z）只隔了 32 分钟，而补丁 commit 的作者日期比 advisory 早 3 天——修复早于披露，披露早于分发，这条时间线是今天所有下游工作的起点。

接下来是一天之内长出的四层：

第一层：谁解释漏洞 —— ikow/php2shell-poc（859⭐ ⑂308，fork-star 35.9%）。作者 Qi Deng，13 小时星数。它把两条 CVE 拆成五条链，并明确标出每条链的「是否预认证 / 需要什么条件 / 适用哪个 SAPI」：

README 自己判定 Chain D 最关键：「zero-dependency pre-auth RCE against any Apache mod_php installation. No LFI, no app vulnerability, no authentication — just a single multipart POST」。仓库结构与这个分层是自洽的：exploit/ 只放 A/B/C 三个文件，poc/ 放五个验证脚本（含 ASAN 版 verify_uaf_asan.php），lab/ 提供 PHP-FPM + nginx + Apache mod_php 的 docker-compose.yml 一键靶场，detection/ 放四类规则。

第二层：谁检测 —— ikow/php2shell-poc 自带 php2shell.rules（Suricata/Snort IDS）· php2shell.yaml（Sigma SIEM）· modsecurity.conf（ModSecurity WAF）· php2shell.lua（OpenResty/Nginx Lua 模块）；openai/php2shell-checker（310⭐ ⑂22，Apache-2.0，26 KB）走另一条路——不做检测，只做版本判定，并把它包装成两个 skill（skills/phpcheck-server/SKILL.md 有服务器权限时用、skills/phpcheck-url/SKILL.md 只有 URL 时用），入口是 node phpcheck.js "<url>" 或 node phpcheck.js --local，退出码 0=OK / 1=VULNERABLE / 3=UNKNOWN，--json 输出 patch_status。它最值得抄的不是代码而是 Limitations 段：「OK is a version comparison based on the assumption that subsequent stable patches in each listed branch contain the fix. It does not independently verify a security fix.」「Headers can be hidden or changed, and distribution backports may not change the upstream version. UNKNOWN does not mean the target is patched!」——在一个所有人都在抢着发「我的一键检测」的窗口里，明确写出自己的结论不能被当证据，是罕见的自我设限。

第三层：谁在国家层面处置 —— NCSC-NL/php2shell（96⭐ ⑂21，EUPL-1.2，subscribers_count = 8 为本批最高）。荷兰 NCSC 以 TLP:CLEAR 发布（README 标注 last significant change 21 October 2026 17:25 CEST），指明 CERT-EU 追踪编号 2026-018，并给出两条 advisory 都没有强调的一句：「The impact is not limited to websites: PHP is also embedded in appliances, network devices, management interfaces and other vendor products where administrators may not be able to update PHP directly.」 处置建议里包含 session.upload_progress 禁用、重启 worker、memory_limit / post_max_size / PHP 8.5 fatal_error_backtraces 指引，并诚实标注 「PHP states that these measures are not complete fixes」。仓库里 software/ 目录放的是「有 PHP 依赖的受影响软件产品清单」——这是把「78% 的网站」这类统计换成具体产品名单的动作。

第四层：谁在等补丁期间先保住机器 —— 这正是趋势 2 的 HOSTED-POWER/php_uploadprogress_guard。

趋势 2：把「等补丁」这段空窗期做成可安装软件（趋势分 89）

HOSTED-POWER/php_uploadprogress_guard（53⭐ ⑂4，C，MIT，12 小时）是今日四个项目里唯一不是 PoC 也不是 PoC 检测的项目，也是唯一一个把缓解措施本身当作产品来交付的。它的核心动作是把官方补丁逐组件镜像进一个可加载的 PHP 扩展，从而「在未打补丁的 PHP 上移除已公布攻击链的每一环」。

它的 README 从一个反直觉的建议开始：「Install the official PHP release… we recommend it without reservation. This module protects an unpatched PHP for real.」 并给出理由——包管理器可能明天就供上补丁，也可能永远不供（发行版停更的 LTS、嵌入式设备、被厂商锁死的 appliance）。这个表述把项目的定位卡得很准：它不是补丁的替代品，是补丁的候补。

技术上三个机制（README 明示）：v3.0.0 移除 session upload-progress handler + 携带修复版 parser + 让 parser 本身不可能 OOM（headroom guard 保留 memory_limit 的八分之一）；mode=native 改为在 OOM 时直接结束进程（exit 137）而非继续服务下一个请求；mbstring.encoding_translation=On 的宿主交还给 PHP 自带 parser，因为 mbstring 的多字节 hook 是 file-static、无法镜像（但 callback detach 仍然生效）。

最见工程功力的是「自检让位」机制：用 nm -D 探测引擎是否导出了修复符号，已带官方补丁就报告 carries the official fix => yes (fix symbol exported by the engine; parser replacement skipped)。README 给出了逐版本的结果：Sury 的 5.6.40-104 / 7.0.33-92 / 7.3.33-35 / 7.4.33-31 / 8.1.34-9 / 8.3.36-1 全部报 yes，官方 docker 的 8.4.11 / 8.1.20 / 7.4.33 / 5.6.40 全部报 no 且全部机制 active；并说明「Neither fix symbol exists on any unpatched engine (nm -D)」。这意味着装了它的机器在升级 PHP 后会自己退场，不需要任何人工卸载动作——这是临时缓解方案最重要的工程属性。

它的 7 组实测记录是本日可复核性最高的材料（README 原文摘录）：

场景 无模块 装模块
php-cgi，15000 字段的单个 multipart body，未打补丁 8.4.11 / 8.1.20 / 7.0.33 / 5.6.40 exit 255 Allowed memory size exhausted（请求启动期间） mode=native → exit 137（进程结束）；默认 mode=parse → exit 0 + Status: 413（headroom guard，根本没触发 OOM）
php-fpm，GET 后接一个带文件字段的 OOM POST，再 GET（8.4.11 / 7.4.33 / 5.6.40） 留下 1 个孤儿上传临时文件（code 70） mode=native worker 因 child exited with code 137 被回收，0 孤儿文件；mode=parse 回 413，复用同一 worker，0 临时文件
set_error_handler + 未定义变量 + trigger_error，15000 字段 POST（8.4 与 5.6） — OK:15000 handled: … handled: custom → 请求状态重置不动用户的错误处理器
OPcache 编译窗口（memory_limit=20M，5.5 MB 脚本首编 + 9 MB POST in-memory） Allowed memory size … in Unknown on line 0，错误落在 OPcache store 内部 compiled+ran, memory_limit=20M，第二次请求正常
cPanel EA4 ea-php83 8.3.35 on AlmaLinux 10.2（glibc 2.39）· DirectAdmin CustomBuild php84 8.4.22 on Debian 13 — 均加载预编译文件并报 detached；cPanel 上新开 php-cgi -m 列出模块
Ansible 幂等性（tag-scoped phpguard run + 二次 run + 全量 untagged deploy） — ansibletest failed=0，二次 changed=0，全量部署 ok=1506 failed=0；web1/2/3 经 AWX 各 changed=4，fpm 重启，二次 changed=0；cpanel1.staging 8.1–8.4 failed=0 changed=0；directadmin1.staging 8.2–8.4 failed=0 changed=0 且三个 fpm 全部重启

并且两次回归都被写在 README 里：v3.0.0 在 PHP 7.0–7.4 上因读取了 8.0.28 才存在的 ini 而拒绝所有 multipart 请求（Multipart body parts limit exceeded 0）——v3.0.0 修了它；v3.0.0 的 8.2–8.5 二进制构建于 Debian 13 因而要求 GLIBC_2.38，在 Debian 12 及更早上加载失败（PHP Startup: Unable to load dynamic library，PHP 继续运行但没有 guard）——v3.0.1 修了它，build.sh 现在拒绝任何高于 GLIBC_2.14 的构建。

架构师速览（php_uploadprogress_guard）：

决策问题 研究判断 证据边界
系统边界 一个 PHP 扩展（src/hp_uploadprogress_guard.c + config.m4）+ 按 PHP minor 预编译的 NTS x86_64 .so 与 SHA256SUMS（dist/）+ 重建脚本（build.sh，从官方 php:<X.Y>-cli 镜像重建）+ 测试三件（test/probe.php、test/run-builtin-server.sh、test/fcgi-probe.py）+ 实际部署用的 Ansible task 与 ini（ansible/）。控制面在 PHP 引擎内部（handler 摘除 + parser 替换 + 内存余量闸门），数据面是 multipart 请求解析 全部来自 README 的「Repository layout」与「v3.1.0」测试段；flare 式的内部符号级实现细节（具体 patch 了哪些引擎内部结构）README 未展开，只说 mirrors the official fix component by component
主路径 请求进入 → PHP 启动/请求初始化阶段 session upload-progress handler 已被摘除（对 109619 的直接对策）→ parser 换成修复版并带 headroom guard，memory_limit 的八分之一保持空闲（对 109618 的直接对策）→ 若真发生 OOM，mode=native 结束进程而非让半初始化状态继续跑 → 请求结束后状态被重置，用户的 error handler 不受影响 → 升级到带官方补丁的 PHP 后，nm -D 探测到修复符号即跳过 parser 替换 逐条来自 README 的 v3.1.0 测试表、tmp 文件计数、error handler 测试、fix detection 段；headroom guard 与 OOM exit 的优先级关系、mode=parse 与 mode=native 的自动选择逻辑 README 未说明
关键权衡 自研缓解层（覆盖补丁空窗期，代价是必须逐版本跟引擎结构）vs 只发检测（安全但不阻断）vs 等发行版 backport（最稳但可能永远不来） · mode=parse 返回 413（保住进程，但改变了服务端对超大 multipart 的响应语义）vs mode=native 直接 exit 137（语义最贴近「崩溃」，但牺牲 worker）· 预编译二进制覆盖 5.6–8.5 十二个 minor（覆盖广，但每个都要单独构建与测试）vs 只支持当前分支（省事，但嵌入式与 LTS 机器恰恰是老分支）· 在 mbstring.encoding_translation=On 的宿主上放弃镜像 parser（诚实降级）vs 强行镜像（可能出错）· 主动向 PHP 官方发行版退让（自检到已修复就跳过）vs 长期驻留（与官方补丁冲突的风险） README 明示「we recommend it without reservation」「it notices and steps aside」「steps aside on its own, so there is nothing to undo」以及 mbstring 与 max_multipart_body_parts 的两处降级说明；未明示：12 个 minor 二进制的构建矩阵如何维护、与未来 CVE 的兼容性、以及长期维护者承诺
最小 PoC 1. 找一台不能升级 PHP 的机器（发行版停更 / 厂商 appliance / 自编译旧版）→ 2. 核对 nm -D $(php -i \| grep extension_dir) 确认修复符号不存在（README 用这条命令证明未打补丁机没有该符号）→ 3. 从 dist/ 取对应 minor 的 .so 并核对 SHA256SUMS → 4. 用 test/probe.php 确认模块加载且报 detached → 5. 用 test/run-builtin-server.sh 复现 v3.1.0 表：15000 字段 POST 前后各一次 GET，确认得到 Status: 413（mode=parse）或 worker 被回收且无孤儿临时文件（mode=native）→ 6. 装一个带 set_error_handler 的脚本，确认 handled: 前缀仍在（证明未改用户代码语义）→ 7. 跑一次 Ansible tag-scoped 部署，再跑第二次确认 changed=0（幂等性是这个项目最值得学的工程纪律）→ 8. 升级 PHP 到带补丁版本，确认 php -v / 模块自检报告 carries the official fix 并自动让位 PoC 顺序完全按 README 已给的证据链倒排；第 2 步与第 8 步是整个 PoC 的意义所在：证明「装了会自己退场」这一点，比证明「装了能挡住」更重要；第 5 步是唯一真正需要自己动手的部分，前 3 步的产物 README 都已提供

趋势 3：大厂把研究原型当研究原型发布（趋势分 86）

NVIDIA/flare-local-inference（485⭐ ⑂47，fork-star 9.7%，Apache-2.0，NVIDIA 官方组织，2 天）的 README 有一个细节值得单独记：第一句是对 agent 说的——「Coding agents: skip this README and read AGENTS.md directly.」

架构上，它把「构建期」与「运行期」切成一条硬边界并写进代码库结构：

四条设计原则里最有信息量的是第三条：「Make memory and state explicit. Plan buffers and execution capacities ahead of time. Treat conversation state—including recurrent state alongside KV caches—as a whole, so reuse, branching, and resuming preserve it correctly.」——把循环状态（recurrent state）与 KV cache 当作一个整体来规划，正是 2026 年 serving 设计的核心争论点，而 README 把它列为原则而非实现细节。

它同时划了两条非常少见的边界。第一条在 README：「Flare is not, and will never, be a replacement for production inference engines like vLLM.」第二条在 AGENTS.md，而且是面向所有贡献者（含 agent）的三类驳回标准：

还有一句直接针对 agent 生成的贡献：「Hypothetical future consumers, agent-generated suggestions, and lint findings alone do not establish a need for a change.」 并且把发版纪律写成流程：进入 clone 后与 pull 后必须重读 AGENTS.md 与 docs/design-review.md，提交前启用 .githooks/commit-msg 钩子并按该文档做 staged-diff 复核；「A rejected acknowledgment requires reading that document and reviewing the staged change before retrying; do not treat the rejection as a formatting repair」——最后这半句是针对「agent 收到拒绝后当成格式问题去改」的防御性设计。

架构师速览（flare）：

决策问题 研究判断 证据边界
系统边界 四块且依赖方向单向：Ignition（Python，准备期：加载/调 kernel/编译/图捕获 → 运行时包）· Heliopause（crate，提供 flare_heliopause 扩展）· Helios（Rust 运行库，无 Python 与准备工具依赖，负责调度、缓存存储、请求处理）· Orbit（管理服务流程所需的主机、准备、包与 rank 进程）。数据面是 CUDA graph 驱动的推理；控制面是准备期产物（运行时包）与多主机调度 AGENTS.md 开篇的依赖描述 + README 四条原则 + 仓库树中 ignition/ heliopause/ helios/ flare/ 四目录与 docs/ 下的 orbit.md multi-host.md；Ignition 产出物的具体格式（docs/runtime-package-design.md 存在但本窗口未取其内容）与签名机制（docs/signing.md 存在）待核验
主路径 主机侧用 PyTorch/Transformers/FlashInfer/b12x 把选定模型配方编译并捕获 CUDA graph → 打成运行时包 → Orbit 把包分发到目标主机、起 rank 进程 → Rust CLI 经 Helios 直接执行已捕获的 CUDA graph 服务请求，全程无 Python、无运行期编译、无稳态 GPU 分配 → 会话状态（循环状态 + KV cache）按预规划容量整体复用，支持分支与恢复 全部由 AGENTS.md 的依赖方向、README 的「Compilation and graph capture finish before serving」与「the runtime owns scheduling, cache storage, and request handling」推出；分支与恢复的具体实现（docs/prefix-cache-offload.md / docs/scheduling-*.md 存在但本窗口未取内容）待核验
关键权衡 构建期 PyTorch 生态 vs 运行期 Rust（编译期灵活、服务期轻）vs 全 Python（简单但服务期重） · 复用规范模型实现 vs 为布局/执行不同的部分特化（README 明示后者是例外而非默认）· 提前规划内存与容量（稳态无分配）vs 动态按需分配（灵活但引入抖动与碎片） · 聚焦硬件（仅 SM120/SM121）与模型覆盖（换取聚焦的服务契约）vs 广覆盖（vLLM 的路子） · 贡献闸门严格（拒绝范围蔓延 / 拒绝架构违规 / 拒绝削弱保证）vs 接受度与迭代速度 · 发布研究原型收早期反馈 vs 等更成熟再开源 README 四条原则 + 「Flare trades that breadth for a focused serving contract」「Flare is not, and will never, be a replacement for production inference engines like vLLM」+ AGENTS.md 三类驳回标准与「This is a research prototype, and is made available via open-source to enable technical collaboration and collect early feedback」；未明示：SM120/SM121 具体对应哪些 GPU、聚焦模型清单、以及哪些部分已有实测数据
最小 PoC 1. 确认机器是 SM120 或 SM121（README 未给检测方法，docs/cli-design.md 可能有）→ 2. 按 docs/model-preparation.md 准备一个受支持模型配方 → 3. 用 docs/container.md 或 docs/debian.md 起环境 → 4. 只起单机（README 明示 single-host execution 在范围内），跨节点 TP 放到最后 → 5. 用 docs/clients/codex.toml / claude-code.json 的客户端配置接上 → 6. 只测一个明确工作负载：长会话 + 重复工具调用（README 自述的定位场景）→ 7. 故意在同一会话里做一次「恢复」与一次「分支」，核对会话状态（含循环状态与 KV cache）是否被整体保留——这是 README 第三条原则唯一可证伪的地方 → 8. 跑 ./.github/workflows/native-serving.yml（仓库内存在该工作流）对照 PoC 顺序按依赖倒排且刻意只测单机；第 1 步（硬件判定）与第 7 步（状态整体性）是本项目最关键也最缺公开说明的两个点，前者 README 未给命令，后者只能靠 docs/prefix-cache-offload.md 与 docs/scheduling-theory.md 补

趋势 4：多 agent 终端从「多标签」到「多 agent 状态机」（趋势分 84）

dominikmartn/harp（527⭐ ⑂29，Rust，AGPL-3.0 但 warpui 与 warpui_core 两个 crate 为 MIT，217 MB，个人项目，2 天 4 个 release：v0.1.0 10-20 11:13Z → v0.1.1 13:43Z → v0.1.2 18:09Z → v0.1.3 10-21 10:29Z）是 Warp 的非官方 fork，核心动作一句话说清：把 tab bar 换成专门为长跑型 coding agent 设计的侧边栏，其余保持 Warp 原样。

侧边栏每行显示的状态是：working / waiting for you / done / inactive，配一个「未读标记，直到你真的看过才消失」；一个小圆点表示后台任务仍在跑；一个月亮表示你把这个 tab 置入了暂存；Cmd+R 重命名 tab。

限额环（limit rings）是本项目最可借鉴的设计。每个 provider 两个环——5 小时窗口与周限额，悬停显示数字与重置时间。数据来源分两种，README 说得很清楚：

并且它把信任边界写成了三句否定：「Harp fetches nothing and reads no credentials.」「Everything else is upstream Warp… They talk to Warp's servers exactly as upstream does; Harp adds no servers of its own.」「Logging in through Harp is untested.」

tmux 集成的思路同样值得记：打开后，分组名与顺序存在 tmux session 本身上，因此跨重启存活，且其他 tmux 客户端看到同一布局；从手机 ssh 起的 session 可以用 tmux set-option @warp_adopt 1 认领一个 tab。默认关闭，开启后每 10 秒轮询。

它还明确列出「故意移除」的东西：tab bar 的搜索框、视图选项、tab 配置按钮、侧边栏分隔线选项、标题条面板开关。以及调试开关的用途——WARPOSS_STATUS_TRACE=1 把每一行状态的每次变化写成 ~/Library/Logs/harp.log 的 [status-check] 行，「以对照某个 agent 的 transcript 做回归检查」；WARPOSS_SKIP_LOGIN=1 用测试用户启动并让所有认证请求失败以便自动化。

架构师速览（harp）：

决策问题 研究判断 证据边界
系统边界 一个 macOS 桌面 App（Warp 的 fork，AGPL-3.0，warpui/warpui_core 为 MIT）。侧边栏替代 tab bar；限额环从两个本地来源读（Codex 的 ~/.codex/sessions 日志、Claude Code 的 status line 输入）；tmux 集成为可选（默认关闭）；云功能（agents / Warp Drive / session sharing / login）仍直连 Warp 的服务器，Harp 不自建服务器。控制面：agent 状态探测 + 限额读取 + tmux 轮询；数据面：本地文件（~/.codex/sessions、~/.harp/claude-statusline.json、~/.harp/settings.toml）+ tmux session 属性 全部来自 README 的 What it adds / Settings / 贡献者细节三段；agent 状态的判定机制（读 transcript？调 hook？）README 只提了一个「reports background tasks to the sidebar」的 Claude Code hook（integrations/claude-code/README.md），主路径待核验
主路径 启动 → 侧边栏为每个 tab 探测 agent 状态并归入 working / waiting / done / inactive + 未读标记 → 每 10 秒轮询 tmux（若开启）同步 tab 名、分组、顺序与 read/inactive 标志，并从 tmux 属性读限额或按 session_script 执行自定义脚本 → 限额环读 Codex 的 rate_limits 日志与 Claude Code 的 status line 输入 → 若用户已有 statusLine 则不改动，若无则由 Harp 写入一个并把输入落盘到 ~/.harp/claude-statusline.json → 一切云功能仍走 Warp 上游 逐条来自 README；「Harp adds a statusLine if none exists」这条路径的失败模式（status line 被用户换掉、Claude Code 改格式）README 未讨论
关键权衡 fork 上游（Warp）拿全部既有功能 vs 从零写（无兼容负担）——README 明确 Harp 不生产可用的更新：这是 fork 路线最本质的债 · 读本地文件与日志拿限额 vs 请求云端 API（后者准确但要凭据）——选择本地读并因此只能用 status line 这条间接通道 · 自动注入 status line（开箱即用）vs 不动用户配置（尊重但用户要自己配）——README 选了「有就不动，没有才加」的折中 · tmux 集成默认关闭（多数用户不需要）vs 默认开启（多 agent 玩家的核心诉求） · AGPL-3.0（改动必须开源回流的强约束）vs MIT（更易集成）——Harp 用「warpui 与 warpui_core 两个 crate 例外为 MIT」给自己留了口子 README 明示「does not produce usable updates」「Harp fetches nothing and reads no credentials」「Harp adds no servers of its own」「Logging in through Harp is untested」「if ~/.claude/settings.json has no statusLine yet, Harp adds one… A status line you already have is left alone」与许可证例外条款；未明示 fork 与上游的同步策略、以及 AGPL 例外是否会随上游改动失效
最小 PoC 1. 从 Releases 取最新 DMG 拖入 Applications（v0.1.3 已发布，这条路今天就能走通，与昨日 opentrap 的空 releases 形成对比）→ 2. 同时开一个 Claude Code 会话与一个 Codex 会话，不要设任何 status line → 3. 启动 Harp，核对是否出现两个限额环（悬停应显示 5 小时窗口与周限额的数字与重置时间）→ 4. 检查 ~/.claude/settings.json 是否被写入了一个 statusLine，以及 ~/.harp/claude-statusline.json 是否生成 → 5. 现在把 status line 改成自己的一条命令，核对 Harp 不再改动它（README 明示已有则不碰），并按 README 提示改成 tee ~/.harp/claude-statusline.json \| 你的命令 → 6. 观察五个状态是否随 agent 实际行为切换，并用 WARPOSS_STATUS_TRACE=1 把 ~/Library/Logs/harp.log 的 [status-check] 行与某个 agent 的 transcript 对照，验证状态判定不是猜的 → 7. 打开 tmux 集成，建两个分组，重启一次，核对分组名与顺序是否仍在、其他 tmux 客户端是否看到同一布局 → 8. 从手机 ssh 上去 tmux set-option @warp_adopt 1 认领一个 tab PoC 逐步来自 README；第 6 步是本项目最有价值的验证动作——它把「状态显示对不对」从主观感受变成可对照的日志证据；第 3 步可能失败（若 Claude Code 走的是 API key 而非 Claude.ai 计划，README 明示此时不出现环）

最值得关注的方向

今天四个项目分属三个领域，但共享一个更值得记的判断标准：README 里的「我不做什么」，比「我能做什么」更能预测项目会不会活下来。

跨项目的第二个观察：今日四个项目的 fork-star 分化极大（4.9%–35.9%），且分化方向可解释。

项目 ⭐ ⑂ fork-star 本批内 fork/star 最高者
ikow/php2shell-poc 859 308 35.9% ✅
NVIDIA/flare-local-inference 485 47 9.7%
HOSTED-POWER/php_uploadprogress_guard 53 4 7.5%
dominikmartn/harp 527 29 5.5%

推断（不构成事实）：php2shell-poc 的 35.9% 有明确的机制解释——它带 lab/docker-compose.yml 一键靶场与五条可运行的验证脚本，fork 一个仓库去搭自己的复现环境是有直接用途的，而 fork 一个终端或一个扩展则不然。flare 的 9.7% 同样可解释——它带 30+ 份设计文档与 docs/clients/*.toml 客户端配置。但这只是本批四个点的观察，不足以支撑任何普遍结论；7 天后 fork 是否继续增长才是判据。

必须同时说清的第三点：今日排名最高的趋势，其热度来源与其他三个根本不同。 ikow/php2shell-poc 的 859⭐ 出现在 created_at 后约 13 小时，而作者把最关键的 Chain D/E 利用代码放在付费 Substack 之后——这里的 star 数度量的是 CVE 事件的关注度，不是工具采用度。任何基于「今天最热的项目」做技术选型的判断，在这个案例上都会失效。

重点项目深度分析（top 3）

Deep Dive 1：HOSTED-POWER/php_uploadprogress_guard（把「等补丁」做成可安装、可自检、会自己退场的软件）

项目定位。 宿主托管商 Hosted Power 为自家机队构建的 PHP 扩展，公开给所有人。12 小时 53⭐ ⑂4（fork-star 7.5%），C，MIT，5750 KB，subscribers_count = 4，open_issues_count = 2，覆盖 PHP 5.6–8.5 与 Sury / Remi / cPanel EA4 / DirectAdmin CustomBuild / 官方 Docker 镜像。

为什么它值得比它的 star 数更多的注意力。 因为它回答的是一个具体到可以立即执行的问题：你的机器今天就要被攻击，但你的发行版要三个月后才供上补丁，或者永远不会（嵌入式 appliance、被厂商锁死的管理界面、LTS 已停更）——那这三个月怎么办？ NCSC-NL 的公告恰好点名了这一类机器（「PHP is also embedded in appliances, network devices, management interfaces and other vendor products where administrators may not be able to update PHP directly」）。这个缺口此前只能靠手改 php.ini 或加 WAF 规则顶，而这两者都不改引擎内部。

技术亮点（全部可核验于 README）： - 逐组件镜像官方补丁，覆盖 PHP 5.6–8.5 十二个 minor，每分支每 SAPI 单独测试 - 三个机制：移除 session upload-progress handler（对 109619）· 携带修复版 parser 并让 parser 本身不可能 OOM（对 109618，headroom guard 保留 memory_limit 的八分之一）· mode=native 在 OOM 时直接结束进程（exit 137）而非让半初始化状态继续服务下一个请求 - 自检让位：用 nm -D 探测引擎导出的修复符号，已打补丁则报告 carries the official fix => yes 并跳过 parser 替换——升级后自动退场，无需人工卸载 - 两处诚实降级：mbstring 的多字节 hook 是 file-static 无法镜像 → mbstring.encoding_translation=On 的宿主交还给 PHP 自带 parser（callback detach 仍生效）；8.0–8.3 的副本不再依赖中途才加入的 max_multipart_body_parts - 孤儿临时文件这一条最容易被忽略：mode=native 下 worker 因 child exited with code 137 被回收且 0 孤儿上传临时文件，而原生 PHP 启动失败会留下 1 个（code 70）——在共享主机上这是磁盘耗尽的一个真实来源 - 12 个二进制全部 GLIBC_2.14 以下，零编译警告，修复探针以 versionless weak reference 形式存在（objdump -T 可查） - 两次自身回归写在 README：v3.0.0 修了 v2.2.0 在 PHP 7.0–7.4 上拒绝所有 multipart 请求的 bug（原因：读取了 8.0.28 才存在的 ini）；v3.0.1 修了 v3.0.0 二进制在 Debian 12 及更早上因 GLIBC_2.38 无法加载、导致 PHP 继续运行但 guard 未生效的 bug

风险。 - dist/ 里是二进制 .so：即使有 SHA256SUMS，宿主仍需信任发布者。这是所有「预编译缓解方案」的共同性质，也是本项目最大的信任假设 - 维护是单人 + 一个托管商：上游 PHP 若在 Zend 引擎结构上做新改动，镜像可能失效；README 未说明跟进机制 - 与 WAF 的关系未讨论：把 session.upload_progress.enabled=Off 这类官方缓解（NCSC-NL 列出的第一条）与本扩展叠加是否会冲突，README 未涉及 - subscribers_count = 4：这不是被广泛验证的工具 - 「PHP 继续运行但没有 guard」这个失败模式值得用户自查——README 自己写下了这个回归，说明它真实发生过

是否值得跟踪。 值得，且优先级高于它的 star 数。 理由与热度无关：它是本日唯一一个把「临时缓解方案」当作长期工程对象来做、并把「自己会退场」写进机制设计的项目。这两条（可复现的验证记录 + 自动让位）正是所有临时缓解方案通常缺失的部分。观察重点：dist/ 二进制的信任模型是否被独立验证（README 给了 SHA256SUMS 但发布者即构建者）、12 分支持续矩阵如何维护、以及是否会有第二个维护者出现。

Deep Dive 2：NVIDIA/flare-local-inference（研究原型的发布方式本身就是技术信号）

项目定位。 NVIDIA 官方组织的本地推理服务器，面向 SM120/SM121 GPU，定位「long conversations, coding agents, and repeated tool use」，2 天 485⭐ ⑂47（fork-star 9.7%，本批最高），Apache-2.0，22386 KB，subscribers_count = 5，open_issues_count = 8。README 明写：「This is a research prototype, and is made available via open-source to enable technical collaboration and collect early feedback.」

最值得记的技术判断（README 四条原则）： - 构建期拥抱标准 PyTorch 生态，运行期用 Rust——ignition/（Python）负责加载/调 kernel/编译 forward/捕获 CUDA graph 并打包，flare/（Rust CLI）链接 helios/（Rust 运行库）在无 Python 的情况下服务该包。AGENTS.md 明确了依赖方向：Helios 被 Flare 与 Heliopause 依赖，而 Helios 没有任何 Python 或准备工具的依赖 - 复用规范模型实现，只为布局或执行确实不同的部分做特化——这是对「什么都自己重写」的直接否定 - 把内存与状态显式化：提前规划 buffer 与执行容量；把会话状态连同循环状态与 KV cache 当作整体，使复用、分支与恢复都能正确保持 - 运行时保持小而专：模型配方负责模型计算，运行时负责调度、缓存存储与请求处理 - 编译与图捕获在服务之前完成——运行期不编译

最值得记的非技术判断（AGENTS.md）： 这是本日唯一把「拒绝什么」写成制度文件的项目。三类驳回标准之外，还有两条常被忽略的补充：其一，「Hypothetical future consumers, agent-generated suggestions, and lint findings alone do not establish a need for a change」——直接拒绝以「未来可能有人用」或「agent 建议」为理由的贡献；其二，发版纪律要求提交前启用 .githooks/commit-msg 钩子并按 docs/design-review.md 做 staged-diff 复核，且「被拒绝的确认不得当作格式修复处理」——这是针对「agent 把架构评审的拒绝当成 lint 报错去改」的防御性设计。

风险。 - 研究原型，无 release：releases API 返回空数组，启动路径需自行按 docs/ 构建 - 硬件门槛硬：仅 SM120/SM121，vLLM 覆盖更广的模型、硬件与部署形态——覆盖面确实窄 - subscribers_count = 5，8 个 open issues 在 2 天内——早期项目的正常状态，不能读作质量信号 - README 几乎不给出性能数字：30+ 份设计文档（scheduling-theory / prefix-cache-offload / mtp-design / roce-ring 等）存在，但 README 首页没有任何 benchmark 表格——架构主张与实测证据之间目前有可见的落差 - 贡献闸门严格可能拖慢采纳：对外部贡献者而言，被 AGENTS.md 明确拒绝的范围（训练/微调、多模型托管、CPU 执行）恰好覆盖了不少人最想做的事

是否值得跟踪。 值得，理由是它提供了一份「研究原型该如何被公开」的完整样本——尤其是 AGENTS.md 的驳回标准与 staged-diff 复核流程，可以直接被抄进任何有 agent PR 的开源项目。观察重点：是否开始发布带 benchmark 的 release、SM120/SM121 之外是否扩展、以及贡献闸门在实际协作中是否真的挡住了架构违规（看 issue 里被拒绝的 PR 类型）。

Deep Dive 3：ikow/php2shell-poc（五条链 + 一键靶场 + 四类规则，但 star 数度量的是事件而非采用）

项目定位。 个人研究者 Qi Deng 的 CVE 研究与利用工具包，13 小时 859⭐ ⑂308，Python，2706 KB，subscribers_count = 4，open_issues_count = 2。

必须先讲的一件事：它的热度不是技术指标。 859⭐ 出现在创建后约 13 小时，而最关键的 Chain D 与 Chain E 的利用代码放在付费 Substack 订阅之后（README Disclaimer 明写），公开的 exploit/ 只有 A/B/C 三条链。也就是说：star 数最高的那部分价值，恰好是免费拿不到的——这与「star = 工具被采用」的常规读法完全不同。同时它引用的「影响 78% 网站、WordPress 43%」是作者主张，本日报未独立核验；相比之下 NCSC-NL/php2shell 给出的是 software/ 目录里的具体产品清单，这种形式更可核验。

技术亮点（可核验于 README 与仓库树）： - 五条链各自标注「是否预认证 / 需要什么条件 / 适用哪个 SAPI」，Chain D 明确标为「Conditions: None — any endpoint」「mod_php」，并被作者自己判为最关键 - lab/ 一键靶场：docker-compose.yml 同时起 PHP-FPM + nginx + Apache mod_php，另有 php-apache.ini 与 setup.sh - poc/ 五个验证脚本逐链对应，含 ASAN 版 verify_uaf_asan.php（对 UAF 类问题用 ASAN 是标准做法） - detection/ 四类规则：Suricata/Snort IDS、Sigma SIEM、ModSecurity WAF、OpenResty/Nginx Lua 模块——同一仓库同时覆盖网络层、SIEM 层、WAF 层与应用层 - 缓解建议附边界声明：session.upload_progress.enabled = Off + session.use_only_cookies = On，并明写「The only complete fix is patching PHP… The OOM corruption (Chain D) is in the Zend engine core — no INI setting fixes it.」——明确否定了「改 ini 就行」的流行说法 - 下游影响表逐框架标注条件（WordPress 核心不用 PHP session 但 WooCommerce 与多数插件用；Magento 在维护模式下仍受影响；Laravel 的 PendingBroadcast 是已知 __destruct gadget）

风险。 - ⚠️ 许可证不一致（可核验）：GitHub API 的 license.spdx_id 为 null（NOLICENSE），而 README 末尾写 MIT。以 GitHub 侧为准则无授权。对要复用其检测规则或靶场配置的人，这是必须先澄清的问题 - 最关键的利用代码不公开：D/E 链在付费墙后 - subscribers_count = 4 / oi = 2：这是事件驱动的注意力，不是深度关注 - NOLICENSE 的连带影响：detection/ 里的规则能否被安全地内嵌进商业产品，取决于许可证澄清的结果 - 同时存在的多个竞争 PoC：eness/php2shell-...-PoC（530⭐ ⑂94）、9bie/php2shell-bypass-aslr-exp（356⭐ ⑂130）、Zer061/CVE-2026-109618（52⭐ ⑂39）、junaire/CVE-2026-109618-exploit（74⭐ ⑂49）等，多数无 license 或无 description——生态碎片化明显，也说明本仓库的优势不在唯一性而在完整性（链 + 靶场 + 检测三者齐备）

是否值得跟踪。 作为研究材料跟踪，作为依赖不推荐。 理由：它的检测规则（四类）与靶场配置是可直接复用的资产，值得抽取；它的利用代码部分在付费墙后，价值不可核验；而 NOLICENSE 与 MIT 的不一致必须在复用前解决。观察重点：仓库是否补上 LICENSE 文件、四个检测规则是否被主流 WAF/IDS 项目（如 Corelight README 中提到的社区规则）合并、以及 Chain D/E 的公开程度。

风险与机遇

机会

  1. 「临时缓解方案」是一个被低估的产品形态。 php_uploadprogress_guard 证明了一件事：在官方补丁到达之前的那段窗口里，有真实且迫切的需求，且这个需求可以做成有版本、有测试、有退场机制的正经软件。这对任何做基础库、运行时、协议的项目都适用——不只是安全事件。
  2. 在事件洪峰里主动写「我不做什么」，是本日最稀缺的动作。 openai/php2shell-checker 写「UNKNOWN 不等于已打补丁」「我不独立验证安全修复」；guard 写「我们无条件推荐官方发行版」；flare 写「不是也不会是 vLLM 的替代」。热度越高，这类声明的价值越大，因为它替代了本该由用户承担的验证成本。
  3. 把贡献边界写成机器可读的文件，而不是散落在 CONTRIBUTING 里。 flare 的 AGENTS.md 把「拒绝什么」列成三类可执行标准，并明确「agent 生成的建议本身不构成变更理由」。在 agent 参与开源贡献越来越多的当下，这类文件本身就是一种防御机制。
  4. agent 状态管理正在成为独立的一层。 harp 证明「多开几个 agent」带来的真问题不是终端多标签，而是「哪一个在等我」。五种状态 + 未读标记 + 后台圆点 + 置入暂存 + 双 provider 限额环，是一套不需要模型就能做的信息设计；其中「限额从本地日志与 status line 读、不读任何凭据」的信任边界尤其值得借鉴。
  5. 国家 CERT 仓库是 CVE 响应的高质量参考物。 NCSC-NL/php2shell 以 EUPL-1.2 + TLP:CLEAR 发布，software/ 目录放受影响产品清单而非「78% 网站」这类统计，并引用 CERT-EU 编号 2026-018 与其他成员国 CSIRT 公告——「给具体产品名」比「给一个百分比」有用得多。

风险

  1. CVE 事件的 star 数与技术价值脱钩，且这种脱钩有明确机制。 本日排名第一的趋势是事件驱动：13 小时 859⭐，而最关键的利用代码在付费墙后，最常用的资产（检测规则）反而不需要 star 数来评价。今天的热度排序对技术选型没有参考价值——这与昨日「fork-star 普遍偏低说明热度更像曝光」的观察是同一个问题的两面。
  2. 预编译二进制的分发仍是信任问题。 guard 的 dist/ 提供了 SHA256SUMS，但发布者即构建者，没有独立签名或第三方构建。这类方案在安全事件中的可信度高度依赖读者是否验证——而 README 明确鼓励「install the official release」，恰恰说明作者自己也把它定位为候补而非首选。
  3. NOLICENSE 与 MIT 自述不一致。 php2shell-poc 的 GitHub 侧 license.spdx_id 为 null。这是可核验的事实，也是本日报中唯一一处元数据与自述直接冲突的记录——在安全事件这种「大家都在复制粘贴」的场合，许可证不明意味着检测规则无法安全内嵌进商业产品。
  4. 研究原型的架构主张与实测证据之间有落差。 flare 有 30+ 份设计文档，但 README 首页没有任何 benchmark。「我们把内存与状态显式化」是一句主张，不是一个测量结果；在本日报采信的所有材料中，guard 的 7 组实测表是唯一带具体输入与输出数值的一组。
  5. 非官方 fork 的路线债是结构性的。 harp 明写「does not produce usable updates」——这意味着上游 Warp 的每次改动都不会自动到达，用户要么自己解冲突要么放弃某部分功能。2 天 4 个 release 表明当前跟随强度尚可，但这不是一个能长期成立的模型，README 自己也知道。
  6. Android TV 桌面赛道已连续第 5 天有新项目，但今日仍不重复建档。 lesnolie/Tigris（222⭐，声称已在索尼 BRAVIA XR-55A80J 验证）、op7418/guizang-tv（137⭐）、Jimu888/home-tv-cn（41⭐，README 明写「基于 Aerial 定制」）——赛道真实存在竞争，但也开始出现直接派生。赛道已验证不等于每个项目都有价值；差异化正在从「UI 像不像 tvOS」转向「在什么机型上能活下来」。

证据边界总结

项目 关键事实（可核验） 推断（不构成事实） 待观察（待后续数据）
ikow/php2shell-poc Python + 2706 KB + 13 小时 859⭐ ⑂308（fork-star 35.9%，本批最高）+ 作者 Qi Deng + 两条 CVE 各 CVSS 9.2（GHSA-w8hw-w9fx-j79w「RCE via OOM corruption」published 2026-10-21T13:34:25Z / GHSA-6wmf-4rv5-p3rp「RCE via stale global state」published 13:34:13Z）+ 官方补丁 commit 3584a98bda（作者日期 2026-10-18T15:26:39Z，标题 Avoid state corruption via bailout，300 文件）+ 首个 release php-8.5.12 published 2026-10-21T14:06:46Z + 官方判定受影响 <8.2.35 / <8.3.36 / <8.4.27 / <8.5.12 + 5 条链（作者判定 D 最关键：Conditions None — any endpoint，mod_php）+ exploit/ 公开 A/B/C 三条链，D/E 在付费 Substack 后 + poc/ 5 个验证脚本含 ASAN 版 + lab/ PHP-FPM+nginx+mod_php docker-compose 一键靶场 + detection/ 四类规则（Suricata/Snort · Sigma · ModSecurity · OpenResty Lua）+ 缓解 session.upload_progress.enabled=Off 且明言 Chain D 在 Zend 引擎核心里没有任何 INI 设置能修 + 下游表（WordPress 核心不用 session 但 WooCommerce 与多数插件用 · Magento 维护模式下仍受影响 · Laravel PendingBroadcast 为已知 __destruct gadget）+ license.spdx_id 为 null 而 README 写 MIT（可核验的不一致） + subs 4 oi 2 推断：35.9% 的 fork-star 与「带一键靶场与可运行验证脚本」直接相关——fork 去搭自己的复现环境有用途，fork 一个工具则未必；推断：其作为资产的价值主要在 detection/ 与 lab/，而不在 star 数 待核验：是否补上 LICENSE 文件（决定检测规则能否安全内嵌） + Chain D/E 的公开程度 + 四类规则是否被主流 WAF/IDS 合并 + README 的「78% 网站 / WordPress 43%」缺乏独立来源 + NOLICENSE 与 MIT 自述冲突的解决方式
HOSTED-POWER/php_uploadprogress_guard C + MIT + 5750 KB + 12 小时 53⭐ ⑂4（fork-star 7.5%）+ Hosted Power 为自家机队构建后公开 + 覆盖 PHP 5.6–8.5 与 Sury/Remi/cPanel EA4/DirectAdmin CustomBuild/官方 Docker + README 开头即 「we recommend it without reservation」装官方发行版 + 三机制（移除 session upload-progress handler · 携带修复版 parser + headroom guard 保留 memory_limit 八分之一 · mode=native 遇 OOM 直接 exit 137）+ 自检让位：nm -D 探测修复符号，Sury 5.6.40-104/7.0.33-92/7.3.33-35/7.4.33-31/8.1.34-9/8.3.36-1 全报 carries the official fix => yes，官方 docker 8.4.11/8.1.20/7.4.33/5.6.40 全报 no 且机制全 active，未打补丁引擎上「Neither fix symbol exists (nm -D)」+ v3.1.0 未打补丁机型行为表（15000 字段单 multipart，8.4.11/8.1.20/7.0.33/5.6.40 一致：无模块 exit 255 Allowed memory size exhausted；mode=native exit 137；默认 mode=parse exit 0 + Status: 413）+ php-fpm 场景 mode=native worker 因 child exited with code 137 被回收且 0 孤儿上传临时文件（原生 PHP 留 1 个，code 70） + set_error_handler 场景在 8.4 与 5.6 均返回 OK:15000 handled: …，证明请求状态重置不动用户错误处理器 + OPcache 编译窗口 20M 限额下无模块报 Allowed memory size … in Unknown on line 0（错误落在 OPcache store 内），装模块后 compiled+ran + cPanel EA4 ea-php83 8.3.35 on AlmaLinux 10.2 与 DirectAdmin CustomBuild php84 8.4.22 on Debian 13 均加载预编译并报 detached，cPanel 上 php-cgi -m 列出模块 + Ansible 幂等：ansibletest 二次 changed=0、全量 ok=1506 failed=0；web1/2/3 经 AWX 各 changed=4 且 fpm 重启、二次 changed=0；cpanel1.staging 8.1–8.4 与 directadmin1.staging 8.2–8.4 均 failed=0 changed=0 + 两次回归写在 README：v3.0.0 修 v2.2.0 在 7.0–7.4 拒绝所有 multipart；v3.0.1 修 v3.0.0 二进制因 GLIBC_2.38 在 Debian 12 及更早加载失败、PHP 继续运行但 guard 未生效，build.sh 现拒绝任何高于 GLIBC_2.14 的构建 + 12 个二进制零编译警告、修复探针为 versionless weak reference（objdump -T）+ mbstring 与 max_multipart_body_parts 两处诚实降级 + releases API 返回空数组（dist/ 与文档是主分发路径）+ subs 4 oi 2 推断：「装了会自己退场」比「装了能挡住」更重要——这是所有临时缓解方案通常缺失的工程属性；推断：把缓解做成产品需要在补丁空窗期之外还想清楚两件事：信任模型与跟随机制 待核验：dist/ 二进制无独立签名（发布者即构建者，SHA256SUMS 需自行验证） + 12 分支持续矩阵如何维护 + 未来 Zend 引擎结构变更时的跟进机制 + 与 WAF / session.upload_progress.enabled=Off 叠加是否冲突 + 是否有第二维护者
NVIDIA/flare-local-inference Apache-2.0 + Python + 22386 KB + 2 天 485⭐ ⑂47（fork-star 9.7%，本批最高）+ NVIDIA 官方组织 + 定位 SM120/SM121 GPU 的本地推理服务器 + README 第一句给 agent：Coding agents: skip this README and read AGENTS.md directly + 四组件单向依赖（ignition/ Python 用 PyTorch+Transformers+FlashInfer+b12x 加载/调 kernel/编译/捕获 CUDA graph 打包 → heliopause/ crate 构建 flare_heliopause → flare/ Rust CLI 链接 helios/ Rust 运行库无 Python 服务 → Helios 无任何 Python 或准备工具依赖）+ 编译与图捕获在服务之前完成 + 四原则（构建期 PyTorch 生态 / serve 时 Rust · 复用规范模型实现只特化布局与执行不同处 · 把内存与状态显式化：提前规划 buffer 与执行容量，把会话状态连同循环状态与 KV cache 当作整体使复用分支恢复都正确 · 运行时小而专：模型配方负责模型计算、运行时负责调度缓存存储与请求处理）+ README 明文划界：vLLM 覆盖更广的模型硬件与部署形态，Flare 用广度换聚焦服务契约；不是、也永远不会是对 vLLM 这类生产推理引擎的替代 + 自述研究原型，开源是为技术协作与收集早期反馈 + AGENTS.md 三类驳回标准（拒绝未批准的范围扩张：CPU/非 NVIDIA 执行、可互换执行后端、训练或微调、多模型托管与路由、无关服务 API、通用集群编排，且已支持的跨节点 TP 不授权这些新增 / 拒绝架构违规：生产 Python 回调、eager serving、运行期编译或重捕获、稳态 GPU 分配、模型特定原生策略或状态更新算法、准备元数据中的可执行扩展机制，且 Flags/enums/callbacks/optional paths/temporary implementations 不能用来绕过 / 拒绝削弱保证：完整缓存与投机状态、非活跃行行为、异步资源生命周期、checkpoint 精度、模型语义、模型包兼容性，不得删除校验、压制错误、静默替换执行路径或放宽参考值工作负载与数值边界换取通过的检查或好看的指标）+ 「Hypothetical future consumers, agent-generated suggestions, and lint findings alone do not establish a need for a change」 + 发版纪律：进入 clone 与 pull 后重读 AGENTS.md 与 docs/design-review.md，提交前启用 .githooks/commit-msg 钩子并做 staged-diff 复核，「被拒绝的确认不得当作格式修复处理」 + Orbit 管理主机/准备/包/rank 进程，单机执行与跨节点 TP 均在范围内 + docs/ 含 30+ 份设计文档（core-design / runtime-package-design / prefix-cache-offload / mtp-design / scheduling-theory / scheduling-runtime-design / scheduling-oracle / scheduling-utility / same-process-tp / tp-checkpoint-layout / roce-ring / direct-execution / signing / design-review / orbit / multi-host 等）+ docs/clients/{claude-code.json, codex-models.json, codex.toml} 客户端样本 + .github/workflows/native-serving.yml + releases API 返回空数组 + subs 5 oi 8 推断：把「拒绝什么」写成机器可读的 AGENTS.md 并显式排除「agent 建议」作为变更理由，是可被任何有 agent PR 的开源项目直接抄走的制度设计；推断：README 无 benchmark 而设计文档 30+ 份，说明架构主张与实测证据之间目前有可见落差 待核验：SM120/SM121 对应哪些具体 GPU 与 README 未给检测方法 + 受支持模型清单 + 是否开始发布带 benchmark 的 release + 运行时包格式与签名机制（docs/runtime-package-design.md 与 docs/signing.md 存在但本窗口未取内容） + 分支与恢复的具体实现（docs/prefix-cache-offload.md 与 scheduling-* 未取内容） + 贡献闸门在实际协作中是否真的挡住了架构违规
dominikmartn/harp Rust + AGPL-3.0（warpui 与 warpui_core 两个 crate 为 MIT）+ 222265 KB（217 MB，本批最大）+ 个人项目 + 2 天 527⭐ ⑂29（fork-star 5.5%）+ 2 天 4 个 release：v0.1.0（10-20 11:13Z）→ v0.1.1（13:43Z）→ v0.1.2（18:09Z）→ v0.1.3（10-21 10:29Z） + 徽章只标 macOS + Warp 非官方 fork，把 tab bar 换成专为长跑型 coding agent 设计的侧边栏，其余保持 Warp 原样 + 五种状态（working / waiting for you / done / inactive）+ 未读标记直到真的看过 + 小圆点=后台仍在跑 + 月亮=已置入暂存 + Cmd+R 重命名 + 分组名与顺序存 tmux session 本身（跨重启存活、其他 tmux 客户端见同一布局）+ tmux set-option @warp_adopt 1 收养手机 ssh 起的 session + 双 provider 限额环（5 小时窗口 + 周限额，悬停显示数字与重置时间；Codex 从 ~/.codex/sessions 或 $CODEX_HOME 的 rate_limits 日志读且需至少回答过一次；Claude Code 只能从 status line 拿计划限额——首次启动若 ~/.claude/settings.json 无 statusLine 则 Harp 自己加一个并把输入存 ~/.harp/claude-statusline.json 且不打印任何内容，已有 statusLine 则保持不动（要兼得需先落盘如 tee ~/.harp/claude-statusline.json \| 你的命令），环在下一次回答后出现，只对 Claude.ai 计划有效、API key 无效）+ 「Harp fetches nothing and reads no credentials」 + 其余全为上游 Warp（agents / Warp Drive / session sharing / login），与上游一样直连 Warp 服务器，Harp 不自建任何服务器；通过 Harp 登录未测试 + tmux 集成默认关闭，开启后每 10 秒轮询，支持 session_script 自定义 + 明确列出故意移除（tab bar 搜索框、视图选项、tab 配置按钮、侧边栏分隔线选项、标题条面板开关）+ 调试开关（WARPOSS_STATUS_TRACE=1 把每行状态变化写成 ~/Library/Logs/harp.log 的 [status-check] 行以对照 agent transcript 做回归 / WARPOSS_SKIP_LOGIN=1 用测试用户启动且所有认证请求失败以便自动化 / WARP_DATA_PROFILE 把数据放 ~/.harp-<name>）+ 身份诚实（显示名来自 app_display_name!()，bundle id / URL scheme / 设置目录有文件级列举，内部名称保持 Warp 的：warp-oss 二进制、crates、WARPOSS_ 开关、@warp_ tmux 选项）+ 构建 script/bootstrap → script/run → target/debug/bundle/osx/Harp.app；script/macos/run 用钥匙串首个 Apple Development 身份签名、失败回落 ad-hoc；script/release_macos 产出可公证 release DMG + 提交前跑 ./script/presubmit（format/clippy/tests）+ subs 2 oi 5 推断：「多开几个 agent」的真问题不是终端多标签而是「哪一个在等我」，这套信息设计不需要模型即可成立；推断：限额环选择读本地日志与 status line 而非云端 API，代价是只能覆盖两个 provider 且 Claude 侧依赖间接通道 待核验：agent 状态的判定机制（读 transcript？调 hook？README 只提了一个「reports background tasks to the sidebar」的 Claude Code hook，主路径未说明）+ Harp 注入的 statusLine 在 Claude Code 改格式或用户换掉时的失败模式 + fork 与上游 Warp 的同步策略（README 明写 does not produce usable updates）+ AGPL 例外（warpui/warpui_core 为 MIT）是否会随上游改动失效 + 2 天 4 个 release 的当前强度能否延续

总证据边界： 本日全部元数据取自 2026-10-22 CST 06:00 前后经 gh CLI 认证的 GitHub REST / Search API，README 与 AGENTS.md 原文经 Accept: application/vnd.github.raw 抓取，CVE 与补丁事实经 repos/php/php-src/security-advisories/*、repos/php/php-src/commits/3584a98bda、repos/php/php-src/releases 直接核验。「X 小时 / Y 天 Z⭐」按 created_at（UTC）到 2026-10-22 计算，总星数除以经过时长为下限粗估；本日报未做逐日 star 增量统计（需分页遍历 stargazer），因此任何「增速」表述都不能读作当日新增。 四个 key_projects 中三个的 releases API 返回空数组（openai/php2shell-checker、NVIDIA/flare-local-inference、HOSTED-POWER/php_uploadprogress_guard），subscribers_count 为 4 / 5 / 4 / 2——说明这批项目都还没有「深度关注者」，热度可持续性在写作时无法判断；4 个项目 topics 均为空数组（未设 GitHub topics，不代表无主题）。发现一处可核验的元数据冲突：ikow/php2shell-poc 的 license.spdx_id 为 null 而 README 写 MIT，本日报按「未附可识别许可证」处理并列为待澄清项。今日排名第一的趋势是 CVE 驱动的注意力洪峰而非技术突破——ikow/php2shell-poc 的 859⭐ 出现在创建后约 13 小时，且作者把最关键的 Chain D/E 利用代码放在付费 Substack 之后，star 数在此度量事件关注度而非工具采用度；今天的热度排序对技术选型没有参考价值。本批 Search 结果中已过滤可核验的 spam 模式（.github 作仓库名 + *-tool(s)/.github 命名 + fork/star ≥ 0.5：lol-tools-new/.github 95⭐ ⑂95、DLSS-5-Swapper-Download-2026/.github 86⭐ ⑂50、DLSS-5-Swapper-Update-Download/.github 76⭐、cs-tool-s/.github 244⭐ ⑂216、val-tools/.github 242⭐ ⑂238、rbl-tools/.github 240⭐ ⑂196；以及 80–82⭐ ⑂0 + size 2 KB + 统一「Full working installer…Ready to run」描述的破解软件仓库：shareshellrelease/Cinema-4d、ThresholdSummoner/Camtasia、slaterockweb/BorisFX、Torrentthefoundry/KMS-Pico）。未纳入 key_projects 的候选：eness/php2shell-...-PoC（530⭐ ⑂94，无 license）、9bie/php2shell-bypass-aslr-exp（356⭐ ⑂130，21.5 MB，无 description 无 license）、Zer061/CVE-2026-109618、junaire/CVE-2026-109618-exploit、wakemeiflose/php2shell、JoasASantos/php2shell-scanner、syhunt/php2shell-protection——均为同事件 PoC/检测变体，作为「生态规模」的证据被引用但与主档内容重叠，不重复建档；eagle-hq/EAGLE-4（713⭐ ⑂18，Official Inference Code of EAGLE-4，NOASSERTION，本窗口未取 README，模型与许可均无法核验）；lesnolie/Tigris（222⭐，中文 tvOS 26 风格 Android TV 桌面，声称已在索尼 BRAVIA XR-55A80J 验证）、op7418/guizang-tv（137⭐）、Jimu888/home-tv-cn（41⭐，README 明写「基于 Aerial 定制」）——Android TV 桌面赛道连续第 5 天有新项目，但该赛道已在 10-19/10-20/10-21 三份日报完整记录，今日不重复建档，仅记为赛道延续性证据。本日不新增延续跟踪条目。今日最重要的判断不是「哪个项目最热」，而是三个各自独立的项目在同一个早上做了同一件事：把「我不做什么」写进可核验的位置——flare 写进 AGENTS.md 的三类驳回标准并显式排除「agent 建议」作为变更理由；openai/php2shell-checker 写进 README 的 Limitations（UNKNOWN 不等于已打补丁、不独立验证安全修复）；guard 写进 README 的第一句（无条件推荐装官方发行版，本模块只是候补）。这与 star 数完全无关，却是本日跨领域最强的共同信号。 与之相对的是本日最需要警惕的一点：php2shell 生态的 fork-star 35.9% 可以用「带一键靶场与可运行验证脚本」解释（fork 去搭复现环境有直接用途），但这是本批四个点的观察，不足以支撑普遍结论；7 天后 fork 是否继续增长，仍是区分真实采用与事件余温的唯一判据。

重点项目档案