@aipper/aiws-spec 0.0.24 → 0.0.26

package/templates/workspace/.iflow/commands/ws-memory-bank-init.toml

@@ -1,100 +0,0 @@
-# Command: ws:memory-bank-init
-# Description: 初始化 memory-bank/（用于固定上下文，避免会话跑偏）
-# Category: workspace
-# Version: 1
-
-description = "初始化 memory-bank/（用于固定上下文，避免会话跑偏）"
-
-prompt = """
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在当前 git workspace 根目录创建/更新 `memory-bank/` 的模板文件（非需求真值），用于固定工程上下文。
-
-执行：
-!{bash -lc '
-set -euo pipefail
-
-ws_root="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
-cd "$ws_root"
-
-mkdir -p memory-bank
-
-write_if_missing() {
-  local p="$1"
-  shift
-  if [[ -f "$p" ]]; then
-    echo "OK: exists: $p"
-    return 0
-  fi
-  mkdir -p "$(dirname "$p")"
-  cat >"$p" <<EOF
-$*
-EOF
-  echo "OK: created: $p"
-}
-
-write_if_missing "memory-bank/README.md" "# Memory Bank（工作区上下文）
-
-目的：给 iFlow/Codex/Claude 一个“固定且可持续更新”的上下文集合，避免每次会话重新讲一遍导致跑偏。
-
-在你的工作区中：
-- \`REQUIREMENTS.md\` 仍是**需求真值**（不要复制到这里）。
-- \`AI_PROJECT.md\` / \`AI_WORKSPACE.md\` 是**边界与运行真值**。
-- 本目录补齐的是“实现过程中的稳定上下文”（更偏工程视角）。
-
-建议规则：
-- 改代码前：先看 \`REQUIREMENTS.md\` + \`AI_PROJECT.md\` + \`AI_WORKSPACE.md\`，再结合本目录的 \`architecture.md\`/\`progress.md\`。
-- 每次完成一个可验证的小步：更新 \`progress.md\`（写清：做了什么、证据路径、下一步）。
-- 发生重大结构变化：更新 \`architecture.md\`（只写高层关系，不要堆细节）。
-"
-
-write_if_missing "memory-bank/tech-stack.md" "# Tech Stack
-
-填写原则：只写“确实在用且影响决策”的信息，避免长篇大论。
-
-建议包含：
-- 语言/运行时版本（例如 Java/Node/Python）
-- 构建工具链（Gradle/Maven、pnpm、uv 等）
-- 关键框架与约束（Spring Boot、Ktor、Vue、React 等）
-- 数据层（DB/Redis/MQ）与迁移方式
-- 本地/测试环境切换方式（引用 \`AI_WORKSPACE.md\` 的命令即可）
-"
-
-write_if_missing "memory-bank/architecture.md" "# Architecture
-
-目标：记录“模块关系与关键边界”，让新的会话可以快速对齐代码布局。
-
-建议包含：
-- 目录/模块分层（例如 server/web/app）
-- 核心数据流（请求入口 → service → repo → DB）
-- 关键约束（鉴权、request-id、幂等、事务）
-"
-
-write_if_missing "memory-bank/implementation-plan.md" "# Implementation Plan
-
-目标：把需求拆成可验证的小步（每步都有验证命令与期望结果）。
-
-模板（示例字段）：
-- Step 1: …
-  - Scope:
-  - Files:
-  - Verify: \`...\`
-  - Expected:
-"
-
-write_if_missing "memory-bank/progress.md" "# Progress
-
-每次完成一个可验证小步就追加一条：
-
-- YYYY-MM-DD HH:MM: 做了什么（关联 Issue_ID/验收项）
-  - Changed: \`path/to/file\`
-  - Verify: \`command\`
-  - Evidence: \`path/to/log_or_report\`
-  - Next:
-"
-'}
-
-说明：
-- `REQUIREMENTS.md` 仍是需求真值；不要把需求复制进 memory-bank。
-- 建议完成后立刻执行：`/ws-contract-check`（让 pre_tool_guard 放行写入类工具）。
-"""

package/templates/workspace/.iflow/commands/ws-migrate.toml

