tend check: configuration drift on diffplug/dormouse

[dormouse-bot]

tend check reports the following configuration drift on diffplug/dormouse. These require maintainer/admin action (creating a protected environment, moving secrets, gating deployment refs) — the bot cannot fix them itself.

• environment (FAIL): Environment tend not found. Operational secrets must live in it, gated to admin-only refs, or a workflow pushed to any branch can read them. Run tend check --fix to create it admitting main, then move each secret into it and delete the repo-level copy.
• secret-environments (FAIL): Environment security-audit holds secrets and is reachable by a run the bot can cause — it has no required reviewers, admits tags, and no active all-tags ruleset restricting creation/update to admins could be verified. Gate it with a required reviewer that is not the bot, or a deployment policy naming only verified refs (protected branches, or tags under an admin-only all-tags ruleset).
• repo-secret-allowlist (FAIL): Unexpected repo-level secrets (CLAUDE_CODE_OAUTH_TOKEN, TEND_BOT_TOKEN) are available to all workflows, including those triggered by PRs. Move release secrets to a protected environment, or if intentionally available add them to secrets.allowed in .config/tend.yaml. See docs/security-model.md.

Two checks (secrets, claude-auth) are SKIP because the tend environment can't be listed without it existing / admin access — resolving the environment FAIL should clear those too.

Last refreshed: 2026-08-03

[dormouse-bot]

Confirmed via triage: none of these three FAILs are bot-fixable — each needs repo admin access (create a protected environment, set a required reviewer / deployment policy, relocate secrets), which the CI bot doesn't hold. No code change in this repo remediates them.

One nuance worth flagging before acting on repo-secret-allowlist: the two flagged secrets (CLAUDE_CODE_OAUTH_TOKEN, TEND_BOT_TOKEN) are tend's own operational tokens, so adding them to secrets.allowed in .config/tend.yaml only silences the check — it leaves them readable by any PR-triggered workflow. The protected-environment route (move them into the tend environment, delete the repo-level copies) is the one that actually closes the exposure. The allowlist is only the right call for a secret you've deliberately decided should stay repo-wide.

The environment FAIL is the linchpin: creating the tend environment (admitting main) and moving the secrets into it also clears the two SKIP checks (secrets, claude-auth), which can't be evaluated until the environment exists.

(Note: the docs/security-model.md pointer in the report is tend's own doc, not a file in this repo — nothing to add here for it.)