feat(tooling): let every repository keep itself on the standard

.claude-plugin/marketplace.json

@@ -7,7 +7,7 @@
     {
       "name": "lvbt-contributions",
       "description": "Create readable LVBT GitHub issues and pull requests.",
-      "version": "0.4.5",
+      "version": "0.5.0",
       "source": "./packages/cli/plugins/lvbt-contributions"
     }
   ]

.github/workflows/standard-status.yml

@@ -1,37 +1,28 @@
 # Checks every repository in standards/repositories.json against the latest
 # release and the organization settings, and fails when one has drifted:
 # behind the latest release for more than three days, an unreleased vendored
-# commit on main, a failing update pull request, a stale plugin ref, or merge
-# settings that differ from the standard. The job summary lists every
-# repository. A documented, unexpired exception in repositories.json silences
-# one rule for one repository.
+# commit on main, a failing update pull request, a stale plugin ref, a missing
+# org-standard ruleset, or a repository that cannot update itself. The job
+# summary lists every repository. A documented, unexpired exception in
+# repositories.json silences one rule for one repository. Every repository is
+# public, so the workflow's own token reads everything it needs.
 name: Standard status
 
 on:
   schedule:
     - cron: '47 14 * * *'
-  workflow_run:
-    workflows: [Publish standard]
-    types: [completed]
   workflow_dispatch:
 
 permissions:
   contents: read
+  pull-requests: read
 
 jobs:
   status:
     name: Check repositories
     runs-on: ubuntu-latest
     timeout-minutes: 5
     steps:
-      - name: Create the standard bot token
-        id: bot
-        uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
-        with:
-          client-id: ${{ vars.LVBT_BOT_CLIENT_ID }}
-          private-key: ${{ secrets.LVBT_BOT_PRIVATE_KEY }}
-          owner: ${{ github.repository_owner }}
-
       - name: Checkout
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
         with:
@@ -44,5 +35,5 @@ jobs:
 
       - name: Report drift
         env:
-          GH_TOKEN: ${{ steps.bot.outputs.token }}
+          GH_TOKEN: ${{ github.token }}
         run: node standards/status.ts

AGENTS.md

@@ -27,5 +27,7 @@ file is the complete list of durable boundaries for this repository. Do not inve
 feature, file, or task; omit it when the change crosses boundaries.
 
 Nothing is published or tagged from this repository without the maintainer's explicit approval.
-`Publish packages` runs only by hand. Pushing a release tag runs `Publish standard`, which opens a
-self-merging update pull request in every repository in `standards/repositories.json`.
+`Publish packages` runs only by hand. Every repository's daily `Standard update` workflow picks up a
+new release tag and opens an update pull request in that repository, using only that workflow's own
+token. A patch release's pull request merges itself; a minor release's waits for a maintainer. A new
+rule warns for at least one minor release before it fails.

docs/README.md