@@ -1,59 +0,0 @@
-# Command: ws:migrate
-# Description: 将当前目录迁移到最新的 workspace-A 约定（安全，默认不覆盖）
-# Category: workspace
-# Version: 1
-
-description = "迁移当前目录为 workspace-A 约定（补齐 AI_PROJECT.md 与 .gitignore managed block，默认不覆盖）"
-
-prompt = """
-用中文输出；命令与路径保持原样不翻译。
-
-目标：将“当前目录”迁移/补齐为最新的 aiws `workspace` 约定（以 `.aiws/manifest.json` 与模板托管面为准）。
-
-安全规则：
-- 不要打印 secrets；不要创建真实 secrets。
-- 只通过 `aiws init/update/validate` 更新托管面（replace_file + managed blocks）。
-
-迁移完成后建议运行 `/ws-doctor` 并手工检查 `AI_PROJECT.md` 的“项目特有规则”段是否符合本项目约束。
-
-Execute:
-!{bash -lc '
-set -euo pipefail
-
-root="$(pwd)"
-
-run_aiws() {
-  local subcmd="$1"
-  shift
-
-  if [[ -x "$root/node_modules/.bin/aiws" ]]; then
-    "$root/node_modules/.bin/aiws" "$subcmd" "$@"
-    return 0
-  fi
-  if command -v aiws >/dev/null 2>&1; then
-    aiws "$subcmd" "$@"
-    return 0
-  fi
-  if command -v npx >/dev/null 2>&1; then
-    npx -y @aipper/aiws "$subcmd" "$@"
-    return 0
-  fi
-
-  echo "error: aiws not found (install @aipper/aiws or ensure npx is available)" >&2
-  exit 2
-}
-
-if [[ -f ".aiws/manifest.json" ]]; then
-  run_aiws update .
-else
-  run_aiws init .
-fi
-run_aiws validate .
-
-echo
-echo "下一步:"
-echo "  - 运行: /ws-doctor"
-echo "  - 手工检查: AI_PROJECT.md（把本项目的特殊约束补齐进去）"
-echo "  - 如启用了 iFlow pre_tool_guard：执行 /ws-contract-check（写入 stamp）"
-'}
-"""

package/templates/workspace/.iflow/commands/ws-preflight.toml

@@ -1,30 +0,0 @@
-# Command: ws:preflight
-# Description: AI Workspace 预检：读 AI_PROJECT/REQUIREMENTS/AI_WORKSPACE 并输出约束摘要
-# Category: workspace
-# Version: 1
-
-description = "AI Workspace 预检：读 AI_PROJECT/REQUIREMENTS/AI_WORKSPACE 并输出约束摘要"
-
-prompt = """
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在开始“写代码/改配置/给补丁”之前，先把工作区真值文件读全并对齐，避免规则漂移。
-
-执行步骤（强制）：
-1) 定位项目根目录：
-   - 优先：`git rev-parse --show-toplevel`
-   - 若失败：说明无法判断项目根；请用户确认当前目录是否为项目根（不要猜测）。
-2) 在项目根目录读取以下文件（存在则必须读取；缺失则明确报告缺失项，不要臆测内容）：
-   - `AI_PROJECT.md`
-   - `REQUIREMENTS.md`
-   - `AI_WORKSPACE.md`
-3) 输出：
-   - `Root:` <项目根路径>
-   - `Found:` 列出实际读取到的文件列表
-   - `Missing:` 列出缺失文件（若缺失 `AI_PROJECT.md`，建议用户先运行 `/ws-migrate` 或 `/aiws-init` 补齐）
-   - `Key rules:` 用 3–8 条 bullet 摘要关键约束（范围/禁止项/必须产物/必须验证命令）
-
-安全规则：
-- 不打印 secrets；遇到疑似敏感值仅提示并建议迁移到本地私密文件（不要复述原文）。
-- 不执行破坏性命令。
-"""

package/templates/workspace/.iflow/commands/ws-pull.toml

