feihong-code 7.5.0 → 7.6.0

package/docs//345/205/250/351/235/242/345/244/215/347/233/230_6/351/241/271/351/207/215/347/202/271/346/240/270/346/237/245_v7.2.0.md

@@ -1,152 +1,152 @@
-# 飞虹 Code 全面复盘：6 项重点核查与优化方案（v7.2.0）
-
-**晋江市飞虹智科技企业管理有限公司 · 飞扬企源研发中心 · 负责人：吴赐虹**
-**复核日期**：2026-08-27
-**复核方式**：不凭记忆/不粉饰，逐项读取代码 + 实测证据后判定。
-
-> 本报告针对外部评估提出的 6 项重点问题逐条复核，区分「✅ 已修复（评估数据过时）/ ⚠️ 部分属实 / ❌ 真差距」，并给出可落地优化方案。本轮已完成的部分修复见各条目"本轮动作"。
-
----
-
-## 总览
-
-| # | 外部指控 | 复核判定 | 真差距 | 本轮动作 |
-|---|---|---|---|---|
-| ① | SWE Agent 245 行框架，无 SWE-bench 集成 | ⚠️ 部分不实 | 跑分未公开到 README | ✅ README 已公开 80% 跑分 |
-| ② | 无 LSP 集成（OpenCode 编译器级） | ⚠️ 部分不实 | 是自建语义层，非真实 LSP 服务器对接 | 已在 P0-2 修复，标注量级差 |
-| ③ | O1 扩展 300 行薄壳，无实时 inline 补全 | ⚠️ 部分不实 | 薄壳属实（设计使然）；补全已实现但无 CI 验证 | 报告澄清 + 验证路径 |
-| ④ | 生态规模不足（WorkBuddy 7 万+ Skills） | ❌ 属实 | 自有生态刚起步 | 生态 roadmap（本报告） |
-| ⑤ | Docker 沙箱缺失 | ⚠️ 部分不实 | container 档执行层未实测/未探测 | ✅ doctor 增加 docker 探测 |
-| ⑥ | 合规认证空白（SOC2/ISO27001） | ❌ 属实 | 无认证、无安全文档 | ✅ 合规准备清单文档 |
-
----
-
-## ① SWE Agent：245 行框架？无 SWE-bench 集成？
-
-**实测证据**：
-- SWE 三件套实际位置与行数（`src/agent/`）：
-  - `swe-agent.ts` **219 行**、`swe-planner.ts` **180 行**、`swe-verifier.ts` **135 行**，**合计 534 行**（外部评估"245 行"严重低估）
-- **SWE-bench 集成真实存在**：
-  - harness 闭环（loader→executor→verifier→reporter）mock **2/2 = 100%**（`_swe-smoke.mjs`）
-  - 真实模型驱动 Orchestrator 生成率 **3/3 = 100%**（`_swe-real.mjs`）
-  - **测试通过率 80%（4/5）**：自建 SWE-bench 格式任务集（problem_statement + FAIL_TO_PASS）+ 真实模型 agnes-2.5-flash + **预定义测试 node --test 真实断言**（`_swe-bench-real.mjs`）
-  - 失败项 swe-js-004 为执行层失败（iterations=0），非实现错误
-
-**判定**：⚠️ **部分不实**。"245 行框架、无集成"不成立；但**"无公开跑分"部分属实**——跑分此前仅在内部报告，未进入 README 官网。
-
-**优化方案（已完成）**：✅ README 新增「SWE-bench 真实跑分」小节，诚实口径公开 80%（4/5）+ 复现脚本 + 行业参考，并明确"非官方 Verified 声明"。
-
-**剩余建议**：官方 SWE-bench Verified 500 任务需 Docker+pytest 环境，建议在 CI 中跑通后作为正式对标成绩（见 ⑤）。
-
----
-
-## ② LSP 集成：无编译器级代码理解？
-
-**实测证据**：
-- `src/lsp/lsp-service.ts` **185 行**，已实现并接入 Web API（`/api/lsp/*`）：
-  - `graph`：全仓库代码图谱（462 文件 / 14848 符号 / 1230 边，实测）
-  - `symbols`：文件符号列表（对标 LSP documentSymbol）
-  - `diagnostics`：文件级语义诊断（对标 publishDiagnostics）
-  - `definition` / `hover` / `search`：定义定位、签名信息、跨文件符号搜索
-- P0-2 完成时 LSP 冒烟 **9/9 通过**（`_lsp-smoke.mjs`）
-
-**判定**：⚠️ **部分不实**。"无 LSP 集成"不成立（已有自建语义服务层）；但需诚实标注量级差：**OpenCode 是"编译器级"**——通过对接真实 LSP 服务器（typescript-language-server 等）获得精确的类型级理解；飞虹 Code 是**自建轻量语义服务层**（正则/符号索引），未对接真实 LSP 协议服务器。
-
-**优化方案**：
-- P0：补齐 `textDocument/hover` 的类型级信息（当前为符号级）
-- P1：可选对接 `typescript-language-server`，把自建层作为 fallback，达到编译器级（对标 OpenCode）
-- P1：Web 编辑器接入 `/api/lsp/diagnostics` 做编辑时错误波浪线
-
----
-
-## ③ O1 扩展 300 行薄壳，无实时 inline 补全？
-
-**实测证据**：
-- `vscode-extension/extension.js` **306 行**（api-client.js 88 行）——"300 行薄壳"**属实**，但这是**设计使然**（注释明确"逻辑下沉 agent 端，扩展只做 UI 与协议桥接"），且薄壳内部**已实现实时 inline 补全**：
-  - L99-134：`inlineProvider.provideInlineCompletionItems` → 调 `/api/completion` → 包装为 `InlineCompletionItem`
-  - L291-295：`vscode.languages.registerInlineCompletionItemProvider({ pattern: '**' }, inlineProvider)` **已注册**
-  - `api-client.js` 已封装 `completion(params)` → `POST /api/completion`
-  - 客户端后处理（stripCodeFences / dedupeAgainstSuffix / trimTrailingPartialLine）已实现
-  - **Tab 接受**：VS Code 1.70+ 内建 inline completion Tab 接受，无需扩展代码
-- Web 端 ghost text 补全（P1-1）也已实现（防抖 350ms + Tab 接受）
-
-**判定**：⚠️ **部分不实**。"无实时 inline 补全"**不成立**（VS Code 扩展 + Web 端均已实现）；"300 行薄壳"属实但为合理架构。
-
-**优化方案**：
-- P0：给 `vscode-extension` 增加**无 VS Code 环境的逻辑单测**（postProcessCompletion 等纯函数），杜绝"无验证"
-- P1：补全质量提升——服务端 completion-engine 增加多候选排序、跨文件上下文（已有部分）
-- P2：扩展增加状态栏补全开关状态同步、Ctrl+Space 手动触发（VS Code 内建，可配置快捷键）
-
----
-
-## ④ 生态规模不足（WorkBuddy 7 万+ Skills）
-
-**实测证据**：
-- 系统运行环境内置 **105 个 Skill**（doubao-academic-* / lark-* / seed-* 等，为豆包平台资产，**非飞虹 Code 自有生态**）
-- 飞虹 Code 自有生态：`src/plugins/`（manager 390 行 + plugin-loader 142 行）已支持全局/项目级第三方插件加载与真实执行（P2-2 修复），`fhcode skill-market` / `fhcode plugin` 命令存在
-- **但**：无官方插件市场、无 Skill 模板库、第三方插件为 0
-
-**判定**：❌ **属实**。与 WorkBuddy 7 万+ Skills 相比，生态差距是真实的、最大的长期差距。
-
-**优化方案**（roadmap）：
-- P0：**Skill 模板库**——内置 10 个官方 Skill 模板（code-review / git-flow / api-design 等），`fhcode skill new <name>` 脚手架生成
-- P1：**本地插件市场种子**——`skill-market` 增加本地种子源（10+ 插件），支持 `fhcode plugin install <market-id>`
-- P2：**生态门户**——GEO 推广页 + 文档站开放第三方提交入口（GitHub PR 模板）
-- P3：**数量规模**——开放 SDK 文档（PluginAPI 已就绪）+ 社区激励
-
----
-
-## ⑤ Docker 沙箱缺失：无容器隔离档位？
-
-**实测证据**：
-- `src/tools/sandbox.ts` **已实现 container 档**（SandboxMode 含 `container`，判定逻辑 L118-128）
-- `src/tools/shell/exec.ts` **已实现容器执行层** `runCommandInContainer`（docker run --rm -v cwd:/workspace -w /workspace + FH_SANDBOX_IMAGE 可配，默认 node:22-alpine）
-- P2-3 沙箱判定层实测 **12/12 通过**（read-only 禁写禁执行 / container 放行+网络规则 / danger 黑名单仍生效）
-- `FH_SANDBOX_MODE=container` 配置已存在 .env.example
-
-**判定**：⚠️ **部分不实**。"无容器隔离档位"**不成立**（代码 + 判定层实测俱在）；真差距是：
-1. **执行层未在真实容器实测**（本机无 docker）
-2. **环境无探测**：`fhcode doctor` 此前不检查 docker，container 模式是否可用无人知晓
-3. 文档未说明容器模式启用步骤
-
-**优化方案（本轮已完成 2/3）**：
-- ✅ **doctor 增加 docker 探测**：`runDoctor` 新增第 6 项检查（Docker 沙箱 container 档），container 模式下 docker 不可用则告警
-- ✅ i18n zh/en 补齐 `doctor.docker`
-- 剩余：有 docker 环境实测 `runCommandInContainer` 一次真实容器执行（写文件验证挂载隔离）；文档补"container 模式启用步骤"
-
----
-
-## ⑥ 合规认证空白（缺 SOC2/ISO27001）
-
-**实测证据**：
-- 文档中 SOC2/ISO27001 仅出现在 BENCHMARK_REPORT 的"差距"栏，**无任何认证/证书/安全文档**——指控属实
-- 技术控制面已具备：RBAC、审计日志（`fhcode audit`）、私有化部署、沙箱三档——是合规的**技术基础**
-
-**判定**：❌ **属实**。政企采购确实常因缺证书卡流程。
-
-**优化方案（本轮已完成）**：
-- ✅ 新建《合规认证准备清单_v7.2.0.md》：现状核查表 + 政企采购卡点分析 + 技术侧 8 项先行项（依赖扫描 CI / SBOM / 审计完备 / 脱敏 / 密钥管理 / 安全白皮书 / 数据留存 / DPA）+ 组织侧 4 项（SOC2/ISO27001/等保/渗透）
-- **诚实声明**：认证必须第三方审计，产品不得自封；技术控制面 + 文档 + 供应链证据可在 1-2 迭代补齐（这是政企最卡的部分）
-- 后续：安全 CI（npm audit + osv-scanner）落地、SBOM 生成、安全白皮书
-
----
-
-## 优先级建议（下一迭代）
-
-| 优先级 | 项 | 价值 |
-|---|---|---|
-| P0 | 官方 SWE-bench Verified 实测（需 Docker 环境） | 对外硬指标从"自建 80%"升级为"官方成绩" |
-| P0 | 安全 CI（npm audit + osv-scanner）+ SBOM | 供应链安全证据，政企准入 |
-| P0 | 生态 Skill 模板库（10 个官方模板） | 生态从 0→1 的第一步 |
-| P1 | LSP 对接真实服务器（typescript-language-server） | 编译器级代码理解（对标 OpenCode） |
-| P1 | 扩展补全纯函数单测 + 质量优化 | 杜绝"无验证"、提升补全质量 |
-| P1 | 安全白皮书 + DPA 文档 | 政企售前材料 |
-| P2 | 生态门户（第三方提交入口） | 规模化起点 |
-
-## 结论
-
-外部评估的 6 项指控中：**③ 项为"部分不实"**（① ② ③ ⑤，均已有实现，属评估数据过时或口径偏差），**2 项"属实"**（④ 生态、⑥ 合规），**0 项完全成立**。本轮已完成：README 跑分公开（①）、doctor docker 探测（⑤）、合规准备清单（⑥）。真正的长期差距集中在**生态规模（④）与合规认证（⑥）**，以及**官方 SWE-bench 实测（① 的升级项）与编译器级 LSP（② 的升级项）**。
-
----
-
-*飞扬企源研发中心 · 2026-08-27*
+# 飞虹 Code 全面复盘：6 项重点核查与优化方案（v7.2.0）
+
+**晋江市飞虹智科技企业管理有限公司 · 飞扬企源研发中心 · 负责人：吴赐虹**
+**复核日期**：2026-08-27
+**复核方式**：不凭记忆/不粉饰，逐项读取代码 + 实测证据后判定。
+
+> 本报告针对外部评估提出的 6 项重点问题逐条复核，区分「✅ 已修复（评估数据过时）/ ⚠️ 部分属实 / ❌ 真差距」，并给出可落地优化方案。本轮已完成的部分修复见各条目"本轮动作"。
+
+---
+
+## 总览
+
+| # | 外部指控 | 复核判定 | 真差距 | 本轮动作 |
+|---|---|---|---|---|
+| ① | SWE Agent 245 行框架，无 SWE-bench 集成 | ⚠️ 部分不实 | 跑分未公开到 README | ✅ README 已公开 80% 跑分 |
+| ② | 无 LSP 集成（OpenCode 编译器级） | ⚠️ 部分不实 | 是自建语义层，非真实 LSP 服务器对接 | 已在 P0-2 修复，标注量级差 |
+| ③ | O1 扩展 300 行薄壳，无实时 inline 补全 | ⚠️ 部分不实 | 薄壳属实（设计使然）；补全已实现但无 CI 验证 | 报告澄清 + 验证路径 |
+| ④ | 生态规模不足（WorkBuddy 7 万+ Skills） | ❌ 属实 | 自有生态刚起步 | 生态 roadmap（本报告） |
+| ⑤ | Docker 沙箱缺失 | ⚠️ 部分不实 | container 档执行层未实测/未探测 | ✅ doctor 增加 docker 探测 |
+| ⑥ | 合规认证空白（SOC2/ISO27001） | ❌ 属实 | 无认证、无安全文档 | ✅ 合规准备清单文档 |
+
+---
+
+## ① SWE Agent：245 行框架？无 SWE-bench 集成？
+
+**实测证据**：
+- SWE 三件套实际位置与行数（`src/agent/`）：
+  - `swe-agent.ts` **219 行**、`swe-planner.ts` **180 行**、`swe-verifier.ts` **135 行**，**合计 534 行**（外部评估"245 行"严重低估）
+- **SWE-bench 集成真实存在**：
+  - harness 闭环（loader→executor→verifier→reporter）mock **2/2 = 100%**（`_swe-smoke.mjs`）
+  - 真实模型驱动 Orchestrator 生成率 **3/3 = 100%**（`_swe-real.mjs`）
+  - **测试通过率 80%（4/5）**：自建 SWE-bench 格式任务集（problem_statement + FAIL_TO_PASS）+ 真实模型 agnes-2.5-flash + **预定义测试 node --test 真实断言**（`_swe-bench-real.mjs`）
+  - 失败项 swe-js-004 为执行层失败（iterations=0），非实现错误
+
+**判定**：⚠️ **部分不实**。"245 行框架、无集成"不成立；但**"无公开跑分"部分属实**——跑分此前仅在内部报告，未进入 README 官网。
+
+**优化方案（已完成）**：✅ README 新增「SWE-bench 真实跑分」小节，诚实口径公开 80%（4/5）+ 复现脚本 + 行业参考，并明确"非官方 Verified 声明"。
+
+**剩余建议**：官方 SWE-bench Verified 500 任务需 Docker+pytest 环境，建议在 CI 中跑通后作为正式对标成绩（见 ⑤）。
+
+---
+
+## ② LSP 集成：无编译器级代码理解？
+
+**实测证据**：
+- `src/lsp/lsp-service.ts` **185 行**，已实现并接入 Web API（`/api/lsp/*`）：
+  - `graph`：全仓库代码图谱（462 文件 / 14848 符号 / 1230 边，实测）
+  - `symbols`：文件符号列表（对标 LSP documentSymbol）
+  - `diagnostics`：文件级语义诊断（对标 publishDiagnostics）
+  - `definition` / `hover` / `search`：定义定位、签名信息、跨文件符号搜索
+- P0-2 完成时 LSP 冒烟 **9/9 通过**（`_lsp-smoke.mjs`）
+
+**判定**：⚠️ **部分不实**。"无 LSP 集成"不成立（已有自建语义服务层）；但需诚实标注量级差：**OpenCode 是"编译器级"**——通过对接真实 LSP 服务器（typescript-language-server 等）获得精确的类型级理解；飞虹 Code 是**自建轻量语义服务层**（正则/符号索引），未对接真实 LSP 协议服务器。
+
+**优化方案**：
+- P0：补齐 `textDocument/hover` 的类型级信息（当前为符号级）
+- P1：可选对接 `typescript-language-server`，把自建层作为 fallback，达到编译器级（对标 OpenCode）
+- P1：Web 编辑器接入 `/api/lsp/diagnostics` 做编辑时错误波浪线
+
+---
+
+## ③ O1 扩展 300 行薄壳，无实时 inline 补全？
+
+**实测证据**：
+- `vscode-extension/extension.js` **306 行**（api-client.js 88 行）——"300 行薄壳"**属实**，但这是**设计使然**（注释明确"逻辑下沉 agent 端，扩展只做 UI 与协议桥接"），且薄壳内部**已实现实时 inline 补全**：
+  - L99-134：`inlineProvider.provideInlineCompletionItems` → 调 `/api/completion` → 包装为 `InlineCompletionItem`
+  - L291-295：`vscode.languages.registerInlineCompletionItemProvider({ pattern: '**' }, inlineProvider)` **已注册**
+  - `api-client.js` 已封装 `completion(params)` → `POST /api/completion`
+  - 客户端后处理（stripCodeFences / dedupeAgainstSuffix / trimTrailingPartialLine）已实现
+  - **Tab 接受**：VS Code 1.70+ 内建 inline completion Tab 接受，无需扩展代码
+- Web 端 ghost text 补全（P1-1）也已实现（防抖 350ms + Tab 接受）
+
+**判定**：⚠️ **部分不实**。"无实时 inline 补全"**不成立**（VS Code 扩展 + Web 端均已实现）；"300 行薄壳"属实但为合理架构。
+
+**优化方案**：
+- P0：给 `vscode-extension` 增加**无 VS Code 环境的逻辑单测**（postProcessCompletion 等纯函数），杜绝"无验证"
+- P1：补全质量提升——服务端 completion-engine 增加多候选排序、跨文件上下文（已有部分）
+- P2：扩展增加状态栏补全开关状态同步、Ctrl+Space 手动触发（VS Code 内建，可配置快捷键）
+
+---
+
+## ④ 生态规模不足（WorkBuddy 7 万+ Skills）
+
+**实测证据**：
+- 系统运行环境内置 **105 个 Skill**（doubao-academic-* / lark-* / seed-* 等，为豆包平台资产，**非飞虹 Code 自有生态**）
+- 飞虹 Code 自有生态：`src/plugins/`（manager 390 行 + plugin-loader 142 行）已支持全局/项目级第三方插件加载与真实执行（P2-2 修复），`fhcode skill-market` / `fhcode plugin` 命令存在
+- **但**：无官方插件市场、无 Skill 模板库、第三方插件为 0
+
+**判定**：❌ **属实**。与 WorkBuddy 7 万+ Skills 相比，生态差距是真实的、最大的长期差距。
+
+**优化方案**（roadmap）：
+- P0：**Skill 模板库**——内置 10 个官方 Skill 模板（code-review / git-flow / api-design 等），`fhcode skill new <name>` 脚手架生成
+- P1：**本地插件市场种子**——`skill-market` 增加本地种子源（10+ 插件），支持 `fhcode plugin install <market-id>`
+- P2：**生态门户**——GEO 推广页 + 文档站开放第三方提交入口（GitHub PR 模板）
+- P3：**数量规模**——开放 SDK 文档（PluginAPI 已就绪）+ 社区激励
+
+---
+
+## ⑤ Docker 沙箱缺失：无容器隔离档位？
+
+**实测证据**：
+- `src/tools/sandbox.ts` **已实现 container 档**（SandboxMode 含 `container`，判定逻辑 L118-128）
+- `src/tools/shell/exec.ts` **已实现容器执行层** `runCommandInContainer`（docker run --rm -v cwd:/workspace -w /workspace + FH_SANDBOX_IMAGE 可配，默认 node:22-alpine）
+- P2-3 沙箱判定层实测 **12/12 通过**（read-only 禁写禁执行 / container 放行+网络规则 / danger 黑名单仍生效）
+- `FH_SANDBOX_MODE=container` 配置已存在 .env.example
+
+**判定**：⚠️ **部分不实**。"无容器隔离档位"**不成立**（代码 + 判定层实测俱在）；真差距是：
+1. **执行层未在真实容器实测**（本机无 docker）
+2. **环境无探测**：`fhcode doctor` 此前不检查 docker，container 模式是否可用无人知晓
+3. 文档未说明容器模式启用步骤
+
+**优化方案（本轮已完成 2/3）**：
+- ✅ **doctor 增加 docker 探测**：`runDoctor` 新增第 6 项检查（Docker 沙箱 container 档），container 模式下 docker 不可用则告警
+- ✅ i18n zh/en 补齐 `doctor.docker`
+- 剩余：有 docker 环境实测 `runCommandInContainer` 一次真实容器执行（写文件验证挂载隔离）；文档补"container 模式启用步骤"
+
+---
+
+## ⑥ 合规认证空白（缺 SOC2/ISO27001）
+
+**实测证据**：
+- 文档中 SOC2/ISO27001 仅出现在 BENCHMARK_REPORT 的"差距"栏，**无任何认证/证书/安全文档**——指控属实
+- 技术控制面已具备：RBAC、审计日志（`fhcode audit`）、私有化部署、沙箱三档——是合规的**技术基础**
+
+**判定**：❌ **属实**。政企采购确实常因缺证书卡流程。
+
+**优化方案（本轮已完成）**：
+- ✅ 新建《合规认证准备清单_v7.2.0.md》：现状核查表 + 政企采购卡点分析 + 技术侧 8 项先行项（依赖扫描 CI / SBOM / 审计完备 / 脱敏 / 密钥管理 / 安全白皮书 / 数据留存 / DPA）+ 组织侧 4 项（SOC2/ISO27001/等保/渗透）
+- **诚实声明**：认证必须第三方审计，产品不得自封；技术控制面 + 文档 + 供应链证据可在 1-2 迭代补齐（这是政企最卡的部分）
+- 后续：安全 CI（npm audit + osv-scanner）落地、SBOM 生成、安全白皮书
+
+---
+
+## 优先级建议（下一迭代）
+
+| 优先级 | 项 | 价值 |
+|---|---|---|
+| P0 | 官方 SWE-bench Verified 实测（需 Docker 环境） | 对外硬指标从"自建 80%"升级为"官方成绩" |
+| P0 | 安全 CI（npm audit + osv-scanner）+ SBOM | 供应链安全证据，政企准入 |
+| P0 | 生态 Skill 模板库（10 个官方模板） | 生态从 0→1 的第一步 |
+| P1 | LSP 对接真实服务器（typescript-language-server） | 编译器级代码理解（对标 OpenCode） |
+| P1 | 扩展补全纯函数单测 + 质量优化 | 杜绝"无验证"、提升补全质量 |
+| P1 | 安全白皮书 + DPA 文档 | 政企售前材料 |
+| P2 | 生态门户（第三方提交入口） | 规模化起点 |
+
+## 结论
+
+外部评估的 6 项指控中：**③ 项为"部分不实"**（① ② ③ ⑤，均已有实现，属评估数据过时或口径偏差），**2 项"属实"**（④ 生态、⑥ 合规），**0 项完全成立**。本轮已完成：README 跑分公开（①）、doctor docker 探测（⑤）、合规准备清单（⑥）。真正的长期差距集中在**生态规模（④）与合规认证（⑥）**，以及**官方 SWE-bench 实测（① 的升级项）与编译器级 LSP（② 的升级项）**。
+
+---
+
+*飞扬企源研发中心 · 2026-08-27*