@surething/cockpit 1.0.220 → 1.0.221

package/.next-prod/trace-build

@@ -1 +1 @@
-[{"name":"run-webpack","duration":20626180,"timestamp":142274579,"id":14,"parentId":1,"tags":{},"startTime":1781184328170,"traceId":"37077a326bebe80a"},{"name":"run-typescript","duration":17041007,"timestamp":162911095,"id":1528,"parentId":1,"tags":{},"startTime":1781184348807,"traceId":"37077a326bebe80a"},{"name":"static-check","duration":1064279,"timestamp":179986845,"id":1531,"parentId":1,"tags":{},"startTime":1781184365883,"traceId":"37077a326bebe80a"},{"name":"static-generation","duration":5542398,"timestamp":181428395,"id":1789,"parentId":1,"tags":{},"startTime":1781184367324,"traceId":"37077a326bebe80a"},{"name":"collect-build-traces","duration":18686972,"timestamp":181051779,"id":1786,"parentId":1,"tags":{},"startTime":1781184366947,"traceId":"37077a326bebe80a"},{"name":"telemetry-flush","duration":53,"timestamp":199742438,"id":1798,"parentId":1,"tags":{},"startTime":1781184385638,"traceId":"37077a326bebe80a"},{"name":"next-build","duration":57597755,"timestamp":142144748,"id":1,"tags":{"buildMode":"default","version":"16.2.6","bundler":"webpack","has-custom-webpack-config":"true","use-build-worker":"false"},"startTime":1781184328040,"traceId":"37077a326bebe80a"}]
+[{"name":"run-webpack","duration":20779307,"timestamp":210722173,"id":14,"parentId":1,"tags":{},"startTime":1781283743366,"traceId":"de7a9f0cc4e0ee72"},{"name":"run-typescript","duration":16955561,"timestamp":231511781,"id":1528,"parentId":1,"tags":{},"startTime":1781283764155,"traceId":"de7a9f0cc4e0ee72"},{"name":"static-check","duration":1121392,"timestamp":248512898,"id":1531,"parentId":1,"tags":{},"startTime":1781283781157,"traceId":"de7a9f0cc4e0ee72"},{"name":"static-generation","duration":6044407,"timestamp":249734514,"id":1789,"parentId":1,"tags":{},"startTime":1781283782378,"traceId":"de7a9f0cc4e0ee72"},{"name":"collect-build-traces","duration":19091678,"timestamp":249634994,"id":1786,"parentId":1,"tags":{},"startTime":1781283782279,"traceId":"de7a9f0cc4e0ee72"},{"name":"telemetry-flush","duration":56,"timestamp":268730646,"id":1798,"parentId":1,"tags":{},"startTime":1781283801374,"traceId":"de7a9f0cc4e0ee72"},{"name":"next-build","duration":58175017,"timestamp":210555698,"id":1,"tags":{"buildMode":"default","version":"16.2.6","bundler":"webpack","has-custom-webpack-config":"true","use-build-worker":"false"},"startTime":1781283743199,"traceId":"de7a9f0cc4e0ee72"}]

package/README.md

@@ -49,7 +49,7 @@ Cockpit is the instrument panel. It does **not** replace Claude Code; it stands
 | Agent can't reach your browser / DB | **Smart Bubbles**: Chrome, PostgreSQL, MySQL, Redis — drivable by the agent |
 | Reading an unfamiliar repo means a 90-min file-tree scavenger hunt | **Code Map** chip view — caller / callee pins, click to walk the call graph |
 | Reviewing AI output is friction | **LAN-shared review pages**, line-level comments, send any comment back as AI context |
-| Same "do X but don't change code" prompt every day | **Slash modes** `/qa /fx /ex /go /cg /cc` + custom `SKILL.md` via the Skills sidebar |
+| Same "do X but don't change code" prompt every day | **Slash modes** `/qa /fx /ex /go /cg /cc /cr` + custom `SKILL.md` via the Skills sidebar |
 | No automation hooks | One-time / interval / cron-based **scheduled tasks** |
 | "Cloud relay" trust concerns | **Fully local**. No telemetry. Keys (Codex / DeepSeek / Kimi) stay in `~/.cockpit/settings.json` on your laptop. |
 
@@ -107,6 +107,7 @@ Cockpit is the instrument panel. It does **not** replace Claude Code; it stands
 - `/go` — **Land**: take a converged plan, slice into MVP stages, write + self-verify per stage, recap at end
 - `/cg` — **CodeGraph** project exploration: 10 HTTP endpoints for symbol / callers / impact / co-edit / risk / affected queries (precise where grep is fuzzy)
 - `/cc` — **Cockpit CLI**: drive the cockpit CLI surface — codegraph subcommands, terminal observation, browser automation