@@ -1,47 +0,0 @@
-# Command: ws:pull
-# Description: 拉取并对齐 submodules（fast-forward；尽量避免 detached）
-# Category: workspace
-# Version: 1
-
-description = "拉取并对齐 submodules（fast-forward；尽量避免 detached）"
-
-prompt = """
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：安全拉取 superproject，并对齐 submodules，尽量把 submodule 从 detached HEAD “挂回”分支（仅当该分支包含 gitlink commit），减少人为操作差异。
-
-安全约束（强制）：
-- 不执行破坏性命令；不自动提交/不自动 push
-- 若工作区不干净：停止并要求用户先 commit 或 stash
-- `git pull` 默认只允许 fast-forward（避免隐式 merge/rebase）
-
-步骤（建议）：
-1) 输出上下文并检查工作区干净：
-   - `git rev-parse --show-toplevel`
-   - `git branch --show-current`
-   - `git status --porcelain`
-   - 若 `git status --porcelain` 非空：停止。
-
-2) 拉取 superproject（fast-forward only）：
-   - `git pull --ff-only`
-   - 若失败：停止并说明需要用户明确选择 `git pull --rebase` 或手动处理。
-
-3) 更新 submodules 到 superproject 记录的 gitlink commit：
-   - 若存在 `.gitmodules`：
-     - `git submodule sync --recursive`
-     - `git submodule update --init --recursive`
-
-4) （可选但推荐）把 submodule 从 detached HEAD 尽量“挂回分支”（不改动 gitlink commit）：
-   - 为避免 origin 多分支时“猜错分支”，只在 `.gitmodules` 明确配置了 `submodule.<name>.branch` 时才执行；否则保持 detached 并提示先对齐配置
-   - 目标分支：`.gitmodules` 的 `submodule.<name>.branch`（若为 `.` 则用 superproject 当前分支）
-   - 对每个 submodule：
-     - `sub_sha="$(git rev-parse "HEAD:<sub_path>")"`
-     - `git -C "<sub_path>" fetch origin --prune`
-     - 若 `sub_sha` 属于 `origin/<target_branch>`：创建/更新 pin 分支 `aiws/pin/<target_branch>` 指向 `$sub_sha`（不改动现有分支）
-     - 否则保持 detached 并提示原因
-
-可选（方案 2，一次性设置 submodule 跟踪分支，会改 `.gitmodules`，需提交）：
-- `git submodule set-branch --branch main <sub_path>`
-- `git add .gitmodules && git commit -m "chore(submodule): set tracking branch"`
-推荐：优先使用 `ws:submodule-setup` 交互式对齐所有 submodules 的 branch，并提交 `.gitmodules`。
-"""

package/templates/workspace/.iflow/commands/ws-push.toml

@@ -1,40 +0,0 @@
-# Command: ws:push
-# Description: 推送（submodule 感知：先 submodules 后 superproject；fast-forward；不 force）
-# Category: workspace
-# Version: 1
-
-description = "推送（submodule 感知：先 submodules 后 superproject；fast-forward；不 force）"
-
-prompt = """
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：安全 push 当前仓库；若仓库包含 submodules，则先 push submodules，再 push superproject（默认 fast-forward；不 force）。
-
-约束：
-- 不自动提交、不自动 `git add -A`
-- 不使用 `--force` / `--force-with-lease`
-- 若工作区不干净：停止并要求先 commit 或 stash
-
-步骤（建议）：
-1) 输出上下文并检查工作区干净：
-   - `git branch --show-current`
-   - `git status --porcelain`
-   - `git status -sb`
-   - 非空则停止。
-
-2) 判断是否存在 submodules：若存在 `.gitmodules`，输出 submodule 列表：
-   - `git config --file .gitmodules --get-regexp '^submodule\\..*\\.path$'`
-
-3) 若没有 submodules：正常 push（仍需用户确认远端/分支）：
-   - `git remote -v`
-   - `git push`
-
-4) 若有 submodules：先检查 `.gitmodules` 的 `submodule.<name>.branch` 是否齐全（缺失则停止并提示 `ws:submodule-setup`）。
-
-5) 逐个 push submodules（fast-forward only），再 push superproject：
-   - `git -C "<sub_path>" fetch origin --prune`
-   - 若 `origin/<target_branch>` 不是 `HEAD` 的祖先：停止并提示先在 submodule 做 rebase/merge
-   - `git -C "<sub_path>" push origin "HEAD:refs/heads/<target_branch>"`
-   - 最后 `git push`
-"""
-

package/templates/workspace/.iflow/commands/ws-req-change.toml

