@namewta/speculo 0.2.2 → 0.2.6

package/template/vendor/khazix-skills/neat-freak/references/governance.md

@@ -0,0 +1,88 @@
+# 规范执行审计细则
+
+核心原则：规则的内容来自现场层级文件，本 reference 只提供提取、核验和处置方法。系统、用户和项目规则的授权边界高于本 skill。
+
+## 提取可机械核验约定
+
+读实际生效的规则链时，找能够转成检查命令的祈使句，并记录原文出处。
+
+| 类别 | 规则句式 | 核验证据 |
+|---|---|---|
+| 命名 | “目录必须 kebab-case” | 同级名字清单和例外条款 |
+| 必备文件 | “每个项目必须有 X” | 文件存在性与最小内容 |
+| 同源 | “A 软链/导入 B”“只编辑 B” | `readlink`、realpath、导入、加载诊断 |
+| 安全红线 | “密钥不进代码”“ignore 必须含 X” | tracked files、ignore 规则、secret scanner |
+| 目录纪律 | “根目录不放裸文件” | 根目录 manifest 与白名单 |
+| 声明一致 | “启动命令/URL/服务名必须真实” | package/config、服务或 live probe |
+| 发布流程 | “完整汇报与用户确认先于清场” | knowledge receipt、deploy marker、cleanup candidate、post-report user approval receipt |
+
+行为偏好如“结论先行”也要遵守，但不属于结构审计结果，除非存在可验证模板或门禁。
+
+## 确定实际规则链
+
+不要假设所有平台都从根目录读同一个文件：
+
+1. 识别当前 Agent 和 `cwd`。
+2. 从项目根到 `cwd` 查本平台的规则文件、override、fallback 和路径规则。
+3. 再查用户/组织级规则。
+4. 记录加载顺序和覆盖关系；同目录只采用平台实际会加载的文件。
+5. 若项目声明 CLAUDE.md/AGENTS.md 必须同源，再核对软链或导入；没有声明时只报告分叉风险，不擅自规定方向。
+
+## 核验范围
+
+- **当前项目请求**：审当前项目内容；上级规则和同级名字只读。
+- **跨项目变更**：审实际受影响的 upstream/consumer 文档，先说明扩展依据。
+- **整个 workspace**：用户明确授权后，逐项目做存在性、同源和规则检查；仍按风险决定是否读全文。
+- **全局配置**：默认只读审计死引用、矛盾和加载漂移，不把项目细节写入全局。
+
+## 处置等级
+
+先服从现场规则；如果现场没有更具体规定，用下面的默认分级。
+
+### 可直接修
+
+必须同时满足：在请求范围内、安全、可逆、没有外部副作用，并且当前规则授权自动修复。例如：
+
+- 现场明确要求的软链/导入缺失；
+- `.gitignore` 缺少规则明文要求的敏感文件模式；
+- 文档里的明显笔误、确认已不存在的死链接；
+- 同一事实的过期摘要，可由当前代码/运行态唯一裁决。
+
+### 先报告再决定
+
+- 目录或项目重命名、文件/目录删除；
+- 合并内容不同的规则文件且权威无法唯一确定；
+- 规则与稳定实践漂移，但不清楚该改规则还是实践；
+- 修改范围外项目、全局配置或其他人的工作区；
+- 停服、权限/密钥、不可逆迁移、对外消息等现场规则列出的风险动作；
+- 唯一证据在未合并/dirty lane 中，清理会丢失它。
+
+### 只读报告
+
+- 用户明确限制为“看看/审计/报告”；
+- 发现问题位于请求范围外；
+- 平台生成文件禁止直接修改；
+- 事实无法验证或需要外部系统权限。
+
+## 规则本身的质量
+
+同时检查：
+
+- **死引用**：路径、命令、服务、项目是否存在；跨设备路径拿不准时不能直接删。
+- **矛盾**：上下级规则、override、skill 和实践是否给出互斥要求。
+- **不可执行**：大量“保持整洁/注意安全”但没有判断标准。
+- **重复**：同一红线在全局、项目和 skill 复制，导致未来分叉。
+- **过载**：核心规则被历史叙事挤没；优先删/迁，而不是继续加目录。
+- **无门禁**：同一违规第三次出现，说明散文约束不足。根据现场授权建议或实现 check/hook/test。
+
+## 报告要求
+
+每条未自动修复的问题必须包含：
+
+- 证据和规则出处；
+- 所在范围；
+- 对用户或协作流程的影响；
+- 推荐动作；
+- 为什么本次没有自动执行。
+
+不要用“发现 N 个问题”代替判断材料，也不要把范围外问题混进“项目已清洁”的结论。

