docs: GitHub Actions is back on — correct the prose that says otherwise

Actions was disabled 2026-09-16 and re-enabled 2026-09-20; the API confirms
`{"enabled":true}` and runs are landing on main. Ten passages across AGENTS.md
and docs/RELEASING.md still told the reader the opposite, including that
`ci-local.sh` is "the only thing that runs" the hosted lanes, that a `v*` tag
fires nothing, and that the NuGet, PyPI and Maven publish triggers are
inoperative.

That is worse than merely stale in RELEASING.md, which is read WHILE cutting a
release: it would have talked the next cut out of the tag-triggered conformance
and integration gates, and out of the only NuGet path there is.

Records why it came back, because the reason is a constraint and not a
preference: publish-csharp.yml uses Trusted Publishing, and the short-lived
nuget.org key is minted by `id-token: write` inside a workflow run. There is no
long-lived NuGet key — only a NUGET_USER username — so with Actions off, NuGet
cannot be published at all. The other three registries publish locally in the RC
dance and must, because publish-python.yml and publish-java.yml take no version
override and would publish the committed, non-RC version; that caveat is now
stated at both of those steps rather than left implicit.

Keeps publish-leak-scan-status.sh documented rather than dropped: main's
protection requires the leak-scan status, hygiene.yml publishes it again now,
but a direct admin push to main bypasses branch protection and so never gets a
PR's hosted scan. Also records the toggle's own trap — `-F enabled=true` for a
typed boolean, since `-f` sends the string and 422s.

History is kept where it explains a decision, marked as history, instead of
being deleted outright.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015NrWUxA6euwvnFcwKxcK6A

Author: dmealing

AGENTS.md

@@ -109,31 +109,39 @@ runs — goes red, and a direct admin push to `main` bypasses branch protection.
 skipped entirely for non-TS pushes). Bypass in an emergency with `git push --no-verify`
 or `SKIP_TS_TYPECHECK=1 git push`.
 
-**GitHub Actions is DISABLED on this repository (2026-09-16) — every check runs locally.**
-The workflow files are kept and unchanged, because the switch is reversible, but nothing in
-`.github/workflows/` fires today: not `hygiene.yml`'s leak scan on a PR, not `conformance.yml`'s
-nightly + `v*`-tag matrix, and not `local-ci.yml` on the self-hosted runner. **`scripts/ci-local.sh`
-is now the only thing that runs them**, and it already mirrors all three — `--quick` covers
-`hygiene.yml` in full plus the TypeScript half of `conformance.yml`, and the flagless full run
+**GitHub Actions is ENABLED (re-enabled 2026-09-20, and it stays on).** It was off from
+2026-09-16, and a good deal of the prose below was written for that period — read any claim
+that "nothing fires" as history. It came back because **NuGet cannot be published without
+it**: `publish-csharp.yml` uses Trusted Publishing (OIDC), and the short-lived key is minted
+by `id-token: write` INSIDE a workflow run. There is no long-lived NuGet key to publish with
+locally — only a `NUGET_USER` username. The other three registries publish LOCALLY in the RC
+dance and must: `publish-python.yml` and `publish-java.yml` take no version override, so they
+would publish the committed (non-RC) version; only `publish-csharp.yml` has a `version` input.
+(To toggle it: `gh api -X PUT repos/<owner>/<repo>/actions/permissions -F enabled=true` — `-F`
+for a TYPED boolean, since `-f` sends the string `"true"` and 422s.)
+
+**`scripts/ci-local.sh` is still the pre-PR gate**, and it mirrors the hosted lanes —
+`--quick` covers `hygiene.yml` in full plus the TypeScript half of `conformance.yml`, and the
+flagless full run
 adds the C#/Java/Kotlin/Python conformance lanes, the Java reactor and `integration-tests.yml`'s
 Testcontainers matrix. Run `--quick` before opening a PR and the full script before a tag;
 `MO_CI_LIST_ONLY=1 scripts/ci-local.sh [flags]` prints what a selection would run without
 running it. The no-mistakes validation gate runs the script for you — see `.no-mistakes.yaml`,
 whose `lint` and `test` commands partition `--quick` between the two steps. That file is read
 from the **default branch**, so it does nothing until it is merged to `main`.
 
