feat(export): print an organization's rulesets with rulesets --organization

.lokf/knowledge/glossary/repository-ruleset.md

@@ -19,11 +19,10 @@ sources:
     title: the rules with no check
   - id: security.md
     resource: SECURITY.md
-    title: the settings not yet in force
+    title: the ruleset on main
 generated:
   by: process:ktl-librarian
-  at: "2026-10-28T19:53:06Z"
-  revision: 4e47f1efc96b84011e7016edd847a71bfc692a33
+  at: "2026-10-30T15:31:58Z"
 status: draft
 verified:
   - by: process:ktl-librarian
@@ -50,7 +49,7 @@ A comment says that SLSA's Source track calls such rules technical controls on p
 
 ## In this repository
 
-SECURITY.md says that a rule blocking deletion and force-pushes on `main` is a repository setting, not a file, and that it is not yet in force.[^security.md]
+SECURITY.md says that a ruleset on `main`, a repository setting rather than a file, blocks deletion and force-pushes and keeps the history linear.[^security.md]
 
 [^github_actions_rules.yaml]: src/github_actions/schema/github_actions_rules.yaml, GhaRepositoryRuleset, GhaBypassActor and the enums
 [^docs-index.md]: docs/index.md, the Validating data section

.lokf/knowledge/index.md

