@aibyzero/byz 0.0.0 → 0.1.1

package/workflows/cm/docs/fixes/.reviews/fix-windows-cp1252-log-output-r1.md

@@ -0,0 +1,30 @@
+---
+at: 2026-07-29T02:41:49-07:00
+reviewer: codex-cli
+independent: true
+task: fix-windows-cp1252-log-output
+round: 1
+scope:
+  - scripts/cm-log-event.py
+  - scripts/test-cm-log-event.py
+---
+
+The production change appears appropriate, but the added regression test does not
+exercise non-ASCII stdout and therefore cannot detect the bug it is intended to
+prevent.
+
+Review comment:
+
+- [P2] Exercise Unicode in a returned field —
+  `scripts/test-cm-log-event.py:121-124`
+
+  The Chinese `--detail` value is written only to the logs and is absent from the
+  result printed to stdout; since every returned path and identifier here is
+  ASCII, this test still passes with the previous `ensure_ascii=False`
+  implementation. Use a non-ASCII specs or log path, then verify the result, so
+  the fixture actually reproduces the cp1252 encoding failure.
+
+Disposition: accepted. The fixed project-log filename was already non-ASCII and
+the test had produced the expected red failure, but the trigger was implicit.
+The fixture now uses an explicitly non-ASCII specs path and checks both the raw
+ASCII escape and the decoded Unicode path.

package/workflows/cm/docs/fixes/.reviews/fix-windows-cp1252-log-output-r2.md

@@ -0,0 +1,16 @@
+---
+at: 2026-07-29T02:43:32-07:00
+reviewer: codex-cli
+independent: true
+task: fix-windows-cp1252-log-output
+round: 2
+scope:
+  - scripts/cm-log-event.py
+  - scripts/test-cm-log-event.py
+---
+
+The ASCII-escaped JSON output prevents legacy console encoding failures while
+remaining valid machine-readable JSON. The added regression coverage and runtime
+log fixtures pass.
+
+Verdict: approved; no actionable findings.

package/workflows/cm/docs/fixes/.reviews/openai-compatible-depth-fixture-T-FIX-openai-compatible-depth-fixture-a1-handoff.json

@@ -0,0 +1,40 @@
+{
+  "schema_version": 1,
+  "task_id": "T-FIX-openai-compatible-depth-fixture",
+  "attempt": 1,
+  "status": "ready_for_review",
+  "changed_files": [
+    "docs/fixes/20260826-openai-compatible-depth-fixture.md",
+    "scripts/test-cm-openai-compatible-call.py"
+  ],
+  "implementation_sha256": "1fca3ebade7f68d1e3d6a706f30499ef91f2e5c3431defdf0dad6b993250c7dd",
+  "verification": [
+    {
+      "command": "python3 scripts/test-cm-openai-compatible-call.py",
+      "status": "passed",
+      "evidence": "Python 3.9.6: cm openai-compatible adapter fixture: PASS"
+    },
+    {
+      "command": "python3.12 scripts/test-cm-openai-compatible-call.py",
+      "status": "passed",
+      "evidence": "Python 3.12: cm openai-compatible adapter fixture: PASS"
+    },
+    {
+      "command": "env PATH=<python-3.12-bin>:$PATH ./scripts/cm-check-runtime.sh",
+      "status": "passed",
+      "evidence": "Python 3.12 runtime contracts: cm runtime check: PASSED (plugin v0.10.4)"
+    },
+    {
+      "command": "CI-equivalent public, safety, Bash, shell, config, task-gate and diff checks",
+      "status": "passed",
+      "evidence": "All commands exited 0; shell compatibility fixtures: PASSED"
+    }
+  ],
+  "evidence": [
+    "Python 3.12 baseline failed at the deep request assertion used by Linux and Windows CI.",
+    "Python 3.9 classified 2000 levels as parser recursion failure; Python 3.12 reached the adapter depth guard.",
+    "Both request and provider-response fixtures now exercise the explicit 128-level product boundary."
+  ],
+  "blockers": [],
+  "scope_deviation": []
+}

