@surething/cockpit 1.0.220 → 1.0.221

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

@@ -0,0 +1,836 @@
+"use strict";exports.id=8555,exports.ids=[8555],exports.modules={8555:(a,b,c)=>{c.d(b,{M:()=>i});var d=c(29021),e=c(33873),f=c(7939);let g={qa:{zh:`---
+name: qa
+description: "进入需求澄清讨论模式：理解并复述需求，对不明确点回问确认，只输出理解不改代码，遵循 KISS。"
+---
+
+进入需求澄清讨论模式
+尝试理解用户的需求并给出你对需求的理解，有不明确的点需要向我确认，避免理解不一致而导致无效的代码修改
+遵循 KISS 原则
+输出理解，不改代码`,en:`---
+name: qa
+description: "Enter requirement clarification mode: understand and restate the need, ask back on ambiguities, output understanding only without modifying code, follow KISS."
+---
+
+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:`---
+name: fx
+description: "进入 bug 证据链分析模式：只分析不修改代码，给出详细推理过程。"
+---
+
+进入bug证据链分析模式，只分析不修改代码，给出详细推理过程`,en:`---
+name: fx
+description: "Enter bug evidence-chain analysis mode: analysis only, no code changes, with a detailed reasoning process."
+---
+
+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:`---
+name: cg
+description: "进入项目图谱（CodeGraph）探索模式：用预建的符号 + 调用图 + git 协同视图（search/callers/callees/impact/file/coedit + context/related/risk/affected）追代码、评估影响范围，返回坐标而非源码。"
+---
+
+进入项目图谱探索模式（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:`---
+name: cg
+description: "Enter project graph (CodeGraph) exploration mode: use the pre-built symbol + call-graph + git co-edit index (search/callers/callees/impact/file/coedit + context/related/risk/affected) to trace code and assess change impact; responses are coordinates, not source."
+---
+
+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:'---\nname: cc\ndescription: "进入 Cockpit CLI（cock/cockpit 子命令）操作模式：通过瘦客户端驱动本机 server 的 terminal/browser 气泡与 codegraph 等子命令。"\n---\n\n进入 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:"---\nname: cc\ndescription: \"Enter Cockpit CLI (cock/cockpit subcommands) operation mode: drive the running server's terminal/browser bubbles and codegraph subcommands through the thin local client.\"\n---\n\nEnter 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: "},cr:{zh:`---
+name: cr
+description: "完整代码审查:静态 + 动态一遍做完。静态三角校验(拿改动和 意图 / 输入域 / 周遭 三个参照交叉定位)广扫全部改动;碰状态 / 时序 / 并发的切片再走动态推演管线(状态图 + 时间线 → 6 类动态风险)。自包含。"
+---
+
+# cr — 完整代码审查
+
+一次做完一个 PR 的完整审查:**静态广扫 + 动态深挖**。本 skill **自包含**两套方法。
+
+多数 PR 的审查是静态的——读快照就能判对错,**容易但不该漏**。难的、逐行抓不住的是**从静态代码推演出动态行为**:时序 / 状态演化 / 并发。cr 两路都做。
+
+## 执行模式(开跑前先选)
+
+**铁律:实际审查一律在【干净 subagent】里跑,主会话只做派发 + 机械合并,绝不亲自 review。** 刚在主会话写完代码、带着"我知道为什么这么做"的辩护性上下文,是最差的 reviewer。subagent 经 Agent 工具 spawn 时**不继承主会话历史**,只看 diff + 本 skill → 这正是 fresh-eyes 的来源。开发会话的残留历史**不得污染** triage / 建模 / 降级判断。
+
+两条副作用红线:① 主会话**不替 subagent 做实质判断**;② 静态拆出去还顺带消掉"静态广度摊薄动态建模"的主稀释。
+
+按规模三档(**都至少进一个干净 subagent**):
+- **单 subagent**:无动态面 / 极小 → 1 个干净 subagent 跑 Part A。主会话只转交 diff + 收报告。
+- **默认(2 subagent)**:有动态面 → 1 静态 + 1 动态,**两个都干净、并行**,各自在干净 diff 上自行 triage(静态扫全部改动 / 动态用切片原型清单列全切片)。
+- **hard(1 + N subagent)**:高风险 / 大型 → 先 1 个干净 triage subagent 出切片清单,据此 fan out 1 静态 + 每切片 1 个 subagent。最深、最慢。
+
+subagent prompt 模板:\`读本 skill (cr/SKILL.md),只对 <你那块(Part A 全部 / 某个动态切片)> 应用对应 Part,自行 triage,按统一格式输出 findings\`。
+
+**Synthesis(主会话,只整理不重判)**:汇总各 subagent 的 findings → 去重(同根因标"共犯")→ 影响 \xd7 概率排序 → 一份报告 + 梯度图。**禁止用主会话的开发上下文给任何 finding 洗白 / 降级**——subagent 怎么判就怎么收。要质疑某条,**重新 spawn 一个干净 subagent 复核**,而不是主会话自己拍。
+
+> 取舍:默认 2-subagent 既隔离开发污染、又消掉静态摊薄动态;hard 的 per-slice fan-out 是额外深度(实测把 image/video 挖到 🔴 + 多 subagent 独立收敛提置信度),贵且慢,只在高风险上。
+
+## Step 1 — 分诊(triage;两种模式都先做这步)
+读 diff,切两面(可重叠):
+- **静态面** = 全部改动 → 走 **Part A**。
+- **动态面** = 碰 **状态 / 时序 / 并发 / 跨进程时序** 的切片 → 额外走 **Part B**。
+
+切分原则:**A 判 as-written**(写没写对)、**B 判 over-time**(会不会被时序击穿);同一处两面都查。无动态面 → 跳过 Part B。
+
+---
+
+## Part A — 静态三角校验:拿改动和三个参照交叉定位
+
+correctness 这个"未知点",靠 **意图 / 输入域 / 周遭** 三个独立参照三角定位——任何一个单独都会漏(只看意图漏边界、只看输入漏意图、只看周遭漏两者),三点合围才钉死。
+
+只挑**工具判不了的语义层**问题(风格 / 格式 / 未用变量 / 类型不匹配交给 linter & type-checker)。静态 bug 几乎都是**快照与某个参照物对不上**:
+
+### A1. vs 意图(做到声称的事了吗)
+- name / 签名 / 类型 / PR 描述 / 注释**承诺**的,和代码**实际做的**一致吗?(\`isValid\` 出错却返回 true;PR 说改 X 实际动了 Y)
+- 错误 / 边界分支返回的是**对的**东西吗,还是顺手返回了 happy-path 的值?
+- 注释 / 文档和新代码同步了吗,还是还在描述旧行为?
+
+### A2. vs 输入域(覆盖输入全集了吗)— 头号 bug 源
+- 全集都处理了吗:null / undefined / 空 / 单元素 / 重复 / 边界值 / 溢出 / 负数 / unicode / 超长?
+- **错误路径**和 happy path 一样正确吗?早返回 / 异常路径上,资源关了吗、状态一致吗?
+- 外部输入(用户文本、参数、反序列化、webhook)当**不可信**处理了吗?(注入、越权、未校验、secrets 入 log)
+- 典型病:happy path 对、输入域没覆盖全。
+
+### A3. vs 周遭(和已有契约 / 约定一致吗)
+- **契约漂移**:改了签名 / 类型 / 枚举 / 返回结构,**所有 consumer** 都跟着改了吗?(grep 可见,lint 不报)
+- **约定背离**:该用项目既定模式 / helper 却用了裸原语 / 重新发明?
+- **分层 / 边界**:绕过了该走的层、引入了不该有的依赖方向?
+- **类型即事实源**:还是被 \`any\` / 断言 / 强转绕过?
+- **安全对齐**:siblings 都有的检查(鉴权、租户隔离),这里漏了吗?
+
+### 收尾(轻;工具能兜的别重做)
+- 重复逻辑——尤其重复的**决策 / 策略**——该收敛成单一来源?死代码、过度复杂?
+- **局部**性能:N+1、循环内 IO、明显劣化的算法、无界增长?(随状态演化的交 Part B)
+- 测试:新增逻辑的**边界 / 错误路径**有断言吗?红测修前 fail、修后 pass?
+
+---
+
+## Part B — 动态:把静态代码推演成模型再审(仅动态面切片)
+
+读快照看不出时序 bug——它活在「跑起来随时间怎么变」里。把它推演成动态模型再审,而不是逐行扫。
+
+**逐切片建模(硬规则)**:建模前先列出**所有**独立动态切片,逐个打勾跑 B1–B3——**别只对最显眼的那个建模就收工,漏建一个切片 = 它里面的动态风险全漏**。为防清单遗漏,按这几类**切片原型**扫一遍:
+- **共享状态的 init + 多写**(累加器 / key / 缓存:谁先建、谁多写)
+- **跨进程 / 重入复用的状态**(重试 / 恢复 / 多 worker / 队列)
+- **check-then-act 跨异步 gap**(预检 → 耗时操作 → 副作用晚落地;并发发起会集体越过预检 —— TOCTOU)
+- **fire-and-forget 写 + 后续读**(写未落地就被读覆盖)
+- **隐式上下文跨 hop**(ALS / log context 跨进程 / 跨队列后是否还在)
+
+⚠ **一块代码可以同时是静态发现点 + 动态切片**——别因为它在 Part A 已被静态扫过(文案、重复、可选参数)就不再把它当动态切片建模。静态"认领"≠ 动态已覆盖。
+
+### B1. 静态读入(输入)
+读出:**有哪些状态** \xb7 **谁读谁写**(跨 feature、跨上游调用方,别停在本文件)\xb7 **契约 / 类型** \xb7 **控制流与入口**。
+
+### B2. 建动态模型(主产物,写进报告当证据)
+- **状态图** — 有哪些状态 + 迁移;每条迁移标注**谁在什么条件下改它**。
+- **时间线** — 所有 writer/reader 上时间轴,标谁先谁后;**跨组件、跨进程拉通**,追到状态**真正诞生**的那一刻(不是它被本地重新引用的地方)。
+- **变更轨迹** — 关键状态值沿时间线怎么流转:被谁建 / 改 / 读,有没有中途被覆盖 / no-op / 丢失。
+
+这两张图就是证据——很多 bug(一条 6 秒的 gap、一个被先建出来的 key)只有画出来才现形。
+
+### B3. 在模型上评估 6 类动态风险
+
+| 风险 | 在模型上看什么 |
+|---|---|
+| **顺序竞态** | 有 writer 跑在 initializer 之前吗?"init 在本函数被 await" ≠ 它是该状态第一次被碰。追到跨 feature 的最早 writer。 |
+| **重叠 / 漏算** | 多 writer 写同一累加器:同一笔事件被 >1 路记入(双算)?某类事件没人记(漏算)?别信注释的"这条只记 X"分工。 |
+| **丢失更新** | fire-and-forget 写 + 随后的读:读到旧值并**覆盖**了本地正确值? |
+| **fail-open 错值** | 降级路径放行的是*错值*还是*缺失*?对污染值返回自信错值 = 只安全了一半。**判 fail-open/fail-closed 要读守卫的实际比较式(\`x < 阈值\` vs \`x >= 阈值\`),别凭注释或直觉——\`NaN\`/\`Infinity\` 哨兵会让所有 \`x < 阈值 → 安全返回\` 式守卫落 false,放行与拦截两条会同时被击穿。** |
+| **跨进程 / 重入** | 重试 / 恢复 / 多 worker 复用同一状态会串扰吗?隐式上下文(ALS / log context)跨进程 hop 后还在吗? |
+| **provenance 断裂** | 关键值从源头到落点,中途被 no-op / 覆盖 / 类型擦除了吗?(看到 dedup / skip / 幂等守卫 → 问它防什么失败 → 去**没有它**的路径或旧版本查那个失败。) |
+
+**升级档:把难判的顺序 / 算术,框成 satisfiability**(可选——只对 **顺序竞态** 和 **极端值 / 抵消** 两类、且非形式推理拿不准时用):
+1. **自由变量** — 什么能变?顺序(writer 的 interleaving)、取值(关键数值变量 / 输入 / 计数)。
+2. **只写真约束** — 哪些 happens-before 是真成立的(await / 锁 / 队列序)?哪些只是你**假设**的?+ 要守的不变量。
+3. **∃ 反例?** — **SAT**(找到一个顺序/取值破坏不变量)= bug,反例即触发场景;**UNSAT** = 在此模型下证明安全(仅当模型忠实于代码)。
+
+**三条纪律(决定 findings 质量)**
+1. **普查没验证完 order + overlap 两种关系前,不算做完。** 列出 writer ≠ 普查完成。
+2. **不准凭局部观察降级。** ordering / race 类 finding,降档前必须把时间线追到状态诞生点。SMT 话术:你是不是把一条并不存在的 happens-before 当成了约束?(「某步在本函数里被 await」≠ 它在全局上先于其它组件对同一状态的写。)没追到 → 标 \`需动态验证\`,保持原档,不降 ⚪。
+3. **绿测 ≠ 验证。** 问:有没有**对抗序**测试(乱序 / 重试 / write-before-init)?bug 所在那层是不是被 mock 没了?有真实 trace 就拿时间线对账。
+
+---
+
+## 产出 findings(直观优先)
+
+严重度 = **影响 \xd7 概率**,直接给乘积结论,别让读者自己换算。两路 findings 合并去重,统一格式:
+
+\`\`\`
+🔴|🟡|⚪ <位置(file:line)> — 不修会发生什么(一句大白话后果,不带术语)
+  影响: 坏到什么程度 + 坏给谁(具体:哪类用户 / 租户 / 调用方,而非泛指"用户")
+  概率: 多大概率发生 + 取决于什么
+  证据: 静态 → 三角校验里哪个参照对不上(意图 / 输入域 / 周遭);动态 → 模型证据(指回状态图 / 时间线哪一处)
+  正解: 应该是什么 / 被破坏的不变量(术语放这里)
+\`\`\`
+
+- 🔴 高概率 \xd7 大影响(卡发布) | 🟡 该修但不流血 | ⚪ 顺手。降序输出。
+- 一句话结论说**后果**,不说技术原因(原因放 \`正解\`)。
+- 概率取决于待验证因子就显式写,并写明如何升降档;别把"待验证"伪装成"已确认"。
+- 多条同根因 → 标 **"共犯"** 合并成一条,别同一问题报两遍(尤其静态/动态对同一行各看一面时)。
+- 收尾给一张 **影响 \xd7 概率** 梯度图:
+
+\`\`\`
+影响 ↑
+ 大  │ 🔴 #1
+ 中  │            🟡 #2
+ 小  │ 🟡 #3                  ⚪ #4
+     └─────────────────────────────→ 概率
+        低         中         高
+\`\`\`
+
+## 别走过场
+- **别漏升级**:Step 1 标了动态面,就必须真的对它跑 Part B(建模 + 6 类风险);只静态扫一遍就收工 = 漏。
+- **不和工具抢活**(静态):风格 / 格式交给 linter & type-checker,cr 只挑语义层。
+- **碰动态别硬推**:看到状态 / 时序 / 并发,要**建模**(Part B),别凭读代码下结论。
+- **trivial 改动**:无动态面 → 跳过 Part B,只交一份静态报告。`,en:`---
+name: cr
+description: "Full code review: static + dynamic in one pass. Static triangulation (cross-locate the change against three references — intent / input domain / surroundings) sweeps all changes; slices touching state / timing / concurrency additionally run the dynamic-derivation pipeline (state diagram + timeline → 6 classes of dynamic risk). Self-contained."
+---
+
+# cr — Full Code Review
+
+Do a PR's complete review in one pass: **broad static sweep + deep dynamic dig**. This skill is **self-contained** in both methods.
+
+Most PR review is static — read the snapshot and you can judge right/wrong, **easy but must not be skipped**. The hard part, the part you can't catch line-by-line, is **deriving dynamic behaviour from static code**: timing / state evolution / concurrency. cr does both tracks.
+
+## Execution mode (choose before you start)
+
+**Iron rule: the actual review always runs in a 【clean subagent】; the main session only dispatches + mechanically merges, NEVER reviews in person.** Having just written the code in the main session, carrying the defensive "I know why I did it this way" context, is the worst possible reviewer. When a subagent is spawned via the Agent tool it **does not inherit the main session's history** — it sees only the diff + this skill → that is exactly the source of fresh eyes. The dev session's residual history **must not pollute** triage / modelling / downgrade judgements.
+
+Two side-effect red lines: ① the main session **does not make substantive judgements on the subagent's behalf**; ② splitting static out also removes the "static breadth dilutes dynamic modelling" dilution of the main thread.
+
+Three tiers by scale (**all enter at least one clean subagent**):
+- **Single subagent**: no dynamic surface / tiny → 1 clean subagent runs Part A. Main session just relays the diff + collects the report.
+- **Default (2 subagents)**: has a dynamic surface → 1 static + 1 dynamic, **both clean, in parallel**, each triaging on the clean diff itself (static scans all changes / dynamic lists every slice via the slice-archetype checklist).
+- **hard (1 + N subagents)**: high-risk / large → first 1 clean triage subagent produces the slice list, then fan out 1 static + 1 subagent per slice. Deepest, slowest.
+
+Subagent prompt template: \`Read this skill (cr/SKILL.md); apply only the matching Part to <your chunk (all of Part A / one dynamic slice)>, triage it yourself, and output findings in the unified format\`.
+
+**Synthesis (main session, organize only — never re-judge)**: gather each subagent's findings → dedup (mark same-root-cause as "accomplices") → sort by impact \xd7 probability → one report + gradient chart. **It is forbidden to use the main session's dev context to whitewash / downgrade any finding** — take what the subagent judged as-is. To dispute one, **spawn a fresh clean subagent to re-check**, not the main session deciding on its own.
+
+> Trade-off: the default 2-subagent both isolates dev pollution and removes static-dilutes-dynamic; hard's per-slice fan-out is extra depth (in practice it dug image/video up to 🔴, and multiple independently-converging subagents raised confidence), expensive and slow, only for high risk.
+
+## Step 1 — Triage (do this first in both modes)
+Read the diff, cut two surfaces (may overlap):
+- **Static surface** = all changes → go to **Part A**.
+- **Dynamic surface** = slices touching **state / timing / concurrency / cross-process timing** → additionally go to **Part B**.
+
+Splitting principle: **A judges as-written** (is it written correctly), **B judges over-time** (can timing break it through); check both surfaces on the same spot. No dynamic surface → skip Part B.
+
+---
+
+## Part A — Static triangulation: cross-locate the change against three references
+
+correctness, that "unknown", is triangulated against three independent references — **intent / input domain / surroundings**. Any one alone misses something (intent-only misses boundaries, input-only misses intent, surroundings-only misses both); only the three together nail it down.
+
+Pick only the **semantic-layer problems tools can't judge** (style / format / unused vars / type mismatch go to linter & type-checker). Static bugs are almost always **the snapshot failing to match some reference**:
+
+### A1. vs intent (did it do what it claims)
+- Do the name / signature / type / PR description / comment **promises** match what the code **actually does**? (\`isValid\` returns true on error; PR says it changes X but actually touched Y)
+- Do error / boundary branches return the **right** thing, or did they carelessly return the happy-path value?
+- Are comments / docs in sync with the new code, or still describing the old behaviour?
+
+### A2. vs input domain (did it cover the full input set) — the #1 bug source
+- Is the whole set handled: null / undefined / empty / single element / duplicate / boundary value / overflow / negative / unicode / over-length?
+- Is the **error path** as correct as the happy path? On early returns / exception paths, are resources closed and state consistent?
+- Is external input (user text, params, deserialization, webhook) treated as **untrusted**? (injection, privilege escalation, unvalidated, secrets into logs)
+- Classic disease: happy path correct, input domain not fully covered.
+
+### A3. vs surroundings (consistent with existing contracts / conventions)
+- **Contract drift**: changed a signature / type / enum / return shape — did **all consumers** change with it? (grep-visible, lint won't flag)
+- **Convention deviation**: should have used the project's established pattern / helper but used a raw primitive / reinvented it?
+- **Layering / boundary**: bypassed a layer it should go through, introduced a forbidden dependency direction?
+- **Type as source of truth**: or bypassed by \`any\` / assertions / casts?
+- **Security alignment**: a check the siblings all have (authn, tenant isolation) — missing here?
+
+### Wrap-up (light; don't redo what tools cover)
+- Duplicated logic — especially duplicated **decisions / policies** — should converge to a single source? Dead code, over-complexity?
+- **Local** performance: N+1, IO in a loop, an obviously degraded algorithm, unbounded growth? (state-evolving cases go to Part B)
+- Tests: do the new logic's **boundary / error paths** have assertions? Does the red test fail before the fix and pass after?
+
+---
+
+## Part B — Dynamic: derive the static code into a model, then review (dynamic-surface slices only)
+
+You can't see timing bugs in a snapshot — they live in "how things change over time once running". Derive it into a dynamic model and review that, instead of scanning line-by-line.
+
+**Model per slice (hard rule)**: before modelling, list **all** independent dynamic slices and tick each through B1–B3 — **don't model just the most obvious one and call it done; missing one slice = all of that slice's dynamic risks are missed**. To avoid omissions, sweep these **slice archetypes**:
+- **Shared-state init + multi-write** (accumulator / key / cache: who creates first, who writes many)
+- **State reused across processes / re-entry** (retry / recovery / multi-worker / queue)
+- **check-then-act across an async gap** (precheck → slow operation → side-effect lands late; concurrent starts collectively cross the precheck — TOCTOU)
+- **fire-and-forget write + later read** (read overwrites before the write lands)
+- **Implicit context across a hop** (ALS / log context: still there after crossing process / queue?)
+
+⚠ **One piece of code can be both a static finding point and a dynamic slice** — don't stop modelling it as a dynamic slice just because Part A already scanned it statically (wording, duplication, optional params). Static "claiming" ≠ dynamic coverage.
+
+### B1. Static read-in (input)
+Read out: **what states exist** \xb7 **who reads/who writes** (across features, across upstream callers — don't stop at this file) \xb7 **contract / type** \xb7 **control flow and entry points**.
+
+### B2. Build the dynamic model (the main artifact, written into the report as evidence)
+- **State diagram** — what states + transitions exist; annotate each transition with **who changes it under what condition**.
+- **Timeline** — all writers/readers on a time axis, marking who's first; **pull it through across components, across processes**, tracing back to the moment the state is **truly born** (not where it's re-referenced locally).
+- **Change trajectory** — how the key state value flows along the timeline: created / changed / read by whom, ever overwritten / no-op'd / lost midway.
+
+These two diagrams are the evidence — many bugs (a 6-second gap, a key created too early) only reveal themselves once drawn.
+
+### B3. Evaluate 6 classes of dynamic risk on the model
+
+| Risk | What to look for on the model |
+|---|---|
+| **Order race** | Is there a writer running before the initializer? "init is awaited in this function" ≠ it's the first touch of that state. Trace to the earliest cross-feature writer. |
+| **Overlap / undercount** | Multiple writers to one accumulator: is the same event recorded by >1 path (double count)? Is some event class recorded by no one (undercount)? Don't trust the comment's "this only records X" division. |
+| **Lost update** | fire-and-forget write + a following read: does it read a stale value and **overwrite** the locally-correct value? |
+| **fail-open wrong value** | Does the degradation path let through a *wrong value* or a *missing value*? Returning a confident wrong value for poisoned input = only half safe. **To judge fail-open/fail-closed, read the guard's actual comparison (\`x < threshold\` vs \`x >= threshold\`); don't go by comment or intuition — \`NaN\`/\`Infinity\` sentinels make every \`x < threshold → safe return\` guard evaluate false, so both let-through and block paths break at once.** |
+| **Cross-process / re-entry** | Does retry / recovery / multi-worker reusing the same state cross-talk? Does implicit context (ALS / log context) survive a cross-process hop? |
+| **Provenance break** | From source to landing point, is the key value no-op'd / overwritten / type-erased midway? (Seeing dedup / skip / idempotency guards → ask what failure they prevent → go to the path **without** them, or an older version, to find that failure.) |
+
+**Escalation: frame hard ordering / arithmetic as satisfiability** (optional — only for **order race** and **extreme value / cancellation**, and only when informal reasoning is uncertain):
+1. **Free variables** — what can vary? Order (writer interleaving), values (key numeric variables / inputs / counts).
+2. **Write only real constraints** — which happens-before relations truly hold (await / lock / queue order)? Which are just your **assumption**? + the invariant to hold.
+3. **∃ counterexample?** — **SAT** (found an order/value that breaks the invariant) = bug, the counterexample is the trigger scenario; **UNSAT** = proven safe under this model (only if the model is faithful to the code).
+
+**Three disciplines (they decide findings quality)**
+1. **A census isn't done until both order + overlap relations are verified.** Listing writers ≠ census complete.
+2. **No downgrading on local observation.** For ordering / race findings, before downgrading you must trace the timeline to the state's birth. SMT phrasing: did you treat a non-existent happens-before as a constraint? ("some step is awaited in this function" ≠ it globally precedes other components' writes to the same state.) Not traced → mark \`needs dynamic verification\`, keep the tier, don't drop to ⚪.
+3. **Green tests ≠ verification.** Ask: is there an **adversarial-order** test (shuffled / retry / write-before-init)? Was the layer the bug lives in mocked away? With a real trace, reconcile against the timeline.
+
+---
+
+## Produce findings (intuitive first)
+
+Severity = **impact \xd7 probability**; give the product conclusion directly, don't make the reader do the math. Merge and dedup findings from both tracks, unified format:
+
+\`\`\`
+🔴|🟡|⚪ <location (file:line)> — what happens if unfixed (one plain-language consequence, no jargon)
+  Impact: how bad + to whom (specific: which users / tenants / callers, not a vague "users")
+  Probability: how likely + what it depends on
+  Evidence: static → which reference fails in triangulation (intent / input domain / surroundings); dynamic → model evidence (point back to which spot on the state diagram / timeline)
+  Fix: what it should be / the broken invariant (jargon goes here)
+\`\`\`
+
+- 🔴 high probability \xd7 big impact (blocks release) | 🟡 should fix but not bleeding | ⚪ nice-to-have. Output in descending order.
+- The one-line conclusion states the **consequence**, not the technical cause (cause goes in \`Fix\`).
+- If probability depends on a to-be-verified factor, say so explicitly and write how to raise/lower the tier; don't disguise "to be verified" as "confirmed".
+- Multiple same-root-cause → mark as **"accomplices"** and merge into one; don't report the same problem twice (especially when static/dynamic each see one side of the same line).
+- Close with an **impact \xd7 probability** gradient chart:
+
+\`\`\`
+Impact ↑
+ big  │ 🔴 #1
+ mid  │            🟡 #2
+ small│ 🟡 #3                  ⚪ #4
+      └─────────────────────────────→ Probability
+        low        mid        high
+\`\`\`
+
+## Don't go through the motions
+- **Don't skip escalation**: if Step 1 flagged a dynamic surface, you MUST actually run Part B on it (modelling + 6 risk classes); scanning statically once and stopping = a miss.
+- **Don't compete with tools** (static): style / format go to linter & type-checker, cr only picks the semantic layer.
+- **Don't hand-wave the dynamic**: seeing state / timing / concurrency, **build the model** (Part B), don't conclude from reading code.
+- **Trivial changes**: no dynamic surface → skip Part B, deliver only a static report.`}},h=(0,e.join)(f.Kv,"skills");function i(a,b="en",c){var f,j;let k,l=a.trimStart(),m=l.match(/^\/([a-zA-Z]+)(?:\s+|$)/);if(!m)return a;let n=m[1],o=b.startsWith("zh")?"zh":"en",p=g[n],q=p?.[o];if(!q)return a;let r=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),s=q.replaceAll("{{BASE_URL}}",r),t=function(a,b){try{let c=(0,e.join)(h,a);(0,d.mkdirSync)(c,{recursive:!0});let f=(0,e.join)(c,"SKILL.md");return(0,d.writeFileSync)(f,b.endsWith("\n")?b:`${b}
+`,"utf-8"),f}catch{return null}}(n,s),u=l.slice(m[0].length).trimStart(),v=(f=p,(k="zh"===(j=o)?f.labelZh:f.labelEn)||("zh"===j?"问题：":"Question: "));if(!t)return u?`${s}
+
+${v}${u}`:s;let w="zh"===o?`请读取这个 skill 文件：
+${t}`:`Please read this skill file:
+${t}`;return u?`${w}
+
+${v}${u}`:w}}};