@@ -1,64 +0,0 @@
-# Command: ws:req-change
-# Description: 记录需求变更到 requirements/CHANGELOG.md 并更新 REQUIREMENTS.md
-# Category: requirements
-# Version: 1
-
-description = "记录需求变更到 requirements/CHANGELOG.md 并更新 REQUIREMENTS.md"
-
-prompt = """
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：处理“进行中的需求变更”，并把变更记录到独立的变更文件中，避免 REQUIREMENTS.md 的历史被覆盖。
-
-约定：
-- `REQUIREMENTS.md`：当前有效需求（唯一真值）
-- `requirements/CHANGELOG.md`：需求变更历史（追加记录，不改旧记录）
-- `requirements/requirements-issues.csv`：需求拆解执行合同（机器可读；用于审核/回放/状态机）
-
-步骤（必须按顺序）：
-1) 读取 `REQUIREMENTS.md` 与 `requirements/CHANGELOG.md`（若不存在则创建 changelog 文件与目录）
-2) 明确本次变更的类型：
-   - Clarify：补充不清晰的验收字段（不改变语义）
-   - Change：修改/新增/删除需求（改变语义）
-3) 产出“变更摘要”（1-5 条）并在执行前确认边界：
-   - 是否影响 API（OpenAPI/状态码/鉴权/字段）
-   - 是否影响自动化测试边界（allow_mutations/dangerous_disabled/base_url_allowlist）
-4) 对比与冲突检查（强制，不写文件）：
-   - 对比“变更前 vs 拟变更后”的差异清单（新增/删除/语义变化）
-   - 整理潜在冲突/不确定点（只列“最可能影响验收/实现”的，避免噪音）
-5) 逐条澄清（强制，避免一次问完）：
-   - 若存在潜在冲突/不确定点：本轮只问 1 个最高优先级问题（给出 2–4 个可选答案或二选一），然后停止，等待用户回复；不要继续问下一题，也不要写文件。
-   - 收到用户回复后：更新拟变更方案，回到步骤 4) 重新对比，直至没有未决问题。
-6) 强制停下来让用户确认：是否继续落盘？(Y/N)
-7) 用户确认 Y 后再写入：
-   - 更新 `REQUIREMENTS.md`（只留下当前有效版本；不要在文件中堆历史表格）
-   - 追加一条 changelog 记录到 `requirements/CHANGELOG.md`（必须包含：日期、变更内容、原因、影响范围、关联 issues/PR、记录人）
-8) 需求拆解到 CSV 执行合同（强制）：
-   - 确保存在 `requirements/requirements-issues.csv`（若无则初始化）：
-     - `python3 tools/requirements_contract.py init`
-   - 为本次变更新增/更新 1..N 条 Req 行，并拆到“可实现、可测试”的粒度：
-     - 每条至少写清：CRUD、Scenario、Inputs、Outputs、Business_Logic、Tests
-     - 状态机：
-       - `Spec_Status`: DRAFT(未完善)/READY(已完善可开工)
-       - `Impl_Status`: TODO/DOING/DONE/BLOCKED/SKIP
-   - 完成后必须跑一次校验（READY/DONE 的必填字段会被检查）：
-     - `python3 tools/requirements_contract.py validate`
-9) 同步/补齐需求执行合同（强制，自动处理 FlowSpec 有/无两种情况）：
-   - `python3 tools/requirements_contract_sync.py --workspace .`
-   - 说明：若 `REQUIREMENTS.md` 中不存在 FlowSpec（或 flows 为空），该命令只会确保 `requirements/requirements-issues.csv` 表头存在并给出 WARN（这是预期行为，不要当成失败）。
-10) 同步执行合同（至少做到其中之一）：
-   - 更新 `issues/feature-issues.csv`（新增/调整对应任务，并关联 Req_ID）
-   - 若涉及 API：运行/更新 runner 产物并修正 `issues/server-api-issues.csv` 的验收字段
-11) 生成简短逻辑图与场景执行合同（可选，但若存在 FlowSpec 则强烈建议自动执行）：
-   - 若 `REQUIREMENTS.md` 同时包含 `<!-- FLOW_SPEC_BEGIN -->` 与 `<!-- FLOW_SPEC_END -->`：运行 `/ws-req-flow-sync` 生成/更新 `docs/api-flow.mmd` 与 `issues/server-scenario-issues.csv`
-   - 否则：跳过，并提示用户“可以先不维护 FlowSpec；后续需要场景回归时再补”
-
-输出必须包含：
-- 本次更新的文件清单（路径）
-- 回滚方案（如何撤销本次需求变更）
-- 下一步建议命令（若存在 FlowSpec：包含 `/ws-req-flow-sync`；以及 `/server-fix` 或 runner 命令）
-
-安全规则：
-- 不打印 secrets/test-accounts.json
-- 不引入任何 token/密钥到仓库
-"""