-**A green `leak-scan` check on a PR is a LOCAL scan, not a hosted one.** `main`'s protection
-requires that one status, and `hygiene.yml` was the only thing that ever published it — so with
-Actions off, nothing could merge. Rather than weaken the rule, `scripts/publish-leak-scan-status.sh`
-runs `.githooks/leak-scan.sh` and reports that exact result as the `leak-scan` commit status,
-bound to the SHA it scanned. Run it after pushing, once per head you want mergeable. It publishes
-the real verdict only — a failed scan publishes `failure` — and refuses outright on a dirty tree,
-on a HEAD that moved mid-scan, or with no credential. The status description repeats the caveat,
-so the PR page carries it too. No hosted scan runs while Actions is off, on any branch.
+**`leak-scan` is hosted again.** `main`'s protection requires that one status, and `hygiene.yml`
+is the only thing that publishes it — so while Actions was off, nothing could merge. Rather than
+weaken the rule, `scripts/publish-leak-scan-status.sh` runs `.githooks/leak-scan.sh` and reports
+that exact result as the `leak-scan` commit status, bound to the SHA it scanned. With Actions on
+you do NOT need it; keep it for the next time Actions is off, and for a direct admin push to
+`main` (which bypasses branch protection and so never gets a PR's hosted scan). It publishes the
+real verdict only — a failed scan publishes `failure` — and refuses outright on a dirty tree, on
+a HEAD that moved mid-scan, or with no credential. A status it published is a LOCAL scan, and its
+description says so on the PR page.
 
 **Lane selection is "not known-green", not "affected"** (`scripts/ci-ports-to-run.sh`).
-This is how `local-ci.yml` chooses its lanes, so it is dormant while Actions is off — but
-it is still committed and still gated, and it is what resumes if Actions comes back.
+This is how `local-ci.yml` chooses its lanes, and with Actions back on it is live again.
 The selector unions the ports this push touched (`scripts/ci-affected-ports.sh`) with
 the ports whose *newest* verdict on `main` is not a success, read from the workflow's
 own run history — so a stale red lane gets **re-run**, not merely reported. Affected

docs/RELEASING.md

@@ -201,11 +201,11 @@ Publish in tier order so a dependent never lands before its dependency. **`forge
    a review found eight defects in 172 lines. If you change a gate, change its case there —
    and check the change against a mutation, not just a green run.
 
-   **A second effect, dormant while Actions is off.** `conformance.yml` and
-   `integration-tests.yml` used to be the heavy gates that ran on a `v*` tag and nowhere
-   else; today they run nowhere, and step 3 above is what gates the cut instead. The
-   ordering still earns its place, because if Actions is re-enabled those runs land on the
-   FINAL coordinated tree — all four registries bumped, docs refreshed, payload true —
+   **A second effect.** `conformance.yml` and `integration-tests.yml` are the heavy gates
+   that run on a `v*` tag and nowhere else. (They were dormant while Actions was off,
+   2026-09-16 to 09-20, and step 3 above was what gated the cut instead; step 3 still
+   earns its place, because it is the only gate that runs BEFORE the tag.) The ordering
+   matters because those runs land on the FINAL coordinated tree — all four registries bumped, docs refreshed, payload true —
    instead of the npm-only commit, which is a tree that never actually shipped.
    `publish-npm.yml` triggers on `npm-v*`, not `v*`, so moving the tag does not re-trigger
    a publish.
@@ -264,7 +264,7 @@ days**.
 
 **The gate: `node scripts/check-metamodel-version.mjs`** (runs in the `gates` lane, so any
 `scripts/ci-local.sh` run that includes `gates` enforces it — `--quick`, `--only gates`, or
-the flagless full run; hosted CI does not, because Actions is disabled here). It diffs
+the flagless full run). It diffs
 `expected-registry.json` — already the byte-exact bill of materials every port is gated
 against — against its content at the **last release tag**, classifies every difference,
 and fails if the declared version did not move by at least the amount the change
@@ -408,11 +408,10 @@ diff explained.
   > improvement (research-backed, not yet adopted)" that `.claude/skills/releasing/SKILL.md`
   > still files it under.
   >
-  > **That replacement is itself inoperative right now: GitHub Actions is disabled on this
-  > repository (2026-09-16), so `publish-npm.yml` cannot fire** and a registration would have
-  > no runner to serve it. The publishing path that replaces the token after the 2027
-  > deadline is being decided and is not written down yet; until it is, the local-token
-  > procedure above is the only npm publishing path that runs.
+  > The publishing path that replaces the token after the 2027 deadline is being decided and
+  > is not written down yet; until it is, the local-token procedure above is the npm
+  > publishing path we actually use. (It was additionally blocked while Actions was off,
+  > 2026-09-16 to 09-20 — Actions is back on, so `publish-npm.yml` can fire again.)
 - `bun publish` does **not** apply `publishConfig` field overrides (bin/main/exports) — only
   `access`/`tag` (oven-sh/bun#19205). So fields like `bin` must be correct at the top level, not
   swapped via `publishConfig`.
@@ -546,11 +545,9 @@ and deleting a dist-tag is package access. Measured across all 14 packages on 20
 the prerelease install path, which is the actual harm; the tag continuing to exist alongside an
 identical `latest` is cosmetic.
 
-**The CI route is inoperative right now (2026-09-16): GitHub Actions is disabled on this
-repository, so the dispatch below cannot run**, and the replacement path is being decided.
-Until it lands, the `dist-tag add` above is what repoints the tag — run from your machine,
-per package. The dispatch is kept because the switch is reversible: it ran the whole
-set from CI, where the publish token already lives — Actions →
+Either route works: the `dist-tag add` above run from your machine, per package, or the CI
+dispatch, which does the whole set at once from where the publish token already lives —
+Actions →
 **npm dist-tag** → Run workflow → tag `next`, action `add`, version `<version>`
 ([`.github/workflows/npm-dist-tag.yml`](../.github/workflows/npm-dist-tag.yml); the set and its
 order come from `scripts/publish-set.mjs`, never a list maintained there). Action `ls` is the
@@ -593,11 +590,9 @@ The workflow [`.github/workflows/publish-csharp.yml`](../.github/workflows/publi
 the four projects, exchanges a GitHub OIDC token for a short-lived (~1 hour) nuget.org key via
 `NuGet/login@v1`, then `dotnet nuget push`es.
 
-**Both triggers are inoperative right now (2026-09-16): GitHub Actions is disabled on this
-repository, so neither the manual dispatch nor a `csharp-v*` tag can run anything** — and a
-NuGet publish fundamentally needs Actions for its OIDC exchange, so there is no local
-stand-in; the replacement path is being decided. The workflow and the one-time setup below
-are kept as the mechanism record, because the switch is reversible. Trigger it manually
+**A NuGet publish fundamentally needs Actions for its OIDC exchange — there is no local
+stand-in.** That is why Actions was re-enabled on 2026-09-20 after four days off: with it
+disabled, NuGet simply cannot be published. Trigger it manually
 (**Actions → publish-csharp → Run workflow**, with an optional version override) or by
 pushing a `csharp-v*` tag once it fires again.
 
@@ -660,19 +655,18 @@ lock the repo/owner IDs against resurrection attacks.)
    dotnet tool install --global --add-source /tmp/mo-nupkg MetaObjects.Cli && dotnet meta --help
    ```
 3. **Run persistence conformance** if the runtime/codegen changed: `scripts/integration-test.sh csharp`.
-4. **Publish:** GitHub → **Actions → publish-csharp → Run workflow** (or push a `csharp-v<version>` tag)
-   — **inoperative while Actions is off (2026-09-16)**; see the note under "How we publish" above.
+4. **Publish:** GitHub → **Actions → publish-csharp → Run workflow** (or push a `csharp-v<version>` tag).
+   This is the one registry that CANNOT be published locally — see "How we publish" above.
 5. **Verify** on nuget.org: all four packages listed and **owned by the `metaobjects` org**
    (indexing/validation takes a few minutes).
 
 # Releasing the Python package to PyPI
 
 How to publish the **`metaobjects`** Python package to PyPI: push a `python-v<version>` tag and
-the workflow publishes it with the `PYPI_API_TOKEN` repo secret. **That trigger is inoperative
-right now (2026-09-16): GitHub Actions is disabled on this repository, so the tag fires
-nothing** — and PyPI publishing here runs only through the workflow, so there is no local
-stand-in; the replacement path is being decided. The workflow description below is kept as the
-mechanism record, because the switch is reversible.
+the workflow publishes it with the `PYPI_API_TOKEN` repo secret. PyPI publishing here runs
+only through that workflow — there is no local stand-in. Note `publish-python.yml` takes no
+version override, so it publishes the COMMITTED version: in the RC dance, do not fire it for
+a pre-release you have not committed.
 
 ## What gets published
 
@@ -764,8 +758,8 @@ versioned on its own major line — npm major + 7, so `7.x` while npm was `0.x`
 3. **Deploy — ONE of two routes, never both** (a second deploy of a published version fails
    with `Component … already exists`): push a `java-v<maven-version>` tag, and
    `publish-java.yml` runs the deploy below in CI with the signing secrets (how `8.0.4`
-   shipped — **inoperative while Actions is off, 2026-09-16**: GitHub Actions is disabled on
-   this repository, so the tag fires nothing); or run `mvn -Prelease deploy` from `server/java`.
+   shipped; it takes no version override, so it deploys the COMMITTED version — do not fire
+   it for an uncommitted pre-release); or run `mvn -Prelease deploy` from `server/java`.
    The `central-publishing-maven-plugin`
    (`<publishingServerId>central</publishingServerId>`, `<autoPublish>true</autoPublish>`) uploads
    the signed bundle and auto-releases — **no manual staging → release promotion**. Auth + the GPG