progmune-runtime 3.2.0 → 3.2.1

package/README.md

@@ -23,6 +23,21 @@ Output: `APPROVED` / `NEEDS_REVIEW` / `BLOCKED` — with Trust Score, evidence,
 
 ---
 
+## Two Paths: Intercept or Verify
+
+Progmune covers **two code sources** with two complementary mechanisms:
+
+| | **Generate path** (agent-time interception) | **Verify path** (post-hoc checking) |
+|---|---|---|
+| **Covers** | Code generated *through Progmune* (`progmune_generate` / `progmune_execute`) | Code written anywhere — Copilot, Cursor, humans (`progmune_trust_check` / SDK / CI) |
+| **Mechanism** | 8 validation gates inside the generation loop: JSON parse → schema → SVL-1 symbol → SVL-2 types → SVL-3 dataflow → SVL-4 protocol state machine → BFS deterministic repair → semantic contract. Violating code is **never written to disk** — it is corrected or retried before emission. | Trust Engine: 4-dimension weighted scoring (policy 35% / protocol 30% / coverage 20% / governance 15%) → Decision + evidence trail |
+| **When errors are handled** | At creation time — the error never exists | After the fact — the file already exists |
+| **Cost curve** | Zero — the violation never landed | Higher the later it's found |
+
+This is the core product thesis: **verify at generation time, not after the fact.** LLM outputs are proposals; the state machine is the referee. LLMs can be persuaded — state machines cannot.
+
+---
+
 ## What Progmune Detects
 
 AI code generators produce syntactically valid code that often violates **protocol lifecycles** — the correct sequence of operations like open→read→close or auth→validate→respond. These violations are invisible to traditional static analysis.
@@ -81,11 +96,19 @@ Progmune is honest about what it can and cannot verify.
 | Language | Status | Evidence |
 |----------|--------|----------|
 | **TypeScript / JavaScript** | ✅ Production | Blind benchmark: P=86.8%, R=83.6%, F1=85.2% (432 sequences, 10 projects) |
-| **C** | ⚠️ Research | Gold benchmark: curl F1=45.7%, libssh F1=46.2%. L3 cross-function experiment terminated — L4 (pointer/CFG) needed. |
+| **C** | ⚠️ Research-only | Gold benchmark F1=16.5%. L3 cross-function experiment terminated; L4 not planned. See [C Language Status](docs/c-language-status.md). |
 | **Python** | 🔨 IR only | IR extractor exists (`extract-ir-python.ts`), no verification rules yet |
 | **Go, Java** | ❌ None | Planned |
 
-**Framework adapters: 1/13.** Express is the first. Next.js, NestJS, Fastify, Django, FastAPI — 12 remaining. Framework adaptation is the #1 product gap.
+**Framework adapters: 2/13.** Express ✅ and tRPC ✅ have dedicated detectors; Next.js has version-aware governance; NestJS is partial. Django, FastAPI and 8 more remain — framework adaptation is the #1 product gap.
+
+### What Progmune does NOT cover (honest boundaries)
+
+- **Taint-based injection flaws** — SQL injection, XSS, command injection. These require dataflow/taint tracking, which is deliberately out of scope in Phase 1 (adding it would make Progmune a generic SAST competitor; protocol-sequence verification is the differentiator).
+- **SCA / dependency vulnerabilities** — hallucinated package names, supply-chain issues. Separate tooling exists for this.
+- **Runtime behavior** — Progmune is static analysis only; no DAST/sandbox execution.
+- **Obfuscated or dynamic code** — `eval`, `Function` constructor, and heavily obfuscated flows degrade regex/IR detection recall.
+- **Known failure boundaries are documented** rather than hidden: if Progmune cannot verify a language (e.g. Go), Confidence is lowered instead of pretending 100%.
 
 → [Full Coverage Matrix](docs/coverage-matrix.md)
 
@@ -104,14 +127,9 @@ Public, reproducible precision data. All numbers measured against gold-annotated
 | F1 | 85.2% |
 | Projects | 10 (ecommerce, blog, chat, crm, forum, wiki, issuetracker, filestorage, todo, scheduler) |
 
-### C (Gold Benchmark v7)
+### C (Gold Benchmark — research status)
 
-| Repo | Precision | Recall | F1 | Samples |
-|------|-----------|--------|-----|---------|
-| curl | 30.9% | 87.5% | 45.7% | 85 |
-| libssh | 36.0% | 64.3% | 46.2% | 47 |
-| nginx | — | — | 0 FP | 50 |
-| redis | — | — | 0 FP | 50 |
+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](docs/c-language-status.md) for the full picture and reasoning.
 
 ### P0-P3 Rule Injection (2026-08)
 
@@ -150,9 +168,9 @@ SDK (src/sdk.ts)           verify() → APPROVED / NEEDS_REVIEW / BLOCKED
 
 ## Scientific Foundation
 
-Progmune is built on the premise that **LLM outputs are statistical performances, not reasoning** (Kambhampati et al., ICML 2026). 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/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.
 
-Recent work applies Sergei Gukov's "Two-Hump Problem" framework to understand and systematically close detection capability gaps.
+Coverage-gap analysis borrows the "two-hump problem" terminology **as a cross-domain analogy** from Sergei Gukov's work in mathematical physics (the Andrews-Curtis conjecture in group theory, 2026) — it describes a bimodal coverage distribution, not a collaboration. See [Two-Hump Report](docs/two-hump-report.md) for the full methodology.
 
 → [Investor Whitepaper](docs/Progmune_投资人白皮书_v2.0.html) · [Trust Decision Model](docs/ai-trust-decision-model-v1.md)
 
