Agent 要动手之前，
先在你手腕上问一句

「危险操作要不要做」只有三种答案

前两种都是偷懒的正确，第三种才是能长期跑下去的。

一次确认，就是一次请求与一次结算

Agent 宿主的 PreToolUse hook 在命令真正执行之前拦下来，向本地网关发一个请求； 网关把卡片送出去、等你选择，再把结论回填给 hook。链路两端都是本地 HTTP / WebSocket， 推送这一跳才交给 Home Assistant。

# Agent 宿主 → 网关（本地回环 127.0.0.1）
POST /v1/approvals
{
  "tier":       "L3",
  "title":      "高危操作确认",
  "body":       "git push --force origin main",
  "ttl":        120,
  "wait":       90000,
  "session_id": "…"
}

# 网关 → Agent 宿主（回填结论）
200 OK
{
  "verdict":   "allow",
  "decidedBy": "ha",
  "latencyMs": 8420
}

# 其余时刻（超时 / 推送失败）
"verdict": "deny"  ← fail-closed，绝不放行

关键分工：Home Assistant 只负责送通知、收事件，不做任何判断。 令牌校验、重放拦截、超时兜底、审计留痕全部在网关里。

走一遍完整链路

点下面的按钮，看一条 L3 命令怎么从 Agent 走到你的手腕、再走回来。 中途把「手机离线」打开，可以看它在推送失败时的兜底行为 —— 那是这套系统最见功力的地方。

四档，决定打扰你的频率

分级只看命令文本的正则。设计目标不是「把危险的都抓出来」——而是 不把无害的判高：打扰预算一旦被噪音消耗完，人就会开始无脑点「允许」，整套方案等于白接。

复合命令取最危险的那一段，不让无害段稀释它： for f in a; do sudo true; done 仍是 L3。反过来，rm 会看目标路径是否落在 node_modules / dist / /tmp 这类常规清理目录，以及是否递归 —— 目录内清理判 L1，非递归删单文件判 L2，递归删外部路径判 L3。

为什么它敢拦住而不是放行

推送失败时最糟的处理，是「静默放行」。这里的每一层都朝着 fail-closed 长。