progmune-runtime 3.7.2 → 3.7.4

package/CHANGELOG.md

@@ -1,7 +1,67 @@
 # Changelog
 
+## [3.7.4] — 2026-08-26
+
+### 新增：C 语言 IR 提取（注册表第三语言）
+
+- **`src/extract-ir-c.ts`**：纯 TS C 提取器（无子进程桥、无原生依赖）——函数签名（含多行、`static`/`inline`/`__attribute__`、指针/数组/函数指针参数）、调用列表（成员调用取 `->`/`.` 后的调用名，`goto` 合成 `goto_<label>`）、`@progmune`/`@protocol` 注解与 `@purpose/@tags/@requires/@produces/@useWhen/@inputs/@outputs` 文档标签（C 注释块镜像 Python 装饰器语法）；注释/字符串感知的括号计数（修复 v2 提取器已知缺口，未改动 `sequence-extractor`——C 金标基准管线保持不动）
+- **`LANGUAGE_EXTRACTORS` 注册 `c`**（detect `.c`/`.h`，extract `extractIRC`）——agent 循环、execute() 的 ir.json 写入与 MCP 自动生效；C 项目从纯正则回退切换到 IR-first 序列验证 + SSG 状态机，C 函数名进入词段匹配门控（仅项目函数）；协议行与 protocols.json 规则名（`verify_password` 等）按名命中
+- **端到端验证**：临时 C 项目上 extractProjectIR → evaluateTrust 走通——4 条植入违规全部精确定位（内置 auth×2 / db×1 + 自定义 pay 命名空间注解×1），合法链零误报（NEEDS_REVIEW 72 分）；**应用级 C 金标 v1**（`blind-benchmark/scan-protocol-c-app.ts`，镜像 Python 盲测方法学）：10 clean × 7 违规 → **P=87.5% / R=100% / F1=93.3%**（唯一 FP 为跨函数窗口边界，与 Python 盲测 T2×S5 同类）
+- **规模化提取**（`blind-benchmark/scan-protocol-c.ts`）：6 个 vendored 仓库（curl 4192 / libssh 3689 / nginx 2970 / openssl 14394 / nghttp2 1274 / redis 9590 函数）秒级提取，黄金函数恢复率 81–99%；旧 TLS 级金标上 SSG 命中 0/38（口径差异：SSG 无 TLS 规则，如实记录）；nginx 3 FP 为 `ngx_*` 前缀包装器撞词段匹配（引擎层问题，记录待议，未动 SSG 桥避免 TS/Python 漂移）
+- **修复：签名正则指数级回溯**——v2 风格类型 token 循环对 `name = ssh_userauth_kbdint_getname(...)` 类行穷举标识符切分（44 字符缓冲 ~11s），改为候选迭代（跳过关键字/类型名候选，返回类型从缓冲区前缀推导）；libssh 提取 >15min（病态）→ 1.8s，回归测试已加
+- **评审修复轮（detect/extract 口径、死代码、TU 绑定等）**：①`hasSourceFiles` SKIP_DIRS 补 `benchmarks`（与 extract 口径一致，本仓库自身不再误标 C）；②`#if 0` 死代码块预处理剥离（真实仓库不平衡花括号不再腐蚀函数体计数）；③顶层 `#` 行只跳自身不再吞相邻函数（openssl 14,394→15,896 函数，黄金函数恢复率升至 89–100%）；④`buildCallSequences` 同文件定义优先绑定（跨文件同名 static 不再 last-wins 错绑，入口判定文件化；Python 盲测 v1.2 复测零漂移——报告与基线逐字节一致仅时间戳不同）；⑤提取器取消调用去重（状态机重复调用有语义，双 close/重复 logout 可检出，与 TS/Python 提取器一致）；⑥删死代码 `isCProject`；⑦混合 TS+C 项目回归测试。应用级 C 金标扩至 v2（11 clean × 11 违规 + helper 中介风格 + 逐命名空间分解）：**TP 11/11 FP 1 FN 0 → P=91.7% / R=100% / F1=95.7%**（唯一 FP 为 do_logout 跨函数窗口边界）。已知系统性风险文档化：C 前缀包装器（`ngx_*` 等）撞词段匹配（nginx 3 FP），缓解方案（前缀剥离/连续词段）留待下一轮并强制盲测复跑
+- **限制如实记录**：函数指针分发静态不可见（L3 结论不变）、宏/K&R/C++ 不解析、无数据流/指针分析（L4 无计划）；提取器遍历跳过 vendored `benchmarks/`；`docs/c-language-status.md` 已更新（新路线小节 + 基准结果 + Decision record）
+
+## [3.7.3] — 2026-08-24
+
+### 中央免疫 Hub 上线 + 失败语料统一
+
+- **中央 Hub 重新部署**（`progmune-runtime` 应用，`server/hub.js`）：fly.toml 补 443 TLS 端口（此前仅 80，https 不可达），`https://progmune-runtime.fly.dev/report` 生效；数据落持久卷 `progmune_data`（`/app/immune_hub_data`），Dashboard `GET /api/dashboard` 可用（含 5 月历史 12 条指纹 + 冒烟测试 1 条）
+- **上报链路打通**：`PROGMUNE_HUB` 指向中央 hub；`immune-reporter` 实测可连（游标增量上报，无新指纹时正常返回）；端到端 POST 冒烟通过（received:1 / total:1）
+- **统一失败语料写入路径**：`failure-collector.ts` 的 `CORPUS_DIR` 由仓库根 `failure-corpus/` 改为项目级 `.progmune_corpus/emitter-failures/`（与 `failure-corpus.ts` 同规则：`PROGMUNE_CORPUS_DIR || <PROGMUNE_PROJECT_DIR|cwd>/.progmune_corpus`），消除两套语料并存；dist 已重建
+- **部署配置瘦身**：根 Dockerfile 改为零依赖（hub 仅需 `server/` + `public/`，去掉 npm install 与 dist 拷贝）；`.dockerignore` 补 benchmarks/、.progmune_corpus/、dist/ 等大目录（构建上下文 1.1G → 数百 KB）
+- **Hub 接口扩展**：`/api/dashboard` 新增 `topPatternsWeek`（本周高频错误模式 Top10）+ 全接口 CORS（`Access-Control-Allow-Origin: *`），供落地页跨域实时拉取
+
+### 落地页新增「失败语料飞轮」板块（05）
+
+- 三卡飞轮叙事（失败入库 → 中央汇聚 → 反馈增强）+ **实时本周高频错误模式 Top 10**（浏览器端 fetch `progmune-runtime.fly.dev/api/dashboard`，SVL 分级徽章 + 调用序列 + 次数；空态/不可达有兜底文案）
+- 中英文切换覆盖（113 i18n 键）；序号顺延：使用→06、路线图→07、社区→08；导航新增「飞轮」入口
+
+### 文档全量一致性审计
+
+- 全仓文档与当前进度核对并修正：
+  - **CLAUDE.md**：Current coverage reality 更新至 2026-08-24（TS 795 gold 98.5%/100%、Python ✅ 生产级、C ⚠️）；"Python/Go/Java planned"→"TS + Python production"；"Don't add TS rules"禁令改按现行基准表述；P0-P3 标注历史阶段；架构表补 `src/call-sequence.ts`（P4.6）、Protocol Detector 标注为正则回退；SDK 导出修正为 verify/explain/getCompatibility
+  - **README 双语**：P0-P3 数字统一为权威口径（+31 规则/+86 轨迹/+13 检测器/+11 防护，另 +19 检测）；21→27 命名空间；架构图 Protocol Detector 标注正则回退 + 补 P4.6 调用序列层
+  - **覆盖矩阵双语**：C 列 Connection 按图例降 ⚠️（极高误报率），汇总 ✅×4/⚠️×4；IR 层补 3.7.1 恢复 IR-first + 词段门控注记；日期 08-24
+  - **BASELINE_PROTOCOL_PYTHON_v1.md**：标题升 v1.2（文件名兼容保留）；风格表补 S5 行
+  - **BASELINE_v6.md**：reset_password"已检出/未覆盖"矛盾消歧（md5 形状已检出、其他形状无规则）；TS precision 99.1%（8-15 波次）与 100%（8-16 打磨后）口径注明
+  - **QUICK_START.md**：npx 子命令（发布包中不存在）改为真实入口（MCP / GitHub Action / 仓库 CLI）；覆盖表对齐覆盖矩阵
+  - **API_REFERENCE.md**：按真实表面重写——SDK 仅 verify/explain/getCompatibility（verify 为同步单参、VerificationResult 字段如实列出）；npm bin = MCP server（工具清单）；仓库 CLI scripts 表；环境变量表保留
+  - **RUNTIME_ARCHITECTURE.md**：7 protocol definitions→27 命名空间/148 规则；业务指标表过时数字（FPR 97%、F1 27-41%）改为现行基准（0 FP、TS 98.5%/100%、C F1 16.5%）
+  - **项目全解.html**：hero 版本 v3.2.0→v3.7.2；21→27 命名空间（2 处）；85.2% F1 旧数字→现行基准；5.7 基准表补协议盲测 v1.2 行；6.1 产品形态补社区双渠道机器人
+  - **投资人白皮书_v3.2.html**：Python"未激活"→✅；144→148 规则（2 处）；PrintLab 案例对齐最终态（46→0 违规、44→87 APPROVED）；P2 待办 Python/Go→Go/Java；里程碑表补 3.7 行；"当前能力（v3.2）"标注最新 npm 3.7.2
+  - **新增产品落地页 `index.html`**：产品介绍（为什么 / 是什么 / 核心能力 / 覆盖矩阵 / 使用方法 / 社区反馈）+ 双群二维码 + 自动回复说明 + 联系邮箱 shenlian1983@qq.com + 官网 tuxingren.xyz；自包含单文件（内联 CSS，无外部依赖），图片相对路径，可直接部署至 tuxingren.xyz
+  - **落地页上线 Fly.io**：新增 `web/` 静态站部署目录（nginx:alpine + fly.toml，app `progmune-web`，sin 区域，2 台机器）；`fly certs add tuxingren.xyz` 已绑定域名证书，DNS 待用户按记录配置（A `149.248.206.6` / AAAA `2a09:8280:1::17a:e05f:0`）；踩坑记录：Fly 远程构建不解析符号链接（web/ 内用真实文件副本）、hkg 区域已弃用（改用 sin）、文件权限需 644（nginx 用户可读）
+  - **落地页迭代**：新增中英文切换（data-i18n + localStorage）；新增「下一步方向」板块（6 个轻量方向卡：更多语言 / Trust API SaaS / 协议扩展 / CI/CD 插件 / 行业基线 / 公开基准，依据 `docs/development-plan.md`）；移除 tuxingren.xyz 全部引用（官网行 + 页脚链接 + i18n 键，待换新域名）；去除联系卡片"自动回复"行
+
+### 修复
+
+- `src/sdk.ts` `RUNTIME_VERSION` 1.0.0 → 3.7.2（verify() 输出的运行时版本与发布版本对齐）
+
 ## [3.7.2] — 2026-08-23
 
