Simplify SECURITY.md and security-audit.yaml

Five focused trims:
- Cron-time bug: header callout said 07:13 UTC; the cron is
  21 4 * * * (04:21 UTC). Match the doc to the code.
- AUDIT_PAT pre-check heredoc compresses from 16 lines to 5; the
  failure report links back to SECURITY.md instead of inlining
  provisioning steps.
- Define "agent-managed workflows" once near the top of GitHub
  Actions Policies, drop the parenthetical enumeration from the
  two later FAIL IFs that referenced it.
- Audit prompt drops a duplicated $GH_TOKEN description and a
  redundant "available environment" trailer; same instructions in
  ~30 lines instead of ~50.
- "Audit visibility" paragraph reduced from 4 sentences to 2 —
  the gap-resistant timestamp mechanism doesn't need to live in
  SECURITY.md, it's an implementation detail of the workflow.

Net: -36 lines across the two files, same behavior.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: nedtwigg

.github/workflows/security-audit.yaml

@@ -49,27 +49,10 @@ jobs:
         env:
           AUDIT_PAT: ${{ secrets.AUDIT_PAT }}
         run: |
-          if [ -n "$AUDIT_PAT" ]; then
-            echo "AUDIT_PAT present."
-            exit 0
-          fi
+          [ -n "$AUDIT_PAT" ] && exit 0
           echo "FAIL" > audit-status.txt
-          cat > audit-report.md <<'EOF'
-          ## Summary
-
-          **Overall status: FAIL.** `AUDIT_PAT` is not present in the
-          `security-audit` environment.
-
-          The audit refuses to run without `AUDIT_PAT`. It needs read-only
-          `Administration`, `Secrets`, and `Environments` access to
-          verify the ruleset, secret, and environment FAIL IFs.
-
-          Provision per `SECURITY.md` > CI Validation Contract: mint a
-          fine-grained PAT scoped to this repository only, then run
-          `gh secret set AUDIT_PAT --env security-audit --repo
-          diffplug/dormouse`.
-          EOF
-          echo "::error::AUDIT_PAT secret is not set in the security-audit environment."
+          echo "**FAIL** — \`AUDIT_PAT\` is not present in the \`security-audit\` environment. See [SECURITY.md > CI Validation Contract](https://github.com/$GITHUB_REPOSITORY/blob/main/SECURITY.md#ci-validation-contract) for provisioning." > audit-report.md
+          echo "::error::AUDIT_PAT secret is not set."
           exit 1
 
       - name: Audit against SECURITY.md
@@ -89,56 +72,37 @@ jobs:
           # writing audit-status.txt.
           claude_args: '--allowed-tools "Read,Write,Edit,Bash,Grep,Glob"'
           prompt: |
-            You are auditing this repository against SECURITY.md. The
-            specifications are concrete `FAIL IF` lines plus the
-            explicit clause that the list is not exhaustive — any code
-            change that creates a security hole or reveals an existing
-            one should fail this job.
-
-            Process:
-              1. Read SECURITY.md.
-              2. For each `FAIL IF` line, identify the mechanical check
-                 (gh api, grep, file presence, running a script) and
-                 execute it. Record PASS or FAIL with concrete evidence
-                 — file path and line number, API response excerpt, or
-                 command output.
-              3. After the FAIL IF list is exhausted, do a qualitative
-                 pass. Inspect `.github/workflows/`, `.config/tend.yaml`,
-                 `.github/dependabot.yml`, `scripts/`, and any code that
-                 references secrets, for security holes the specs don't
-                 cover.
-
-            `$GH_TOKEN` is the `AUDIT_PAT` — a fine-grained,
-            read-only PAT scoped to Administration + Secrets +
-            Environments. A previous workflow step has already verified
-            the token is present, so you can assume it is. If `gh api`
-            returns 403 / "Resource not accessible by integration" on
-            any check, record that check as `FAIL` with a note that
-            `AUDIT_PAT`'s scope has drifted from what SECURITY.md
-            specifies — do not treat it as `UNVERIFIABLE`. Reserve
-            `UNVERIFIABLE` for the rare case where an endpoint is
-            genuinely indeterminable (e.g. a transient network error),
-            and note explicitly why in the report.
-
-            Produce a Markdown report with three sections:
+            Audit this repository against SECURITY.md. The `FAIL IF`
+            lines are concrete checks; the spec also says the list is
+            not exhaustive, so flag any other security hole you find.
+
+            For each `FAIL IF`, run the mechanical check (`gh api`,
+            grep, file presence, or a script) and record PASS or FAIL
+            with concrete evidence — file path and line number, API
+            response excerpt, or command output. Then do a qualitative
+            pass over `.github/workflows/`, `.config/tend.yaml`,
+            `.github/dependabot.yml`, `scripts/`, and any code that
+            touches secrets.
+
+            `$GH_TOKEN` is the `AUDIT_PAT` — a fine-grained, read-only
+            PAT covering Administration + Secrets + Environments,
+            guaranteed present by the previous step. If `gh api`
+            returns 403 on any check, record FAIL with the note "PAT
+            scope drifted from SECURITY.md"; reserve `UNVERIFIABLE`
+            only for genuinely indeterminable cases (e.g. a transient
+            network error) and explain why.
+
+            Write `audit-report.md` with three sections:
               - `## FAIL IF results` — one line per check with PASS/FAIL