package/template/vendor/khazix-skills/neat-freak/references/sync-matrix.md

@@ -0,0 +1,77 @@
+# 变更影响矩阵
+
+矩阵用于路由，不用于强造固定文件名。先识别项目现有的架构、接入、运维、决策和发布文档，再把对应受众更新到位。
+
+## 先删哪些噪音
+
+| 反模式 | 默认处理 |
+|---|---|
+| “某日 X 上线，详见 Y”塞在主规则顶部 | 现役约束就地融合；纯历史迁 git/changelog/事故文档 |
+| 主规则抄完整架构、评分公式或数据流 | 留边界和权威文档指针，详细机制回 docs |
+| 多个版本都自称“现役” | 以代码开关、运行态和回退链裁决；历史版显式标回退/退役 |
+| 已完成待办仍列开放项 | 核实后删除或改为当前约束，不保留“已完成”流水账 |
+| 单次事故长篇常驻 memory | 提炼可复用教训；机制进 docs，过程进 incident/git |
+| 多处复制同一规则 | 保留一个权威真身，其他位置放短指针或删除 |
+| “保留作历史”但没有真实读者和用途 | 删除；历史需要用途、权威位置和检索入口 |
+| Agent 会话残留：一次性计划文档、调试脚本、`xxx_old`/`xxx_backup` 副本 | 有效内容并进正式文档；文件列删除候选，经用户确认后才清 |
+
+## 代码或运行态变化 → 知识面
+
+| 变化 | 要核对的受众面 |
+|---|---|
+| API / 路由 /协议 | 外部接入合同、架构路由、鉴权、示例、consumer 文档、smoke |
+| 环境变量 / provider / model | 示例 env、运行手册、默认值权威、下游配置、成本/回退说明 |
+| schema / 存储字段 | 数据模型、迁移与回滚、派生/缓存、读写边界、测试 |
+| 用户流程 / 权限 /导航 | README/产品说明、架构权限、运营手册、视觉验收 |
+| 评分 /筛选 /聚类 / prompt | 现役算法文档、阈值/开关、回测证据、回退链、展示影响 |
+| 服务 /部署 /CDN /边缘 | 运维手册、服务名、marker、cache、回滚、live acceptance |
+| 后台任务 /告警 | job 文档、调度、失败收口、告警路由、决策面 |
+| 退役 /改名 /下线 | 搜旧 symbol 的非历史引用、consumer、rules、skills 和 memory；保留明确标注的历史证据 |
+| 发布流程 /多 Agent 生命周期 | SOP、合并/部署脚本、知识凭证、清场门禁、workspace audit |
+
+## 受众职责
+
+新增或改变一个能力时，至少判断四种职责是否存在；不是要求创建四个固定文件：
+
+1. **怎么用**：README、API/集成指南、示例。
+2. **怎么工作**：architecture、schema、状态机、设计边界。
+3. **怎么运维**：runbook、环境变量、smoke、回滚、告警。
+4. **当前状态/历史**：产品 changelog、release note、incident 或 git；只有项目规则/用户明确要求才写 changelog。
+
+如果同一文档承担多个职责，可以就地更新，不为形式拆文件。
+
+## 记忆路由
+
+| 记忆类型 | 处理 |
+|---|---|
+| 用户偏好 /反复纠正 | 在平台允许且用户授权时保留短、可执行条目 |
+| 系统机制 | 毕业进权威 docs；memory 只留检索指针 |
+| 决策事件 | 只保留最终结论和仍有效的为什么；过程归 git/changelog |
+| 已完成开放项 | 核实后删，不让它继续冒充计划 |
+| 相对时间 | 当前状态改绝对日期；历史叙事中的自然语言不机械替换 |
+| 重复或冲突 | 用当前代码/运行态裁决；无法裁决就保留冲突并标 pending |
+| 机器生成索引 | 不直接编辑；写规定输入或候选，交给生成流程 |
+| 长期未引用 | 结合权威性和复用价值判断；未引用不是单独删除理由 |
+
+## 规则违规 → 动作
+
+| 发现 | 动作 |
+|---|---|
+| 现场规则要求同源，但软链/导入缺失 | 在授权范围内补齐并验证 realpath/load |
+| 两份独立规则内容不同 | 能由现场声明唯一裁决则合并；否则待决 |
+| 有可运行代码但缺项目规则 | 默认创建最小规则文件（五要素、精简）；工作空间有模板按模板 |
+| ignore 缺安全红线 | 在请求范围和授权内直接补，并验证 tracked secrets |
+| 命名违规、根目录乱放 | 只读报告影响；移动/重命名/删除通常待决 |
+| 规则引用退役路径/命令 | 当前机器唯一确认且无跨设备疑点时清；否则报告 |
+| 同一违规反复出现 | 用 check/hook/test 根治；是否自动实现服从现场授权 |
+
+## 跨项目检查
+
+以下任一为真，就搜索实际 consumer，而不是只改当前项目：
+
+- 共享 API、SDK、域名、认证、schema 或环境变量改变；
+- 部署/边缘层改变了下游可见行为；
+- 公共 skill、脚本或模板被多个项目引用；
+- 当前项目文档明确列出依赖方。
+
+只读发现 consumer 不等于获准编辑它。先说明依赖证据和影响，再按任务与工作空间规则行动。

