dcg

DCG：遇到阻止操作时

核心要点： 阻止是检查点，而非错误。几乎总有安全的替代方案。提及覆盖操作前，先找到替代方案。

限制

• 绝不请求、生成或运行一次性放行绕过，因为只有人类可以授权并执行确切的受阻命令。
• 使用范围最窄且可撤销的替代方案，保留用户想要的结果，因为防护机制保护的是状态，而不只是命令写法。
• 请求人类判断前，先说明匹配的规则和仍然存在的风险；绝不重试、混淆命令或绕过 DCG 阻止。

快速导航

我需要……	前往
立即处理阻止操作	确切工作流程
查找安全的替代方案	安全替代方案
查看所有 CLI 命令	COMMANDS.md
启用更多规则包	PACKS.md
按项目配置	CONFIG.md
排查钩子问题	TROUBLESHOOTING.md

---

确切工作流程

遇到阻止操作时，每次都按以下顺序处理：

1. Run `dcg explain "cmd"` → Understand why (see trace)
2. Check Safe Alternatives table → Use if exists (DON'T mention override)
3. No alternative? → Explain risk clearly, let human decide
4. Human approves? → THEY run: dcg allow-once CODE

切勿： 首先请求覆盖操作。切勿悄悄重试。切勿绕过。

按风险等级划分的审批次数

没有安全替代方案、必须由人类决定时，所需的不同人类审批次数会随命令可能造成的破坏程度而增加：

等级	影响范围	所需审批
可恢复	可通过 reflog/stash/trash/backup 撤销	针对此确切命令的一次性放行
本地破坏性	永久删除本地、未提交或未备份的状态	一次性放行，且只有在你说明确切的丢失状态并确认不存在备份后才能授予
共享破坏性	共享历史记录、远程分支、数据库、他人使用的命名空间	每次单独的命令执行都需一次审批——绝不批量处理，也绝不扩大模式范围

停止条件：绝不将第 2 级或第 3 级命令说成第 1 级；绝不将多个待处理的阻止操作合并为一次笼统审批。一次「同意」被用于多个破坏性命令，就是审批洗白失效模式——每个一次性放行代码都绑定到一个目录中的一条命令，工作流程必须确保这一点。

阻止操作输出示例：

BLOCKED: git reset --hard HEAD
Rule: core.git:reset-hard
Reason: Discards uncommitted changes permanently
Allow-once code: ab12
Safer alternative: git stash

恰当的回复：

「我原本想丢弃更改，但 git reset --hard 被阻止了。我改用 git stash 吧——需要时可以恢复。」[继续执行 stash]

安全替代方案

被阻止的命令	改用	原因
git reset --hard	git stash	可恢复
git checkout -- file	git stash push file	保留更改
git push --force	git push --force-with-lease	检查远程端是否未更改
git clean -fd	git clean -fdn（预览）	显示将要删除的内容
git stash drop	先运行 git stash list	确认是哪条 stash
rm -rf /path	rm -ri /path 或验证路径	交互式操作／确认
kubectl delete namespace	kubectl delete -l app=X	选择性删除
DROP DATABASE	先备份	由人类审批
docker system prune -a	先运行 docker system df	查看正在使用的内容

快速参考

dcg doctor              # Health check — hook registered?
dcg explain "cmd"       # WHY is it blocked? (with trace)
dcg test "cmd"          # Would this be blocked? (dry-run)
dcg allow-once CODE     # Human approves (THEY run this)
dcg packs               # List available rule packs
dcg scan --staged       # Pre-commit: scan for issues

---

会被拦截的内容

类别	模式	安全替代方案
Git 破坏性操作	reset --hard、checkout --	stash、restore --staged
Git 历史记录	push --force、branch -D	--force-with-lease、-d
Git 暂存	stash drop、stash clear	先运行 stash list
文件系统	rm -rf（危险路径）	允许 /tmp/*
数据库	DROP、TRUNCATE、不带 WHERE 的 DELETE	添加 WHERE 子句
K8s	delete namespace、delete --all	-l 标签选择器

**上下文感知（基于 dcg 0.5.6 测量）：**临时目录例外允许在 /tmp、/private/tmp、/var/tmp 下以及字面形式的 $TMPDIR 路径中使用 rm -rf。 其他所有情况都会被拦截——rm -rf ./build 和其他相对路径 （core.filesystem:rm-rf-general）、/home/... 和 / 等绝对路径 （core.filesystem:rm-rf-root-home），甚至 /private/var/tmp 也不例外。 除 $TMPDIR 外，未解析的变量不会被视为临时目录。

dcg explain 示例（7 步流水线）：

$ dcg explain "git reset --hard HEAD"
BLOCKED by core.git:reset-hard

Evaluation trace:
  1. Config allow overrides: no match
  2. Config block overrides: no match
  3. Heredoc detection: not applicable
  4. Quick reject: triggered (contains "reset")
  5. Context sanitization: no changes
  6. Normalization: git reset --hard HEAD
  7. Pack evaluation:
     - Safe patterns: no match
     - Destructive: MATCH "reset --hard"

Suggestion: Use `git stash` to preserve changes

反模式

❌ "Command blocked. Run dcg allow-once ab12"  → Find alternative first!
❌ *Retrying silently or circumventing*         → Always acknowledge blocks
❌ Treating blocks as errors                    → They're checkpoints
❌ Asking user to allow-once without explaining → They need context

配置

# .dcg.toml — enable rule packs per-project
[packs]
enabled = ["database.postgresql", "kubernetes.kubectl", "cloud.aws"]

[overrides]
allow_patterns = ["rm -rf ./node_modules"]  # Project-specific safe

环境变量：

• DCG_PACKS="containers.docker,kubernetes" — 启用规则包
• DCG_DISABLE="kubernetes.helm" — 禁用指定规则包
• DCG_BYPASS=1 — 逃生开关（仅限人工使用）

关键信息

• 提供 49+ 个规则包（数据库、容器、K8s、云等）
• 亚毫秒级延迟 — 不会拖慢工作流
• 超时后默认放行 — 如果 DCG 卡住，命令仍会运行（并显示警告）
• Here-doc 扫描 — 会分析内联脚本（bash -c、python -c）
• 内联片段误报 — 扫描会匹配命令字符串中的任何破坏性标记，因此，即使实际不会执行破坏性操作，仅作为数据出现的模式（例如提交消息正文、here-doc 内容或探测参数）也可能触发拦截。安全做法：不要把内容放在命令行上，而是通过文件或标准输入传递（例如 git commit -F <file>），或者直接运行目标工具，而不是内联文本。切勿通过拆分或转义命令标记来重构被拦截的命令，以此绕过防护——这会破坏安全层。
• 一次性放行码 — 4 个十六进制字符，有效期 24 小时，并绑定到确切的命令和目录

事件缘起

2025 年 12 月 17 日，一个 AI Agent 对包含数小时未提交工作的文件运行了 git checkout --。这些文件通过 git fsck --lost-found 恢复了，但这证明：指令无法阻止执行，只有机械式强制执行才能做到。

---

验证

# Quick health check
dcg doctor | head -20

# Test if a command would be blocked
dcg test "git reset --hard HEAD"

# Should show: WOULD BE BLOCKED

输出规范

• **路径：**响应和命令输出写入 stdout/stderr；仅在明确要求配置时才写入 .dcg.toml 或 .dcg/allowlist.toml。
• **文件名：**原样保留 DCG 的项目文件名；常规拦截处理不会创建持久文件。
• **格式：**说明被拦截的命令、匹配的规则、风险、可逆替代方案及该替代方案的验证结果；命令必须原样引用。
• **退出码：**执行 bash skills/dcg/scripts/validate-dcg.sh，安装或配置工作必须要求返回零；dcg test 被拦截是预期证据，并非绕过许可。
• **后续处理：**继续使用通过验证的安全替代方案；如果不存在等效方案，则向人工说明确切风险及一次性放行选项。

质量检查清单

• 响应明确指出具体拦截项和规则，不泄露或暗示未经授权的绕过途径。
• 所选替代方案的范围更小、尽可能可逆，并且能够证明可实现用户要求的结果。
• 验证过程能区分预期的破坏性命令拦截与 DCG 安装或配置故障。

---

脚本

脚本	用途
./scripts/validate-dcg.sh	完整安装验证

---

参考资料

• COMMANDS.md — 完整的 CLI 参考，包含 dcg explain、dcg scan
• PACKS.md — 49+ 条规则包体系（数据库、k8s、云等）
• CONFIG.md — 配置、Agent 配置文件、heredoc 设置
• SCENARIOS.md — 包含良好/糟糕响应的详细示例
• PHILOSOPHY.md — DCG 采用这种工作方式的原因
• TROUBLESHOOTING.md — 常见问题及解决方法