package/templates/workspace/.iflow/commands/ws-req-contract-sync.toml

@@ -1,25 +0,0 @@
-# Command: ws:req-contract-sync
-# Description: 从 REQUIREMENTS.md 的 FlowSpec 补齐 requirements/requirements-issues.csv（半自动）
-# Category: requirements
-# Version: 1
-
-description = "从 REQUIREMENTS.md 的 FlowSpec 补齐 requirements/requirements-issues.csv（半自动）"
-
-prompt = """
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-用途：当项目已经做了一部分，但 `requirements/requirements-issues.csv` 还没建立/没补齐时，用本命令从 `REQUIREMENTS.md` 的 FlowSpec（机器可读）生成/补齐需求条目骨架。
-
-说明：
-- 本命令只做“补齐骨架”：把每条 Flow 变成一条 Req（默认 `Spec_Status=DRAFT`、`Impl_Status=TODO`），不会猜测你已完成哪些。
-- 生成后请手工补齐 CRUD/Inputs/Outputs/Business_Logic/Tests，并把可开工的条目标为 `Spec_Status=READY`。
-
-执行：
-!{bash -lc '
-set -euo pipefail
-python3 tools/requirements_contract_sync.py --workspace .
-'}
-
-下一步：
-- 运行：`/ws-req-contract-validate`
-"""

package/templates/workspace/.iflow/commands/ws-req-contract-validate.toml

@@ -1,16 +0,0 @@
-# Command: ws:req-contract-validate
-# Description: 校验 requirements/requirements-issues.csv（READY/DONE 必填字段）
-# Category: requirements
-# Version: 1
-
-description = "校验 requirements/requirements-issues.csv（READY/DONE 必填字段）"
-
-prompt = """
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-执行（失败则修正 CSV 再重试）：
-!{bash -lc '
-set -euo pipefail
-python3 tools/requirements_contract.py validate
-'}
-"""

package/templates/workspace/.iflow/commands/ws-req-flow-sync.toml

@@ -1,36 +0,0 @@
-# Command: ws:req-flow-sync
-# Description: 从 REQUIREMENTS.md FlowSpec 生成流程图与场景 CSV
-# Category: requirements
-# Version: 1
-
-description = "从 REQUIREMENTS.md FlowSpec 生成流程图与场景 CSV"
-
-prompt = """
-用中文输出；命令与路径保持原样不翻译。
-
-目标：在工作区根目录基于 `REQUIREMENTS.md` 内的 FlowSpec（FLOW_SPEC_BEGIN/END 标记）生成：
-- `docs/api-flow.mmd`（简短逻辑图，Mermaid）
-- `issues/server-scenario-issues.csv`（场景执行合同：TODO/DONE/BLOCKED）
-
-要求：
-- 不读取/不打印 secrets
-- 输出要短：只打印生成的文件路径与下一步命令
-
-Execute:
-!{bash -lc '
-set -euo pipefail
-
-[[ -f REQUIREMENTS.md ]] || { echo "缺少 REQUIREMENTS.md（请先 /aiws-init 或补齐需求文件）" >&2; exit 2; }
-
-if [[ -f tools/requirements_flow_gen.py ]]; then
-  python3 tools/requirements_flow_gen.py --workspace .
-  echo ""
-  echo "下一步:"
-  echo "  - 查看逻辑图: cat docs/api-flow.mmd"
-  echo "  - 查看场景合同: cat issues/server-scenario-issues.csv"
-else
-  echo "缺少工具: tools/requirements_flow_gen.py（建议运行 /aiws-init 或从模板复制）" >&2
-  exit 2
-fi
-'}
-"""

package/templates/workspace/.iflow/commands/ws-req-review.toml