+### 新增：社区双渠道自动回复机器人（微信 + WhatsApp）
+
+- **微信公众号自动回复 Bot**（`wechat-bot/`）：零依赖 Node webhook——公众号开发者模式服务器配置（sha1 签名校验、安全模式 AES-256-CBC 加解密、被动回复 5s 窗口）、关键词规则自动回复（与 whatsapp-bot 同规则）、关注欢迎语；`Dockerfile`/`fly.toml` 部署模板 + 本地冒烟文档
+- **WhatsApp 自动回复 Bot**（`whatsapp-bot/`，补录）：零依赖 Node webhook——Meta webhook 握手、Graph API 回复、可选 `X-Hub-Signature-256` 签名校验、关键词规则自动回复；`Dockerfile`/`fly.toml` 部署模板 + 本地冒烟文档
+- **「群」指令升级为二维码图片消息**：新增合成图 `assets/community-qr.png`（微信 + WhatsApp 群码并排）；公众号侧经 access_token + 临时素材上传回图片消息（3 天有效、到期自动重传，未配置 `WEIXIN_APP_SECRET` 时回文字版指引）；WhatsApp 侧直接发送图片链接
+- README（中英）「社区与反馈」章节注明双渠道自动回复已上线：关注公众号 / 向官方号码发送「帮助」查看全部指令
+- 回复规则双端同步维护；版本号硬编码于规则内，发版后需同步（`RULES` 数组）
+
+### 修复：微信安全模式 AES 加解密 IV 规范
+
+- 对齐官方 WXBizMsgCrypt：**IV = AES 密钥前 16 字节、密文不带 IV 前缀**（此前误按"IV = 密文前 16 字节"导致解密错位 16 字节、`msgLen` 读出乱码、`appid mismatch`）
+
 ### 文档
 
 - CHANGELOG 悬空项收口：3.6.0「二维码占位待替换」补注 3.6.1 已换真实群码；3.7.0「合并形态 IR-first 待恢复」补注 3.7.1 已完成；3.4.0「check 失败待单独排期」补注 3.4.1 已修复

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 shenlian19831109
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -103,7 +103,7 @@ Progmune is honest about what it can and cannot verify.
 |----------|--------|----------|
 | **TypeScript / JavaScript** | ✅ Production | Blind benchmark: **recall 98.5% / precision 100%** (795 gold findings, 100 projects) |
 | **Python** | ✅ Production | Blind benchmark: **recall 100% / precision 100%** (729 gold findings, 90 projects); real-world validation: PyGoat (OWASP vulnerable-by-design Django app) **67 TP / 0 FP, 100% labeled precision**; three well-written apps (django/fastapi realworld, django-unicorn) with 0 false-positive true findings |