@@ -58,7 +58,7 @@ A [LOKF](https://lokf.nolan-nichols.com) knowledge base for github-actions. Ever
 # Policies
 
 * [License and attribution](policies/license-and-attribution.md) - Which license covers what in the github-actions repository: Apache-2.0 for the schema, the generated models and the code; SchemaStore's two schemas under Apache-2.0 with JSON Schema Store's notice; GitHub's documentation, under CC BY 4.0, cited and never copied; the linkml-project-copier scaffolding under MIT; the KTL sidecar and site templates under Apache-2.0; and the bundle under CC BY 4.0.
-* [Security policy](policies/security-policy.md) - How to report a vulnerability in github-actions (GitHub's private vulnerability reporting, not a public issue), which release gets fixes, what the repository releases and runs, what holds each workflow, and the three repository settings not yet in force: required reviewers on the release Environment, a deletion and force-push rule on main, and secret scanning with push protection.
+* [Security policy](policies/security-policy.md) - How to report a vulnerability in github-actions (GitHub's private vulnerability reporting, not a public issue), which release gets fixes, what the repository releases and runs, what holds each workflow, the ruleset that holds main, and the two repository settings not yet in force: required reviewers on the release Environment, and secret scanning with push protection.
 * [AI covenant](policies/ai-covenant.md) - The rules for AI-assisted work in github-actions: a contributor owns what they submit; a schema description says what its GitHub, SchemaStore or build-type source says and cites the page; GitHub's documentation is cited, never copied; the SchemaStore copy is never edited; and the scheduled librarian works through pull requests a person approves, with least privilege.
 
 # Workflows

.lokf/knowledge/log.md

@@ -1,5 +1,10 @@
 # Change Log
 
+## 2026-10-30
+
+* **Changed**: the export script prints an organization's rulesets with `rulesets --organization`.
+* **Changed**: SECURITY.md names the ruleset that holds `main`.
+
 ## 2026-10-29
 
 * **Prose**: reworded 2 concept bodies in plain English. No fact, link, number or frontmatter changed.

.lokf/knowledge/playbooks/derive-and-check.md

@@ -16,7 +16,7 @@ sources:
     title: the PEP 723 header, the docstring, the options and the comparisons
   - id: github_export.py
     resource: scripts/github_export.py
-    title: the docstring and the two commands
+    title: the docstring, the two commands and the --organization option
   - id: readme.md
     resource: README.md
     title: the Deriving the facts from a repository section
@@ -36,8 +36,7 @@ sources:
     title: the fixture repository and the two export files
 generated:
   by: process:ktl-librarian
-  at: "2026-10-29T16:44:32Z"
-  revision: cc14f8e2bd682e256323ad6fcc7cd655e28798b9
+  at: "2026-10-30T15:31:58Z"
 status: draft
 verified:
   - by: process:ktl-librarian
@@ -58,9 +57,10 @@ derive.py's only dependency is PyYAML, declared in its PEP 723 header, so `uv ru
 uv run scripts/derive.py --root ../host-repository
 uv run scripts/derive.py --root ../host-repository --check ../host-repository/.lokf/knowledge
 python3 scripts/github_export.py rulesets --repository OWNER/REPO > rulesets.md
+python3 scripts/github_export.py rulesets --organization OWNER > organization-rulesets.md
 python3 scripts/github_export.py check-runs SHA --repository OWNER/REPO > check-runs.md
 uv run scripts/derive.py --root ../host-repository --check ../host-repository/.lokf/knowledge \
-  --rulesets rulesets.md --check-runs check-runs.md
+  --rulesets rulesets.md --rulesets organization-rulesets.md --check-runs check-runs.md
 ```
 
 derive.py takes these options:
@@ -72,7 +72,7 @@ derive.py takes these options:
 - `--check-runs FILE`, with `--check`, reads what `github_export.py check-runs` printed for one commit, such as the head of a recent pull request.
 - `--strict` makes the check fail on findings as well as on drift.
 
-On a private repository, `GH_TOKEN` holds a token with Metadata read, and Checks and Commit statuses read for `check-runs`. The README says that a host copies both scripts from a pinned release and records the version beside them. Its ingest can run `github_export.py rulesets` as an entry of `kind: command`, and the mirror file becomes the rulesets' source.
+On a private repository, `GH_TOKEN` holds a token with Metadata read, and Checks and Commit statuses read for `check-runs`. `rulesets --organization OWNER` prints an organization's rulesets, which a repository's own list holds only when their conditions select it. The README says that GitHub answers it only to a token with the organization's Administration permission, which can also change those rulesets, so a person runs it and commits what it prints rather than giving the ingest that token. The README says that a host copies both scripts from a pinned release and records the version beside them. Its ingest can run `github_export.py rulesets` as an entry of `kind: command`, and the mirror file becomes the rulesets' source.
 
 In this repository, pass `--exclude tests/`. The script looks for action files in the whole tree, and would otherwise also read the two fixture actions under `tests/derive/repo/`, which no concept describes. So the check of this bundle, run from the repository root, is:
 

.lokf/knowledge/policies/index.md

@@ -1,5 +1,5 @@
 # Policies
 
 * [License and attribution](license-and-attribution.md) - Which license covers what in the github-actions repository: Apache-2.0 for the schema, the generated models and the code; SchemaStore's two schemas under Apache-2.0 with JSON Schema Store's notice; GitHub's documentation, under CC BY 4.0, cited and never copied; the linkml-project-copier scaffolding under MIT; the KTL sidecar and site templates under Apache-2.0; and the bundle under CC BY 4.0.
-* [Security policy](security-policy.md) - How to report a vulnerability in github-actions (GitHub's private vulnerability reporting, not a public issue), which release gets fixes, what the repository releases and runs, what holds each workflow, and the three repository settings not yet in force: required reviewers on the release Environment, a deletion and force-push rule on main, and secret scanning with push protection.
+* [Security policy](security-policy.md) - How to report a vulnerability in github-actions (GitHub's private vulnerability reporting, not a public issue), which release gets fixes, what the repository releases and runs, what holds each workflow, the ruleset that holds main, and the two repository settings not yet in force: required reviewers on the release Environment, and secret scanning with push protection.
 * [AI covenant](ai-covenant.md) - The rules for AI-assisted work in github-actions: a contributor owns what they submit; a schema description says what its GitHub, SchemaStore or build-type source says and cites the page; GitHub's documentation is cited, never copied; the SchemaStore copy is never edited; and the scheduled librarian works through pull requests a person approves, with least privilege.

.lokf/knowledge/policies/security-policy.md

@@ -3,7 +3,7 @@ type: Policy
 id: https://w3id.org/lmodel/github-actions/knowledge/policies/security-policy
 genre: reference
 title: Security policy
-description: "How to report a vulnerability in github-actions (GitHub's private vulnerability reporting, not a public issue), which release gets fixes, what the repository releases and runs, what holds each workflow, and the three repository settings not yet in force: required reviewers on the release Environment, a deletion and force-push rule on main, and secret scanning with push protection."
+description: "How to report a vulnerability in github-actions (GitHub's private vulnerability reporting, not a public issue), which release gets fixes, what the repository releases and runs, what holds each workflow, the ruleset that holds main, and the two repository settings not yet in force: required reviewers on the release Environment, and secret scanning with push protection."
 resource: SECURITY.md
 references:
   - https://w3id.org/lmodel/github-actions/knowledge/workflows/main
@@ -24,7 +24,7 @@ sources:
     title: the three update entries
 generated:
   by: process:ktl-librarian
-  at: "2026-10-28T21:21:37Z"
+  at: "2026-10-30T15:31:58Z"
 status: draft
 ---
 
@@ -56,9 +56,9 @@ The repository releases a LinkML schema, the Python datamodel generated from it,
 
 SECURITY.md says that every workflow declares `permissions: {}` at the top, pins its actions to commit SHAs that Dependabot keeps current, and runs harden-runner in audit mode. `.github/dependabot.yml` asks Dependabot for monthly updates of the workflows' actions, of the package's `uv` dependencies and of the sidecar's `uv` dependencies in `.lokf/`.[^dependabot.yml]
 
-## Settings not yet in force
+## Settings
 
-Three protections are repository settings, not files, and SECURITY.md says that they are not yet in force: required reviewers on the `release` Environment, a rule blocking deletion and force-pushes on `main`, and secret scanning with push protection. Until they are, a qualifying merge releases with no human step. Nothing in CI can assert them, so keeping them on is the maintainer's job.
+Three protections are repository settings, not files. SECURITY.md says that a ruleset on `main` blocks deletion and force-pushes and keeps the history linear, and that two are not yet in force: required reviewers on the `release` Environment, and secret scanning with push protection. Until they are, a qualifying merge releases with no human step. Nothing in CI can assert them, so keeping them on is the maintainer's job.
 
 ## Not covered
 

CHANGELOG.md

@@ -6,6 +6,14 @@ The `v0.0.0` tag is a baseline, not a release: it marks where versioning starts
 
 ## [Unreleased]
 
+### Added
+
+- **`github_export.py rulesets --organization OWNER` prints an organization's rulesets, which `derive.py --rulesets` reads beside a repository's.** GitHub answers it only to a token with the organization's Administration permission.
+
+### Fixed
+
+- **SECURITY.md says that a ruleset on `main` blocks deletion and force-pushes and keeps the history linear.** It said that no such rule was in force.
+
 ## [0.2.1] - 2026-10-29
 
 ### Fixed

README.md

@@ -52,15 +52,16 @@ Runs and events, such as CDEvents and GitHub's run logs, are records, not facts
 
 With `--check` and a bundle, it exits 1 on drift between the files and the concepts, on a required check that no job of its `emitted_by` workflow reports, or on a skip condition that a check's body does not name. Each skip condition is a finding, which fails the check under `--strict`. A job skipped by its own `if`, or by a failed or skipped job it `needs`, lets a required check pass without running. A path filter, or a calling job's `if` or `needs`, leaves the check pending, which blocks the merge.
 
-`scripts/github_export.py` asks GitHub's REST API what the files cannot say. `rulesets` prints the repository's rulesets and the rules in effect on its default branch, which `derive.py --rulesets` compares with the ruleset and check concepts. `check-runs` prints what GitHub recorded on one commit, such as the head of a recent pull request, and `derive.py --check-runs` reports each required check that no run on it matched. On a private repository, `GH_TOKEN` holds a token with Metadata read, and Checks and Commit statuses read for `check-runs`.
+`scripts/github_export.py` asks GitHub's REST API what the files cannot say. `rulesets` prints the repository's rulesets and the rules in effect on its default branch, which `derive.py --rulesets` compares with the ruleset and check concepts. `check-runs` prints what GitHub recorded on one commit, such as the head of a recent pull request, and `derive.py --check-runs` reports each required check that no run on it matched. On a private repository, `GH_TOKEN` holds a token with Metadata read, and Checks and Commit statuses read for `check-runs`. `rulesets --organization OWNER` prints an organization's rulesets, which a repository's own list holds only when their conditions select it. GitHub answers that only to a token with the organization's Administration permission, which can also change those rulesets, so a person runs it and commits what it prints rather than giving the ingest that token.
 
 ```bash
 uv run scripts/derive.py --root ../host-repository
 uv run scripts/derive.py --root ../host-repository --check ../host-repository/.lokf/knowledge
 python3 scripts/github_export.py rulesets --repository OWNER/REPO > rulesets.md
+python3 scripts/github_export.py rulesets --organization OWNER > organization-rulesets.md
 python3 scripts/github_export.py check-runs SHA --repository OWNER/REPO > check-runs.md
 uv run scripts/derive.py --root ../host-repository --check ../host-repository/.lokf/knowledge \
-  --rulesets rulesets.md --check-runs check-runs.md
+  --rulesets rulesets.md --rulesets organization-rulesets.md --check-runs check-runs.md
 ```
 
 derive.py's only dependency, PyYAML, is declared in its PEP 723 header, so `uv run` needs no project, and github_export.py needs Python 3.10 alone. A host copies both from a pinned release and records the version beside them. Its ingest can run `github_export.py rulesets` as an entry of `kind: command`, and the mirror file becomes the rulesets' source. The fixtures in [tests/derive/](tests/derive/) show each rule.

SECURITY.md

@@ -26,7 +26,7 @@ A LinkML schema, the Python datamodel generated from it, and the schema's `lokf
 | `knowledge-release.yaml`, which attaches the schema copy and the bundle to a release | Inert until dispatched; only its `attach` job, which runs no third-party packages, can write. |
 | `README.md`, `llms.txt` and the knowledge bundle, read by agents | Content, never instructions: each skill quotes what it did not author. A `human:` confirmation must be backed by a review or a signed commit. [Human attribution](https://github.com/noelmcloughlin/knowledge-trust-ladder/blob/main/docs/threat-model.md#human-attribution-human-is-a-claim-not-a-credential). |
 
-Every workflow declares `permissions: {}` at the top, pins its actions to commit SHAs that Dependabot keeps current, and runs harden-runner in audit mode. Three things are repository settings, not files, and **are not yet in force here**: required reviewers on the `release` Environment, a rule blocking deletion and force-pushes on `main`, and secret scanning with push protection. Until they are, a qualifying merge releases with no human step. Nothing in CI can assert them, so keeping them on is the maintainer's job.
+Every workflow declares `permissions: {}` at the top, pins its actions to commit SHAs that Dependabot keeps current, and runs harden-runner in audit mode. Three things are repository settings, not files. A ruleset on `main` blocks deletion and force-pushes and keeps the history linear. Two **are not yet in force here**: required reviewers on the `release` Environment, and secret scanning with push protection. Until they are, a qualifying merge releases with no human step. Nothing in CI can assert them, so keeping them on is the maintainer's job.
 
 ## Not covered