package/template/vendor/khazix-skills/neat-freak/references/verification.md

@@ -0,0 +1,92 @@
+# 证据层级与发布终态
+
+## 风险决定证据深度
+
+| 结论 | 最低证据 |
+|---|---|
+| “文档链接有效” | 项目自己的 doc-link/index check 或逐链接存在性 |
+| “规则已同源” | realpath/readlink/import + 平台实际加载顺序 |
+| “代码实现是 X” | 当前目标分支代码、schema、配置与相关测试 |
+| “PR 已完成” | PR state=merged + merge commit；不能推导已部署 |
+| “已部署” | deploy marker/release 指向目标 commit + 服务 active |
+| “用户已看到新版本” | canonical 用户 URL/API 的真实响应，必要时同时比 origin/cache |
+| “可安全清场” | merged + production contains change + knowledge receipt + lane clean + 无唯一未集成文件 |
+| “已获准清场” | 完整结果已向用户汇报 + 用户在该汇报后明确确认可以清场 + 现场要求的确认凭证 |
+| “整个项目干净” | 项目内所有适用事实面 verified；warning、pending 和 out-of-scope 单列 |
+
+代码直觉、旧 memory、commit message 和 cache-buster URL 都只能当线索，不能单独证明生产终态。
+
+## 真相矩阵
+
+对每个发现至少记录：
+
+```text
+topic: <事实主题>
+authority: <当前权威来源>
+code: verified-current | stale | n/a
+runtime: verified-current | stale | unverified | n/a
+docs: verified-current | stale | changed
+rules: verified-current | stale | changed | n/a
+memory: verified-current | stale | generated-read-only | changed | n/a
+action: <做了什么或为什么没做>
+verification: <命令、页面或门禁>
+```
+
+用户不需要看到完整矩阵，但最终摘要必须保留未闭合状态。
+
+## 发布状态机
+
+```text
+implemented
+  -> locally verified
+  -> pushed / PR opened
+  -> CI + required backtest/visual review passed
+  -> merged
+  -> deployed
+  -> live verified
+  -> knowledge closed + receipt recorded
+  -> full result reported while evidence is preserved
+  -> user explicitly approved cleanup after the report
+  -> workspace cleaned
+  -> post-cleanup audit passed
+  -> cleanup result appended
+```
+
+跳过的状态必须有项目规则允许的原因。失败停在哪一格，就按那一格汇报，不能用“基本完成”覆盖。
+
+## 缓存和多表面产品
+
+当用户可见内容经过 CDN、边缘缓存、搜索索引、异步 worker 或多客户端时，至少识别：
+
+- origin 是否为新内容；
+- canonical URL 是否仍为旧缓存；
+- API/页面/通知/RSS 是否共享同一数据出口；
+- deploy marker 是否在所有异步进程真正切换之后才写；
+- cache-buster 是否只是诊断，而非真实用户验收。
+
+只验证其中一个表面时，在结论里明确限制范围。
+
+## 清场前 gate
+
+清场会销毁复盘和用户复核证据，因此顺序固定为：
+
+1. 验证目标工作已集成并上线；
+2. 同步 docs/rules/获准记忆；
+3. 记录项目要求的 knowledge closeout receipt；
+4. 预览待删除 worktree/branch/db/artifact；
+5. 检查 dirty 文件和 patch equivalence；
+6. 向用户完整汇报结果并保留上述现场；
+7. 等待用户在看完汇报后明确确认可以清场；
+8. 记录项目要求的用户确认凭证并执行授权的清理；
+9. 重新运行 workspace audit，补充汇报清场结果。
+
+用户最初任务中的“收尾并清理”“做完删掉”等预授权不替代第 7 步；确认必须发生在完整汇报之后，因为用户要先看到结果才能判断是否需要保留现场继续复核。
+
+目录名、分支年龄和 agent 会话是否关闭都不能证明可删除。
+
+## 验证失败时
+
+- 同一失败第二次出现，停止盲重试，重新检查假设、环境和命令名。
+- 门禁要求机器可读 metadata 时，补正确留痕并触发新事件；不要用人工确认绕过可修复的格式问题。
+- 失败发生在生产写入前，明确说“尚未影响生产”；发生在切流后，先确认当前 active release 和回滚边界。
+- 任何未验证项保持 `pending`，不要为了摘要好看把它降格成 warning。

