chore(contributors): automated audit script + weekly GitHub Action

[masukai]

Summary

Closes the recognition-gap detection loop that surfaced 3 distinct forgotten action items during the #531 / #619 / #620 conversation. After this lands we get a weekly tracking issue when .all-contributorsrc falls out of sync, instead of relying on someone noticing in the middle of an unrelated thread.

What landed

File	Purpose
scripts/check_contributors.sh	Three audit checks (URL drift / missing entries / overdue Triage invitations) — exit 0 clean / 1 mismatch / 2 script error
Makefile (+ check-contributors target)	Local sibling to check-i18n / check-changelog / check-skills
.github/workflows/contributors-audit.yml	Weekly Monday 00:30 UTC run — opens / updates a tracking issue when a gap is detected

The three checks

#	Check	Failure mode it would have caught
1	Profile URL drift between README.md and .all-contributorsrc	#616 → #617 → #620 (Muawiya YouTube URL still in source-of-truth after README was hand-fixed)
2	Contributors with merged PRs missing from .all-contributorsrc	@yodakanohoshi (co-Owner!) missing through 4 merged PRs and the v0.7.8 cut — discovered manually only during the #531 conversation. Also flags @Photon101 (9 PRs!) and @kiwamizamurai who #620 missed initially
3	Triage Collaborator eligibility per GOVERNANCE.md (5+ merged PRs, active last 30 days)	Would have given a definitive answer to "wait, is Muawiya not Triage Collaborator yet?" — instead of having to grep collaborator lists manually

Bot filtering

Check 2 filters out *[bot], dependabot, renovate, and github-actions accounts so they're not flagged as "missing contributors".

Sample output (against current main before #620 merges)

=== Check 1: profile URL drift (.all-contributorsrc vs README.md) ===
  ✗ @Muawiya-contact: drift
      .all-contributorsrc: https://www.youtube.com/@Coding_Moves
      README.md:        https://muawiya-contact.github.io/muawiya-portfolio/

=== Check 2: contributors with merged PRs missing from .all-contributorsrc ===
  ✗ missing entries (these accounts have merged PRs but no entry):
      @Deadpool2000: 1 merged PRs
      @Godzilaa: 1 merged PRs
      @Photon101: 9 merged PRs
      @kiwamizamurai: 2 merged PRs
      @nvphungdev: 1 merged PRs
      @safridwirizky: 1 merged PRs
      @sap6011: 1 merged PRs
      @yodakanohoshi: 4 merged PRs

=== Check 3: GOVERNANCE.md Triage Collaborator eligibility (5+ merged PRs, active last 30 days) ===
  ✓ no overdue Triage Collaborator invitations

After #620 merges, Check 1 + the @yodakanohoshi line of Check 2 will go away. I'll add @Photon101 and @kiwamizamurai to #620 before it merges (real misses the script just surfaced). The remaining 1-PR drive-by contributors will get a separate metadata pass.

Workflow behaviour

The weekly Action runs bash scripts/check_contributors.sh. On non-zero exit:

• If a tracking issue titled "chore(contributors): weekly audit found gaps in .all-contributorsrc" is already open, the workflow appends a comment with the new report (so multiple weeks of drift don't fragment).
• Otherwise, it opens a fresh tracking issue with the report.

This matches the pattern used by check-changelog-required (#590) — surface gaps as actionable signals, never silently accumulate.

Out of scope (intentionally deferred)

• Phase 2c — PR-label → all-contributors badge auto-suggest. Depends on whether the @all-contributors GitHub App is installed on the repo and on the bot accepting webhook-invoked commands. Needs a separate check before wiring.
• Phase 3 (Monthly Contributor Spotlight policy + Owner promotion criteria automation): policy decisions, needs co-Owner discussion via GOVERNANCE.md process.

Test plan

• bash scripts/check_contributors.sh locally — output above
• make check-contributors — same exit code
• Bot filtering verified (allcontributors[bot] / dependabot[bot] no longer in "missing" list)
• CI green on this PR
• Workflow dispatched manually after merge to validate the issue-opening path

[skip changelog] — tooling-only addition, no user-facing or release-note impact.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[masukai]

@yodakanohoshi — small ping when you have a window 🙏

Scripts + Makefile target + weekly GitHub Action that audits .all-contributorsrc for drift, missing entries, and Triage Collaborator eligibility. CI green, the script was the one that surfaced @Photon101 / @kiwamizamurai as missing on #620.

No rush — just flagging.

[yodakanohoshi]

Nice — this closes the recognition-gap loop cleanly. The 0/1/2 exit-code contract and the bot filtering both look right, and it already proved itself surfacing @Photon101 / @kiwamizamurai on #620.

One thing to sanity-check: the create path uses --label "chore,contributors", but I don't see a contributors label in the repo or in .github/labels.yml (didn't verify exhaustively). If it's genuinely absent, gh issue create would fail on the first run that opens an issue — the comment-update branch is fine. Probably cleanest to add it to labels.yml so sync-labels owns it rather than a manual gh label create. Want me to fold that in?

Otherwise good to go — happy to merge once the label question is settled.

[masukai]

Great catch — you're right, contributors didn't exist (only chore did), so the first run that opens an issue would've hard-failed on gh issue create. Fixed in two parts:

1. .github/labels.yml — added contributors under a new "Meta" section so sync-labels owns it as the source of truth, exactly as you suggested. Colour 5319e7 (governance purple), description tied to the recognition/governance automation.

2. workflow self-bootstrap — added an idempotent gh label create contributors --force || true right before the gh issue create in the open-new-issue branch. This makes the workflow self-sufficient: it can open its tracking issue even on a fresh repo state, without depending on make sync-labels having run first. --force is update-or-create, and labels.yml stays the SSoT (sync-labels reconciles colour/description on its own runs).

I went with both rather than just labels.yml because of the bootstrap-ordering window — labels.yml is declarative, so the label only materialises when sync-labels runs, and the audit could fire (weekly cron / push to main) before that. The self-bootstrap guard closes that window so a missing label can never hard-fail the issue creation. The duplicated colour/description in the guard is cosmetic — sync-labels overwrites it from labels.yml.

Thanks for not letting that slip through — it's exactly the kind of first-run failure that's invisible until it bites. Ready for another look. 🙏

[yodakanohoshi]

The self-bootstrap guard is the better call — closing the labels.yml-vs-cron ordering window so a fresh-state run can't hard-fail on gh issue create is exactly the right move, and keeping labels.yml as the SSoT while --force handles the bootstrap is clean. Verified contributors is now in labels.yml and the guard sits ahead of the create. CI green.

Approving. Thanks for the fast turnaround 🙏