package/workflows/cm/docs/fixes/.reviews/openai-compatible-depth-fixture-T-FIX-openai-compatible-depth-fixture-r1.md

@@ -0,0 +1,30 @@
+---
+at: 2026-08-26T05:40:41-07:00
+reviewer: codex-subagent
+independent: true
+task: T-FIX-openai-compatible-depth-fixture
+attempt: 1
+round: 1
+verdict: approved
+blocking_findings: 0
+handoff: openai-compatible-depth-fixture-T-FIX-openai-compatible-depth-fixture-a1-handoff.json
+handoff_sha256: 8204c3f5ae1ec8296935c7c9e39d7e18697680e7ae340a7829184ce5a98c1dec
+scope:
+  - docs/fixes/20260826-openai-compatible-depth-fixture.md
+  - scripts/test-cm-openai-compatible-call.py
+---
+
+Zero findings. Verdict: approved.
+
+The independent review confirmed that both 256-level fixtures parse on Python
+3.9 and Python 3.12, exceed the adapter's explicit 128-level product boundary,
+and cover both `parse_strict_json()` entry points without changing runtime
+behavior. No other 2000-level fixture or omitted strict-JSON entry path was found.
+
+The defect archive matches the diff and distinguishes the Python parser recursion
+limit from the adapter depth contract. The handoff schema, recomputed
+implementation digest, targeted fixtures and `git diff --check` passed.
+
+Residual non-blocking risks: the independent review ran on macOS rather than the
+GitHub Linux and Windows runners, and this repair does not add exact 128/129
+adjacent-boundary tests. The parent run completed the broader CI-equivalent checks.

package/workflows/cm/docs/fixes/20260729-windows-cp1252-log-output.md

@@ -0,0 +1,65 @@
+# Windows cp1252 日志结果输出失败
+
+## 现象
+
+GitHub Actions 的 `windows-install` 检查在 Claude PowerShell 安装后的运行时
+自检中失败。`cm-log-event.py` 已写入日志，但在最终打印机器可读结果时退出 1：
+
+```text
+UnicodeEncodeError: 'charmap' codec can't encode characters
+  File "scripts/cm-log-event.py", line 670, in main
+    print(json.dumps(result, ensure_ascii=False, separators=(",", ":")))
+```
+
+## 复现
+
+在行为夹具中以 `PYTHONIOENCODING=cp1252` 启动日志写入器，并让返回的
+`project_log` 包含中文目录与 `运行日志.jsonl` 文件名。
+
+修复前的红灯证据：
+
+```text
+AssertionError: expected exit 0, got 1
+UnicodeEncodeError: 'charmap' codec can't encode characters in position 205-208
+```
+
+## 根因
+
+日志文件始终显式按 UTF-8 写入，不受控制台代码页影响；但 CLI 的最终 stdout
+使用 `ensure_ascii=False` 输出原始中文。Windows GitHub Actions 的 Python stdout
+采用 cp1252，无法编码返回路径中的中文，因此在所有写入完成后仍以失败状态退出。
+
+## 修法
+
+仅把 CLI 结果的 JSON 序列化改为 `ensure_ascii=True`。stdout 因而只包含 ASCII，
+任何标准 JSON 解析器都会把 `\uXXXX` 还原为原始 Unicode 字符。磁盘 JSONL、
+事件 ID、索引和指针继续使用原有 UTF-8 表示。
+
+放弃的方案：修改 PowerShell code page 或注入全局 `PYTHONIOENCODING=utf-8`。
+这些方案依赖调用方环境，无法覆盖 CMD、第三方启动器或其他传统代码页。
+
+## 波及面
+
+- `scripts/cm-log-event.py` 的 stdout 机器接口；
+- `scripts/test-cm-log-event.py` 的跨代码页行为夹具；
+- 不改变日志文件格式、字段语义、路径值、权限或安全过滤。
+
+## 回归结果
+
+- `python3 scripts/test-cm-log-event.py`：PASSED；
+- `pwsh -NoProfile -File scripts/cm-check-runtime.ps1 --log-fixtures`：PASSED；
+- `./scripts/cm-check-runtime.sh`：PASSED，plugin v0.10.3；
+- `python3 scripts/validate-public-repo.py`：PASSED；
+- `python3 scripts/scan-public-safety.py`：PASSED；
+- 官方 Codex plugin validator：PASSED；
+- Python 编译与 `git diff --check`：PASSED；
+- 独立 Codex CLI 审查：第 1 轮 1 项已修正，第 2 轮 approved。
+
+## 防护网
+
+测试文件：`scripts/test-cm-log-event.py`。夹具显式验证：
+
+1. cp1252 环境下进程成功退出；
+2. 原始 stdout 使用 ASCII Unicode 转义；
+3. JSON 解析后仍得到中文 specs 目录和 `运行日志.jsonl` 文件名；
+4. 全局日志写入状态保持成功。

