AntFleet

Disagreement · 32b75da9-anthropic-2

Bot allowlist is matched on owner login but membership semantics are ambiguous

mismatch
repo 6f7fc663·PR #27·reviewed 1 week ago

Primary finding

Bot allowlist is matched on owner login but membership semantics are ambiguous

lowbuglow
  • skills/fork-first-run-alert/SKILL.md:152-156
The allowlist contains `[bot]`-suffixed logins, but fork owners on GitHub cannot have `[bot]` in their login when listed via the forks API (those are GitHub Apps, not users that can hold forks). The values may therefore never match, making the suppression effectively dead code while suggesting a guarantee that won't hold if a real human owner ever uses `dependabot` as a username. Same comment may exist in fork-cohort; either way the doc misleads about what's filtered.

Recommendation

Clarify whether the allowlist matches on `owner.type == "Bot"` (the right field) or on raw login without the `[bot]` suffix; align with fork-cohort's actual implementation.

Counterpart finding

Inconsistent field name between captured run metadata ('name') and template fallback ('workflow_name')

lowdocs-gaphigh
  • skills/fork-first-run-alert/SKILL.md:149-152
  • skills/fork-first-run-alert/SKILL.md:154-156
  • skills/fork-first-run-alert/SKILL.md:182-184
The jq selection captures the field as 'name', but later documentation and templates refer to 'workflow_name'. This mismatch can lead to empty fallback values in notifications if implementers follow the template literally.

Recommendation

Standardize on 'name' throughout, or explicitly rename during capture: '{workflow_name: .name, display_title, updated_at, html_url}'. Update the template and state schema references accordingly.

Why this didn't post

This finding didn't meet AntFleet's unanimous agreement threshold. Both frontier models review every PR independently; only findings they both flag with the same severity and category are posted to the PR. This one fell through.

read the methodology →