@@ -1,56 +0,0 @@
-# Command: ws:req-review
-# Description: 需求整体评估（不落盘）：对 REQUIREMENTS.md 做 QA，输出缺口/冲突/风险，减少漂移
-# Category: requirements
-# Version: 1
-
-description = "需求整体评估（不落盘）：对 REQUIREMENTS.md 做 QA，输出缺口/冲突/风险，减少漂移"
-
-prompt = """
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在不修改任何文件的前提下，对“当前整体需求”做一次质量评估（Requirements QA），提前发现不清晰/不可验收/与项目约束冲突的点，减少后续实现漂移。
-
-执行步骤（必须按顺序）：
-1) 定位项目根目录（优先 `git rev-parse --show-toplevel`；失败则停止并让用户确认根目录）。
-2) 在项目根目录读取（存在则必须读取；缺失则明确报告缺失项，不要臆测内容）：
-   - `AI_PROJECT.md`
-   - `REQUIREMENTS.md`
-   - `AI_WORKSPACE.md`
-   - `requirements/CHANGELOG.md`（若存在）
-   - `requirements/requirements-issues.csv`（若存在）
-3) 输出一个固定结构的评估报告（Markdown）：
-
-## Requirements QA
-
-### 1) 结论（1–3 行）
-- 当前需求是否“可进入实现阶段”？（是/否/有条件）
-
-### 2) 漂移风险（必须列出）
-- 哪些点最容易导致实现与需求不一致？为什么？
-
-### 3) 可验收性（必须列出）
-- 列出“缺少明确验收标准”的条目（输入/输出/错误码/边界条件/示例）。
-
-### 4) 完整性（必须列出）
-- 是否缺少：Non-goals、兼容性/迁移、鉴权/权限、失败重试、并发/幂等、观测性（日志/trace/request-id）、性能预算。
-
-### 5) 一致性（必须列出）
-- 与 `AI_PROJECT.md`（禁止项/产物要求/验证要求/边界）是否冲突？逐条列冲突与建议。
-
-### 6) 可测试性与证据（必须列出）
-- 给出最小验证路径（命令 + 期望结果 + 证据落盘路径建议，例如 `.agentdocs/tmp/...`）。
-
-### 7) 风险清单（3–8 条）
-- 风险 → 影响面 → 缓解建议（尽量可操作）。
-
-### 8) 需要澄清的问题（优先级排序）
-- 用 5–12 个问题把不确定点一次问清（每题说明“为什么要问/影响什么验收”）。
-
-4) **强制停下来询问用户确认**：
-   - 问用户：**“是否基于上述评估进入需求落盘/变更流程 `/ws-req-change`？(Y/N)”**
-   - 若 N：停止，等待用户补充信息或调整需求文本。
-
-边界：
-- 不打印任何 secrets（尤其是 `secrets/test-accounts.json`）。
-- 不执行破坏性命令。
-"""

package/templates/workspace/.iflow/commands/ws-review.toml

@@ -1,33 +0,0 @@
-# Command: ws:review
-# Description: AI Workspace 交叉审计交付（Claude + Codex + Gemini），证据优先落盘到 changes/<change-id>/review/
-# Category: workspace
-# Version: 1
-
-description = "AI Workspace 交叉审计交付（Claude + Codex + Gemini），证据优先落盘到 changes/<change-id>/review/"
-
-prompt = """
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：在实现/提交前，对当前工作区改动进行交叉审计，并把审计结论优先落盘到 `changes/<change-id>/review/`（若无法确定 `change-id` 再回退 `.agentdocs/tmp/review/`），便于回放与追责。
-
-强制步骤：
-1) 读取真值文件：`AI_PROJECT.md`、`REQUIREMENTS.md`、`AI_WORKSPACE.md`。
-2) 若 iFlow 拦截写入：先执行 `/ws-contract-check`，再继续。
-3) 审计输入（按优先级）：
-   - `git diff`（或变更工件 `changes/<change-id>/`）
-   - `issues/*.csv`（状态机是否存在 TODO/DOING/BLOCKED）
-   - 最近一次门禁输出（如 `aiws validate .`）
-4) 输出（必须）：
-   - Findings：问题清单（按严重性排序，引用具体文件路径）
-   - Risks：3–8 条
-   - Next：最小修复清单 + 最小验证命令
-5) 证据落盘（必须）：
-   - 默认：在 `changes/<change-id>/review/` 写入一份 `iflow-review.<timestamp>.md`
-   - 回退：在 `.agentdocs/tmp/review/` 写入同名文件（仅在无法确定 `change-id` 时使用）
-6) 如果目标是提交前门禁：
-   - 建议运行：`aiws validate .`（或 `npx @aipper/aiws validate .`）
-
-边界：
-- 不打印任何 secrets（尤其是 `secrets/test-accounts.json`）。
-- 不执行破坏性命令。
-"""