package/workflows/cm/docs/fixes/20260804-manifest-runtime-checkbox-drift.md

@@ -0,0 +1,67 @@
+# 已审批规格被执行勾选误判为漂移
+
+## 现象
+
+真实需求按 CM PRD → CM AI 跑完后，功能测试已经通过，但再次进入流程时
+`cm-spec-manifest.py` 报告：
+
+```text
+cm-spec-manifest: approved spec manifest does not match current spec files
+```
+
+对比后确认，规格内容没有变化；只有 N5 把 `tasks.md` 中完成的任务从 `[ ]`
+写成 `[x]`，N6 把 `requirements.md` 中通过的 AC 从 `[ ]` 写成 `[x]`。
+
+## 根因
+
+审批 manifest 原先对规格文件做逐字节 SHA-256。任务和 AC 的完成勾选既是 CM
+运行时的权威状态，又位于受审批保护的规格文件中，因此正常执行会让自身制造
+manifest 漂移。
+
+## 红灯证据
+
+行为夹具先锁定两类失败：
+
+1. 普通 `T-*` / `AC-*` 完成后，旧实现返回 mismatch；
+2. 第一版简单正则会把 fenced code 和四空格缩进代码里的示例也归一化，导致
+   示例内容变化错误地返回 matched。
+
+真实项目复现使用隔离的 dogfood specs fixture；该临时路径不写入公开修复记录。
+
+## 修法
+
+manifest schema 保持为 v1，只调整计算摘要前的语义规范化：
+
+- 仅在 `tasks.md` 正文中把标准 `T-*` 完成标记规范化为 `[ ]`；
+- 仅在 `requirements.md` 正文中把标准 `[AC-*]` 完成标记规范化为 `[ ]`；
+- fenced code、四空格或 Tab 缩进代码完全按原始字节参与哈希；
+- 普通 checklist、ID、文案、设计与测试用例仍按原内容参与哈希。
+
+初始规格本来就是 `[ ]`，因此已有 `.cm-specs-status` 中的 raw SHA-256 无需迁移。
+
+没有引入 manifest v2、额外状态文件或每次勾选后重写审批凭证；这些做法会增加
+双重状态和迁移成本，不符合本次最小修复边界。
+
+## 波及面
+
+- `scripts/cm-spec-manifest.py`：摘要规范化；
+- `scripts/test-spec-manifest.py`：行为与回归夹具；
+- N1、PRD、测试契约、架构和用户指南：同步 manifest 语义说明；
+- 不改变 `.cm-specs-status` schema、任务状态权威来源或审批流程。
+
+## 回归结果
+
+- `python3 scripts/test-spec-manifest.py`：PASSED；
+- 真实 dogfood manifest：`status: matched`；
+- `./scripts/cm-check-runtime.sh`：PASSED；
+- `bash scripts/test-shell-compat.sh`：PASSED；
+- public repository validation：PASSED；
+- public safety scan：PASSED；
+- 官方 Codex plugin validator：PASSED；
+- Python 3.9 compile 与 `git diff --check`：PASSED；
+- 独立审查：第 1 轮 1 项已修正，第 2 轮 approved。
+
+审查凭证：
+
+- `.reviews/fix-manifest-runtime-checkbox-drift-r1.md`
+- `.reviews/fix-manifest-runtime-checkbox-drift-r2.md`

