No tool manages a deployment environment, and GOVERNANCE.md still says a repo carries ruleset payloads #1482

Two findings from finishing ptr727/aiopurpleair's repo-config/ retirement (ptr727/aiopurpleair#104). Both are about the same transition: docs/repo-config.md:16 says "Downstream repositories carry no repo-config/ directory", and the surrounding surfaces have not all caught up.

1. GOVERNANCE.md "Hub-Hosted Tooling" contradicts docs/repo-config.md

Read on main at 8195c43, GOVERNANCE.md:126:

What a repository carries and what it reaches is decided by what the content is. It carries the content it is audited against and the configuration that describes it, meaning its rule text, the files the manifest declares, and the ruleset payloads its own audit diffs the live configuration against.

The emphasised clause is false for every repository that has completed this retirement. LanguageTags, Utilities and PlexCleaner already carry no repo-config/, aiopurpleair is completing it now, and configure.sh check diffs the live rulesets against the hub's payloads rather than against anything downstream.

The clause is not merely stale prose. An agent running AUDIT.md against a converged repository reads this rule, finds no ruleset payloads in the tree, and has grounds to record a branch-model miss for content the fleet deliberately retired.

spec/files.json declares this section fidelity: verbatim, so a downstream repository cannot fix it locally without registering as drift on the next fidelity check. It has to move here. aiopurpleair#104 routes it rather than editing its copy.

2. No tool applies or checks a deployment environment, and nothing says so

repo-config/configure.sh has no environment handling at all: cmd_check runs check_ruleset, check_settings, check_security and check_labels, and there is no apply_environment counterpart in cmd_apply. spec/audit.py does not reach one either, and spec/secrets.json's own note already concedes the adjacent case, that neither tool can enumerate an environment-scoped store.

For most of the fleet that is harmless, because most repositories use no deployment environment. LanguageTags and Utilities publish to NuGet over OIDC and have none. aiopurpleair does: its publish-pypi job runs in a pypi environment whose deployment-branch policy is what stops a dispatch from an unintended ref minting a publish token. That policy is a real half of the OIDC publish gate and nothing mechanical watches it.

The history makes the gap concrete. The retired per-repo configure.sh carried a check_environment that asserted custom_branch_policies == true, protected_branches == false, and an exact allowed-branch set. Retiring the carried script removed that check, and the hub-hosted replacement never had one, so the retirement is a net loss of coverage for any repository using an environment. aiopurpleair has moved the intended state into its own AUDIT.md section 4 as prose with the gh api commands and expected values, which is the best a single repository can do and is not a fleet answer.

Worth deciding:

1. Whether configure.sh should manage deployment environments, restoring apply_environment/check_environment hub-side, driven by a registry field so only repositories that declare one are checked.
2. Or whether environments stay out of scope deliberately, in which case say so where a reader looks, since the current silence reads as "covered" rather than "out of scope". docs/repo-config.md and WORKFLOW.md's D8.5 are the two places that imply full coverage today.

Option 2 is legitimate. What is not is the present state, where a repository retires a working check on the strength of a hub replacement that does not contain it, and nothing in the process surfaces the difference.

Related

Same transition as #1472, #1473 and #1475, all filed from this repository's resync. This one differs in that half of it (finding 1) is a straightforward correction and the other half is a scope decision.

Not filed here

No audit report or registry change is being written back. aiopurpleair#104 lands without either finding resolved, since its own copy cannot fix the first and the second is fleet scope.