-                and concrete evidence
-              - `## Qualitative findings` — free-form findings with
-                severity (BLOCKER / WARNING / INFO)
+                and evidence
+              - `## Qualitative findings` — severity BLOCKER / WARNING / INFO
               - `## Summary` — overall PASS or FAIL with a one-paragraph
                 rationale
 
-            Write the report to `audit-report.md` in the workspace.
-            Write `PASS` or `FAIL` (no other text, no newline required)
-            to `audit-status.txt`. Status is FAIL if any `FAIL IF` is
-            violated or any qualitative finding is BLOCKER severity.
-            Do not call `exit`; the next workflow step inspects the
-            status file and surfaces the result.
-
-            Available environment: `$GH_TOKEN` is the workflow's
-            GitHub token (read repo, write issues), `$GITHUB_REPOSITORY`
-            is `owner/name`. Use `gh api` for GitHub configuration
-            queries (rulesets, secrets, environments, collaborators).
+            Write `PASS` or `FAIL` (no other text) to `audit-status.txt`.
+            Status is FAIL if any `FAIL IF` is violated or any
+            qualitative finding is BLOCKER. Do not call `exit` — the
+            workflow inspects the status file.
 
       - name: Surface result, file or close issue
         if: always()

SECURITY.md

@@ -1,6 +1,6 @@
 # Security
 