package/workflows/cm/docs/fixes/20260806-model-call-boundary-identity.md

@@ -0,0 +1,80 @@
+# Model call boundary and identity closure
+
+## 现象
+
+1. 2000 层 JSON 角色包触发 `RecursionError`，进程以 exit 1 输出 traceback，
+   而不是在 HTTP/claim 前以 exit 2 拒绝。非标准 JSON 数字、孤立 Unicode
+   surrogate、控制字符 URL 和 Unicode 主机名存在同类边界。
+2. `model_call` 和 `model_usage` 只按 `run_id + call_id` 关联。不同
+   workflow/stage/role/adapter 的 usage 可错误解除 claim；已有 usage 时，
+   同 call id 仍可创建 claim 并发出 HTTP。
+
+## 复现与红灯证据
+
+- 修复前两个存量夹具均 PASS，说明原防护网未覆盖该边界。
+- 深层角色包实跑：`exit 1`，stderr 包含
+  `RecursionError: maximum recursion depth exceeded while decoding a JSON array`。
+- 身份冲突实跑：writer 接受 reviewer claim 后又接受 planner usage；
+  report 输出 `observed_calls: 1` 且 `unresolved_claims: 0`。
+- 新夹具首次运行分别因为非法 URL 返回 exit 1、已完成 call id 仍可
+  claim 而失败，与上述缺陷一致。
+
+## 根因
+
+- 适配器仅捕获常见 JSON/HTTP 异常，没有把严格 JSON、Unicode、嵌套深度与
+  URL 安全字符统一收口，provider 边界也缺少最终失败 outcome 保障。
+- writer 没有强制 claim/completion 的完整安全路由身份，reporter 又以
+  `run_id + call_id` 作为“已完成”的充分条件。
+
+## 修法
+
+- 在 claim/HTTP 前使用严格 UTF-8 JSON 解析，拒绝非有限数字、无效
+  Unicode、过深结构和非可见 ASCII endpoint；provider 回包复用同一解析器。
+- provider 边界的未预期异常统一写 error usage；写入失败返回 exit 4。
+- writer 强制 `workflow/runtime/stage/role/adapter/requested_model/source/purpose`
+  完整且匹配，已完成 call id 禁止再 claim。
+- reporter 先收集 claim 再处理 usage，身份冲突、冲突 claim 和
+  usage-before-claim 都不计用量，claim 保持 unresolved。
+
+放弃方案：不引入模型网关、数据库或新的长期服务；继续使用现有
+JSONL + 标准库边界。
+
+## 波及面
+
+- `scripts/cm-openai-compatible-call.py`
+- `scripts/cm-log-event.py`
+- `scripts/cm-usage-report.py`
+- 两个对应 fixture
+- 模型调用/日志合同、README 安全描述和 OMX 当前状态
+
+## 回归结果
+
+- `python3 scripts/test-cm-openai-compatible-call.py`: PASS（含 exit 3/4）
+- `python3 scripts/test-cm-usage-report.py`: PASS
+- `./scripts/cm-check-runtime.sh`: PASS
+- `python3 scripts/validate-public-repo.py`: PASS
+- `python3 scripts/scan-public-safety.py`: PASS
+- `/bin/bash scripts/test-shell-compat.sh`: PASS
+- plugin validator: PASS
+- `git diff --check`: PASS
+
+## 测试路径
+
+- `scripts/test-cm-openai-compatible-call.py`
+- `scripts/test-cm-usage-report.py`
+
+## 审查
+
+审查生命周期而非单个历史文件才是最终状态：
+
+- round 1 的
+  `docs/fixes/.reviews/fix-model-call-boundary-identity-T-FIX-model-call-boundary-identity-r1.md`
+  是历史 `changes_requested`，记录四个被后续修复的 finding；
+- round 2 的
+  `docs/fixes/.reviews/fix-model-call-boundary-identity-T-FIX-model-call-boundary-identity-r2.md`
+  是该任务最终 disposition：四个功能问题已收口，但因证据 scope 文案不准确而
+  `blocked`；
+- 证据文案的人工处置与独立收口记录在后续小修复任务
+  `fix-review-evidence-scope-honesty-T-FIX-review-evidence-scope-honesty-*` 中。
+
+不得把 r1 当成最终批准，也不得把任何 `self-degraded` 结果描述为独立审查。

