现象
.github/workflows/contract-guard.yml 对任何改动 .github/workflows/ 的 PR 都会失败，除非该 PR 同时满足两个条件（scripts/workflows/contract-rules.mjs 的 repo-harness 规则 + validateStructuredImpactSummary）：
- 同一个 PR 里带一个
scripts/tests/ 下的契约测试改动；
- PR 正文里有结构化的 GitNexus impact summary（
Risk level / Critical skeleton changes / GitNexus impact / Verification）。
dependabot 两条都给不出：它不会顺手改测试，PR 正文是它自动生成的 release notes。
证据
当前 3 个 dependabot PR 因此长期红：
失败输出（#371，run 30331781880）：
GitNexus contract: failed
- Missing contract test for critical file: .github/workflows/release.yml
- Missing GitNexus impact summary field: Risk level
- Missing GitNexus impact summary field: Critical skeleton changes
- Missing GitNexus impact summary field: GitNexus impact
- Missing GitNexus impact summary field: Verification
影响
一个永远红的 check 不会提高安全性，只会训练维护者忽略 check 面板。repo-guard.yml 出于同样的理由已经跳过 dependabot（github.actor != 'dependabot[bot]'）。
建议修复
给 gitnexus-contract job 加 dependabot 豁免，并在 scripts/tests/workflow-rules.test.mjs 里钉住它。
判定应挂在 PR 作者（github.event.pull_request.user.login）而不是 github.actor：维护者一旦对 dependabot 分支执行 update-branch 或补推一次提交，github.actor 就变成维护者本人，用 actor 判定会让这道必然失败的门禁重新出现——这正是本次处理这批 PR 时实际踩到的情况。
dependabot 升级的把关仍然是 CODEOWNERS 人工审阅 + CI（唯一的 required status check）。
现象
.github/workflows/contract-guard.yml对任何改动.github/workflows/的 PR 都会失败，除非该 PR 同时满足两个条件（scripts/workflows/contract-rules.mjs的repo-harness规则 +validateStructuredImpactSummary）：scripts/tests/下的契约测试改动；Risk level/Critical skeleton changes/GitNexus impact/Verification）。dependabot 两条都给不出：它不会顺手改测试，PR 正文是它自动生成的 release notes。
证据
当前 3 个 dependabot PR 因此长期红：
actions/upload-artifact4 → 7softprops/action-gh-release2 → 3GitGuardian/ggshield1.51.0 → 1.53.0失败输出（#371，run 30331781880）：
影响
一个永远红的 check 不会提高安全性，只会训练维护者忽略 check 面板。
repo-guard.yml出于同样的理由已经跳过 dependabot（github.actor != 'dependabot[bot]'）。建议修复
给
gitnexus-contractjob 加 dependabot 豁免，并在scripts/tests/workflow-rules.test.mjs里钉住它。判定应挂在 PR 作者（
github.event.pull_request.user.login）而不是github.actor：维护者一旦对 dependabot 分支执行 update-branch 或补推一次提交，github.actor就变成维护者本人，用 actor 判定会让这道必然失败的门禁重新出现——这正是本次处理这批 PR 时实际踩到的情况。dependabot 升级的把关仍然是 CODEOWNERS 人工审阅 +
CI（唯一的 required status check）。