Adopt the fleet check mode into the configure.sh canonical - #393
Merged
Conversation
Most of the fleet (5 of 6 divergent copies) carries a configure.sh with a check/5D-audit mode the hub canonical lacked - the hub was behind the fleet, not the other way round. Adopt the check mode into the canonical and converge the fleet onto it. - repo-config/configure.sh: keep the hub's registry-driven apply logic (model resolution, carry inference, create-or-update rulesets) and restructure into `apply`/`check` subcommands. `apply` additionally enables Dependabot vulnerability alerts + automated security updates (fleet policy the forks already applied). `check` is the read-only inverse and exits non-zero on drift: the ruleset and settings assertions are driven by the committed payloads, so they stay repo-agnostic and survive GitHub normalizing a stored ruleset (rule presence + merge methods + required checks, not a byte diff). Secrets are per-repo and not readable by a standalone carry, so they are a manual-verify note. The command defaults to apply, so the old `configure.sh [owner/repo] [model]` calls still apply. shellcheck-clean; check verified live against a release repo and an operational repo with no false positives. - README/STANDUP/repo-config-carry: document the apply/check interface and security enabling. - spec/divergences.json: configure.sh moves from upstream-candidate/investigate to re-vendor - the hub adopted the mode, so the fleet's forked and stale copies now re-vendor onto the new canonical (downstream follow-up). reports/divergences.md regenerated (UNTRIAGED empty). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the hub’s canonical repo-config/configure.sh to match the fleet by adding a read-only drift detection mode (check) alongside the existing apply behavior (apply, still the default). It also updates onboarding/docs and the divergence ledger/report to reflect the new canonical so downstream repos can be re-vendored consistently.
Changes:
- Restructure
repo-config/configure.shintoapply(write) andcheck(read-only drift detection) modes, and enable Dependabot security features duringapply. - Update documentation to reflect the new
apply/checkCLI and onboarding flow. - Update divergence disposition data and the generated divergence report to reflect that
configure.shshould now be re-vendored across listed repos.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| STANDUP.md | Updates onboarding instructions to use configure.sh apply and the new check validation step. |
| spec/divergences.json | Reclassifies repo-config/configure.sh divergences into a single re-vendor disposition with updated rationale. |
| reports/divergences.md | Regenerates the divergence report to reflect the updated ledger dispositions. |
| repo-config/README.md | Documents the new apply vs check modes and Dependabot security enablement. |
| repo-config/configure.sh | Implements apply/check subcommands, adds drift assertions, and enables Dependabot security features during apply. |
| docs/repo-config-carry.md | Updates carry instructions to run configure.sh apply then configure.sh check for validation. |
- ruleset_id: fetch with per_page=100 in a single request instead of --paginate, so the
response is one JSON array. A paginated fetch concatenates multiple arrays, which the
single-array jq would mishandle. A repo never has more than a handful of rulesets.
- check_ruleset: drive the enforcement assertion from the payload's enforcement field
instead of hardcoding "active", keeping the whole function payload-driven.
- check_security: read automated-security-fixes under an explicit failure guard so a read
error is a clean FAIL rather than a set -e abort. (The endpoint returns 200 JSON
{ enabled, paused } - verified live - so the JSON check stands.)
- STANDUP.md: spell out the check invocation instead of an ellipsis, so it is copy-pasteable.
Re-verified: shellcheck clean, check passes live against a release and an operational repo.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (1)
repo-config/configure.sh:206
- check_security assumes
gh api repos/$repo/automated-security-fixesreturns a JSON body, but GitHub commonly returns 204 No Content when the feature is enabled (and 404 when disabled). In the 204 case,jq_haswill fail on empty input and incorrectly report drift.
check_security() {
local sec
# vulnerability-alerts: 204 enabled / 404 disabled, so probe with gh_ok. automated-security-fixes returns
# a JSON body { enabled, paused }; capture it under an explicit failure guard so a read error is a clean
# FAIL rather than a set -e abort.
Restore the duplicate-name warning the original apply loop had and that the ruleset_id refactor dropped. A repo with more than one ruleset named develop or main (a known drift state) is a real hazard - operating on the first silently could touch the wrong one. Warn to stderr with the count so the duplicates get resolved. grep -c and sed read all input, so neither SIGPIPEs jq under pipefail. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rewrite the semicolon-joined clauses in the header and inline comments as separate sentences (or commas/dashes) per the repo prose convention. Swept the whole file, not just the flagged header line. shellcheck still clean; check still passes live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… modes settings.json is a required base payload, so a missing one is a broken carry, not a no-op. - cmd_apply: pre-flight settings.json and both ruleset payloads before any write, so a partial carry aborts before it half-applies (previously a missing settings.json silently skipped the settings step). Unguard the settings block now that existence is guaranteed. - check_settings: fail cleanly with a drift message when settings.json is missing, instead of letting the jq process substitution abort the script under set -e. Also recast the remaining semicolon-joined echo messages as sentences. shellcheck clean; check passes live and now clean-FAILs (exit 1) when settings.json is absent. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The triage of the
configure.shdivergences found the hub was behind the fleet: 5 of the 6 divergent copies carry acheck/5D-audit mode the hub's apply-only canonical never had. Adopt it into the canonical and converge the fleet.configure.sh
apply/checksubcommands. The command defaults toapply, so existingconfigure.sh [owner/repo] [model]calls still apply.applyadditionally enables Dependabot vulnerability alerts + automated security updates — fleet policy the forks already applied (both test repos already had it on).checkis the read-only inverse, exits non-zero on drift. Ruleset and settings assertions are payload-driven — every rule type, merge method, and required-check context in the committed*.jsonmust be present live — so they stay repo-agnostic and survive GitHub normalizing a stored ruleset (policy check, not a byte diff). Secrets are per-repo and not readable from a standalone carry, so they are a manual-verify note.Verification
shellcheckclean;bash -nclean; LF preserved.checkrun live againstPlexCleaner(release) andESPHome-Config(operational) — all assertions pass, exit 0, no false positives (operational correctly skips the PR/merge/status rules its payload lacks).spec/validate.pygreen;reports/divergences.mdregenerated, UNTRIAGED empty, markdownlint-clean.Downstream follow-up (not this PR)
The ledger moves
configure.shto re-vendor: 6 forked + 8 stale copies now converge onto the new canonical (per-repo re-vendoring, parked in the burn-down). NxWitness's hardcoded-secret check isn't in the repo-agnostic canonical (manual-verify note); it can keep a thin repo-specific wrapper.🤖 Generated with Claude Code