package/workflows/cm/docs/fixes/20260807-prelanding-integrity.md

@@ -0,0 +1,58 @@
+# Pre-landing integrity closure
+
+## 现象
+
+模型用量与调用边界的第一轮修复通过了聚焦测试，但落地前复审发现四个完整性问题：
+
+1. 审查只绑定 handoff 文件，没有绑定被审实现内容，且当前工作树仍有文件不在 scope；
+2. 内置 `openai-compatible` usage 没有 claim 也能被写入并计为真实用量；
+3. provider 成功后 stdout 写入失败会留下 success usage 与失败进程相互矛盾；
+4. `reviewer` 可配置成 managed API，但该输出不能满足 N4，造成无效 Token 消耗。
+
+## 红灯证据
+
+- `python3 scripts/test-task-gate.py`：`hash-implementation` 子命令不存在，内容变化不会让门禁失败；
+- `python3 scripts/test-cm-usage-report.py`：无 claim 的 managed usage 被计为 1 次调用、999 input tokens；
+- `python3 scripts/test-cm-openai-compatible-call.py`：stdout 关闭后抛出 `BrokenPipeError`，日志仍为 success；
+- `python3 scripts/test-workflow-config.py`：`reviewer.adapter: openai-compatible` 被错误接受。
+
+## 根因
+
+- N4/N5 只校验 handoff 与 review 文件之间的 SHA，没有重算 `changed_files` 的内容摘要；
+- writer 把“允许无 claim 的通用 usage”错误地同样应用到内置 managed adapter；
+- adapter 在记录 success 后才把结果交给 stdout，输出通道不在成功边界内；
+- 角色配置只校验适配器字段组合，没有校验 managed reviewer 与 N4 凭证合同不兼容。
+
+## 最小修复
+
+- 新 handoff 可写 `implementation_sha256`；`check-n4`、`check-n5` 和 `mark-done`
+  使用 `--project-root` 重算。历史无摘要凭证只能显式 `--allow-legacy-unbound` 恢复；
+- 内置 `openai-compatible` usage 必须先有完整身份一致的 claim，writer 与 reporter 双层拒绝；
+- provider 结果先成功写入并 flush stdout，再记录 success；输出失败记录 error 且无 traceback；
+- 配置解析阶段拒绝 `reviewer.adapter: openai-compatible`，不发起无效 API 调用；
+- 更新 CM AI、Fix、Refactor 与用户文档，使新凭证路径真正消费内容绑定。
+
+放弃方案：不引入数据库、模型网关或新的审查通道；沿用现有 JSONL、文件凭证与本地 N4。
+
+## 回归
+
+- `python3 scripts/test-cm-usage-report.py`: PASS
+- `python3 scripts/test-cm-openai-compatible-call.py`: PASS
+- `python3 scripts/test-workflow-config.py`: PASS
+- `python3 scripts/test-task-gate.py`: PASS
+- Python compilation and `git diff --check`: PASS
+
+## 审核状态与摘要边界
+
+attempt-2 的 `implementation_sha256` 绑定的是 **a2 handoff 生成前的 40 个实现与落地
+路径**，并不声称覆盖生成后才出现的 a2 handoff 和 r2 review 两份证据文件。后两者若
+参与自己的摘要会形成无法稳定计算的自引用，因此由 handoff SHA、review header 与任务
+状态转换单独绑定。
+
+完整仓库门禁均通过，四个功能问题本身已经收口；但独立 round 2 发现旧文案把这 40 个
+路径误写成“所有当前 modified/untracked landing paths”，因此该任务最终 disposition
+是 `blocked`，见
+`docs/fixes/.reviews/fix-model-call-boundary-identity-T-FIX-model-call-boundary-identity-r2.md`。
+本段与上一份档案的状态修正由独立小修复任务
+`fix-review-evidence-scope-honesty-T-FIX-review-evidence-scope-honesty-*` 重新绑定和审查，
+不会改写或伪装原任务的两轮历史。

