Hwip Auto — 定时自主工作模式

Hwip Auto — 定时自主工作模式 是做什么的？

在固定的时间预算内自主工作：探索 → 规划 → 实现 → 验证 → 提交，一次一个单元。用户通过 hwip_ask 按钮从手机上进行引导；当他们没有回答时，你基于声明的安全默认值继续，而不是停滞。整个运行过程在一个响应中完成——结束你的回合即结束该模式。

前置条件——如果未满足则拒绝启动

• 已配置 hook id — ~/.hwip/config.json 中的 hookId（由 hwip install 写入），或 HWIP_HOOK_ID 环境变量。SessionStart 上下文结束时如果已配置则为 Mode: two-way (notify + ask)；Mode: one-way 意味着没有引导通道——拒绝并引导用户运行 /hwip-config。
• 未静音。 如果 /hwip-mode 报告 NOTIFICATIONS: muted，则拒绝：无通知的自主模式是无人值守且无法引导的工作。建议运行 /hwip-mode unmute。
• 用户明确调用。 永远不要因为任务“看起来很长”而自行触发此模式。用户通过 /hwip-auto ... 选择加入。

参数

/hwip-auto [持续时间] [任务描述...]

• 持续时间 — 2h、90m、1h30m，或一个表示分钟数的裸数字。默认：1h。限制在 10 分钟到 8 小时内。
• 任务 — 持续时间之后的所有内容。如果省略，则根据当前对话推断；如果没有对话，则在启动提问中提出 2-3 个候选任务（例如修复失败的测试、清除 lint 警告、进行 TODO 清理）。

设置

1. 记录截止时间（状态文件可抵御上下文压缩——当你不确定剩余时间时重新读取它）：

   HASH=$(printf '%s' "${CLAUDE_PROJECT_DIR:-$(pwd)}" | cksum | cut -d' ' -f1)
   STATE_DIR="${XDG_STATE_HOME:-$HOME/.local/state}/hwip"
   mkdir -p "$STATE_DIR"
   MINUTES=120   # 从 duration 参数解析
   DEADLINE=$(( $(date +%s) + MINUTES * 60 ))
   printf '%s %s\n' "$DEADLINE" "$MINUTES" > "$STATE_DIR/auto-$HASH"
   date -r "$DEADLINE" 2>/dev/null || date -d "@$DEADLINE"   # macOS | Linux
   

2. 保护分支守卫——永远不要直接在 main/master/develop 上工作：

   BRANCH=$(git branch --show-current 2>/dev/null)
   case "$BRANCH" in
     main|master|develop) git checkout -b "auto/$(date +%Y%m%d)-<任务简写>" ;;
   esac
   

3. 在编写任何代码前发现验证器：项目的确定性检查（package.json、Makefile、CI 配置中的测试 / lint / 类型检查 / 构建命令）。这些检查控制着每次提交。如果项目没有检查，则在启动提问中说明，并将“代码编译/运行”视为最低门槛。

4. 启动提问——在接触任何内容之前进行一次 hwip_ask：

   • title："Auto mode: <任务> (<预算>)"
   • body：2-3 行计划 + 哪些验证器控制提交 + 分支名
   • actions：[{id:"start", label:"开始", style:"primary"}, {id:"stop", label:"取消"}] （如果任务有歧义，将“开始”替换为 2-3 个候选任务按钮）
   • placeholder："调整计划或范围..."
   • timeout：180, fallback："start"（或推荐的候选）

   自由文本回复修改计划；stop 取消该模式（删除状态文件）。

循环

将任务拆分为单元：最小的独立可验证、可提交的块（每个约 15-45 分钟）。然后对每个单元：

1. 时间检查（在开始每个单元之前）：

   HASH=$(printf '%s' "${CLAUDE_PROJECT_DIR:-$(pwd)}" | cksum | cut -d' ' -f1)
   read -r DEADLINE MINUTES < "${XDG_STATE_HOME:-$HOME/.local/state}/hwip/auto-$HASH"
   echo "剩余时间：$(( (DEADLINE - $(date +%s)) / 60 ))m / ${MINUTES}m"
   

   如果剩余时间低于收尾阈值——预算的 10%，至少 5 分钟——则不开始新单元，直接进入收尾阶段。

2. 探索 → 规划该单元（先阅读相关代码；不做盲目编辑）。

3. 实现该单元。

4. 验证通过确定性检查。绿色是唯一的通过信号——"看起来正确"不是验证器，永远不要为了通过而削弱或删除一个失败的测试。如果失败，修复并重新验证，最多 3 次尝试；如果仍然是红色，则撤销该单元的更改（git checkout -- <files> / git stash）以保持工作树干净，记录为已跳过，然后继续。

5. 提交绿色单元，使用清晰的约定式提交信息。不要推送。

6. 心跳——提交后，发送一段简短的 hwip_notify（"✅ <单元> — 剩余 m"），但最多每约 15 分钟一次；批量处理小单元。阻塞问题是例外：一旦出现，立即推送 priority: "high" 的通知。

重复直到单元完成或达到收尾阈值。

提问协议——永不停滞，永不破坏

运行过程中的问题通过 hwip_ask 提出（永远不要用 AskUserQuestion，永远不要用纯文本——CORE_RULES 规则 3/10 适用）：

• 将推荐的默认值放在最前面，在正文中说明超时时会自动执行该选项，设置 timeout: 180（对于真正重大的决策可设为 600），并将 fallback 设为该默认选项的 id。
• 记录所有通过回退解决的决策——最终报告列出它们，以便用户可以审计在没有他们参与的情况下决定了什么。
• 任何回复都是直接指令：立即应用。stop 回复（或自由文本会话结束指令）意味着立即收尾。
• 不可逆或面向外部的操作永远不符合回退条件：推送到远程、PR/发布、部署、数据删除、模式删除、强制操作、任何工作树之外的操作。对于这些操作，回退必须是 skip——超时时跳过该操作并记录，而不是执行它。只有明确的按钮点击才能授权。

收尾

1. 完成或撤销正在进行的单元（同样适用 3 次尝试规则——永远不要留下红色或脏的工作树）。
2. 删除状态文件：rm -f "${XDG_STATE_HOME:-$HOME/.local/state}/hwip/auto-$HASH"。
3. 最终报告在你的响应文本中：已完成的单元（含提交哈希）、跳过的单元及原因、每个通过回退解决的决策，以及剩余的工作。
4. 最终提问：
   • actions：[{id:"extend", label:"+30m"}, {id:"review", label:"审查"}, {id:"done", label:"完成", style:"primary"}]
   • timeout：300, fallback："done"
   • extend → 向状态文件写入新截止时间（+30m）并重新进入循环；review → 审查差异；done → 结束。

如果出现问题

• 无 hook id（Mode: one-way）——双向工具不可用；自动模式无法运行。运行 /hwip-config 进行设置。
• 运行过程中状态文件丢失（例如状态目录被清除）：将截止时间视为现在——收尾而不是猜测剩余预算。
• 用户在运行过程中在终端中输入：该消息是引导输入，与 hwip_ask 回复相同。应用它并继续循环。
• 验证器不稳定（相同命令在无更改的情况下交替绿/红）：不要浪费尝试次数进行重跑——通过 hwip_notify（priority: "high"）报告为阻塞问题并继续下一个单元。