approval-note-card
审批卡片还可接受简短备注，并在拒绝调用前将其作为用户消息发送给模型。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:SilverCrossing/approval-note-card#9b2166e90864dbf9855cf1c80865434feab525ccApproval Note Card 以 approval-note-card 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
给 DSH 的审批卡加一个输入框：拒绝的时候顺手告诉模型为什么。
原生审批卡只有两个答案。拒绝只等于"否定"，不等于"方向"——模型拿不到理由，就会自己猜：换个工具、换个目录、或者换一个更"权威"的来源（整盘遍历、注册表、系统文件）。这不是它想作恶，是它只能猜。
这个插件在拒绝前，把你写的理由作为一条用户消息发给模型：
本插件是为下面这套护栏设计的。四个可以单独装，也可以一起装：
| 插件 | 仓库 | 职责 |
|---|---|---|
write-approval-guard | https://github.com/SilverCrossing/write-approval-guard | 写操作审批；高危操作二次确认；敏感文件读取审批；判定日志 |
outside-access-guard | https://github.com/SilverCrossing/outside-access-guard | 工作区外读/写的审批；敏感位置二次确认；判定日志 |
dsh-safety-toolkit | https://github.com/SilverCrossing/dsh-safety-toolkit | safe_* 工具：改前快照、语法门禁、失败自动还原、可回滚 |
approval-note-card | 本仓库 | 审批卡加输入框；拒绝时把说明作为用户消息送给模型 |
联动关系：
approval/request 瀑布发起审批，本插件在浏览器侧接管渲染，回答仍走同一条瀑布——所以守卫的拦截行为和审计日志完全不受影响；dsh-safety-toolkit 的写操作同样经过 write-approval-guard，因此也会显示这张卡片。兼容性上唯一的约束见下一节：说明依赖 steer，和 onReject: turn（拒绝即取消本轮）互斥。
dsh plugin --profile desktop add github:SilverCrossing/approval-note-card#<commit>
它是纯客户端插件：宿主侧那一行是空实现，真正的 UI 在 client.js 里注册到 conversation.composer。
说明是通过 session.prompt(content, 'steer') 送进当前这一轮的。如果宿主侧守卫在拒绝时取消了本轮（onReject: turn），inbox 会被清空，说明就会丢。
所以：
onReject: call（拒绝但不停本轮）→ 说明正常送达；onReject: turn → 这条通道失效，需要改走宿主旁路。/plugins 里禁用或卸载本插件 → 官方 ui-approval 仍在，退回原生卡片。kind / answer / answerable 不满足）→ select 返回 null，同样退回原生卡。本插件不落盘日志——纯客户端，碰不到文件系统。四件套里的另外三个（write-approval-guard、outside-access-guard、dsh-safety-toolkit）已经覆盖了绝大多数信息：谁触发的审批、判定结果、callId 都在它们各自的日志里。
本插件只留两处间接痕迹：说明原文作为一条用户消息进入会话记录（[拒绝说明] …）；守卫日志里有对应的 outcome: "rejected" 和 callId，但不含说明文本。两者按时间对齐，不能按 callId join。后续如果确实需要精确归因，再补宿主侧日志。
conversation.approval.detail 槽，所以卡片里看不到 Tool 的详情/ diff。守卫给的 displayReason 里通常已经带了路径或命令，够用；需要时再加。stopPropagation 拦的。页面把 Enter 绑定成"允许"，这层拦截是否彻底需要实测。