@@ -174,8 +192,8 @@ High-impact contribution areas:
 - **Runtime Pipeline:** Detect → Explain → Repair → Validate (L1–L4)
 - **Trust Engine:** 4-dimension scoring with binary explainability gate
 - **MCP Tools:** 19 — `progmune_trust_check`, `progmune_score`, `progmune_policy_check`, `progmune_certify`, and more
-- **Framework Adapters:** Express ✅ (1/13)
-- **Knowledge Base:** 31 domains, 140 protocol rules, 22 detectors, 26 safeguards
+- **Framework Adapters:** Express ✅, tRPC ✅, NestJS partial (2/13)
+- **Knowledge Base:** 31 domains, 148 protocol rules, 22 detectors, 26 safeguards, PLSB 13/13 categories
 - **Corpus:** 2,500+ trajectories across 6+ repositories
 - **Current focus:** Framework adaptation + enterprise PoC validation
 

package/docs/Progmune_/351/241/271/347/233/256/345/205/250/350/247/243.html

@@ -346,7 +346,7 @@
   <div class="bar"><span class="bl">人工审查能力</span><div class="bt"><div class="bf" style="width:10%"></div></div><span class="bv">1x</span></div>
 
   <h3>3.2 问题本质：AI 写代码的原理决定了它"看不见"错误</h3>
-  <p>大语言模型生成代码的方式是<strong>统计预测</strong>——根据训练数据猜"下一个最可能的词"。学术研究（Kambhampati et al., ICML 2026）明确指出：LLM 输出的"逐步推理"是统计表演，中间 token 与真实推理之间没有可靠的因果对应。</p>
+  <p>大语言模型生成代码的方式是<strong>统计预测</strong>——根据训练数据猜"下一个最可能的词"。这一观点的代表性论述来自 Subbarao Kambhampati 等的立场论文《Stop Anthropomorphizing Intermediate Tokens as Reasoning/Thinking Traces!》（arXiv:2505.22285）及其 ICML 2026 关于 verifier 的主题演讲：LLM 输出的"逐步推理"是统计表演，中间 token 与真实推理之间没有可靠的因果对应。</p>
   <p>这意味着：AI 写出"看似合理的代码"和"实际正确的代码"是两件事。它会一本正经地调用不存在的函数、跳过关键的认证步骤——<strong>而且完全静默，不报错</strong>。</p>
 
   <h3>3.3 现有方案为什么不够</h3>
@@ -470,7 +470,18 @@ AI 生成: create_session(...)   ← 当前状态 UNAUTHENTICATED
   <h3>5.4 API 语义映射：让检查认识"陌生函数"</h3>
   <p>真实项目使用的函数名千变万化（<code>createSessionToken</code>、<code>signSession</code>、<code>jwt.sign</code>……）。系统用三层策略把陌生函数映射到协议规则：① 本地前缀/别名表（含项目自定义 <code>.progmune_aliases.json</code>）→ ② 单词切分匹配 → ③ LLM 批量语义分类（带磁盘缓存，重复运行零 LLM 成本）。</p>
 
-  <h3>5.5 信任引擎：五阶段流水线</h3>
+  <h3>5.5 双路径架构：生成时拦截 vs 事后检查</h3>
+  <p>Progmune 用两条互补路径覆盖两类代码来源——这是理解产品的关键，也是最容易被误读的地方：</p>
+  <table>
+    <tr><th></th><th><strong>生成路径</strong>（生成时拦截）</th><th><strong>验证路径</strong>（事后检查）</th></tr>
+    <tr><td>覆盖场景</td><td>通过 <code>progmune_generate</code> 生成的代码</td><td>任何来源的代码（Copilot、Cursor、人工）</td></tr>
+    <tr><td>机制</td><td>生成循环内 8 道验证关卡：JSON 解析 → 结构预检 → 符号纠正 → 类型修正 → 数据流 → 协议状态机 → BFS 确定性修复 → 语义合约。违规代码<strong>从不写入文件</strong></td><td>信任引擎五阶段流水线（收集→评分→决策→组装），四维加权输出部署决策</td></tr>
+    <tr><td>错误处理时机</td><td>创建时刻——错误从未存在</td><td>事后——文件已存在</td></tr>
+    <tr><td>成本曲线</td><td>零——违规没有落地</td><td>发现越晚越贵</td></tr>
+  </table>
+  <p>核心产品论：<strong>在生成时刻验证，而非事后补救。</strong>LLM 的输出只是提议，状态机才是裁判——LLM 可以被劝服，状态机不会。</p>
+
+  <h3>5.6 信任引擎：五阶段流水线</h3>
   <div class="flow">
     <div class="node">1. 收集<br><span style="font-size:.8em;font-weight:400">策略+协议+框架数据</span></div>
     <span class="arrow">→</span>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "progmune-runtime",
-  "version": "3.2.0",
+  "version": "3.2.1",
   "description": "Progmune — AI Trust Decision Engine. Verify AI-generated code before it reaches production. Outputs APPROVED / NEEDS_REVIEW / BLOCKED with evidence.",
   "files": [
     "dist/",
@@ -106,4 +106,4 @@
     "tsx": "^4.22.4",
     "vitest": "^3.2.6"
   }
-}
+}