-> **Audited automatically.** This spec is checked against the repository by [`security-audit.yaml`](.github/workflows/security-audit.yaml) on a 24-hour schedule (07:13 UTC) and as a required gate before every VS Code release. Each failure is filed as an issue labeled [`security-audit-failure`](https://github.com/diffplug/dormouse/issues?q=is%3Aissue+label%3Asecurity-audit-failure) — open ones are live, closed ones are the historical record of what tripped past audits and what changed to clear them.
+> **Audited automatically.** This spec is checked against the repository by [`security-audit.yaml`](.github/workflows/security-audit.yaml) on a 24-hour schedule (04:21 UTC) and as a required gate before every VS Code release. Each failure is filed as an issue labeled [`security-audit-failure`](https://github.com/diffplug/dormouse/issues?q=is%3Aissue+label%3Asecurity-audit-failure) — open ones are live, closed ones are the historical record of what tripped past audits and what changed to clear them.
 
 Dormouse is a terminal, so users trust it with shells, source trees, credentials, and local files. The dependency graph and release pipeline is part of the product's security boundary.
 
@@ -23,7 +23,7 @@ New npm package versions are not adopted immediately. The workspace uses pnpm's
 
 GitHub Actions are always pinned by commit hash, not version tag. Dependabot will update the hashes as necessary.
 
-The agent-managed workflows (`tend-*.yaml`, `workflow-audit.yaml`, and `security-audit.yaml`) are exempt from the two rules below because they run Claude-powered automation that requires modifying issues, PRs, or code, or fetching an OIDC token. Their scope is bounded separately in the "Automated Maintainer" section.
+**Agent-managed workflows** are `tend-*.yaml`, `workflow-audit.yaml`, and `security-audit.yaml`. They implement the repo's automation and self-audit infrastructure, and are exempt from the two rules below because they need to modify issues, PRs, or code, or fetch an OIDC token. Their bounded scope is defined in the "Automated Maintainer" section.
 
 - FAIL IF `pull_request_target` appears in any `.github/workflows/**` file other than `tend-*.yaml`.
 - FAIL IF a non-agent-managed workflow grants write permissions other than the explicitly scoped release provenance permissions `id-token: write` and `attestations: write`.
@@ -40,7 +40,7 @@ This repository runs the [tend](https://github.com/max-sixty/tend) agent harness
 
 **Upstream compromise.** Tend's action is pinned by commit SHA (`max-sixty/tend@<sha>`) in every generated workflow, so silent updates to the running setup are not possible. `uvx tend@latest` runs only at install and during nightly regen; a compromise of that path would affect the next re-run, not the in-flight workflows.
 
-**Audit visibility.** `workflow-audit.yaml` is a nightly job that walks every commit touching `.github/workflows/` since its previous successful run (using the GitHub API's timestamp as the lower bound, so a failed run pushes the window forward rather than dropping commits). It opens an issue summarizing each commit's author, refs, and changed files. A bot push that adds a new workflow file is visible in the next successful audit even if the bot tries to silently modify the audit workflow — the modification itself appears in the audit.
+**Audit visibility.** `workflow-audit.yaml` is a nightly job that walks every commit touching `.github/workflows/` since its previous successful run, opening an issue summarizing each. A bot push that disables or modifies the audit itself is caught in the next successful run's diff window.
 
 - FAIL IF the repository ruleset named `Merge access` is missing, doesn't target `~DEFAULT_BRANCH`, blocks anything other than `update`, or doesn't have admin (`RepositoryRole` actor `5`) as its sole bypass actor.
 - FAIL IF the repository ruleset named `Tag operations` is missing, doesn't target `~ALL` tags, doesn't block both `creation` and `update`, or doesn't have admin-only bypass.
@@ -50,8 +50,8 @@ This repository runs the [tend](https://github.com/max-sixty/tend) agent harness
 - FAIL IF `AUDIT_PAT` is missing from the `security-audit` environment, or is present at the repo level instead. The audit refuses to run without it, and it must be env-scoped so a bot-pushed feature branch cannot reach it.
 - FAIL IF `CHROMATIC_PROJECT_TOKEN` is missing from `secrets.allowed` in `.config/tend.yaml`. The allowlist entry is an explicit acknowledgment that the bot can read this token.
 - FAIL IF `.github/workflows/workflow-audit.yaml` is missing, disabled, or has not produced a successful run in the last 48 hours.
-- FAIL IF any `tend-*.yaml` workflow uses an unpinned action reference (e.g. `@main`, no version). Inside `tend-*.yaml`, both tag pins (`@v6`, `@0.0.25`) and SHA pins are accepted because the file is owned by the upstream generator (`max-sixty/tend`), which currently uses tag pins. All actions in every other workflow — including `workflow-audit.yaml` and `security-audit.yaml` — must follow the SHA-pin rule in "GitHub Actions Policies".
-- FAIL IF any agent-managed workflow (`tend-*.yaml`, `workflow-audit.yaml`, `security-audit.yaml`) grants a permission beyond `contents: write`, `pull-requests: write`, `issues: write`, `id-token: write`, `actions: read`, or any `read` permission.
+- FAIL IF any `tend-*.yaml` workflow uses an unpinned action reference (e.g. `@main`, no version). Tag pins are accepted inside `tend-*.yaml` because the file is owned by the upstream generator; every other workflow — agent-managed or not — must SHA-pin per the rule above.
+- FAIL IF any agent-managed workflow grants a permission beyond `contents: write`, `pull-requests: write`, `issues: write`, `id-token: write`, `actions: read`, or any `read` permission.
 
 ## VS Code Extension Releases