+- `/cr` — **Code review**: full PR review — static triangulation (intent / input domain / surroundings) + dynamic modelling (state diagram + timeline → 6 risk classes), findings ranked by impact × probability
 - **Custom**: drop any `SKILL.md` and add it via the Skills sidebar — it auto-appears in the slash autocomplete menu (see [Skills](#skills--extensibility))
 
 ### Scheduled tasks — Cron for AI

package/README.zh.md

@@ -49,7 +49,7 @@ Cockpit 就是那个仪表盘。它**不替代** Claude Code，而是站在官
 | Agent 够不到浏览器 / 数据库 | **智能气泡**：Chrome、PostgreSQL、MySQL、Redis —— Agent 可驱动 |
 | 读陌生仓库就是 90 分钟"找地鼠" | **代码地图（Code Map）** chip 视图 —— caller / callee pin 一点即跳 |
 | AI 输出审阅低效 | **局域网共享评审页**、行级评论、任意评论可回喂给 AI |
-| 每天写一遍"做 X 但不要动代码" | **斜杠模式** `/qa /fx /ex /go /cg /cc` + 通过 Skills 侧边栏自定义 `SKILL.md` |
+| 每天写一遍"做 X 但不要动代码" | **斜杠模式** `/qa /fx /ex /go /cg /cc /cr` + 通过 Skills 侧边栏自定义 `SKILL.md` |
 | 没有自动化触发器 | 一次性 / 间隔 / **Cron** **定时任务** |
 | 担心"云端中转" | **完全本地**。无遥测，Codex / DeepSeek / Kimi 的 Key 仅存在本机 `~/.cockpit/settings.json` |
 
@@ -107,6 +107,7 @@ Cockpit 就是那个仪表盘。它**不替代** Claude Code，而是站在官
 - `/go` —— **落地**：把收敛后的方案切成 MVP 阶段，每阶段自运行验证，最后端到端回看
 - `/cg` —— **CodeGraph 项目探索**：10 个 HTTP 接口按符号 / 调用关系 / 影响范围 / 协同编辑 / 风险 / 受影响测试精确查询（比 grep 精准）
 - `/cc` —— **Cockpit CLI**：驾驭 cockpit 命令行 —— codegraph 子命令、terminal 观察、browser 自动化
+- `/cr` —— **代码审查**：完整 PR 审查 —— 静态三角校验（意图 / 输入域 / 周遭）+ 动态推演（状态图 + 时间线 → 6 类风险），按 影响 × 概率 排序输出 findings
 - **自定义**：任意 `SKILL.md` 通过 Skills 侧边栏添加 —— 自动出现在斜杠补全菜单（见 [Skills](#skills--可扩展性)）
 
 ### 定时任务 —— 给 AI 的 Cron

package/dist/wsServer.mjs

@@ -951,6 +951,16 @@ var dispatchMessage = (msg, projectCwd, registry, send) => Effect_exports.sync((
       USER: process.env.USER,
       SHELL: process.env.SHELL,
       TERM: "xterm-256color",
+      // UTF-8 locale so the pty renders multi-byte text (CJK, emoji) correctly.
+      // ptyEnv is rebuilt from scratch (not inherited from process.env), and a
+      // macOS `--login` shell does NOT restore LANG (Terminal.app/iTerm inject it,
+      // not the rc files) — so without this, vim/less open UTF-8 files in the
+      // C/POSIX locale and mojibake every non-ASCII char. Pass the real locale
+      // through when present, else fall back to a UTF-8 default; LC_ALL/LC_CTYPE
+      // stay undefined (and are skipped below) unless the server actually has them.
+      LANG: process.env.LANG ?? "en_US.UTF-8",
+      LC_ALL: process.env.LC_ALL,
+      LC_CTYPE: process.env.LC_CTYPE,
       FORCE_COLOR: "1",
       CLICOLOR: "1",
       CLICOLOR_FORCE: "1",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@surething/cockpit",
-  "version": "1.0.220",
+  "version": "1.0.221",
   "description": "Claude Code GUI for parallel AI coding — drive Claude (default), Codex, DeepSeek, Kimi, or local Ollama in tabs. Multi-project sessions, terminal, browser & DB bubbles, code review, slash modes. Local-first, MIT.",
   "author": "Robert",
   "license": "MIT",

package/.next-prod/server/chunks/9877.js

@@ -1,511 +0,0 @@
-"use strict";exports.id=9877,exports.ids=[9877],exports.modules={29877:(a,b,c)=>{c.d(b,{M:()=>e});let d={qa:{zh:`进入需求澄清讨论模式
-尝试理解用户的需求并给出你对需求的理解，有不明确的点需要向我确认，避免理解不一致而导致无效的代码修改
-遵循 KISS 原则
-输出理解，不改代码`,en:`Enter requirement clarification mode.
-Understand the user's needs and state your understanding.
-Ask for clarification on ambiguous points to avoid unnecessary code changes.
-Follow the KISS principle.
-Output your understanding only; do not modify code.`},fx:{zh:"进入bug证据链分析模式，只分析不修改代码，给出详细推理过程",en:`Enter bug evidence chain analysis mode.
-Analyze only; do not modify code.
-Provide a detailed reasoning process.`},ex:{zh:`---
-name: ex
-description: "结构化讨论 skill：用'问题研究 + 假设-验证循环 + 发散-收敛-发散-迭代验证-总结 + What/Why/How + 对比矩阵'方法论分析复杂问题。用户通过 \`/ex\` 显式触发。仅分析不改代码。"
----
-
-# ex — 结构化讨论 skill
-
-用一套固定的思考骨架分析复杂问题。**只输出分析，不修改代码。**
-
-## 入口：复杂度判断
-
-收到问题后，**先判断复杂度**：
-
-- **简单问题** → 直接简答，**不套方法论**（KISS）
-- **复杂问题** → 走完整方法论骨架（下方 6 步）
-
-判断标准（任一即视为复杂）：
-- 涉及多个候选方案需要权衡
-- 存在多个可能假设需要验证
-- 跨多个模块/系统/层次
-- 用户明确要求深入讨论
-
-## 方法论骨架（仅复杂问题）
-
-按顺序一次性走完，**不中途停下问用户**：
-
-\`\`\`
-1. 问题研究    用 What / Why / How 三个切面把问题本身研究清楚
-2. 发散        穷举可能的假设、方案、视角
-3. 收敛        筛出 Top 1-3
-4. 再发散      对优选做深入展开（细节、风险、边界条件）
-5. 迭代验证    用代码检索 / Web 搜索 / Bash 实验 验证关键假设
-6. 总结        给结论；若多方案/多假设并排，用对比矩阵
-\`\`\`
-
-### What / Why / How 切面（贯穿全流程）
-
-- **What**：问题/方案是什么，边界在哪
-- **Why**：为什么会有这个问题、为什么选这个方案
-- **How**：怎么实现、怎么落地、怎么验证
-
-## 执行规则
-
-### 一次性走完，不打断用户
-
-- 全程**不调用 AskUserQuestion**
-- 信息不足时 → 明确标注 **"⚠️ 待补充：xxx"**，由用户后续追问补充
-- 不要因为信息不全就中断流程，能推到哪推到哪
-
-### 验证手段
-
-允许的验证方式：
-
-| 手段 | 工具 | 使用场景 |
-|---|---|---|
-| 代码检索 | Grep / Read / Glob | 在仓库中找证据验证假设 |
-| Web 搜索 | WebSearch / WebFetch | 查官方文档、外部资料 |
-| Bash 实验 | Bash | 跑小命令、测试脚本、curl |
-
-**禁止**：通过 AskUserQuestion 向用户提问验证。
-
-## 输出规则
-
-- **不强制固定输出结构**，按问题特点灵活组织
-- **对比矩阵不是必选项**，仅在"多方案/多假设需要并排比较"时才出
-- 简单问题就简短回答，不要为了套框架而套框架
-
-## 不做什么
-
-- ❌ 不修改代码（这是讨论 skill，不是实施 skill）
-- ❌ 不中途问用户（一次走完）
-- ❌ 不强制对每个问题都输出对比矩阵
-- ❌ 不和 \`/qa\`、\`/fx\` 抢戏 —— 三者并列，由用户显式选择触发
-`,en:`---
-name: ex
-description: "Structured discussion skill: analyze complex problems with the methodology of 'problem study + hypothesis-verify loop + diverge-converge-diverge-iterate-verify-summarize + What/Why/How + comparison matrix'. Explicitly triggered by the user via \`/ex\`. Analysis only; do not modify code."
----
-
-# ex — structured discussion skill
-
-Analyze complex problems with a fixed thinking skeleton. **Output analysis only; do not modify code.**
-
-## Entry: complexity check
-
-When the question arrives, **first judge complexity**:
-
-- **Simple problem** → answer directly, **do not apply the methodology** (KISS)
-- **Complex problem** → run the full 6-step skeleton below
-
-Treat as complex if any of these holds:
-- Multiple candidate solutions need trade-off
-- Multiple hypotheses need verification
-- Spans multiple modules / systems / layers
-- The user explicitly asks for deep discussion
-
-## Methodology skeleton (complex problems only)
-
-Run in order, **in one pass, without stopping to ask the user**:
-
-\`\`\`
-1. Problem study   Clarify the problem itself through What / Why / How
-2. Diverge         Enumerate candidate hypotheses, solutions, perspectives
-3. Converge        Pick the top 1-3
-4. Diverge again   Deep-dive into the chosen ones (details, risks, edge cases)
-5. Iterate-verify  Verify key hypotheses via code search / web search / bash experiments
-6. Summarize       Conclude; use a comparison matrix when multiple options sit side by side
-\`\`\`
-
-### What / Why / How facets (cross-cutting)
-
-- **What**: what is the problem / solution, what is the boundary
-- **Why**: why does this problem exist, why pick this solution
-- **How**: how to implement / land / verify it
-
-## Execution rules
-
-### Run once, never interrupt the user
-
-- **Never call AskUserQuestion**
-- When information is missing → explicitly mark **"⚠️ Pending: xxx"** and let the user follow up later
-- Do not stop just because info is incomplete; push as far as the evidence allows
-
-### Verification means
-
-Allowed verification tools:
-
-| Means | Tools | Use case |
-|---|---|---|
-| Code search | Grep / Read / Glob | Find in-repo evidence for hypotheses |
-| Web search | WebSearch / WebFetch | Look up official docs and external material |
-| Bash experiments | Bash | Run small commands, test scripts, curl |
-
-**Forbidden**: verifying by asking the user via AskUserQuestion.
-
-## Output rules
-
-- **No mandatory output template** — organize by what the problem needs
-- **Comparison matrix is optional** — use it only when multiple options / hypotheses must sit side by side
-- Simple questions get short answers; do not over-frame for the sake of framing
-
-## What this skill does NOT do
-
-- ❌ Do not modify code (this is a discussion skill, not an implementation skill)
-- ❌ Do not interrupt the user mid-flow (one-shot)
-- ❌ Do not force a comparison matrix on every question
-- ❌ Do not compete with \`/qa\` or \`/fx\` — the three are siblings, triggered explicitly by the user`},go:{zh:`---
-name: go
-description: "基于已有调研结论，按最小可交付可验证拆分原则连续推进落地。每阶段写代码 → 自运行验证 → 输出【交付总结 + 验证报告】 → 自动进入下一阶段，全部完成后再做端到端回看。用于：调研已收敛、用户说『开始落地 / 开始实施 / go』，希望自动连续推进不被中途打断。"
-argument-hint: "[调研结论路径 / 简述 / 留空表示沿用当前会话上文]"
----
-
-# 落地模式 (Landing Mode)
-
-把已经收敛的调研结论，按 MVP 自动连续落地，每阶段内闭环验证，全部完成后统一回看。
-
-## 触发条件（必须全部满足）
-
-1. 调研/方案讨论阶段已结束，结论已收敛
-2. 用户明确要"开始落地 / 实施 / go"
-3. 用户希望自动连续推进，不需要每阶段停下来确认
-
-任一不满足，先回 \`qa\` 模式澄清。
-
-## 前置检查（开始前必做）
-
-确认以下信息**已掌握**，缺一项就停下来问，不要猜：
-
-| 项 | 来源 |
-|---|---|
-| 调研结论 | 会话上文 / 用户指定的文档路径 / 直接粘贴 |
-| 落地范围 | 做什么、不做什么 |
-| 验收标准 | 怎么算"端到端跑通" |
-| 工作目录与技术栈 | 项目根路径、语言、框架 |
-
-## 执行循环
-
-\`\`\`
-while 还有未完成的 MVP 子任务:
-  1. 选定下一个最小闭环子任务
-     - 可交付：能独立存在的产物
-     - 可验证：有明确的运行/检查方式
-  2. 写代码（最小变更，KISS）
-  3. 自运行验证：跑命令、调接口、看输出，不依赖用户点头
-  4. 输出【阶段 N 交付总结 + 验证报告】
-  5. 不停顿，进入下一阶段
-end while
-
-最后输出【整体回看：端到端交互验证 + 总交付清单】
-\`\`\`
-
-## 每阶段输出格式
-
-\`\`\`markdown
-### 阶段 N：<子任务名>
-
-**交付总结**
-- 目标：<这阶段要达成什么>
-- 变更：
-  - <文件1>: <做了什么>
-  - <文件2>: <做了什么>
-- 状态：✅ 完成 / ⚠️ 部分完成 / ❌ 阻塞
-
-**验证报告**
-- 验证方式：<跑了什么命令 / 调了什么接口>
-- 验证结果：<输出摘要 / 关键指标>
-- 遗留问题：<无 / 列表>
-\`\`\`
-
-## 最终回看格式
-
-\`\`\`markdown
-## 整体回看
-
-### 端到端交互验证
-- 场景：<完整用户流程描述>
-- 步骤：<1 → 2 → 3>
-- 结果：<跑通 / 失败点>
-
-### 总交付清单
-| 阶段 | 子任务 | 关键产物 | 状态 |
-
-### 已知遗留
-<无 / 列出未解决项及优先级建议>
-\`\`\`
-
-## 何时停下来问（仅限三种情况）
-
-1. **阻塞性歧义**：缺关键信息无法推进（未知 API 契约、不明业务规则）
-2. **破坏性操作**：删数据、强推远端、改 git 历史等不可逆动作
-3. **方案分叉**：发现调研结论没覆盖的关键选型决策
-
-**不要因为以下原因停**：
-- "这步看起来重要要不要确认" → 不要，按 KISS 默认做
-- "可能想这样可能想那样" → 选最简实现继续
-- "完成一阶段汇报等批复" → 不要，直接进下一阶段
-
-## 关键原则
-
-- **KISS 优于完备**：能跑通的最小实现 > 大而全
-- **运行优于阅读**：实际跑起来验证 > 静态看代码
-- **连续优于停顿**：自动推进 > 频繁问询
-- **回看优于中断**：最后统一 review > 中途打断
-`,en:`---
-name: go
-description: "Based on prior research conclusions, drive landing forward in minimum-deliverable-verifiable slices. Per stage: write code → self-verify → emit [delivery summary + verification report] → auto advance to the next stage; after all stages, do one end-to-end recap. Use when: research is converged, the user says 'start landing / start implementing / go', and wants continuous progress without mid-stage interruption."
-argument-hint: "[research conclusion path / brief / leave empty to reuse current session context]"
----
-
-# Landing Mode (落地模式)
-
-Take the already-converged research conclusion and land it as MVP slices continuously and automatically; each stage closes its own verification loop, with one end-to-end recap at the very end.
-
-## Trigger conditions (all must hold)
-
-1. The research / discussion phase has ended and the conclusion has converged
-2. The user explicitly says "start landing / implement / go"
-3. The user wants continuous, automatic progress without per-stage confirmation
-
-If any condition fails, fall back to \`qa\` mode for clarification first.
-
-## Pre-flight check (mandatory before starting)
-
-Confirm the following are **in hand**; if any is missing, stop and ask — do not guess:
-
-| Item | Source |
-|---|---|
-| Research conclusion | Session context / a path the user gives / pasted text |
-| Landing scope | What's in, what's out |
-| Acceptance criteria | What counts as "end-to-end runs" |
-| Working directory and stack | Project root path, language, framework |
-
-## Execution loop
-
-\`\`\`
-while there are unfinished MVP sub-tasks:
-  1. Pick the next minimum closed-loop sub-task
-     - Deliverable: a standalone artifact
-     - Verifiable: a clear way to run / check it
-  2. Write code (minimum change, KISS)
-  3. Self-verify: run commands, hit endpoints, read output — do not wait for the user's nod
-  4. Emit [Stage N delivery summary + verification report]
-  5. No pause; proceed to the next stage
-end while
-
-Finally emit [Overall recap: end-to-end interaction verification + total delivery list]
-\`\`\`
-
-## Per-stage output format
-
-\`\`\`markdown
-### Stage N: <sub-task name>
-
-**Delivery summary**
-- Goal: <what this stage achieves>
-- Changes:
-  - <file1>: <what was done>
-  - <file2>: <what was done>
-- Status: ✅ done / ⚠️ partial / ❌ blocked
-
-**Verification report**
-- How verified: <commands run / endpoints called>
-- Result: <output summary / key metrics>
-- Residual issues: <none / list>
-\`\`\`
-
-## Final recap format
-
-\`\`\`markdown
-## Overall recap
-
-### End-to-end interaction verification
-- Scenario: <full user-flow description>
-- Steps: <1 → 2 → 3>
-- Result: <passes / failure points>
-
-### Total delivery list
-| Stage | Sub-task | Key artifact | Status |
-
-### Known residuals
-<none / list with suggested priority>
-\`\`\`
-
-## When to stop and ask (only three cases)
-
-1. **Blocking ambiguity**: a key piece of info is missing and progress is impossible (unknown API contract, unclear business rule)
-2. **Destructive operation**: deleting data, force-pushing, rewriting git history, or other irreversible actions
-3. **Branching decision**: a key design choice the research did not cover
-
-**Do NOT stop for**:
-- "This step looks important, should I confirm?" → No, do the KISS default
-- "Maybe this way, maybe that way" → Pick the simplest implementation and continue
-- "Done with a stage, awaiting sign-off" → No, go straight to the next stage
-
-## Key principles
-
-- **KISS over completeness**: a minimal runnable implementation > grand-and-complete
-- **Running over reading**: actually run it to verify > stare at code
-- **Continuous over pausing**: auto-advance > frequent asking
-- **Recap over interruption**: one final review > mid-flow breaks
-`},cg:{zh:`进入项目图谱探索模式（CodeGraph）
-
-CodeGraph = 项目预建的符号 + 调用图索引 + git 协同视图。6 个接口各回答一类问题：
-
-| 问题 | 接口 |
-|---|---|
-| X 在哪定义 / 有哪些同名符号？ | search?q=X |
-| 谁调用 X？ | callers?qname=X |
-| X 调用了什么？ | callees?qname=X |
-| 改 X 会影响哪些符号？ | impact?qname=X&depth=2 |
-| 文件 F 有哪些符号？ | file?path=F |
-| 文件 F 常和哪些文件一起改？（约定耦合 / 双写注册表） | coedit?filePath=F |
-
-所有响应都是坐标 / 文件路径，不含源码——比 grep 字面匹配精确，比 Read 全文扫描省 token。
-
-## 6 个图谱接口（{{BASE_URL}}）
-
-# search: 按名字找符号 → file / qname / kind / startLine / endLine / params
-# q 自动做命名风格归一：user_profile / userProfile / user-profile / USER_PROFILE 等价
-# 加 includeLiterals=true 时，还搜源码里的字符串字面量（tool 名 / 事件名 / 配置 key / 路由路径
-# 等"长得像名字但不是 identifier"的字符串），返回字段多一个 literals[]，每项含 value/filePath/line/enclosingSymbol
-curl -fsS "{{BASE_URL}}/api/projectGraph/search?cwd=$PWD&q=<NAME>"
-curl -fsS "{{BASE_URL}}/api/projectGraph/search?cwd=$PWD&q=<NAME>&includeLiterals=true"
-
-# callers / callees: 1-hop 调用关系
-curl -fsS "{{BASE_URL}}/api/projectGraph/callers?cwd=$PWD&qname=<QNAME>"
-curl -fsS "{{BASE_URL}}/api/projectGraph/callees?cwd=$PWD&qname=<QNAME>"
-
-# impact: 传递性 callers BFS（depth 1-5，默认 2）
-curl -fsS "{{BASE_URL}}/api/projectGraph/impact?cwd=$PWD&qname=<QNAME>&depth=2"
-
-# file: 文件符号树（无源码）
-curl -fsS "{{BASE_URL}}/api/projectGraph/file?cwd=$PWD&path=<REL_PATH>"
-
-# coedit: 与目标文件协同编辑的文件 = git log 历史 + 当前 working tree 同时被改的文件
-#   抓 call-graph 抓不到的"约定耦合"(平行注册表 / 双写 / 同名 .md 配置等)
-curl -fsS "{{BASE_URL}}/api/projectGraph/coedit?cwd=$PWD&filePath=<REL_PATH>"
-
-## 技术契约
-- 接口只返坐标，源码用 Read 自取：\`Read offset=startLine limit=endLine-startLine+1\`
-- qname 用 \`Parent>Child\` 形式（不是 \`.\`），直接复用 search 返回的 \`qualifiedName\`
-- 同名符号跨多文件时响应里 \`ambiguousIn\` 列出，加 \`&filePath=<rel>\` 消歧
-
-## 3 个进阶接口（智能排序 / 关联 / 风险）
-
-当基础 6 个接口的纯结构信息不够用 —— 尤其在"探索式追代码"或"评估影响范围"时 —— 用这 3 个接口拿到带相关性评分和风险标注的结果。
-
-| 问题 | 接口 |
-|---|---|
-| 这个问题/光标位置相关的代码在哪？ | context?query=&cursor= |
-| 看 X 时，还应该顺手看哪些相关代码？ | related?qname=X |
-| 改 X 真正高风险的少数节点是哪些？哪些测试要跑？ | risk?qname=X |
-| 改了这些文件，CI 应该跑哪些测试文件？（保守闭包） | affected?files=… |
-
-# context: 多源种子语义检索（query / cursor / openFiles 任传其一）
-# 返回 Top-K 相关坐标 + signals（query-match / ppr / pagerank / open）
-curl -fsS "{{BASE_URL}}/api/projectGraph/context?cwd=$PWD&query=<TEXT>&cursor=<FILE>::<QNAME>&topK=15"
-
-# related: 比 callers/callees 更广，纳入 coedit / PPR 邻居 / Louvain 社区
-# 每个结果带 relations 数组：caller / callee / ppr-neighbor / frequent-coedit / sibling-in-community
-# 同名跨多文件时响应里 ambiguousIn 列出，加 &filePath=<rel> 消歧（同 callers/callees 行为）
-curl -fsS "{{BASE_URL}}/api/projectGraph/related?cwd=$PWD&qname=<QNAME>&topK=10"
-
-# risk: impact 的风险化版本
-# 返回 highRisk（按 risk.score 降序） + suggestedTests 建议运行的测试文件
-# risk.score = callFreq + coeditProb + (hasTest ? 0 : penalty) + pagerank，按 depth 衰减
-curl -fsS "{{BASE_URL}}/api/projectGraph/risk?cwd=$PWD&qname=<QNAME>&depth=2&topK=20"
-
-# affected: 给定一组改动文件，沿 importedBy 闭包返回受影响的测试文件
-# 与 risk 互补：risk 给人/LLM 看（按符号、精准），affected 给 CI/管道用（按文件、保守）
-# 多文件输入用 POST，URL 太长用 POST；要纯文本输出用 format=plain
-curl -fsS "{{BASE_URL}}/api/projectGraph/affected?cwd=$PWD&files=<a.ts,b.ts>&depth=10"
-
-## 进阶接口契约
-- \`score\` / \`risk.score\` 只用于排序参考，无绝对意义
-- \`signals\` / \`relations\` / \`tags\` 是"为什么相关"的解释，引用时可直接告诉用户
-- \`degraded: true\` 时结果仍可用，但精度降低；\`degradedReason\` 给出原因（\`analytics-warming\` 表示后台索引还在预热，\`coedit-unavailable\` 表示 git 历史信号不可用，回落手工挑测试）
-- **risk / related 响应里已经带 \`coedit\` 字段**（target 文件的 coedit 历史），同一文件不要再单独发 /coedit 请求
-- related 响应若有 \`ambiguousIn\`，表示同名符号跨多文件，下次调用补 \`&filePath=\`
-- 这 3 个接口同样只返坐标，源码用 Read 自取`,en:`Enter project graph exploration mode (CodeGraph).
-
-CodeGraph = pre-built symbol + call-graph index + git co-edit view. Six endpoints, each answers one class of question:
-
-| Question | Endpoint |
-|---|---|
-| Where is X defined / which files share the name? | search?q=X |
-| Who calls X? | callers?qname=X |
-| What does X call? | callees?qname=X |
-| Changing X affects which symbols? | impact?qname=X&depth=2 |
-| What symbols does file F contain? | file?path=F |
-| Which files are commonly edited alongside F? (conventional coupling / parallel registries) | coedit?filePath=F |
-
-All responses are coordinates / file paths — never source. More precise than grep's textual match, cheaper in tokens than Reading whole files.
-
-## The 6 graph endpoints ({{BASE_URL}})
-
-# search: find symbols by name → file / qname / kind / startLine / endLine / params
-# q is normalized for naming style: user_profile / userProfile / user-profile / USER_PROFILE are equivalent
-# Pass includeLiterals=true to also search identifier-shaped string literals (tool names, event names,
-# config keys, route paths — the "looks like a name but isn't an identifier" strings). The response
-# then carries an extra literals[] array with value / filePath / line / enclosingSymbol per hit.
-curl -fsS "{{BASE_URL}}/api/projectGraph/search?cwd=$PWD&q=<NAME>"
-curl -fsS "{{BASE_URL}}/api/projectGraph/search?cwd=$PWD&q=<NAME>&includeLiterals=true"
-
-# callers / callees: 1-hop call relations
-curl -fsS "{{BASE_URL}}/api/projectGraph/callers?cwd=$PWD&qname=<QNAME>"
-curl -fsS "{{BASE_URL}}/api/projectGraph/callees?cwd=$PWD&qname=<QNAME>"
-
-# impact: transitive callers BFS (depth 1-5, default 2)
-curl -fsS "{{BASE_URL}}/api/projectGraph/impact?cwd=$PWD&qname=<QNAME>&depth=2"
-
-# file: file symbol tree (no source)
-curl -fsS "{{BASE_URL}}/api/projectGraph/file?cwd=$PWD&path=<REL_PATH>"
-
-# coedit: files commonly edited alongside the target = git log history + current working-tree co-edits
-#   catches "conventional coupling" the call-graph can't see (parallel registries / double-writes / sibling .md configs)
-curl -fsS "{{BASE_URL}}/api/projectGraph/coedit?cwd=$PWD&filePath=<REL_PATH>"
-
-## Technical contract
-- Endpoints return coordinates only. Fetch source with Read: \`Read offset=startLine limit=endLine-startLine+1\`
-- qname uses \`Parent>Child\` form (not \`.\`); copy \`qualifiedName\` from search's response directly
-- Cross-file name collisions are listed in \`ambiguousIn\` — pass \`&filePath=<rel>\` to disambiguate
-
-## Three advanced endpoints (smart ranking / relatedness / risk)
-
-When the six base endpoints' pure structural data isn't enough — especially when exploring code or evaluating change impact — use these to get scored, signal-annotated results.
-
-| Question | Endpoint |
-|---|---|
-| Where is the code related to this question / cursor? | context?query=&cursor= |
-| What else should I read while looking at X? | related?qname=X |
-| Changing X — which few nodes truly matter? Which tests to run? | risk?qname=X |
-| Changed these files — which tests should CI run? (conservative closure) | affected?files=… |
-
-# context: multi-source semantic retrieval (query / cursor / openFiles — at least one)
-# Returns Top-K relevant coordinates + signals (query-match / ppr / pagerank / open)
-curl -fsS "{{BASE_URL}}/api/projectGraph/context?cwd=$PWD&query=<TEXT>&cursor=<FILE>::<QNAME>&topK=15"
-
-# related: broader than callers/callees — includes coedit / PPR neighbours / Louvain community
-# Each result carries a relations[] array: caller / callee / ppr-neighbor / frequent-coedit / sibling-in-community
-# Cross-file name collisions are listed in ambiguousIn — pass &filePath=<rel> to disambiguate (same as callers/callees)
-curl -fsS "{{BASE_URL}}/api/projectGraph/related?cwd=$PWD&qname=<QNAME>&topK=10"
-
-# risk: risk-scored impact
-# Returns highRisk (sorted by risk.score desc) + suggestedTests
-# risk.score = callFreq + coeditProb + (hasTest ? 0 : penalty) + pagerank, decayed by depth
-curl -fsS "{{BASE_URL}}/api/projectGraph/risk?cwd=$PWD&qname=<QNAME>&depth=2&topK=20"
-
-# affected: file-level reverse-import closure → test files transitively affected
-# Sister to /risk: risk is symbol-centric + precision-oriented (for analysis),
-# affected is file-centric + recall-oriented (for CI / selective-test pipelines).
-# Use POST when files list is large; use format=plain for newline-separated paths.
-curl -fsS "{{BASE_URL}}/api/projectGraph/affected?cwd=$PWD&files=<a.ts,b.ts>&depth=10"
-
-## Advanced endpoint contract
-- \`score\` / \`risk.score\` are for ranking only; absolute values have no meaning
-- \`signals\` / \`relations\` / \`tags\` explain WHY each result is relevant — feel free to cite them to the user
-- \`degraded: true\` means results are still usable but lower precision; \`degradedReason\` gives the cause (\`analytics-warming\` = backing index warming up; \`coedit-unavailable\` = git history signal unavailable, fall back to manually picking tests)
-- **risk / related responses already include a \`coedit\` field** (target file's coedit history) — DO NOT issue a separate /coedit request for the same file
-- If related returns \`ambiguousIn\`, the same qname exists in multiple files — retry with \`&filePath=<rel>\`
-- These three endpoints also return coordinates only; fetch source with Read`,labelZh:"探索问题：",labelEn:"Exploration: "},cc:{zh:'进入 Cockpit CLI 操作模式\n\nCockpit CLI 是本机 Cockpit server 的瘦客户端：每个调用都把请求转发到正在跑的 server，复用其索引、缓存、git 视图等。\n\nCLI 入口选择（**默认 = prod**）：\n\n- 默认用 **`cockpit`**（prod，端口 3457）—— 没有明确信号就用这个\n- 仅在用户**明确给出 dev 信号**时才换成 `cockpit-dev`（dev，端口 3456），两种信号：\n  1. 任务文本里直接写了 `cockpit-dev ...`\n  2. `/cc` 后第一个词是 `dev`（例：`/cc dev terminal bmfb 看错误`）\n- `cock` 是 `cockpit` 的 prod 短别名，行为一致；dev 无对应短别名\n\n下文统一写 `cockpit`，仅在上述 dev 信号触发时替换为 `cockpit-dev`。\n\n## 子命令\n\n| 子命令 | 用途 |\n|---|---|\n| (无) / `<path>` | 启动 server，打开项目 |\n| `browser <id> <action>` | 控制浏览器气泡 |\n| `terminal <id> [<action>]` | 只读观察终端 ring buffer |\n| `codegraph <subcmd>` | 项目代码图(search/callers/callees/impact/file/coedit/context/related/risk/affected) |\n| `update` | 升级到最新 npm 版本 |\n\n## 典型用法模式\n\nUI 上的 terminal / browser 气泡带一个 4 字符短 id（如 `bmfb` / `mpcw`）。用户输入 `/cc` 后通常跟一段 `cockpit <subcmd> <id> <要做的事>` 描述，例如：\n\n```\n/cc cockpit terminal bmfb 看一下最近的错误日志           ← 默认 prod (cockpit)\n/cc cockpit browser mpcw 截图当前页面                    ← 默认 prod (cockpit)\n/cc cockpit codegraph risk searchIndex 评估改这个的影响  ← 默认 prod (cockpit)\n/cc dev terminal aqou 看一下错误                         ← dev 信号 #2 → 用 cockpit-dev\n/cc cockpit-dev codegraph file packages/...              ← dev 信号 #1 → 用 cockpit-dev\n```\n\n收到这类输入时：\n1. 把 `<id>` 当作具体的气泡标识传给对应子命令\n2. 先跑 `cockpit <subcmd> <id>`（或 `<subcmd> --help`）看支持的 action\n3. 选合适的 action 执行用户任务\n\n## 先看气泡清单（不知道用哪个 id 时）\n\n当用户用 "alloydb 那个 terminal" / "看一下后台" 这种**语义指代**而非具体 id 时，先用 `connection list` 拿到当前项目所有气泡 + 用户起的 title：\n\n```bash\ncockpit connection list --cwd $PWD\n```\n\n输出每行：`<type>  <shortId>  <title>  <projectCwd>  <command-or-url>`（TAB 分隔）。按 title 匹配用户的语义指代挑出 `<shortId>`，再走「典型用法模式」。title 没设的气泡显示为 `(none)`，此时可结合 `<command>` 字段（terminal 的命令字符串 / browser 的 URL）区分。\n\n## 获取详细用法\n\n每个子命令的 `--help` 是 canonical reference，**包含 usage / flags / 输出格式 / exit code / 示例**。先看 help 再用：\n\n```bash\ncockpit --help\ncockpit <subcommand> --help\ncockpit codegraph <subsubcmd> --help\n```',en:"Enter Cockpit CLI operation mode.\n\nThe Cockpit CLI is a thin local client over the running Cockpit server: each invocation forwards to the server and reuses its CodeIndex / caches / git views.\n\nCLI entry point selection (**default = prod**):\n\n- Default: **`cockpit`** (prod, port 3457) — use this when no explicit dev signal is given.\n- Switch to `cockpit-dev` (dev, port 3456) ONLY when the user explicitly signals dev mode, via one of:\n  1. They write `cockpit-dev ...` directly in the task text.\n  2. The first word after `/cc` is `dev` (e.g. `/cc dev terminal bmfb check the errors`).\n- `cock` is the prod-only short alias of `cockpit`; behaviour is identical. There is no short alias for dev.\n\nExamples below use `cockpit`; only swap in `cockpit-dev` when one of the two dev signals above is present.\n\n## Subcommands\n\n| Subcommand | Purpose |\n|---|---|\n| (none) / `<path>` | Start server, open project |\n| `browser <id> <action>` | Drive browser bubbles |\n| `terminal <id> [<action>]` | Read-only observation of a terminal ring buffer |\n| `codegraph <subcmd>` | Project code graph (search/callers/callees/impact/file/coedit/context/related/risk/affected) |\n| `update` | Upgrade to latest npm version |\n\n## Typical usage pattern\n\nTerminal / browser bubbles in the UI carry a 4-char short id (e.g. `bmfb` / `mpcw`). After `/cc` users typically follow with `cockpit <subcmd> <id> <what to do>`, e.g.:\n\n```\n/cc cockpit terminal bmfb look at the recent error logs           ← default prod (cockpit)\n/cc cockpit browser mpcw take a screenshot of the current page    ← default prod (cockpit)\n/cc cockpit codegraph risk searchIndex assess the impact          ← default prod (cockpit)\n/cc dev terminal aqou check the errors                            ← dev signal #2 → use cockpit-dev\n/cc cockpit-dev codegraph file packages/...                       ← dev signal #1 → use cockpit-dev\n```\n\nWhen you receive such input:\n1. Treat `<id>` as the concrete bubble identifier and pass it to the subcommand\n2. Run `cockpit <subcmd> <id>` (or `<subcmd> --help`) first to see supported actions\n3. Pick the right action to fulfil the user's task\n\n## When you don't know which id to use — list bubbles first\n\nIf the user refers to a bubble semantically (\"the alloydb proxy terminal\" / \"the admin page\") rather than by id, list every bubble in the current project — each one carries any user-set title:\n\n```bash\ncockpit connection list --cwd $PWD\n```\n\nOutput rows are TAB-separated: `<type>  <shortId>  <title>  <projectCwd>  <command-or-url>`. Match the user's reference against the title, take the `<shortId>`, then proceed with the typical usage pattern. Unnamed bubbles show `(none)` for title — fall back to the `<command>` column (terminal's command string / browser's URL) to disambiguate.\n\n## Getting detailed usage\n\nEvery subcommand's `--help` is the canonical reference — **it includes usage, flags, output format, exit codes, and examples.** Read it first:\n\n```bash\ncockpit --help\ncockpit <subcommand> --help\ncockpit codegraph <subsubcmd> --help\n```",labelZh:"任务：",labelEn:"Task: "}};function e(a,b="en",c){var f,g;let h,i=a.trimStart(),j=i.match(/^\/([a-zA-Z]+)(?:\s+|$)/);if(!j)return a;let k=j[1],l=b.startsWith("zh")?"zh":"en",m=d[k],n=m?.[l];if(!n)return a;let o=function(a){if(a){let b=new URL(a.url),c=a.headers.get("x-forwarded-proto"),d=a.headers.get("x-forwarded-host");return c||d?`${c??b.protocol.replace(":","")}://${d??b.host}`:b.origin}let b=process.env.COCKPIT_PORT||process.env.PORT||"3457";return`http://localhost:${b}`}(c),p=n.replaceAll("{{BASE_URL}}",o),q=i.slice(j[0].length).trimStart(),r=(f=m,(h="zh"===(g=l)?f.labelZh:f.labelEn)||("zh"===g?"问题：":"Question: "));return q?`${p}
-
-${r}${q}`:p}}};