dcg test --enforce-budget详解如何在诊断环境复现生产钩子延迟【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guardDestructive Command Guarddcg是一个拦截 AI 智能体执行危险 git 与 shell 命令的破坏性命令防护工具。它的钩子Hook在每条命令执行前运行并受一个绝对评估时限约束默认 1000ms。dcg test --enforce-budget是为此设计的诊断标志它让命令行测试使用与生产钩子完全相同的墙钟评估预算从而帮助你在本地诊断环境中精确复现生产钩子延迟提前发现超时导致的 indeterminate 结果而不是等智能体在生产中卡住才发现问题。为什么钩子延迟会成为一个问题dcg 的钩子模式为每条命令设置了一个绝对评估时限普通默认值为1000mscareful_company_running_windows预设默认3000ms。这个预算的意义在于保证任何单条命令都不会让智能体无限期等待使用单调墙钟时间计算即使进程被调度挂起、等待磁盘预算依然推进一旦耗尽预算dcg 返回显式的indeterminate结果——请求运维复核或保守拦截绝不会静默放行fail-open。这正是新手容易踩的坑dcg test默认不带任何时限。测试环境里一条命令跑 3 秒允许了到了生产钩子的 1 秒预算里却变成 indeterminate 拦截。这种测试与实际执行不一致是信任杀手。--enforce-budget就是为了消除这个盲区而生的见 CHANGELOG.md 中 v0.7.8 条目Adddcg test --enforce-budgetso operators can reproduce the live hooks effective wall-clock evaluation budget。--enforce-budget 到底应用了哪段预算这是理解该标志的关键细节。在 src/cli.rs 中可以看到注释与设计逻辑钩子模式的时限从读取 stdin 之后开始覆盖自愈、外部 pack 加载和评估全过程CLI 模式刻意不同它从配置解析、智能体检测、外部 pack 加载之后才开始计时只把pack 展开、allowlist 加载、评估计入预算。原因很实际CLI 自身的启动耗时不在任何智能体的钩子窗口内如果把它算进去该标志会报出一个钩子根本不会花掉的预算。换句话说--enforce-budget复现的是钩子模式下评估侧的延迟。它读取的有效预算来源依次为general.hook_timeout_ms配置项环境变量DCG_HOOK_TIMEOUT_MS平台/预设默认值低于10ms的值会被钳制到安全下限。一条命令复现生产钩子延迟安装好 dcg 后最直接的复现方式就是加上--enforce-budget并用你生产的配置dcg test --enforce-budget --config .dcg.prod.toml git status再配上几个常用变体来自 README.md场景命令要点机器可读结果便于写脚本比对加--format json检查decision字段被拦截的危险命令不想出现在命令行里用--stdin从文件读取候选命令只复现 Bash 钩子走的那条单方言路径加--dialect posix想看清为什么被拦/被放行加--explaindcg test的退出码非常友好0表示该命令会被允许1表示会被拦截可以直接接入 CI 流水线做延迟回归门禁。如何解读复现结果复现时你要盯的不是允许/拦截本身而是预算是否被耗尽indeterminate出现 生产上会超时。按 docs/troubleshooting.md 的准则deadline 耗尽必须以indeterminate呈现绝不能是allow也不应伪装成破坏性模式命中。结果正常但担心余量不足对比你测得的全量评估延迟与预算不要把预算压到实测延迟以下。想确认当前生效的预算来源运行dcg config --format json查看hook_timeout_ms与hook_timeout_source两个字段。延迟超标了怎么调优当诊断环境复现出超时正确的调整顺序是参考 docs/troubleshooting.md 的 Hook errors or timeouts 小节先加预算在配置里设置[general] hook_timeout_ms 1500或临时用DCG_HOOK_TIMEOUT_MS1500单进程覆盖缩小评估面减少启用的 pack 数量、检查 heredoc 大脚本解析调低max_body_bytes/max_body_lines量化验证项目自带延迟基准 benches/hook_latency.rs目标是钩子模式保持p99 50ms的智能体响应水平性能基线数据存放在 perf/baselines/可用 scripts/perf_baseline.py 采集、scripts/check_benchmark_budgets.sh 做预算检查再次复现用dcg test --enforce-budget在同一台慢机器上验证调整后的预算刚好覆盖全量评估。小结dcg test --enforce-budget让诊断环境套用生产钩子的有效墙钟评估预算复现钩子延迟行为它只计 pack 展开、allowlist 加载与评估刻意排除 CLI 自身启动开销保证与钩子口径一致超时必须表现为indeterminate这是 dcg fail-closed 安全模型的底线调优闭环dcg config --format json看预算 →dcg test --enforce-budget复现 → 基准脚本量化 → 调整后回归验证。更多细节可阅读 README.md 的Absolute Evaluation Deadline章节与 docs/troubleshooting.md规则与包体系的设计文档见 docs/packs/core.md。【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
dcg test --enforce-budget详解如何在诊断环境复现生产钩子延迟【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guardDestructive Command Guarddcg是一个拦截 AI 智能体执行危险 git 与 shell 命令的破坏性命令防护工具。它的钩子Hook在每条命令执行前运行并受一个绝对评估时限约束默认 1000ms。dcg test --enforce-budget是为此设计的诊断标志它让命令行测试使用与生产钩子完全相同的墙钟评估预算从而帮助你在本地诊断环境中精确复现生产钩子延迟提前发现超时导致的 indeterminate 结果而不是等智能体在生产中卡住才发现问题。为什么钩子延迟会成为一个问题dcg 的钩子模式为每条命令设置了一个绝对评估时限普通默认值为1000mscareful_company_running_windows预设默认3000ms。这个预算的意义在于保证任何单条命令都不会让智能体无限期等待使用单调墙钟时间计算即使进程被调度挂起、等待磁盘预算依然推进一旦耗尽预算dcg 返回显式的indeterminate结果——请求运维复核或保守拦截绝不会静默放行fail-open。这正是新手容易踩的坑dcg test默认不带任何时限。测试环境里一条命令跑 3 秒允许了到了生产钩子的 1 秒预算里却变成 indeterminate 拦截。这种测试与实际执行不一致是信任杀手。--enforce-budget就是为了消除这个盲区而生的见 CHANGELOG.md 中 v0.7.8 条目Adddcg test --enforce-budgetso operators can reproduce the live hooks effective wall-clock evaluation budget。--enforce-budget 到底应用了哪段预算这是理解该标志的关键细节。在 src/cli.rs 中可以看到注释与设计逻辑钩子模式的时限从读取 stdin 之后开始覆盖自愈、外部 pack 加载和评估全过程CLI 模式刻意不同它从配置解析、智能体检测、外部 pack 加载之后才开始计时只把pack 展开、allowlist 加载、评估计入预算。原因很实际CLI 自身的启动耗时不在任何智能体的钩子窗口内如果把它算进去该标志会报出一个钩子根本不会花掉的预算。换句话说--enforce-budget复现的是钩子模式下评估侧的延迟。它读取的有效预算来源依次为general.hook_timeout_ms配置项环境变量DCG_HOOK_TIMEOUT_MS平台/预设默认值低于10ms的值会被钳制到安全下限。一条命令复现生产钩子延迟安装好 dcg 后最直接的复现方式就是加上--enforce-budget并用你生产的配置dcg test --enforce-budget --config .dcg.prod.toml git status再配上几个常用变体来自 README.md场景命令要点机器可读结果便于写脚本比对加--format json检查decision字段被拦截的危险命令不想出现在命令行里用--stdin从文件读取候选命令只复现 Bash 钩子走的那条单方言路径加--dialect posix想看清为什么被拦/被放行加--explaindcg test的退出码非常友好0表示该命令会被允许1表示会被拦截可以直接接入 CI 流水线做延迟回归门禁。如何解读复现结果复现时你要盯的不是允许/拦截本身而是预算是否被耗尽indeterminate出现 生产上会超时。按 docs/troubleshooting.md 的准则deadline 耗尽必须以indeterminate呈现绝不能是allow也不应伪装成破坏性模式命中。结果正常但担心余量不足对比你测得的全量评估延迟与预算不要把预算压到实测延迟以下。想确认当前生效的预算来源运行dcg config --format json查看hook_timeout_ms与hook_timeout_source两个字段。延迟超标了怎么调优当诊断环境复现出超时正确的调整顺序是参考 docs/troubleshooting.md 的 Hook errors or timeouts 小节先加预算在配置里设置[general] hook_timeout_ms 1500或临时用DCG_HOOK_TIMEOUT_MS1500单进程覆盖缩小评估面减少启用的 pack 数量、检查 heredoc 大脚本解析调低max_body_bytes/max_body_lines量化验证项目自带延迟基准 benches/hook_latency.rs目标是钩子模式保持p99 50ms的智能体响应水平性能基线数据存放在 perf/baselines/可用 scripts/perf_baseline.py 采集、scripts/check_benchmark_budgets.sh 做预算检查再次复现用dcg test --enforce-budget在同一台慢机器上验证调整后的预算刚好覆盖全量评估。小结dcg test --enforce-budget让诊断环境套用生产钩子的有效墙钟评估预算复现钩子延迟行为它只计 pack 展开、allowlist 加载与评估刻意排除 CLI 自身启动开销保证与钩子口径一致超时必须表现为indeterminate这是 dcg fail-closed 安全模型的底线调优闭环dcg config --format json看预算 →dcg test --enforce-budget复现 → 基准脚本量化 → 调整后回归验证。更多细节可阅读 README.md 的Absolute Evaluation Deadline章节与 docs/troubleshooting.md规则与包体系的设计文档见 docs/packs/core.md。【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
调试口保护)