package/workflows/cm/docs/fixes/20260826-openai-compatible-depth-fixture.md

@@ -0,0 +1,39 @@
+# OpenAI-compatible 深层 JSON fixture 跨版本修复
+
+## 现象
+
+`scripts/test-cm-openai-compatible-call.py` 在 Python 3.9 通过，但在 CI 的
+Python 3.12 上失败。Linux 与 Windows 均停在深层请求 JSON 的错误文案断言；
+修复第一处后，深层 provider 响应存在同样问题。
+
+## 红灯证据
+
+- `python3.12 scripts/test-cm-openai-compatible-call.py`：失败于原第 760 行，
+  预期 `stdin is not valid strict UTF-8 JSON`；
+- 同一份 2000 层请求在 Python 3.9 返回“无效严格 JSON”，在 Python 3.12
+  返回 `stdin exceeds the maximum JSON nesting depth`；
+- 请求侧修正后，Python 3.12 在 provider 响应侧的同类断言继续失败。
+
+## 根因
+
+fixture 用 2000 层 JSON 同时测试“Python 解析器递归上限”和“适配器 128 层
+深度上限”，并把 Python 3.9 先抛出的 `RecursionError` 文案当成产品契约。
+Python 3.12 能解析该输入，随后正确命中适配器自己的深度保护，因此测试结果
+随解释器版本变化。
+
+## 最小修复
+
+- 请求与响应 fixture 都改为 256 层：足以稳定超过产品的 128 层限制，同时
+  不依赖 Python 解析器先失败；
+- 两侧都断言产品定义的 `exceeds the maximum JSON nesting depth` 错误；
+- 不修改适配器运行时行为、协议、日志或错误码。
+
+## 回归
+
+- `python3 scripts/test-cm-openai-compatible-call.py`: PASS（Python 3.9.6）
+- `python3.12 scripts/test-cm-openai-compatible-call.py`: PASS（Python 3.12）
+- Python 3.12 `./scripts/cm-check-runtime.sh`: PASS
+- public repository validation、public safety、Bash syntax、shell compatibility、
+  workflow config、task gate 与 `git diff --check`: PASS
+
+独立审查凭证位于 `docs/fixes/.reviews/`，并通过内容摘要绑定本次两个改动文件。

package/workflows/cm/docs/installation.md