package/templates/workspace/.iflow/commands/ws-rule.toml

@@ -1,43 +0,0 @@
-# Command: ws:rule
-# Description: 整理项目规则写入 AI_PROJECT.md 的 managed block
-# Category: workspace
-# Version: 1
-
-description = "整理项目规则写入 AI_PROJECT.md 的 managed block"
-
-prompt = """
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：当用户提出“项目规则/约束/边界”时，将其整理为结构化条款，并写入工作区根目录的 `AI_PROJECT.md`。
-
-约定真值：
-- `AI_PROJECT.md`：项目约束真值（本命令只维护其中的 managed block）
-- `REQUIREMENTS.md`：需求真值（本命令不改需求）
-- `AI_WORKSPACE.md`：运行/测试真值（本命令不改运行方式）
-
-安全规则（强制）：
-- 不打印 secrets；不把 token/密钥/内网地址写入 `AI_PROJECT.md`。
-- 不进行破坏性命令。
-- 写入前必须创建备份：`.aiws/backups/manual/AI_PROJECT.md.bak.<timestamp>`
-
-写入位置（强制）：
-- 仅修改 `AI_PROJECT.md` 中 `<!-- AI_PROJECT_RULES_BEGIN -->` 与 `<!-- AI_PROJECT_RULES_END -->` 之间的内容。
-- 若文件/标记不存在：先运行 `/aiws-init`（或 `aiws init .`）补齐模板，再继续。
-
-工作流：
-1) 读取（或创建）`AI_PROJECT.md`，并定位 managed block。
-2) 如果用户还没给出明确的规则文本：最多问 3 个澄清问题（例如：允许改动目录白名单/必须跑哪些测试/是否允许有副作用接口/是否允许自动提交）。
-3) 将用户输入整理为短而硬的条款（建议按以下结构）：
-   - 范围/目录白名单
-   - 必须执行的验证命令（含期望结果）
-   - 禁止项（危险操作/敏感文件/越界访问）
-   - 交付产物（必须更新哪些文件：issues/证据/文档）
-4) 更新 managed block：合并去重（同义合并）、保持条款可执行；避免重写文件其它部分。
-4.1) 写入前必须复述“将写入的规则清单”，并要求用户回复 `CONFIRM` 后再落盘（避免误写/误删）。
-5) 输出必须包含：
-   - 更新了哪些文件（路径）
-   - 回滚方式（恢复备份文件）
-   - 下一步建议（例如运行 `/ws-doctor`）
-
-提示：用户的“规则”可能零散，优先把它们变成可检查的条款（能落到命令/文件/目录）。
-"""

package/templates/workspace/.iflow/commands/ws-submodule-setup.toml

@@ -1,32 +0,0 @@
-# Command: ws:submodule-setup
-# Description: 子模块分支对齐（写入 .gitmodules 的 submodule.<name>.branch）
-# Category: workspace
-# Version: 1
-
-description = "子模块分支对齐（写入 .gitmodules 的 submodule.<name>.branch）"
-
-prompt = """
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
-
-目标：为每个 submodule 写入 `.gitmodules` 的 `submodule.<name>.branch`（团队真值），让 `ws:pull`、`ws:finish` 能确定性地减少 detached 与人为差异；并使 `aiws validate` 的 submodule 分支门禁通过。
-
-约束：
-- 不自动提交、不自动 push（必须先输出 diff 并让用户确认）
-- 不做破坏性命令
-
-步骤（建议）：
-1) 确认工作区干净：`git status --porcelain`（非空则停止）。
-2) 列出 submodules：
-   - `test -f .gitmodules || { echo "no .gitmodules"; exit 0; }`
-   - `git config --file .gitmodules --get-regexp '^submodule\\..*\\.path$'`
-3) 对每个 submodule 让用户选择目标分支（推荐具体分支名；可选 `.` 表示跟随 superproject 分支名）。
-4) 写入分支配置：
-   - `git submodule set-branch --branch <branch-or-dot> <sub_path>`
-5) 输出 diff 并让用户确认是否提交：
-   - `git diff -- .gitmodules`
-   - `git status --porcelain`
-6) 用户确认后提交：
-   - `git add .gitmodules`
-   - `git commit -m "chore(submodule): set tracking branches"`
-"""
-