Compliance: check-suite-prefs-unreadable

Compliance Finding

Category: settings
Severity: warning
Check: check-suite-prefs-unreadable

Detail

Could not read check-suite preferences — verify GH_TOKEN has repo scope and the repo is accessible. Check-suite auto-trigger compliance was not evaluated.

Standard Reference

standards/github-settings.md

Remediation

Run scripts/apply-repo-settings.sh TalkTerm with a token that has admin access to the repository (requires a classic PAT with repo scope or equivalent):

GH_TOKEN=<admin-pat> bash scripts/apply-repo-settings.sh TalkTerm

This script applies all standard settings defined in standards/github-settings.md in one pass.
For a dry run to preview changes without applying: DRY_RUN=true GH_TOKEN=<admin-pat> bash scripts/apply-repo-settings.sh TalkTerm

This issue was automatically created by the weekly compliance audit.

Dev-Lead Implementation Plan

Issue: #296 — Compliance: check-suite-prefs-unreadable

Root-cause analysis

The audit's check_check_suite_prefs() (in petry-projects/.github/scripts/compliance-audit.sh) issues a GET on repos/{owner}/{repo}/check-suites/preferences. That GitHub endpoint is PATCH-only and returns 404 Not Found for any caller, so the GET yields an empty body and the audit raises the check-suite-prefs-unreadable warning ("compliance was not evaluated"). The audit itself lives in another repo and is out of scope here.

What is fixable in this repo: the auto-generated remediation command bash scripts/apply-repo-settings.sh TalkTerm references a positional-arg signature that this repo's scripts/apply-repo-settings.sh does not support — it only reads GITHUB_REPOSITORY and ignores $1. It also blindly PATCHes both apps even when an app is missing (the standard treats missing as already-compliant) and is not 404-safe.

Scope

Align scripts/apply-repo-settings.sh with standards/github-settings.md#check-suite-auto-trigger-preferences and the documented remediation signature, without regressing the existing apply-repo-settings.yml workflow invocation.

Implementation Checklist

Refactor scripts/apply-repo-settings.sh: resolve target repo from positional $1 (bare name → petry-projects/<name>, or full owner/repo), falling back to GITHUB_REPOSITORY/REPO env (preserves the workflow).
Preserve the existing security_and_analysis enablement behavior.
Fix check-suite handling: read prefs, treat missing/false as compliant (skip), only PATCH apps whose auto-trigger is true; be 404-safe (when prefs are unreadable, apply the disabling PATCH for all configured apps).
Make pure helpers sourceable (guard main so tests can source without executing).

Tests to Write

scripts/apply-repo-settings.test.sh — portable, shellcheck-clean bash tests sourcing the script's pure helpers:
- auto_trigger_status: returns missing / false / true for the relevant prefs JSON shapes and empty input.
- resolve_repo: bare name → petry-projects/<name>; owner/repo passthrough; GITHUB_REPOSITORY fallback.

Test Command

bash scripts/apply-repo-settings.test.sh (plus bash .dev-lead/scripts/dev-lead-lint.sh for shellcheck)

Note on full remediation

Actually applying the settings requires a classic PAT with repo/admin scope (the check-suites API rejects OAuth tokens). This agent's token is OAuth repo-scope, so it cannot mutate live repo settings; an admin must run the script. This PR makes that documented command work correctly when they do.

Dev-Lead: Implementation Complete

Root cause

The check-suite-prefs-unreadable warning originates in the org audit (petry-projects/.github/scripts/compliance-audit.sh), whose check_check_suite_prefs() does a GET on check-suites/preferences — a PATCH-only GitHub endpoint that returns 404 for every caller, so the audit can never read prefs and always emits this warning. That audit is in another repo and out of scope here.

What was actionably wrong in this repo: the auto-generated remediation bash scripts/apply-repo-settings.sh TalkTerm referenced a positional-arg signature this repo's script did not support (it only read GITHUB_REPOSITORY and ignored $1), and it blindly PATCHed both apps even when an app was missing (which the standard treats as already-compliant) without being 404-safe.

Plan Execution

Refactored scripts/apply-repo-settings.sh to resolve the target repo from a positional arg (bare TalkTerm → petry-projects/TalkTerm, or owner/repo), falling back to GITHUB_REPOSITORY/REPO so the existing apply-repo-settings.yml workflow still works
Preserved the security_and_analysis enablement behavior
Fixed check-suite handling: missing/false apps are skipped (compliant), only true apps are disabled, and it is 404-safe (disables all configured apps when prefs are unreadable)
Made pure helpers (resolve_repo, auto_trigger_status) sourceable behind a main guard so they are unit-testable
Added portable, shellcheck-clean unit tests (no bats dependency — not installed in this repo)

Test Results

$ bash scripts/apply-repo-settings.test.sh   (rc=0)
ok   - auto_trigger_status: enabled app -> true
ok   - auto_trigger_status: disabled app -> false
ok   - auto_trigger_status: app absent -> missing
ok   - auto_trigger_status: empty list -> missing
ok   - auto_trigger_status: empty string -> missing
ok   - resolve_repo: bare name -> org/name
ok   - resolve_repo: owner/repo passthrough
ok   - resolve_repo: GITHUB_REPOSITORY fallback
ok   - resolve_repo: REPO env fallback
All tests passed.

$ bash .dev-lead/scripts/dev-lead-lint.sh    (rc=0)
  [lint] shellcheck on 2 file(s)...
  [lint] validating .github/CODEOWNERS...
OK: .github/CODEOWNERS
  [lint] all checks passed

shellcheck (severity=warning, -x) on both files: clean.

Files Changed

scripts/apply-repo-settings.sh: refactored into sourceable helpers + guarded main; positional/env repo resolution; standard-conformant, 404-safe check-suite handling
scripts/apply-repo-settings.test.sh (new): unit tests for auto_trigger_status and resolve_repo

Notes

Full remediation still requires an admin run. The check-suites API rejects OAuth app tokens (verified: 403 with this agent's OAuth repo-scope token); it needs a classic PAT with repo/admin scope. This change makes the documented command behave correctly when an admin runs it — it does not (and cannot) mutate live repo settings from this agent.
The underlying audit false-positive (GET on a PATCH-only endpoint) would need a fix in petry-projects/.github; consider a follow-up issue there if the warning recurs after settings are applied.
No production app code exists in this repo yet (no package.json); the only CI gates here are gitleaks (ci.yml) and dev-lead-lint.sh (shellcheck) — both green.

feat: implement issue #296 — Compliance: check-suite-prefs-unreadable (…

feat: implement issue #454 — Compliance: ruleset-drift-pr-quality-req…

feat: implement issue #296 — Compliance: check-suite-prefs-unreadable (…

Navigation Menu

Repository navigation

Compliance: check-suite-prefs-unreadable #296

Compliance Finding

Detail

Standard Reference

Remediation

Dev-Lead Implementation Plan

Root-cause analysis

Scope

Implementation Checklist

Tests to Write

Test Command

Note on full remediation

Dev-Lead: Implementation Complete

Root cause

Plan Execution

Test Results

Files Changed

Notes

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Compliance: check-suite-prefs-unreadable #296

Description

Compliance Finding

Detail

Standard Reference

Remediation

Activity

don-petry commented on Jun 19, 2026

Dev-Lead Implementation Plan

Root-cause analysis

Scope

Implementation Checklist

Tests to Write

Test Command

Note on full remediation

don-petry commented on Jun 19, 2026

Dev-Lead: Implementation Complete

Root cause

Plan Execution

Test Results

Files Changed

Notes

5 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions