@ranger1/dx 0.1.77 → 0.1.78

package/README.md

@@ -130,60 +130,50 @@ target（端）不写死，由 `env-policy.jsonc.targets` 定义；`commands.jso
 
 ## PR Review Loop（自动评审-修复闭环）
 
-dx 内置一套 PR 评审自动化工作流：并行评审 → 聚合结论 → 生成修复清单 → 自动修复 → 再评审，最多循环 3 轮，用于让 PR 更快收敛。
+仓库内提供了基于 Codex Skill 的 PR 评审自动化工作流：并行评审 -> 聚合结论 -> 生成修复清单 -> 自动修复 -> 再评审，最多循环 3 轮，用于让 PR 更快收敛。
 
 ### 什么时候用
 
 - PR 变更较大、想要更系统地覆盖安全/性能/可维护性问题
-- 希望在 CI 通过的前提下，把评审建议落成可执行的修复清单（fixFile）
-- 希望避免同一个问题在不同轮次被反复提出（通过 Decision Log 机制）
+- 希望在 CI 通过前提下，把评审建议落成可执行修复清单（fixFile）
+- 希望避免同一个问题在不同轮次被反复提出（Decision Log）
 
 ### 如何运行
 
-在创建 PR 后执行：
+在 Codex 会话中触发该技能：
 
-```
-/pr-review-loop --pr <PR_NUMBER>
+```text
+使用 $pr-review-loop 对 PR #<PR_NUMBER> 执行审核闭环
 ```
 
-更多命令说明见：`@opencode/commands/pr-review-loop.md`。
+技能入口与说明见：
 
-提示：在创建 PR 的流程中也会给出快捷入口，见：`@opencode/commands/git-commit-and-pr.md`。
+- `codex/skills/pr-review-loop/SKILL.md`
+- `codex/skills/pr-review-loop/references/agents/*.md`
 
 ### 工作流概览
 
-- 预检（`pr-precheck`）：先做编译/预检 gate，不通过则进入修复再预检（最多 2 次）
-- 获取上下文（`pr-context`）：生成本轮上下文缓存 `contextFile`
-- 并行评审（4 个 reviewer）：`codex-reviewer` / `claude-reviewer` / `gemini-reviewer` / `gh-thread-reviewer`
-- 聚合（`pr-review-aggregate`）：合并各 reviewer 结果、去重、输出 `fixFile`，并发布本轮 Review Summary
-- 修复（`pr-fix`）：按 `fixFile` 逐条修复（每条 findingId 单独 commit + push），输出 `fixReportFile`
-- 发布修复报告（`pr-review-aggregate` 模式 B）：发布 Fix Report
-
-备注：每轮发布到 PR 的评论都会带 `<!-- pr-review-loop-marker -->`，用于幂等与避免反复采集机器人评论。
+- 预检（`pr-precheck`）：先做编译/基础 gate，不通过则终止流程
+- 获取上下文（`pr-context`）：生成本轮上下文缓存 `contextFile` 与 `runId`
+- 并行评审（reviewers）：按 `./reviewer/*-reviewer.md` 并行审查并产出 reviewFile
+- 聚合（`pr-review-aggregate` 模式 A）：合并评审结果、去重、发布 Review Summary、生成 `fixFile`
+- 修复（`fixer`）：按 `fixFile` 执行修复并产出 `fixReportFile`
+- 发布修复报告（`pr-review-aggregate` 模式 B）
 
-### 缓存文件（项目内 ./\.cache/）
+### 缓存文件（项目内 `./.cache/`）
 
-该流程的中间产物都写入项目内 `./.cache/`，并在 agent/命令之间传递 repo 相对路径：
+该流程中间产物写入 `./.cache/`，并在各阶段传递相对路径：
 
 - `./.cache/pr-context-pr<PR>-r<ROUND>-<RUN_ID>.md`（contextFile）
-- `./.cache/review-<REVIEWER>-pr<PR>-r<ROUND>-<RUN_ID>.md`（reviewFile）
+- `./.cache/review-<ROLE_CODE>-pr<PR>-r<ROUND>-<RUN_ID>.md`（reviewFile）
 - `./.cache/fix-pr<PR>-r<ROUND>-<RUN_ID>.md`（fixFile）
 - `./.cache/fix-report-pr<PR>-r<ROUND>-<RUN_ID>.md`（fixReportFile）
 
-### Decision Log（跨轮次决策日志，用于收敛）
-
-为了解决“第一轮拒绝的问题在后续轮次反复出现”的问题，PR Review Loop 使用 Decision Log 持久化每轮的决策：
+### Decision Log（跨轮次决策日志）
 
 - 文件：`./.cache/decision-log-pr<PR_NUMBER>.md`