-| **C** | ⚠️ Research-only | Gold benchmark F1=16.5%. L3 cross-function experiment terminated; L4 not planned. See [C Language Status](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/c-language-status.md). |
+| **C** | ⚠️ Research-only | 3.7.4: IR extraction merged via the language registry — app-level protocol lifecycles (auth/db/file/payment) verifiable through the SSG state machine (app-level gold v2: **P=91.7% / R=100% / F1=95.7%**). TLS-level coverage still absent (old regex-route F1=16.5% is the historical baseline); L3/L4 conclusions unchanged. See [C Language Status](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/c-language-status.md). |
 | **Go, Java** | ❌ None | Planned |
 
 **Multi-language IR (registry-based).** TypeScript (ts-morph) and Python (AST) extractors are registered entries in one registry (`src/extract-project-ir.ts`); `extractProjectIR` merges every detected language into a single function IR shared by the agent loop, `execute()`, and the MCP server — the agent composes function-protocol chains across both languages. Adding a language (Go, Java, …) = register one extractor entry; callers don't change.
@@ -152,14 +152,14 @@ Public, reproducible precision data. All numbers measured against gold-annotated
 
 → [Real-world validation report](https://github.com/shenlian19831109/progmune-runtime/blob/main/blind-benchmark/REALWORLD_APP_V1.md) · [Benchmark baseline](https://github.com/shenlian19831109/progmune-runtime/blob/main/blind-benchmark/BASELINE_v6.md)
 
-### C (Gold Benchmark — research status)
+### C (IR extraction + app-level protocol verification — research status)
 
-C analysis is **research-only**: gold benchmark F1=16.5% across 4 repos (curl, libssh, nginx, openssl). The bottleneck is rule coverage, not context. L3 (cross-function) was terminated with data; L4 (pointer/CFG) is a multi-year research problem and not planned. See [C Language Status](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/c-language-status.md) for the full picture and reasoning.
+Since 3.7.4, C has an IR extractor in the multi-language registry: C projects flow into IR-first sequence validation + the SSG state machine. App-level protocol lifecycles (auth/db/file/payment) are verifiable on C — app-level gold v2: **11/11 violations caught (Recall 100%), 1 FP, F1=95.7%**; extraction scales to 10k+ functions per repo in seconds with 89–100% gold-function recovery (curl/libssh/nginx/openssl/nghttp2/redis). Two boundaries remain: the old regex-route gold benchmark F1=16.5% measured **TLS-level misuse** (SSG has no TLS state machines — that gap is unchanged), and L3/L4 conclusions stand (function-pointer dispatch is statically invisible; no pointer/CFG analysis planned). See [C Language Status](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/c-language-status.md) for the full picture and reasoning.
 
 ### P0-P3 Rule Injection (2026-08)
 
-- **+19 new detections** across 10 TS projects, **0 false positives** across 6 C repos + PostgreSQL
-- Bootstrapping deadlock broken: all 21 protocol namespaces now have rule vocabulary
+- **+31 rules / +86 trajectories / +13 detectors / +11 safeguards** injected; +19 new detections across 10 TS projects, **0 false positives** across 6 C repos + PostgreSQL
+- Bootstrapping deadlock broken: all 21 protocol namespaces gained rule vocabulary (today: 27 namespaces, 148 rules)
 - `excludePatterns` + `languages` architecture for FP management
 
 → [P0-P3 Final Report](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/p0-p3-final-report.md)
@@ -173,7 +173,9 @@ SDK (src/sdk.ts)           verify() → APPROVED / NEEDS_REVIEW / BLOCKED
   └─ Trust Engine           4-dimension scoring → Decision
        ├─ Policy Engine     Enterprise policy enforcement (ALLOW/WARN/BLOCK)
        ├─ SSG Validator     Protocol state machine verification
-       ├─ Protocol Detector  Regex-based protocol step detection (22 detectors)
+       ├─ Call Sequences     P4.6 cross-function: entry expansion (depth ≤4) +
+       │                     helper-fragment suppression
+       ├─ Protocol Detector  Regex fallback for IR-less languages (C), 22 detectors
        ├─ IR Extraction      Registry-based: TS (ts-morph) + Python (ast module)
        │                     merged into one function IR per project;
        │                     source-level markers: taint tracking, import resolution,
@@ -204,11 +206,13 @@ SDK (src/sdk.ts)           verify() → APPROVED / NEEDS_REVIEW / BLOCKED
 
 Your feedback shapes Progmune. Scan the QR code to join the user discussion group (WeChat / WhatsApp), or open a [GitHub Issue](https://github.com/shenlian19831109/progmune-runtime/issues) for bug reports, feature requests, and suggestions.
 
+**Auto-reply bots are live on both official messaging channels** — keyword-based instant replies via the WeChat Official Account bot ([`wechat-bot/`](wechat-bot/README.md)) and the WhatsApp Business API bot ([`whatsapp-bot/`](whatsapp-bot/README.md)). Follow the official account / message the business number with "help" to see all commands.
+
 ---
 
 ## Scientific Foundation
 
-Progmune is built on the premise that **LLM outputs are statistical performances, not reasoning** — a view developed by Subbarao Kambhampati et al. in the position paper ["Stop Anthropomorphizing Intermediate Tokens as Reasoning/Thinking Traces!"](https://arxiv.org/abs/2505.22285) (arXiv:2505.22285, 2025) and elaborated in his ICML 2026 talk "On the Role of Verifiers and Thinking Traces in Reasoning Models". Rather than trusting what the model says about code, Progmune verifies what the program actually does — using protocol state machines, IR extraction, and evidence-backed decision chains.
+Progmune is built on the premise that **LLM outputs are statistical performances, not reasoning** — a view developed by Subbarao Kambhampati et al. in the position paper ["Stop Anthropomorphizing Intermediate Tokens as Reasoning/Thinking Traces!"](https://arxiv.org/abs/2504.09762) (arXiv:2504.09762, 2025) and elaborated in his ICML 2026 talk "On the Role of Verifiers and Thinking Traces in Reasoning Models". Rather than trusting what the model says about code, Progmune verifies what the program actually does — using protocol state machines, IR extraction, and evidence-backed decision chains.
 
 → [Investor Whitepaper](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/Progmune_投资人白皮书_v2.0.html) · [Trust Decision Model](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/ai-trust-decision-model-v1.md)
 

package/README.zh-CN.md

@@ -103,7 +103,7 @@ Progmune 对能验证什么、不能验证什么保持诚实。
 |------|------|------|
 | **TypeScript / JavaScript** | ✅ 生产 | 盲测基准：**召回 98.5% / 精确率 100%**（795 条 gold finding，100 个项目） |
 | **Python** | ✅ 生产 | 盲测基准：**召回 100% / 精确率 100%**（729 条 gold finding，90 个项目）；真实应用验证：PyGoat（OWASP 故意脆弱 Django 应用）**67 TP / 0 FP，标记精确率 100%**；三个良构应用（django/fastapi realworld、django-unicorn）0 误报真阳性 |
-| **C** | ⚠️ 仅研究 | 黄金基准 F1=16.5%。L3 跨函数实验已终止；L4 无计划。见 [C 语言状态](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/c-language-status.md)。 |
+| **C** | ⚠️ 仅研究 | 3.7.4：IR 提取接入多语言注册表——应用级协议生命周期（认证/数据库/文件/支付）经 SSG 状态机可验证（应用级金标 v2：**P=91.7% / R=100% / F1=95.7%**）。TLS 级覆盖仍无（旧正则口径 F1=16.5% 为历史基线）；L3/L4 结论不变。见 [C 语言状态](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/c-language-status.md)。 |
 | **Go, Java** | ❌ 无 | 规划中 |
 
 **多语言 IR（注册表式）。** TypeScript（ts-morph）与 Python（AST）提取器是同一注册表（`src/extract-project-ir.ts`）中的注册项；`extractProjectIR` 把检测到的所有语言合并为一份函数 IR，由 agent loop、`execute()` 与 MCP server 共享——agent 可在两种语言上编排函数协议链。新增语言（Go、Java……）= 注册一条提取器，调用方零改动。
@@ -152,14 +152,14 @@ Progmune 对能验证什么、不能验证什么保持诚实。
 
 → [真实验证报告](https://github.com/shenlian19831109/progmune-runtime/blob/main/blind-benchmark/REALWORLD_APP_V1.md) · [基准基线](https://github.com/shenlian19831109/progmune-runtime/blob/main/blind-benchmark/BASELINE_v6.md)
 
-### C（黄金基准——研究状态）
+### C（IR 提取 + 应用级协议验证——研究状态）
 
-C 分析**仅研究**：黄金基准 F1=16.5%，覆盖 4 个仓库（curl、libssh、nginx、openssl）。瓶颈是规则覆盖而非上下文。L3（跨函数）已带数据终止；L4（指针/CFG）是多年研究问题，无计划。详见 [C 语言状态](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/c-language-status.md)。
+3.7.4 起 C 拥有多语言注册表中的 IR 提取器：C 项目进入 IR-first 序列验证 + SSG 状态机。应用级协议生命周期（认证/数据库/文件/支付）在 C 上可验证——应用级金标 v2：**11/11 违规全检出（召回 100%）、1 误报、F1=95.7%**；提取规模化至每仓库 1 万+ 函数、秒级完成、黄金函数恢复率 89–100%（curl/libssh/nginx/openssl/nghttp2/redis）。两条边界不变：旧正则口径黄金基准 F1=16.5% 测的是 **TLS 级误用**（SSG 无 TLS 状态机，该口径不变）；L3/L4 结论维持（函数指针分发静态不可见；无指针/CFG 分析计划）。详见 [C 语言状态](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/c-language-status.md)。
 
 ### P0-P3 规则注入（2026-08）
 
-- 10 个 TS 项目 **+19 条新检测**，6 个 C 仓库 + PostgreSQL **0 误报**
-- 打破引导死锁：全部 21 个协议命名空间已有规则词汇
+- 注入 **+31 条规则 / +86 条轨迹 / +13 个检测器 / +11 条防护**；10 个 TS 项目 **+19 条新检测**，6 个 C 仓库 + PostgreSQL **0 误报**
+- 打破引导死锁：全部 21 个协议命名空间获得规则词汇（今天：27 个命名空间、148 条规则）
 - `excludePatterns` + `languages` 架构管理误报
 
 → [P0-P3 终报](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/p0-p3-final-report.md)
@@ -173,7 +173,9 @@ SDK (src/sdk.ts)           verify() → APPROVED / NEEDS_REVIEW / BLOCKED
   └─ 信任引擎                四维评分 → 决策
        ├─ 策略引擎           企业策略执行（ALLOW/WARN/BLOCK）
        ├─ SSG 校验器         协议状态机验证
-       ├─ 协议检测器         基于正则的协议步骤检测（22 个检测器）
+       ├─ 调用序列           P4.6 跨函数：入口展开（深度 ≤4）+
+       │                     helper 片段抑制
+       ├─ 协议检测器         无 IR 语言（C）的正则回退，22 个检测器
        ├─ IR 提取            注册表式：TS（ts-morph）+ Python（ast 模块）
        │                     合并为每项目一份函数 IR；
        │                     源码级标记：污点追踪、import 解析、限定调用链、跨文件模板分析
@@ -203,11 +205,13 @@ SDK (src/sdk.ts)           verify() → APPROVED / NEEDS_REVIEW / BLOCKED
 
 你的意见塑造 Progmune。扫码加入用户讨论群（微信 / WhatsApp），或通过 [GitHub Issue](https://github.com/shenlian19831109/progmune-runtime/issues) 提交缺陷报告、功能需求与建议。
 
+**双渠道自动回复已上线**：微信公众号与 WhatsApp Business 均已接入关键词自动回复机器人（[`wechat-bot/`](wechat-bot/README.md) 与 [`whatsapp-bot/`](whatsapp-bot/README.md)）——关注公众号 / 向官方号码发送「帮助」即可查看全部指令，即时互动。
+
 ---
 
 ## 科学基础
 
-Progmune 建立在"**LLM 输出是统计表演而非推理**"这一前提上——该观点源自 Subbarao Kambhampati 等人的立场论文 ["Stop Anthropomorphizing Intermediate Tokens as Reasoning/Thinking Traces!"](https://arxiv.org/abs/2505.22285)（arXiv:2505.22285，2025），并在其 ICML 2026 演讲 "On the Role of Verifiers and Thinking Traces in Reasoning Models" 中展开。Progmune 不信任模型对代码的说法，而是用协议状态机、IR 提取与证据链验证程序实际行为。
+Progmune 建立在"**LLM 输出是统计表演而非推理**"这一前提上——该观点源自 Subbarao Kambhampati 等人的立场论文 ["Stop Anthropomorphizing Intermediate Tokens as Reasoning/Thinking Traces!"](https://arxiv.org/abs/2504.09762)（arXiv:2504.09762，2025），并在其 ICML 2026 演讲 "On the Role of Verifiers and Thinking Traces in Reasoning Models" 中展开。Progmune 不信任模型对代码的说法，而是用协议状态机、IR 提取与证据链验证程序实际行为。
 
 → [投资人白皮书](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/Progmune_投资人白皮书_v2.0.html) · [信任决策模型](https://github.com/shenlian19831109/progmune-runtime/blob/main/docs/ai-trust-decision-model-v1.md)
 

package/dist/call-sequence.js

@@ -54,19 +54,38 @@ function collectProjectFunctionNames(ir) {
  *   规则函数的平凡函数体会把调用名"吞掉"
  */
 function buildCallSequences(ir, keepNames) {
+    // 全局按名回退 + 同文件优先映射：C 中跨文件同名 static 函数极常见
+    // （每个 .c 都有 static cleanup/helper），名字级 Map 会让 last-wins 的
+    // 定义绑定到错误的调用方。同翻译单元（文件）定义优先解析——
+    // 文件内回调（cf->close_one() → 本文件 static close_one）因此接回序列构建；
+    // 跨文件函数指针分发仍不可见（L3 结论不变）。
     const fnMap = new Map();
+    const fnMapByFile = new Map();
     for (const f of ir) {
-        if (isProjectFn(f))
-            fnMap.set(f.name, f);
+        if (!isProjectFn(f))
+            continue;
+        fnMap.set(f.name, f);
+        let byFile = fnMapByFile.get(f.file);
+        if (!byFile) {
+            byFile = new Map();
+            fnMapByFile.set(f.file, byFile);
+        }
+        if (!byFile.has(f.name))
+            byFile.set(f.name, f);
     }
-    // 被项目函数调用过的函数不是入口（其片段并入调用方展开序列）
+    /** 调用解析：同文件定义优先，全局按名回退（跨文件同名时每个文件绑自己的） */
+    const resolveCall = (fromFile, name) => fnMapByFile.get(fromFile)?.get(name) ?? fnMap.get(name);
+    // 被项目函数调用过的函数不是入口（其片段并入调用方展开序列）——
+    // 按 文件+名字 粒度判定，避免 A 文件的 static x 被 B 文件的调用误判非入口
+    const fnKey = (file, name) => file + "::" + name;
     const calledBy = new Set();
     for (const f of ir) {
         if (!isProjectFn(f))
             continue;
         for (const c of f.calls || []) {
-            if (fnMap.has(c))
-                calledBy.add(c);
+            const resolved = resolveCall(f.file, c);
+            if (resolved)
+                calledBy.add(fnKey(resolved.file, resolved.name));
         }
     }
     /** 展开函数体内的调用（入口序列 = 函数体调用，不含函数自己的名字） */
@@ -75,20 +94,20 @@ function buildCallSequences(ir, keepNames) {
         for (const c of fn.calls || []) {
             if (typeof c !== "string" || c.startsWith("__progmune_"))
                 continue;
-            out.push(...expandCall(c, depth, visiting));
+            out.push(...expandCall(c, depth, visiting, fn.file));
         }
         return out;
     };
-    const expandCall = (name, depth, visiting) => {
+    const expandCall = (name, depth, visiting, fromFile) => {
         if (depth > MAX_DEPTH || visiting.has(name))
             return [];
-        const fn = fnMap.get(name);
+        const fn = resolveCall(fromFile, name);
         // 外部调用或规则函数：调用名保留给匹配层，不内联
         if (!fn || (keepNames && keepNames.has(name)))
             return [name];
         // 叶子函数（函数体只调外部原语）是协议原语或叶子 helper：
         // 保留名字，不内联——否则 S5 改名协议函数的平凡函数体会吞掉调用名
-        const hasProjectCalls = (fn.calls || []).some((c) => fnMap.has(c));
+        const hasProjectCalls = (fn.calls || []).some((c) => resolveCall(fn.file, c));
         if (!hasProjectCalls)
             return [name];
         visiting.add(name);
@@ -100,7 +119,7 @@ function buildCallSequences(ir, keepNames) {
     for (const f of ir) {
         if (!isProjectFn(f))
             continue;
-        if (calledBy.has(f.name))
+        if (calledBy.has(fnKey(f.file, f.name)))
             continue; // 非入口：片段并入调用方
         if (keepNames && keepNames.has(f.name))
             continue; // 协议原语不是入口：只在调用链内验证

package/dist/call-sequence.test.js

@@ -0,0 +1,99 @@
+"use strict";
+/**
+ * call-sequence (P4.6 跨函数传播) — 单元测试。
+ *
+ * 重点覆盖 2026-08-27 引入的同翻译单元（文件）绑定语义：
+ * 调用解析优先同文件定义（C 跨文件同名 static 函数不再 last-wins 错绑），
+ * 入口判定按 文件+名字 粒度。
+ *
+ * 注意叶子规则：只调外部原语的函数保留名字不内联（S5 改名协议函数的
+ * 保护），夹具需用两级项目函数链使绑定可判别。
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+const vitest_1 = require("vitest");
+const call_sequence_1 = require("./call-sequence");
+/** 构造最小 FunctionInfo（isProjectFn 契约：external=false + 真实 file） */
+function fn(name, file, calls) {
+    return { name, params: [], returnType: "void", file, calls, exported: true, external: false };
+}
+(0, vitest_1.describe)("buildCallSequences（文件级绑定）", () => {
+    (0, vitest_1.it)("跨文件同名 static 函数：调用绑定到同文件定义，而不是 last-wins", () => {
+        const ir = [
+            // A 文件：static x → distinct_a（本文件项目函数）
+            fn("x", "a.c", ["distinct_a"]),
+            fn("distinct_a", "a.c", ["g"]),
+            fn("entry_a", "a.c", ["x"]),
+            // B 文件：static x → distinct_b（若 last-wins 且 B 后注册，entry_a 会错绑到 B 的 x）
+            fn("x", "b.c", ["distinct_b"]),
+            fn("distinct_b", "b.c", ["h"]),
+            fn("entry_b", "b.c", ["x"]),
+        ];
+        const seqs = (0, call_sequence_1.buildCallSequences)(ir);
+        const byFn = new Map(seqs.map((s) => [s.function, s.calls]));
+        (0, vitest_1.expect)(byFn.get("entry_a")).toEqual(["distinct_a"]);
+        (0, vitest_1.expect)(byFn.get("entry_b")).toEqual(["distinct_b"]);
+    });
+    (0, vitest_1.it)("文件内回调接回序列：cf->close_one() 产出 close_one，同文件定义被内联", () => {
+        // 提取器对 cf->close_one() 只产出调用名 close_one；同文件定义 close_one 时
+        // 文件级绑定将其函数体（经 notify_peer）内联进调用方序列
+        const ir = [
+            fn("close_one", "conn.c", ["notify_peer"]),
+            fn("notify_peer", "conn.c", ["send_fin"]),
+            fn("shutdown_conn", "conn.c", ["close_one"]),
+        ];
+        const seqs = (0, call_sequence_1.buildCallSequences)(ir);
+        (0, vitest_1.expect)(seqs).toHaveLength(1);
+        (0, vitest_1.expect)(seqs[0].function).toBe("shutdown_conn");
+        (0, vitest_1.expect)(seqs[0].calls).toEqual(["notify_peer"]);
+    });
+    (0, vitest_1.it)("入口判定按文件粒度：A 的 x 被调用非入口，B 的同名 x 未被调用仍是入口", () => {
+        const ir = [
+            fn("x", "a.c", ["distinct_a"]),
+            fn("distinct_a", "a.c", ["g"]),
+            fn("entry_a", "a.c", ["x"]),
+            fn("x", "b.c", ["h"]), // B 的 x 无调用者 → 仍是入口
+        ];
+        const seqs = (0, call_sequence_1.buildCallSequences)(ir);
+        const names = seqs.map((s) => s.function).sort();
+        (0, vitest_1.expect)(names).toEqual(["entry_a", "x"]);
+        // 唯一名为 x 的序列来自 b.c（A 的 x 已并入 entry_a）
+        const xSeq = seqs.find((s) => s.function === "x");
+        (0, vitest_1.expect)(xSeq.file).toBe("b.c");
+        (0, vitest_1.expect)(xSeq.calls).toEqual(["h"]);
+    });
+    (0, vitest_1.it)("无同文件定义时回退全局按名（跨文件唯一名的既有行为不变）", () => {
+        const ir = [
+            fn("helper", "lib.c", ["util"]),
+            fn("util", "lib.c", ["primitive"]),
+            fn("entry", "app.c", ["helper"]),
+        ];
+        const seqs = (0, call_sequence_1.buildCallSequences)(ir);
+        (0, vitest_1.expect)(seqs).toHaveLength(1);
+        (0, vitest_1.expect)(seqs[0].calls).toEqual(["util"]);
+    });
+    (0, vitest_1.it)("规则名保留单元不内联（keepNames），文件级绑定不影响", () => {
+        const ir = [
+            fn("verify_password", "auth.c", ["check_hash"]),
+            fn("login", "auth.c", ["verify_password"]),
+        ];
+        const seqs = (0, call_sequence_1.buildCallSequences)(ir, new Set(["verify_password"]));
+        (0, vitest_1.expect)(seqs).toHaveLength(1);
+        (0, vitest_1.expect)(seqs[0].function).toBe("login");
+        (0, vitest_1.expect)(seqs[0].calls).toEqual(["verify_password"]);
+    });
+});
+(0, vitest_1.describe)("collectProjectFunctionNames", () => {
+    (0, vitest_1.it)("全名/裸名/小写三形态收录", () => {
+        const ir = [fn("FlowService.svc_x", "a.ts", [])];
+        const names = (0, call_sequence_1.collectProjectFunctionNames)(ir);
+        (0, vitest_1.expect)(names.has("FlowService.svc_x")).toBe(true);
+        (0, vitest_1.expect)(names.has("svc_x")).toBe(true);
+        (0, vitest_1.expect)(names.has("flowservice.svc_x")).toBe(true);
+        (0, vitest_1.expect)(names.has("svc_x".toLowerCase())).toBe(true);
+    });
+    (0, vitest_1.it)("external 条目不收录", () => {
+        const external = { name: "readFileSync", params: [], returnType: "void", file: "(external)", calls: [], external: true };
+        (0, vitest_1.expect)((0, call_sequence_1.isProjectFn)(external)).toBe(false);
+        (0, vitest_1.expect)((0, call_sequence_1.collectProjectFunctionNames)([external]).size).toBe(0);
+    });
+});