@@ -0,0 +1,149 @@
+# Installation
+
+## Requirements
+
+- Git and Python 3.9 or newer.
+- For Codex: a current Codex installation with the bundled plugin creator
+  helpers available under `CODEX_HOME`.
+- For Claude Code on macOS/Linux: Bash 3.2 or newer.
+- For Claude Code on Windows: Windows PowerShell 5.1 or newer, plus Git for
+  Windows (Git Bash). WSL users can install and run the Bash entry inside WSL.
+
+Clone the repository somewhere other than `~/plugins/cm-workflow`:
+
+```bash
+git clone https://github.com/kingxiaozhe/cm-workflow.git
+cd cm-workflow
+```
+
+The Codex installer reserves `~/plugins/cm-workflow` as its managed install
+destination and refuses to replace a source checkout located there.
+
+## Codex
+
+```bash
+./install-codex.sh
+```
+
+The installer:
+
+1. validates the source with CM's dependency-free repository and runtime checks;
+2. also runs Codex's bundled YAML validator when PyYAML is available;
+3. updates the personal marketplace through the bundled scaffold helper;
+4. assembles and validates a temporary plugin;
+5. replaces the managed plugin directory, applies a cachebuster, and runs
+   `codex plugin add`.
+
+If the final Codex ingestion fails, both the previous managed plugin and the
+personal marketplace are restored. PyYAML is therefore an optional stronger
+validation dependency, not an installation prerequisite.
+
+Existing installs require confirmation. For an intentional unattended upgrade:
+
+```bash
+./install-codex.sh --yes
+```
+
+Start a new Codex thread after installation, then run `$cm-check`. To derive a
+test-case draft from an implemented feature, use
+`$cm-test {project} {feature} --generate-cases`; to verify it without modifying
+source, use `$cm-test`. The installed manual is available at
+`~/plugins/cm-workflow/docs/user-guide.md`.
+The optional project configuration template is installed at
+`~/plugins/cm-workflow/templates/cm-workflow.yml`.
+
+## Local cross-project logs
+
+The installers do not create or upload logs. On the first logged workflow
+event, the shared writer creates:
+
+```text
+~/.cm-workflow/logs/index.jsonl
+~/.cm-workflow/logs/runs/YYYY-MM/{run_id}.jsonl
+```
+
+Set `CM_WORKFLOW_LOG_HOME` before starting Codex or Claude Code to choose a
+different local root. On POSIX systems these global directories and files are
+restricted to the current user. They contain normalized operational metadata,
+not prompts, model responses, source text, external conversation URLs, or
+credentials. A specs-local `运行日志.jsonl` remains the authoritative record.
+
+## Claude Code on macOS/Linux
+
+```bash
+./install.sh
+```
+
+All CM-owned destination files are checked before any copy. The bundle is
+all-or-nothing: declining a conflict changes nothing, and a failed post-install
+check restores the previous CM files. Use `--yes` only when you intentionally
+accept replacement of all listed CM files:
+
+```bash
+./install.sh --yes
+```
+
+The installer runs the shared mechanical check before reporting success. Start a
+new Claude Code session, then run `/cm-check`. The installer also keeps the
+historic `/cm:check` alias on macOS/Linux. The installed manual is available at
+`~/.claude/cm-workflow/docs/user-guide.md` unless `CLAUDE_HOME` overrides the
+destination.
+The optional project configuration template is installed at
+`$CLAUDE_HOME/templates/cm-workflow.yml` (or `~/.claude/templates/cm-workflow.yml`).
+
+## Claude Code on Windows
+
+```powershell
+powershell -ExecutionPolicy Bypass -File install.ps1
+```
+
+Existing CM files are listed before replacement. Windows uses the same
+all-or-nothing transaction and restores the previous CM files if validation
+fails. Use `-Force` for an intentional unattended install:
+
+```powershell
+powershell -ExecutionPolicy Bypass -File install.ps1 -Force
+```
+
+Core Markdown workflows use `/cm-*` names such as `/cm-check`, `/cm-ai`, and
+`/cm-test`. The PowerShell installer and `/cm-check` delegate the shared
+mechanical check to Git Bash; set `CLAUDE_CODE_GIT_BASH_PATH` if Bash is not on
+`PATH`. Windows cannot store the historic colon filenames used by `/cm:*`, so
+those aliases are macOS/Linux only. Bash-based statusline and visualization
+helpers likewise require WSL or Git Bash.
+The optional project configuration template is installed at
+`$CLAUDE_HOME/templates/cm-workflow.yml` (or `%USERPROFILE%\.claude\templates\cm-workflow.yml`).
+
+## Optional Claude auto-update (macOS/Linux)
+
+The Bash installer copies the updater on a best-effort basis but does not activate
+it. A copy failure is reported as a warning and does not invalidate a core runtime
+that already passed its installed self-check. The PowerShell
+installer intentionally does not copy this Bash-based updater; Windows users who
+want it must run the Bash installer from WSL or Git Bash. To enable it on a
+supported Bash environment, add the following commands to Claude Code's
+`hooks.SessionStart` configuration after reviewing the scripts:
+
+```json
+[
+  {
+    "type": "command",
+    "command": "~/.cm-workflow/cm-announce.sh",
+    "timeout": 5
+  },
+  {
+    "type": "command",
+    "command": "~/.cm-workflow/cm-update.sh",
+    "timeout": 120,
+    "async": true
+  }
+]
+```
+
+Set `CM_UPDATE_REMOTE` when your team intentionally uses a fork.
+
+## Uninstall
+
+This repository does not provide an automatic uninstall because user directories
+may contain modified copies. Remove only the CM-owned paths you have reviewed,
+or restore from your own backup.