-- 生成者：`pr-fix` 在修复完成后创建/追加（append-only，禁止覆盖历史）
-- 内容：记录每轮的 Fixed/Rejected，以及 `essence`（问题本质的一句话描述，用于后续智能匹配）
-
-在后续轮次：
-
-- reviewers 若收到 `decisionLogFile`，必须读取并遵守：已修复不再提、已拒绝不再提（除非严重性升级）
-- aggregate 在模式 A 中基于 LLM 对比 `essence` 做“问题本质相同”的判断，并生成 `escalation_groups` 入参给脚本
-
-升级质疑规则：只有当新 finding 的优先级比历史 rejected 高 ≥2 级（例如 P3→P1、P2→P0）时，才允许重新打开。
+- 作用：记录每轮 Fixed/Rejected 结论，后续轮次用于过滤重复问题
+- 规则：默认 append-only，保留历史决策用于收敛
 
 ## 命令
 
@@ -192,6 +182,7 @@ dx 的命令由 `dx/config/commands.json` 驱动，并且内置了一些 interna
 - `internal: sdk-build`：SDK 生成/构建
 - `internal: backend-package`：后端打包
 - `internal: start-dev`：开发环境一键启动
+- `internal: pm2-stack`：PM2 交互式服务栈（支持端口清理/缓存清理配置）
 
 常用示例：
 
@@ -208,6 +199,76 @@ dx lint
 dx test e2e backend
 ```
 
+### `dx start stack` 配置详解（PM2 交互式服务栈）
+
+从 `0.1.78` 起，`dx start stack` 推荐完全由 `dx/config/commands.json` 配置驱动，不再依赖硬编码服务列表。
+
+最小可用配置：
+
+```json
+{
+  "start": {
+    "stack": {
+      "internal": "pm2-stack",
+      "interactive": true,
+      "description": "PM2 交互式服务栈",
+      "stack": {
+        "ecosystemConfig": "ecosystem.config.cjs",
+        "services": ["backend", "front", "admin"],
+        "preflight": {
+          "killPorts": [3000, 3001, 3500],
+          "pm2Reset": true
+        }
+      }
+    }
+  }
+}
+```
+
+完整字段说明：
+
+- `start.stack.internal`
+  - 固定为 `pm2-stack`，表示启用内置 PM2 交互式 runner。
+- `start.stack.interactive`
+  - 建议设为 `true`，用于标记这是交互式命令（便于团队识别）。
+- `start.stack.stack.ecosystemConfig`
+  - PM2 配置文件路径；支持相对路径（相对项目根目录）或绝对路径。
+  - 默认值：`ecosystem.config.cjs`。
+- `start.stack.stack.pm2Bin`
+  - PM2 命令前缀，默认 `pnpm pm2`。如果团队使用全局 pm2，可改为 `pm2`。
+- `start.stack.stack.services`
+  - 交互命令（`r/l/s`）可操作的服务名单。
+  - 示例：`["backend", "front", "admin"]`。
+- `start.stack.stack.preflight.killPorts`
+  - 启动前自动清理占用端口列表。
+  - 这就是“某些端口被占用时自动处理”的核心配置。
+- `start.stack.stack.preflight.forcePortCleanup`
+  - 是否强制清理端口占用，默认 `true`。
+- `start.stack.stack.preflight.pm2Reset`
+  - 启动前是否执行 PM2 状态重置（`delete all` / `kill` / 状态文件清理），默认 `true`。
+- `start.stack.stack.preflight.cleanPaths`
+  - 启动前需要删除的缓存路径列表（相对项目根目录）。
+  - 适合清理 `.next`、`dist`、`.vite` 等缓存，避免脏状态。
+- `start.stack.stack.preflight.cleanTsBuildInfo`
+  - 是否清理 `*.tsbuildinfo`，默认 `true`。
+- `start.stack.stack.preflight.cleanTsBuildInfoDirs`
+  - 扫描 `*.tsbuildinfo` 的目录列表。
+
+交互命令保持不变：
+
+- `r <service>` 重启服务
+- `l <service>` 查看日志
+- `s <service>` 停止服务
+- `list` 查看状态
+- `monit` 打开 PM2 监控
+- `q` 停止所有服务并退出
+
+推荐实践：
+
+- 将 `services` 与 `ecosystem.config.cjs` 里的 app 名保持一致，避免交互命令找不到服务。
+- `killPorts` 只配置开发态常驻端口，避免误杀不相关进程。
+- 如果项目不是 `apps/front` / `apps/admin-front` 结构，请按实际目录改 `cleanPaths` 与 `cleanTsBuildInfoDirs`。
+
 ## deploy 行为说明
 
 从 `0.1.9` 起，`dx deploy <target>` 不再在 dx 内部硬编码执行任何 `nx build`/`sdk build` 等前置步骤。

package/bin/dx.js

@@ -117,13 +117,13 @@ async function main() {
 
   if (isInitialInvocation(rawArgs)) {
     const packageRoot = resolve(dirname(fileURLToPath(import.meta.url)), '..')
-    const [{ logger }, { runOpenCodeInitial }] = await Promise.all([
+    const [{ logger }, { runCodexInitial }] = await Promise.all([
       import('../lib/logger.js'),
-      import('../lib/opencode-initial.js'),
+      import('../lib/codex-initial.js'),
     ])
 
     try {
-      await runOpenCodeInitial({ packageRoot })
+      await runCodexInitial({ packageRoot })
       return
     } catch (error) {
       logger.error('initial 执行失败')