package/template/vendor/khazix-skills/neat-freak/scripts/audit-inventory.sh

@@ -0,0 +1,106 @@
+#!/usr/bin/env bash
+# Read-only inventory for neat-freak. Prints metadata and paths only; never reads file contents.
+
+set -euo pipefail
+
+usage() {
+  echo "usage: $0 <project-root>" >&2
+  exit 64
+}
+
+[[ $# -eq 1 ]] || usage
+[[ -d "$1" ]] || { echo "[ERR] project root is not a directory: $1" >&2; exit 66; }
+
+PROJECT_ROOT="$(cd "$1" && pwd -P)"
+SEEN_RULE_FILES=$'\n'
+
+section() {
+  printf '\n## %s\n' "$1"
+}
+
+file_size() {
+  local file="$1"
+  local lines bytes
+  lines="$(wc -l < "$file" | tr -d ' ')"
+  bytes="$(wc -c < "$file" | tr -d ' ')"
+  printf '%s\tlines=%s\tbytes=%s\n' "$file" "$lines" "$bytes"
+}
+
+describe_rule_file() {
+  local file="$1"
+  case "$SEEN_RULE_FILES" in
+    *$'\n'"$file"$'\n'*) return ;;
+  esac
+  SEEN_RULE_FILES+="$file"$'\n'
+  if [[ -L "$file" ]]; then
+    local target state
+    target="$(readlink "$file")"
+    if [[ -e "$file" ]]; then state="valid"; else state="broken"; fi
+    printf '%s\tsymlink=%s\tstate=%s\n' "$file" "$target" "$state"
+  elif [[ -f "$file" ]]; then
+    file_size "$file"
+  fi
+}
+
+printf '# neat-freak inventory v2\n'
+printf 'project_root=%s\n' "$PROJECT_ROOT"
+printf 'generated_at=%s\n' "$(date -u '+%Y-%m-%dT%H:%M:%SZ')"
+
+section "platform-directories"
+# Common agent home dirs; nonexistent ones are skipped silently.
+for dir in "$HOME/.claude" "$HOME/.codex" "$HOME/.cursor" "$HOME/.gemini" \
+  "$HOME/.qoder" "$HOME/.trae" "$HOME/.iflow" "$HOME/.codebuddy"; do
+  [[ -d "$dir" ]] && printf '%s\n' "$dir"
+done
+
+section "other-agent-rule-artifacts"
+# Platform-specific rule forms at the project root (existence only).
+for rel in .cursorrules .windsurfrules .cursor/rules .qoder .trae .iflow; do
+  [[ -e "$PROJECT_ROOT/$rel" ]] && printf '%s\n' "$PROJECT_ROOT/$rel"
+done
+true
+
+section "git"
+if git -C "$PROJECT_ROOT" rev-parse --show-toplevel >/dev/null 2>&1; then
+  GIT_ROOT="$(git -C "$PROJECT_ROOT" rev-parse --show-toplevel)"
+  printf 'git_root=%s\n' "$GIT_ROOT"
+  printf 'branch=%s\n' "$(git -C "$PROJECT_ROOT" branch --show-current 2>/dev/null || true)"
+  printf 'head=%s\n' "$(git -C "$PROJECT_ROOT" rev-parse HEAD)"
+  printf 'status_entries=%s\n' "$(git -C "$PROJECT_ROOT" status --porcelain=v1 | wc -l | tr -d ' ')"
+  printf 'worktrees=%s\n' "$(git -C "$PROJECT_ROOT" worktree list --porcelain | awk '$1 == "worktree" {n++} END {print n+0}')"
+else
+  printf 'git_root=none\n'
+fi
+
+section "rule-chain-candidates"
+cursor="$PROJECT_ROOT"
+while :; do
+  for rel in AGENTS.override.md AGENTS.md CLAUDE.md CLAUDE.local.md .claude/CLAUDE.md; do
+    describe_rule_file "$cursor/$rel"
+  done
+  [[ "$cursor" == "/" ]] && break
+  parent="$(dirname "$cursor")"
+  [[ "$parent" == "$cursor" ]] && break
+  cursor="$parent"
+done
+for file in \
+  "$HOME/.codex/AGENTS.override.md" \
+  "$HOME/.codex/AGENTS.md" \
+  "$HOME/.claude/CLAUDE.md"; do
+  describe_rule_file "$file"
+done
+
+section "project-markdown"
+find "$PROJECT_ROOT" \
+  \( -name .git -o -name node_modules -o -name .next -o -name dist -o -name build -o -name .venv -o -name venv -o -name __pycache__ -o -name target -o -name vendor -o -name .turbo -o -name .cache \) -prune \
+  -o -type f \( -name '*.md' -o -name '*.mdx' \) -print \
+  | LC_ALL=C sort
+
+section "project-markdown-count"
+find "$PROJECT_ROOT" \
+  \( -name .git -o -name node_modules -o -name .next -o -name dist -o -name build -o -name .venv -o -name venv -o -name __pycache__ -o -name target -o -name vendor -o -name .turbo -o -name .cache \) -prune \
+  -o -type f \( -name '*.md' -o -name '*.mdx' \) -print \
+  | awk 'END {print NR+0}'
+
+section "root-entries"
+find "$PROJECT_ROOT" -mindepth 1 -maxdepth 1 -print | LC_ALL=C sort

package/template/workflows/person/INDEX.md

@@ -0,0 +1,12 @@
+---
+id: person/index
+type: workflow-index
+workflow: person
+auto_generated: true
+---
+
+# person — Work Index
+
+> 本文件由 `generate-index.mjs` 自动生成，**禁止手动编辑**。
+
+- **M-mao-zedong-cognitive-os** — 毛泽东认知操作系统：以毛泽东方法论为底座的问题诊断、战略制定与行动规划咨询

package/template/workflows/person/M-mao-zedong-cognitive-os/M-mao-zedong-cognitive-os.md

@@ -9,81 +9,80 @@ keywords: [毛泽东, 毛选, 矛盾分析, 战略, 组织, 咨询]
 
 # 毛泽东 · 认知操作系统
 
-本入口把“分析问题—制定战略—组织行动”组织为渐进披露的咨询流程。产物写入当前 `person/changes/<change>/`。
-
-## 阶段
-
-```xml
-<sequence>
-  <phase id="activate" order="1">
-    <instructions root="workflow" path="M-mao-zedong-cognitive-os/activate.md" />
-    <artifact root="change" path="problem-statement.md" />
-    <completion>首次激活声明已执行，问题陈述无 TODO。</completion>
-  </phase>
-  <phase id="diagnose" order="2">
-    <instructions root="workflow" path="M-mao-zedong-cognitive-os/diagnose.md" />
-    <artifact root="change" path="analysis.md" />
-    <completion>至少两个诊断模型已应用，分析无 TODO。</completion>
-  </phase>
-  <phase id="strategize" order="3">
-    <instructions root="workflow" path="M-mao-zedong-cognitive-os/strategize.md" />
-    <artifact root="change" path="strategy.md" />
-    <completion>主要矛盾和战略框架已确认。</completion>
-  </phase>
-  <phase id="mobilize" order="4">
-    <instructions root="workflow" path="M-mao-zedong-cognitive-os/mobilize.md" />
-    <artifact root="change" path="action-plan.md" />
-    <completion>行动、责任与反馈机制已明确。</completion>
-  </phase>
-  <phase id="deliver" order="5">
-    <instructions root="workflow" path="M-mao-zedong-cognitive-os/deliver.md" />
-    <template root="workflow" path="_templates/mao-consultation-output-template.md" />
-    <artifact root="change" path="consultation-output.md" />
-    <completion>综合输出无 TODO，并经用户确认。</completion>
-  </phase>
-</sequence>
-```
-
-## 依赖
-
-```xml
-<dependencies>
-  <dependency kind="hard" from="diagnose" to="activate" />
-  <dependency kind="hard" from="strategize" to="diagnose" />
-  <dependency kind="hard" from="mobilize" to="strategize" />
-  <dependency kind="hard" from="deliver" to="mobilize" />
-</dependencies>
-```
-
-## 状态扩展字段
-
-```xml
-<state-schema>
-  <field name="problem_type" type="string" />
-  <field name="primary_framework" type="string" />
-  <field name="models_applied" type="array" />
-  <field name="frameworks_applied" type="array" />
-  <field name="methods_applied" type="array" />
-  <field name="quotes_cited" type="array" />
-  <field name="consultation_status" type="activating|diagnosing|strategizing|mobilizing|delivering|completed" />
-</state-schema>
-```
-
-## 状态转移
-
-```xml
-<transitions>
-  <transition from="activate" to="diagnose" />
-  <transition from="diagnose" to="strategize" />
-  <transition from="strategize" to="mobilize" />
-  <transition from="mobilize" to="deliver" />
-  <transition from="deliver" to="finalize">
-    <command root="commands" path="finalize.md" />
-    <when>用户确认综合咨询输出。</when>
-  </transition>
-</transitions>
-```
+本入口把"分析问题—制定战略—组织行动"组织为渐进披露的咨询流程。产物写入当前 `person/changes/<change>/`。
+
+## 流程
+
+### 1. 激活与问诊
+
+委托给 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/activate.md</Path>`。输出首次激活声明，通过开口三问摸清用户处境，判定问题类型并匹配主框架。
+
+产物：`<Path>{roots.state}/person/changes/{change}/problem-statement.md</Path>`
+
+**完成标准**：首次激活声明已输出，至少已追问 2 个开口问题且用户已回应，问题类型与主框架已匹配，problem-statement.md 六段均已填写无残留 `[TODO:]`。
+
+### 2. 诊断分析
+
+依赖步骤 1 的 problem-statement.md。委托给 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/diagnose.md</Path>`。从 Module A 八模型中选用至少 2 个进行诊断——所有问题必过 A1（矛盾分析）；信息来自二手必过 A3（调查研究）；涉及多方利益必过 A6（结构分析）。
+
+产物：`<Path>{roots.state}/person/changes/{change}/analysis.md</Path>`
+
+**完成标准**：已应用至少 2 个 Module A 模型，每个模型结论带条件与局限，主要矛盾已明确写出且带论证，analysis.md 无残留 `[TODO:]`。
+
+### 3. 战略制定
+
+依赖步骤 2 的 analysis.md。委托给 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/strategize.md</Path>`。沿元框架流水线（定性→定向→站位→时间→投放→运用）展开主框架，必要时补充辅助框架。
+
+产物：`<Path>{roots.state}/person/changes/{change}/strategy.md</Path>`
+
+**完成标准**：主框架已选定并充分展开，阶段划分清晰（至少分两步），有明确的关键战役判断，strategy.md 无残留 `[TODO:]`。
+
+### 4. 组织行动
+
+依赖步骤 3 的 strategy.md。委托给 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/mobilize.md</Path>`。将战略转化为具体行动方案——谁来干、干什么、什么时候干完、干到什么程度算好、干砸了怎么办。
+
+产物：`<Path>{roots.state}/person/changes/{change}/action-plan.md</Path>`
+
+**完成标准**：行动、责任与反馈机制已明确，action-plan.md 无残留 `[TODO:]`。
+
+### 5. 综合交付
+
+依赖前四步全部产物。委托给 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/deliver.md</Path>`。按模板 `../_templates/mao-consultation-output-template.md` 整合为连贯的教员第一人称咨询输出——五拍论证节奏、收尾四动作、引用纪律、反模式检查和内在张力标注。
+
+产物：`<Path>{roots.state}/person/changes/{change}/consultation-output.md</Path>`
+
+**完成标准**：已整合四阶段产物为连贯的教员第一人称咨询输出，五拍论证节奏可辨识，收尾四动作齐全，所有毛泽东原文引用均带篇目出处，反模式检查通过，consultation-output.md 无残留 `[TODO:]`。
+
+## 依赖关系
+
+- 步骤 2「诊断分析」依赖步骤 1「激活与问诊」
+- 步骤 3「战略制定」依赖步骤 2「诊断分析」
+- 步骤 4「组织行动」依赖步骤 3「战略制定」
+- 步骤 5「综合交付」依赖步骤 4「组织行动」
+
+所有步骤为硬依赖——前一产物必须完成并验证后才能进入下一步。
+
+## 状态追踪
+
+咨询过程中维护以下状态字段，记录在 `<Path>{roots.state}/person/status.json</Path>` 中：
+
+- **`problem_type`**（字符串）—— 问题类型，从激活阶段的问题类型表中选定
+- **`primary_framework`**（字符串）—— 匹配的主框架及篇目编号
+- **`models_applied`**（数组）—— 诊断阶段已应用的 Module A 模型列表
+- **`frameworks_applied`**（数组）—— 战略阶段已应用的 Module B 框架列表
+- **`methods_applied`**（数组）—— 组织阶段已应用的 Module C 方法列表
+- **`quotes_cited`**（数组）—— 已引用的毛泽东原话及出处
+- **`consultation_status`**（字符串）—— 当前阶段：`activating` → `diagnosing` → `strategizing` → `mobilizing` → `delivering` → `completed`
 
 ## 渐进披露
 
 角色、声音、模型和引用规则继续由各 phase 文件及其相对引用拥有；未进入 phase 时不加载对应材料。
+
+| 文件 | 触发条件 |
+|------|----------|
+| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/activate.md</Path>` | 步骤 1「激活与问诊」进入时 |
+| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/diagnose.md</Path>` | 步骤 2「诊断分析」进入时 |
+| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/strategize.md</Path>` | 步骤 3「战略制定」进入时 |
+| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/mobilize.md</Path>` | 步骤 4「组织行动」进入时 |
+| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/deliver.md</Path>` | 步骤 5「综合交付」进入时 |
+| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/books/README.md</Path>` | 需要查原文时——引语库 `references/research/15-quote-bank.md` 映射篇目编号到 books 目录 |

package/template/workflows/specdev/D-diagnose-bugs/D-diagnose-bugs.md

@@ -0,0 +1,85 @@
+---
+id: specdev/diagnose-bugs
+type: workflow-entry
+workflow: specdev
+name: 诊断
+description: 针对疑难 bug 建立诊断循环——构建紧凑反馈回路、复现最小化、可证伪假设排名、插桩定位根因，确认后移交 I-implement 修复。
+keywords: [诊断, 调试, bug, 反馈回路, 假设, 根因分析]
+---
+
+# 诊断
+
+针对疑难 bug 的诊断规程。先建立紧凑的反馈回路锚定症状，再通过可证伪假设排名定位根因，确认后移交 I-implement 执行修复。仅在明确有理由时才跳过阶段。
+
+在开始诊断之前，读取当前变更的上下文与架构决策：
+
+- **CONTEXT.md** —— 项目领域术语与概念：`<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`
+- **ADR.md** —— 架构决策记录：`<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`
+
+如果这些文件不存在，先运行 `<Path>{roots.workflows}/specdev/W-wayfinder/W-wayfinder.md</Path>` 或询问用户以建立上下文。
+
+## 流程
+
+### 1. 加载上下文
+
+读取 `<Path>{roots.state}/specdev/status.json</Path>` 确认活跃变更。读取 CONTEXT.md 获取领域词汇表——使用其中已定义的术语。读取 ADR.md 了解已做出的架构决策——诊断过程中涉及的模块若与已有 ADR 相关，在假设中引用。
+
+**完成标准**：活跃变更已确认，领域词汇表和架构决策已加载。`{change}` 已确定。
+
+### 2. 构建反馈回路
+
+委托给 `<Path>{roots.workflows}/specdev/D-diagnose-bugs/feedback-loop-techniques.md</Path>`。构建一个紧凑的通过/失败信号——一条命令，确定性、秒级、agent 可无人值守运行。在此投入不成比例的精力：反馈回路是诊断的超能力。如果确实无法构建回路，向用户明确说明已尝试的方法并请求访问复现环境或捕获产物。
+
+**完成标准**：反馈回路紧凑且具备变红能力——一条命令已运行并通过/失败输出验证，确定性、秒级、agent 可运行。回路断言的是用户的确切症状，而非"运行不出错"。
+
+### 3. 复现与最小化
+
+运行回路，确认它产生用户描述的故障模式。然后逐元素削减输入、调用者、配置和数据——每次削减后重新运行回路——只保留对故障有负载作用的部分。
+
+**完成标准**：回路已复现用户症状。复现场景已最小化——每个剩余元素都有负载作用，移除任何一个都会使回路变绿。
+
+### 4. 提出诊断计划
+
+委托给 `<Path>{roots.workflows}/specdev/D-diagnose-bugs/hypothesis-format.md</Path>`。生成 3-5 个排名假设，每个假设必须是可证伪的——陈述其预测。将排名列表作为诊断计划呈现给用户确认。用户可能拥有立即重排名的领域知识。如果用户 AFK，按排名继续。
+
+**完成标准**：3-5 个可证伪假设已排名并作为诊断计划呈现给用户。用户已确认或 AFK 下按排名继续。
+
+### 5. 插桩验证
+
+委托给 `<Path>{roots.workflows}/specdev/D-diagnose-bugs/instrumentation-rules.md</Path>`。每个探测映射到诊断计划中的一个具体预测。每次只改变一个变量。使用调试器/REPL 优先于日志。所有调试日志使用 `[DEBUG-xxxx]` 唯一前缀标记。
+
+**完成标准**：根因已通过插桩确认——某个假设的预测已验证，其他假设已排除。所有探测结果与诊断计划中的预测对应。
+
+### 6. 移交修复
+
+调用 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 执行修复。移交以下信息：
+
+- **根因描述**——哪个假设被确认，通过什么探测验证
+- **最小复现场景**——阶段 3 产出的最小化复现，可直接转为回归测试
+- **建议的修复接缝**——在哪个模块/接口处修复最合适
+
+修复、回归测试编写和提交由 I-implement 完成。如果不存在正确的测试缝合点，将此发现记录到 `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>` 并在步骤 7 的事后分析中提出架构改进建议。
+
+**完成标准**：I-implement 已启动，根因描述、最小复现、建议修复接缝已移交。
+
+### 7. 清理与复盘
+
+委托给 `<Path>{roots.workflows}/specdev/D-diagnose-bugs/cleanup-postmortem.md</Path>`。移除所有 `[DEBUG-xxxx]` 标记的插桩代码，删除一次性原型。在 `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>` 中记录：被证实的假设、根因、修复提交。执行事后分析——什么本可以预防这个 bug？如果涉及架构变更，提出改进建议。
+
+**完成标准**：调试产物已清理（grep `[DEBUG-` 无残留），根因已记录到 LOG.md，预防建议已提出。
+
+---
+
+## 子文件引用
+
+| 文件 | 内容 | 触发条件 |
+|------|------|---------|
+| `<Path>{roots.workflows}/specdev/D-diagnose-bugs/feedback-loop-techniques.md</Path>` | 10 种反馈回路构建技术、收紧回路、非确定性 bug 策略、无法构建回路时的升级路径、最小化协议 | 步骤 2「构建反馈回路」和步骤 3「复现与最小化」进入时 |
+| `<Path>{roots.workflows}/specdev/D-diagnose-bugs/hypothesis-format.md</Path>` | 可证伪假设格式模板、排名规则、用户 Plan 呈现模板、AFK 默认行为 | 步骤 4「提出诊断计划」进入时 |
+| `<Path>{roots.workflows}/specdev/D-diagnose-bugs/instrumentation-rules.md</Path>` | 探测映射规则、工具偏好、`[DEBUG-xxxx]` 标记约定、性能分支处理 | 步骤 5「插桩验证」进入时 |
+| `<Path>{roots.workflows}/specdev/D-diagnose-bugs/cleanup-postmortem.md</Path>` | 清理检查清单、事后分析问题、预防建议记录格式 | 步骤 7「清理与复盘」进入时 |
+
+## 依赖关系
+
+- 依赖 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 执行修复——步骤 6 移交已确认的根因和最小复现
+- 依赖 `<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>` 和 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 提供领域上下文——步骤 1 加载