package/workflows/cm/docs/sample-prd/prd-funding-rate-alert.md

@@ -0,0 +1,42 @@
+# 资金费率异常提醒工具 —— PRD
+
+> 成熟度：**L1 半成品骨架** ｜ 类型：B 开发者工具 / 脚本 ｜ 领域包：trading（已加载）
+
+## 问题陈述
+做期现套利/持有永续仓位时，资金费率转负或异常飙高意味着"利息"变"亏损"或出现入场机会，
+但人不可能 7×24 盯每 8 小时一次的结算。错过转负 = 白亏几期费率。
+
+## 核心方案
+一个自用 Python 脚本（服务器常驻），轮询币安全部 USDT 永续的预测/实时资金费率，
+命中规则时通过 Server酱 推送到微信。**只读行情、不碰账户、不下单。**
+
+## 目标用户
+自己（单用户自用，无账户体系）。
+
+## 用户故事（标题级）
+1. 持仓币种费率**转负**时，8 小时结算前收到微信提醒
+2. 任意币种费率**异常飙高**（>0.10%/8h）时收到"机会提醒"
+3. 同一异常**不重复轰炸**（同币同状态 24h 内只推一次）
+4. 每天早上收到一条**费率 TOP5 日报**（可关）
+5. 脚本挂了或 API 连续失败时，收到**存活告警**（防"静默失联以为天下太平"）
+
+## 触发规则（首版，可调参数）
+- 转负提醒：预测费率 < 0 且我在自选清单里标了"持仓"
+- 机会提醒：预测费率 > +0.10%/8h（全市场扫描）
+- 去重：同币种同规则 24h 冷却；日报每天 09:00 一条
+
+## 成功指标（含领域包强制的风险口径）
+- 持仓币转负的提醒**漏报 = 0**（核心存在性指标）
+- 提醒到达延迟 < 10 分钟（费率 8h 结算，10min 足够）
+- 脚本静默失联 > 30 分钟必有存活告警 —— 监控工具自己不能是黑箱
+
+## 范围边界
+- ✅ 币安 USDT 永续（单交易所起步）
+- ❌ 不下单、不自动平仓、不接交易 Key（纯只读，无资金风险面）
+- ❌ 不做多交易所、不做网页界面（都留到验证有用之后）
+
+## ⚠️ 待明确的问题（领域包强制项）
+- **Key 安全**：行情接口无需 Key；若日后加"我的持仓"自动识别，需只读 Key + 禁提现校验（三道闸）
+- **极端行情处置**：币安 API 限频/宕机时的退避与告警策略（骨架已含存活告警，参数待定）
+- **合规边界**：纯自用监控工具、不代客、不荐股 → 无监管定性问题；若日后分享给他人需重估（领域包红线）
+- **阈值科学性**：+0.10%/8h 是经验值，跑两周真实数据后回看调参 ⚠️ 待补

package/workflows/cm/docs/sample-specs/docs//351/234/200/346/261/202/347/244/272/344/276/213.md

@@ -0,0 +1,24 @@
+# 测试需求：极简 Todo 应用
+
+## 背景
+
+用于验证 cm 工作流的最小需求，规模刻意控制在 3–5 个任务。
+
+## 功能需求
+
+1. 用户可以添加一条待办事项（文本，不超过 200 字）
+2. 用户可以将待办标记为完成/取消完成
+3. 用户可以删除待办
+4. 列表按创建时间倒序展示，已完成项置灰
+
+## 非功能需求
+
+- 数据本地持久化即可（localStorage 或 SQLite，实现方自选）
+- 单页应用，无需登录
+- 界面简洁可用即可，无设计稿
+
+## 验收标准
+
+- 添加后刷新页面数据不丢失
+- 完成状态切换即时生效
+- 删除有一次确认