@hupan56/wlkj 3.1.25 → 3.1.26

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hupan56/wlkj",
-  "version": "3.1.25",
+  "version": "3.1.26",
   "description": "AI Product R&D Workflow - PRD/Prototype/Search/Task/Report",
   "bin": {
     "wlkj": "bin/cli.js"

package/templates/qoder/scripts/README.md

@@ -1,102 +1,102 @@
-# .qoder/scripts/ — 引擎脚本目录 (分层架构)
-
-> 引擎代码, 由 `npx @hupan56/wlkj init/update` 生成, **不进团队 git** (Trellis 化)。
-> 用户不直接碰这些文件 — 通过 `/命令` 和 `npx` 间接调用。
-
-## 🏗️ 分层架构 (7 层)
-
-子目录化 (v3.0) 后, 脚本按职责分层, 顶层**无散落 .py**, 只有 7 个分层目录:
-
-```
-scripts/
-├── orchestration/   编排层 — wlkj.py 统一入口 (载体收敛点)
-├── foundation/      基础层 — 共享库 (被所有层 import)
-├── domain/          领域层 — 业务逻辑 (kg/task/report/...)
-├── protocol/        协议层 — MCP server / 传输适配
-├── capability/      能力层 — 链式能力编排 / 冒烟测试
-├── validation/      验证层 — 测试 / 评测 / 基准
-└── deployment/      部署层 — 安装 / 体检 / 载体同步
-```
-
-## 🚪 统一入口: `orchestration/wlkj.py` (Facade)
-
-**所有 Qoder 载体 (commands/skills/rules) 的脚本调用都走这个入口**, 由 DISPATCH 表路由到
-分层路径。这样 scripts/ 重组目录时只改 DISPATCH 一处, 载体不受影响。
-
-```bash
-python .qoder/scripts/orchestration/wlkj.py <命令> [参数...]
-# 例: wlkj.py kg search 保险 | wlkj.py task list | wlkj.py doctor --fix
-```
-
-完整命令表见 `wlkj.py` 的 DISPATCH (kg/search/context/task/sync/req/eval/learn/status/report/test/doctor 等 36 条)。
-脚本内部互调 (Python 进程间) 直接用分层路径, 不绕 wlkj (避免 subprocess 嵌套)。
-
-## 各层职责 + 关键脚本
-
-### 🎼 orchestration/ — 编排
-| 脚本 | 用途 |
-|------|------|
-| `wlkj.py` | **统一调度入口**, DISPATCH 透明转发到各层脚本 |
-
-### 🧱 foundation/ — 基础 (共享库, 不含业务)
-| 模块 | 用途 |
-|------|------|
-| `bootstrap.py` | sys.path 自举 (子目录化后定位 scripts/ 根) |
-| `core/paths.py` | **路径管理** (PROJECT_ROOT / get_repo_root / get_developer) |
-| `identity/` | 身份 (identity.py / developer.py / roles.py 角色章节) |
-| `io/` | 原子 IO (atomicio.py) / 文件锁 (filelock.py) |
-| `protocol/mcp_base.py` | MCP server 基类 (@tool 装饰器 + 元类注册) |
-| `integrations/` | 术语扩展 (terms.py) / 禅道客户端 (zentao_client.py, 单一真源) |
-| `utils/eval_api.py` | 评测 API |
-
-### 🎯 domain/ — 领域 (业务逻辑)
-| 子包 | 关键脚本 | 用途 |
-|------|---------|------|
-| `kg/` | `kg.py` (**图谱统一入口**, 13+ 能力) | 知识图谱 |
-| `kg/search/` | search_index.py / context_pack.py / prefetch.py | 代码搜索 / 一键上下文 |
-| `kg/build/` | kg_build.py / kg_build_db.py / kg_incremental.py / build_style_index.py | 图谱构建 |
-| `kg/graph/` | kg_semantic.py / kg_link_db.py | 语义 / 数据库图谱链接 |
-| `kg/storage/` | kg_duckdb.py | DuckDB 存储层 |
-| `kg/server/` | kgd.py (常驻服务) / perf_bench.py | 语义加速服务 |
-| `task/` | task.py (**任务系统**) / team_sync.py / git_sync.py / zentao_sync.py / syncgate.py | 任务 + 同步 |
-| `requirement/` | req.py / archive_prd.py | 需求生命周期 |
-| `report/` | report.py / status.py / role.py / export.py / *_snapshot.py | 报告 / 状态 |
-| `design/` | fill_prototype.py / gen_design_doc.py | 原型填充 / 设计文档 |
-| `learning/` | learn.py | 学习飞轮 (埋点) |
-
-### 🔌 protocol/ — 协议
-| 子包 | 脚本 | 用途 |
-|------|------|------|
-| `mcp/` | mcp_launcher.py (**统一启动器**) / kg_mcp_server.py / mysql_mcp_server.py / zentao_mcp_server.py / lanhu_stdio_wrapper.py / mcp_doctor.py | 4 个自有 MCP server |
-| `transports/` | cli.py | CLI 传输适配 |
-
-### 🧩 capability/ — 能力编排
-| 脚本 | 用途 |
-|------|------|
-| `chain.py` / `memory_chain.py` | 链式能力编排 |
-| `adapters/` (cli.py / qw.py / mcp.py) | 能力适配器 (CLI/QoderWork/MCP) |
-
-### 🧪 validation/ — 验证
-| 子包 | 关键脚本 | 用途 |
-|------|---------|------|
-| `test/` | autotest.py / smoke_all_commands.py / benchmark.py / kg_test_runner.py | 自动测试 / 冒烟 / 基准 |
-| `metrics/` | eval_prd.py / usability_score.py | **PRD 质量门禁** (EVA, ≥80%) + **工作流可用性** (采纳+流程) |
-| `eval/` | 性能评测报告 | |
-
-### 🚀 deployment/ — 部署
-| 脚本 | 用途 |
-|------|------|
-| `setup.py` | **一键就绪** (npx init 调的主体) |
-| `init_doctor.py` | 环境体检 + 自愈 + 身份注册 |
-| `install_qoderwork.py` | QoderWork 技能/MCP 安装 |
-| `carriers.py` | **载体一致性** (check/check-paths/sync/all, 4 载体对齐) |
-| `repo_root.py` | 仓库根探测 (QoderWork 桌面端用) |
-| `setup_lanhu.py` / `platform_doctor.py` | 蓝湖配置 / 平台体检 |
-
-## 设计原则
-
-1. **分层即分类**: 物理目录 = 职责分层 (foundation/domain/protocol/...), 取代旧的命名前缀
-2. **单一入口**: `orchestration/wlkj.py` 是载体层唯一收敛点; `domain/kg/kg.py` 是图谱入口; `domain/task/task.py` 是任务入口
-3. **foundation/ 共享**: 通用逻辑抽到 foundation/, 领域无关 (路径/身份/IO/协议基类)
-4. **载体与引擎解耦**: 载体 (commands/skills) 只认 wlkj.py 一个路径, 引擎目录重组不波及载体
-5. **降级不崩**: 缺依赖/缺数据时优雅降级, 绝不 sys.exit 崩溃 (见 protocol/mcp/mcp_launcher.py)
+# .qoder/scripts/ — 引擎脚本目录 (分层架构)
+
+> 引擎代码, 由 `npx @hupan56/wlkj init/update` 生成, **不进团队 git** (引擎数据分离)。
+> 用户不直接碰这些文件 — 通过 `/命令` 和 `npx` 间接调用。
+
+## 🏗️ 分层架构 (7 层)
+
+子目录化 (v3.0) 后, 脚本按职责分层, 顶层**无散落 .py**, 只有 7 个分层目录:
+
+```
+scripts/
+├── orchestration/   编排层 — wlkj.py 统一入口 (载体收敛点)
+├── foundation/      基础层 — 共享库 (被所有层 import)
+├── domain/          领域层 — 业务逻辑 (kg/task/report/...)
+├── protocol/        协议层 — MCP server / 传输适配
+├── capability/      能力层 — 链式能力编排 / 冒烟测试
+├── validation/      验证层 — 测试 / 评测 / 基准
+└── deployment/      部署层 — 安装 / 体检 / 载体同步
+```
+
+## 🚪 统一入口: `orchestration/wlkj.py` (Facade)
+
+**所有 Qoder 载体 (commands/skills/rules) 的脚本调用都走这个入口**, 由 DISPATCH 表路由到
+分层路径。这样 scripts/ 重组目录时只改 DISPATCH 一处, 载体不受影响。
+
+```bash
+python .qoder/scripts/orchestration/wlkj.py <命令> [参数...]
+# 例: wlkj.py kg search 保险 | wlkj.py task list | wlkj.py doctor --fix
+```
+
+完整命令表见 `wlkj.py` 的 DISPATCH (kg/search/context/task/sync/req/eval/learn/status/report/test/doctor 等 36 条)。
+脚本内部互调 (Python 进程间) 直接用分层路径, 不绕 wlkj (避免 subprocess 嵌套)。
+
+## 各层职责 + 关键脚本
+
+### 🎼 orchestration/ — 编排
+| 脚本 | 用途 |
+|------|------|
+| `wlkj.py` | **统一调度入口**, DISPATCH 透明转发到各层脚本 |
+
+### 🧱 foundation/ — 基础 (共享库, 不含业务)
+| 模块 | 用途 |
+|------|------|
+| `bootstrap.py` | sys.path 自举 (子目录化后定位 scripts/ 根) |
+| `core/paths.py` | **路径管理** (PROJECT_ROOT / get_repo_root / get_developer) |
+| `identity/` | 身份 (identity.py / developer.py / roles.py 角色章节) |
+| `io/` | 原子 IO (atomicio.py) / 文件锁 (filelock.py) |
+| `protocol/mcp_base.py` | MCP server 基类 (@tool 装饰器 + 元类注册) |
+| `integrations/` | 术语扩展 (terms.py) / 禅道客户端 (zentao_client.py, 单一真源) |
+| `utils/eval_api.py` | 评测 API |
+
+### 🎯 domain/ — 领域 (业务逻辑)
+| 子包 | 关键脚本 | 用途 |
+|------|---------|------|
+| `kg/` | `kg.py` (**图谱统一入口**, 13+ 能力) | 知识图谱 |
+| `kg/search/` | search_index.py / context_pack.py / prefetch.py | 代码搜索 / 一键上下文 |
+| `kg/build/` | kg_build.py / kg_build_db.py / kg_incremental.py / build_style_index.py | 图谱构建 |
+| `kg/graph/` | kg_semantic.py / kg_link_db.py | 语义 / 数据库图谱链接 |
+| `kg/storage/` | kg_duckdb.py | DuckDB 存储层 |
+| `kg/server/` | kgd.py (常驻服务) / perf_bench.py | 语义加速服务 |
+| `task/` | task.py (**任务系统**) / team_sync.py / git_sync.py / zentao_sync.py / syncgate.py | 任务 + 同步 |
+| `requirement/` | req.py / archive_prd.py | 需求生命周期 |
+| `report/` | report.py / status.py / role.py / export.py / *_snapshot.py | 报告 / 状态 |
+| `design/` | fill_prototype.py / gen_design_doc.py | 原型填充 / 设计文档 |
+| `learning/` | learn.py | 学习飞轮 (埋点) |
+
+### 🔌 protocol/ — 协议
+| 子包 | 脚本 | 用途 |
+|------|------|------|
+| `mcp/` | mcp_launcher.py (**统一启动器**) / kg_mcp_server.py / mysql_mcp_server.py / zentao_mcp_server.py / lanhu_stdio_wrapper.py / mcp_doctor.py | 4 个自有 MCP server |
+| `transports/` | cli.py | CLI 传输适配 |
+
+### 🧩 capability/ — 能力编排
+| 脚本 | 用途 |
+|------|------|
+| `chain.py` / `memory_chain.py` | 链式能力编排 |
+| `adapters/` (cli.py / qw.py / mcp.py) | 能力适配器 (CLI/QoderWork/MCP) |
+
+### 🧪 validation/ — 验证
+| 子包 | 关键脚本 | 用途 |
+|------|---------|------|
+| `test/` | autotest.py / smoke_all_commands.py / benchmark.py / kg_test_runner.py | 自动测试 / 冒烟 / 基准 |
+| `metrics/` | eval_prd.py / usability_score.py | **PRD 质量门禁** (EVA, ≥80%) + **工作流可用性** (采纳+流程) |
+| `eval/` | 性能评测报告 | |
+
+### 🚀 deployment/ — 部署
+| 脚本 | 用途 |
+|------|------|
+| `setup.py` | **一键就绪** (npx init 调的主体) |
+| `init_doctor.py` | 环境体检 + 自愈 + 身份注册 |
+| `install_qoderwork.py` | QoderWork 技能/MCP 安装 |
+| `carriers.py` | **载体一致性** (check/check-paths/sync/all, 4 载体对齐) |
+| `repo_root.py` | 仓库根探测 (QoderWork 桌面端用) |
+| `setup_lanhu.py` / `platform_doctor.py` | 蓝湖配置 / 平台体检 |
+
+## 设计原则
+
+1. **分层即分类**: 物理目录 = 职责分层 (foundation/domain/protocol/...), 取代旧的命名前缀
+2. **单一入口**: `orchestration/wlkj.py` 是载体层唯一收敛点; `domain/kg/kg.py` 是图谱入口; `domain/task/task.py` 是任务入口
+3. **foundation/ 共享**: 通用逻辑抽到 foundation/, 领域无关 (路径/身份/IO/协议基类)
+4. **载体与引擎解耦**: 载体 (commands/skills) 只认 wlkj.py 一个路径, 引擎目录重组不波及载体
+5. **降级不崩**: 缺依赖/缺数据时优雅降级, 绝不 sys.exit 崩溃 (见 protocol/mcp/mcp_launcher.py)

package/templates/qoder/scripts/deployment/setup/init_doctor.py

@@ -597,7 +597,7 @@ def check_prd_templates():
             problem('PRD 模板缺失: ' + md, '需要 AI 从团队章程 docx 重新蒸馏')
 
     # Qoder 全系列载体: rules 在 IDE/Quest 生效, AGENTS.md 在 CLI 生效
-    # (Trellis 化: rules 是引擎的一部分, 由 wlkj init/update 生成, 不在团队 git 里)
+    # (引擎数据分离: rules 是引擎的一部分, 由 wlkj init/update 生成, 不在团队 git 里)
     rules_file = os.path.join(BASE, '.qoder', 'rules', 'wl-pipeline.md')
     if os.path.isfile(rules_file):
         say(OK, '.qoder/rules/wl-pipeline.md (Qoder IDE/Quest 规则载体, wlkj 生成)')

package/templates/qoder/scripts/deployment/setup/setup.py

@@ -498,7 +498,7 @@ def _setup_tracking(base):
     没这步, git pull 会报 "no tracking information for the current branch"。
     fetch 可能因网络/认证失败 — 失败只警告, 不阻塞 (remote 至少配上了)。
 
-    关键修复 (Trellis 化): 如果本地是空的 git init 历史 (没有 commit) 或与远程
+    关键修复 (引擎数据分离): 如果本地是空的 git init 历史 (没有 commit) 或与远程
     不相关 (unrelated histories), 就直接 git reset --hard origin/<branch> 采用远程历史。
     原理: 引擎代码现在由 npm 包生成 (不在 git 里), 团队数据 (config/data/workspace) 在
     远程 → 本地空历史直接采用远程是唯一正确姿势, 彻底消除 "refusing to merge unrelated

package/templates/qoder/scripts/domain/report/add_session.py

@@ -13,7 +13,7 @@ Usage:
 日志文件: .qoder/workspace/<developer>/journal-N.md
 索引文件: .qoder/workspace/<developer>/index.md
 
-参考: Trellis 的 add_session.py 设计
+参考:  add_session.py 设计
 """
 
 from __future__ import annotations
@@ -28,7 +28,7 @@ for _ in range(10):
         break
 if _cp not in _s.path: _s.path.insert(0, _cp)
 from bootstrap import setup; setup()
-from foundation.core.paths import get_repo_root
+from foundation.core.paths import get_repo_root
 
 import argparse
 import re

package/templates/qoder/scripts/domain/task/task.py

@@ -15,7 +15,7 @@ QODER Pipeline - 任务生命周期管理
 - add-subtask / remove-subtask: 父子任务关联
 - set-due / block / unblock / gantt: 排期与依赖
 
-参考: Trellis 的 task.py 设计
+参考:  task.py 设计
 
 Usage:
     python task.py create "<title>" [--slug <name>] [--assignee <dev>] [--priority P0|P1|P2|P3]