docs(library): describe only the install path this repository delivers

The package is not published yet and the build branch carries no lib/pkg/,
so the install and versioning sections now say the library is built here
with bun run build:lib and that npm and packaged-branch installation arrive
with the publishing change. The API-by-group content is unchanged.

Author: settings-as-code-release

README.md

@@ -61,7 +61,7 @@ The [getting started guide](docs/start/getting-started.md) walks the same steps
 
 ## Library
 
-The same engine is the npm package `@vivswan/github-settings-as-code` (ESM, Node 22.14 or newer): validate, merge, check, and apply from your own code. Install it with `npm install @vivswan/github-settings-as-code` or `bun add @vivswan/github-settings-as-code`; the [library reference](docs/reference/library.md) has the API by group and the `@next` pre-release channel.
+The same engine is the npm package `@vivswan/github-settings-as-code` (ESM, Node 22.14 or newer): validate, merge, check, and apply from your own code. It is built from this repository with `bun run build:lib`; the [library reference](docs/reference/library.md) has the API by group.
 
 ## Docs
 

docs/README.md

@@ -43,7 +43,7 @@ The documentation for GitHub Settings as Code, in five groups. Start here if the
 - [The undeclared policy](reference/undeclared-policy.md): the `_undeclared` knob on the list sections, per-section defaults, the milestone-deletion caveat, and how the policy layers in `mode: merge`.
 - [Forward compatibility](reference/forward-compatibility.md): where payloads pass through verbatim and which sections are deliberately closed.
 - [Secrets and vaults](reference/secrets-and-vaults.md): the `$NAME` references secret fields take, wiring them from GitHub Secrets or a vault action, and what check mode can and cannot verify.
-- [Library](reference/library.md): the npm package `@vivswan/github-settings-as-code`, its install lines, the API by group with one example each, and how its version tracks the action's.
+- [Library](reference/library.md): the npm package `@vivswan/github-settings-as-code`, how it is built, the API by group with one example each, and how its version tracks the action's.
 
 ## operate: day-to-day operation
 

docs/reference/library.md

@@ -8,22 +8,14 @@ The engine behind the action is also an npm package, `@vivswan/github-settings-a
 
 ## Install
 
-```bash
-npm install @vivswan/github-settings-as-code
-bun add @vivswan/github-settings-as-code
-```
-
-Pre-releases ride the `next` dist-tag; until the first stable release only `@next` exists:
+The package is built from this repository:
 
 ```bash
-npm install @vivswan/github-settings-as-code@next
+bun install
+bun run build:lib
 ```
 
-A packaged commit on the `build` branch that carries `lib/pkg/` installs straight from GitHub (no registry, no build step on your side):
-
-```bash
-npm install github:Vivswan/github-settings-as-code#<packaged sha>
-```
+That writes `lib/pkg/index.js` and `lib/pkg/index.d.ts`, the files the manifest's `exports` point at. Installing from npm or from a packaged commit of the `build` branch arrives with the publishing change.
 
 The package exports three paths: the entry (`.`), the committed settings.yml JSON Schema (`./settings.schema.json`), and its own manifest (`./package.json`).
 
@@ -153,11 +145,7 @@ console.log(exitCode, collected.outputs.result, collected.lines.map((entry) => e
 
 ## Versioning
 
-The package and the action share one version, the one in `.release-please-manifest.json`, so a settings file that validates on the library validates on the action of the same version.
-
-- Every green push to `main` publishes a pre-release under the `next` dist-tag: the next patch version, then `-main.<run>.<sha7>` (the workflow run number and the short source commit).
-- A release publishes the stable version and moves `latest` to it.
-- The `github:Vivswan/github-settings-as-code#<packaged sha>` form installs a packaged commit of the `build` branch, which carries `lib/pkg/` and `lib/index.js` built from its source commit.
+The package and the action share one version, the one in `.release-please-manifest.json` (release-please rewrites `package.json` from it), so a settings file that validates on the library validates on the action of the same version.
 
 ## One-time publishing setup