@@ -9,7 +9,6 @@ reference pages record facts and contracts, and explanation gives the reasoning.
 - [Adopt the standard in an existing repository](how-to/adopt-in-an-existing-repository.md)
 - [Set up a repository's production platform](how-to/set-up-production.md)
 - [Publish a tooling release](how-to/publish-a-release.md)
-- [Set up the standard bot](how-to/set-up-the-standard-bot.md)
 
 ## Reference
 

docs/explanation/packages-and-examples.md

@@ -49,6 +49,6 @@ snapshot. It does not generate or overwrite application-owned configuration.
 
 The organization must keep the packages small and stable, because every repository feels a change to
 them. A repository that needs to diverge does so in its own file, on top of the shared rule, and
-says why in the commit. A release still needs a tag and release notes. The `Publish standard`
-workflow then opens the preset update in every repository, and each one merges once that
-repository's own checks pass.
+says why in the commit. A release still needs a tag and release notes. Each repository's daily
+`Standard update` workflow then opens the preset update in that repository. A patch update merges
+once the repository's own checks pass; a minor update waits for a maintainer.

docs/how-to/adopt-in-an-existing-repository.md

@@ -32,6 +32,8 @@ Copy these from the example, overwriting your versions:
 - `.githooks/commit-msg`, `.githooks/prepare-commit-msg`, `.githooks/pre-push`
 - `.codex/hooks.json` and `.agents/plugins/marketplace.json`
 - `.github/actions/setup-node-pnpm/action.yml` and `.github/renovate.json`
+- `.github/workflows/standard-update.yml`, and give your `ci.yml` a `workflow_dispatch` trigger so
+  the update pull requests it opens run `Validate`
 - `.editorconfig`, `.prettierignore`, `prettier.config.js`
 
 Merge these by hand, keeping what the repository already has:

docs/how-to/create-a-repository.md

@@ -10,7 +10,7 @@ shared rules arrive as ordinary dependencies.
 - Node.js 24 or newer and git are installed on your machine. pnpm is activated by Corepack if it is
   missing (`corepack enable`).
 - You know the repository's durable commit scopes: the two to six boundaries a change can belong to,
-  such as `web`, `worker`, `docs`, `ci`, `dx`. A scope is never a feature, file, task, or role.
+  such as `web`, `worker`, `docs`, `dx`. A scope is never a feature, file, task, or role.
 
 ## 1. Create the repository from a template
 

docs/how-to/publish-a-release.md

@@ -36,25 +36,31 @@ Create the GitHub release from the tag with `gh release create v0.3.0 --generate
 the notes so the first line says what changes for a repository that updates. The release notes page
 `docs/reference/release-<version>.md` belongs in the release commit; `pnpm check` fails without it.
 
-Pushing the tag runs the `Publish standard` workflow. It opens one pull request in every repository
-listed in [`standards/repositories.json`](../../standards/repositories.json), on the branch
-`automation/repository-standard-<tag>`:
+Nothing else is needed to roll the release out. Every repository runs its own `Standard update`
+workflow each day. When it finds a release newer than the one in `.lvbt/web-platform.json`, it opens
+one pull request on the branch `automation/repository-standard-<tag>`, using only that workflow's
+own token:
 
-- Each template repository is regenerated from its example (`examples/basic` for
+- A template repository is regenerated from its example (`examples/basic` for
   [LasVegasForTransit/template-basic](https://github.com/LasVegasForTransit/template-basic),
   `examples/with-astro` for `template-with-astro`, and `examples/with-vite-react` for
   `template-with-vite-react`). These power GitHub's "Use this template" button.
-- Each other repository runs the release's own updater, so the release's migrations apply in one
+- Every other repository runs the release's own updater, so the release's migrations apply in one
   pass however old the repository's current release is.
 
-Every pull request merges itself once its `Validate` check passes; approving the release is the
-review. A newer release closes the older pull requests it replaces. The workflow also runs daily for
-the latest release, which rebuilds an update branch that fell behind `main` and leaves alone a
-branch that someone pushed a fix to.
+A patch release's pull request merges itself once `Validate` passes. A minor release's pull request
+waits for a maintainer to merge it, because a minor release can change how a repository works. A
+newer release closes the older pull requests it replaces, and an update branch that fell behind
+`main` is rebuilt, unless someone pushed a fix to it. To roll a release out sooner, run
+`Standard update` by hand in each repository's Actions tab.
 
-The workflow authenticates as the LVBT standard bot; [set it up](set-up-the-standard-bot.md) once
-before the first release. Manual dispatch accepts stable release tags only; development commits and
-prerelease tags are never published.
+A workflow's own token may not change workflow files. When a release changes one, such as an
+example's `ci.yml`, the update still opens its pull request without that file, and the run fails and
+names the file to copy by hand.
+
+Other contributors depend on the standard staying predictable. A new rule ships as a warning in one
+minor release and becomes a failure only in a later one; the first release's notes say which release
+enforces it, so every repository sees the warning in its own checks first.
 
 ## 3. Publish to GitHub Packages
 
@@ -64,12 +70,12 @@ pnpm configuration to GitHub Packages; CI uses its repository token.
 
 ## 4. Watch the repositories update
 
-The `Standard status` workflow runs daily and after every publication. Its job summary lists each
-repository's release and open update pull request, and it fails when a repository has drifted:
-behind the latest release for more than three days, an unreleased vendored commit on `main`, a
-failing update pull request, a contribution plugin ref that differs from the vendored release, or
-merge settings that differ from the standard. Run the same check locally with
-`pnpm standards:status`.
+The `Standard status` workflow runs daily. Its job summary lists each repository's release and open
+update pull request, and it fails when a repository has drifted: behind the latest release for more
+than three days, an unreleased vendored commit on `main`, a failing update pull request, a
+contribution plugin ref that differs from the vendored release, a missing `org-standard` ruleset, or
+no way to update itself (no `standard-update.yml`, or a `ci.yml` without `workflow_dispatch`). Run
+the same check locally with `pnpm standards:status`.
 
 A failing update pull request means the repository needs a change the updater could not make. Fix it
 on the update branch; the pull request then merges itself. A repository that must diverge from one