README.md
README.md is a file in Bane's Lab Content. 104 lines of code and 0 definitions.
<!-- Auto-generated 2026-09-29T00:22Z v5 -->
# @banes-lab/content
<!-- concern:overview -->
## Purpose
This member holds its entry points under `runtime/entrypoints/`. The verify pipeline runs each one with a direct `node` call: the derivations in its build stage and the validations in its validation stage.
The derivations write the data the validations read:
- `inventory.entrypoint.ts` scans every governing document for one-line rules and avoidance pairs.
- `seed.entrypoint.ts` joins each meta record of the algorithm collection to its kernel, and each invariant stated in the coordination models to the principles in the operator profile.
- `tone.entrypoint.ts` measures every strings module of the site member through the code parser.
- `leak.entrypoint.ts --derive` collects the leak set, every internal identifier the public copy must not contain.
The validations then hold the site to that data. `coverage.entrypoint.ts` checks every content graph: each concept is taught in one place, a concept is taught after what it requires, and every trace resolves. `leak.entrypoint.ts` reads the built page payloads against the leak set.
`chapter.entrypoint.ts` renders the built Markdown alternates and page payloads into the methodology checkout inside the workspace, or into the directory named by `--out`. `--shape` picks the form:
- `repository` composes the README from the methodology, FAQ and exhibit payloads. It writes one chapter per methodology tab at the root with the attribution line, and one folder per tab set of the grammar, architecture and ontology pages. The FAQ lives in the README, and the anatomy stays on the site.
- `wiki` writes the Home page, one numbered page per tab of every teaching page in reading order, the sidebar and the footer into the checkout's wiki.
The render owns every top-level Markdown file in its output directory, so it removes the file of any page the site does not publish. Every location resolves through `@ssot/paths`, and every generated file is written through the canonical writer.
<!-- /concern:overview -->
<!-- concern:use -->
## When to use
- When you add a page whose copy teaches the method, you declare its content graph in the site member's constants, and the validators find it by its name suffix.
- You can render the methodology repository by hand, although the site build's last plugin already runs this entry point for both shapes. `node banes-lab.root/banes-lab.content/runtime/entrypoints/chapter.entrypoint.ts` repeats the repository render from the built site, `--shape wiki` renders the wiki, and `--out` points either one at a folder of your own. Committing the two checkouts is the developer's step.
- Before you decide a punctuation or vocabulary policy, you can read the tone baseline in the generated document under `doc-arch/generated/`.
## When NOT to use
- This member writes no user-visible string. Site copy is written in the strings modules, which the developer owns.
- Linting a single strings module is the job of the vocabulary, punctuation and lesson rules in the governance host, which run through the linter.
<!-- /concern:use -->
<!-- concern:charts -->
## Architecture charts
The structure, logical-flow and dependency diagrams derived from the source AST live in [_code.info.generated/mermaid-charts.generated.md](./_code.info.generated/mermaid-charts.generated.md).
<!-- /concern:charts -->
<!-- concern:install -->
## Install
A private workspace member, resolved through the `workspaces` list in the root `package.json`, so one `npm install` at the repository root sets it up. It declares its `@banes-lab/*`, `@govlab/*` and `@ssot/*` siblings and has no third-party dependency of its own.
## Quick start
```sh EXAMPLE: Derive the data the validations read
node banes-lab.root/banes-lab.content/runtime/entrypoints/inventory.entrypoint.ts
node banes-lab.root/banes-lab.content/runtime/entrypoints/seed.entrypoint.ts
node banes-lab.root/banes-lab.content/runtime/entrypoints/tone.entrypoint.ts
node banes-lab.root/banes-lab.content/runtime/entrypoints/leak.entrypoint.ts --derive
```
```sh EXAMPLE: Validate the built site against the derived artifacts
node banes-lab.root/banes-lab.content/runtime/entrypoints/coverage.entrypoint.ts
node banes-lab.root/banes-lab.content/runtime/entrypoints/leak.entrypoint.ts
```
```sh EXAMPLE: Render the methodology repository into its checkout
node banes-lab.root/banes-lab.content/runtime/entrypoints/chapter.entrypoint.ts
```
```sh EXAMPLE: Render the teaching pages as the repository's wiki
node banes-lab.root/banes-lab.content/runtime/entrypoints/chapter.entrypoint.ts --shape wiki
```
<!-- /concern:install -->
<!-- concern:api -->
## API
The package exposes no public API.
<!-- /concern:api -->
<!-- concern:config -->
## Configuration
- `configuration/constants/inventory.constants.ts` — The tokens the rule scanner recognizes, which are the backticks around a slug, the colon, the list marker, the bold lead-in, the locked markers, the gate tail and the avoidance arrow.
- `configuration/constants/tone.constants.ts` — The literal node type the tone analyzer reads, the sentence terminals, the grammatical-person markers and the separators of labeled items.
- `configuration/constants/leak.constants.ts` — The token stops, the minimum token length, the payload keys and the names of the sources that the leak set is built from.
<!-- /concern:config -->
<!-- concern:deps -->
## Dependencies
- `@banes-lab/web`
- `@govlab/argv`
- `@govlab/canonical-write`
- `@govlab/code-parse`
- `@govlab/constants`
- `@govlab/content-fingerprint`
- `@govlab/context`
- `@govlab/docs`
- `@govlab/pipeline`
- `@govlab/quality`
- `@ssot/govlab`
- `@ssot/paths`
<!-- /concern:deps -->
<!-- concern:ai-context -->
## AI context
- The verify pipeline runs each entry point from the repository root, and every path resolves through `@ssot/paths`, never from the module's own location.
- The derivations are `wide` steps and the validations are bound to the site member, so a run scoped to this member proves only its typecheck, lint and tests. To prove a single step, run the full scope with `--only <label>`.
- The leak set is data that the leak validator cites, so a token added to a source enters the set at the next derivation without a rule change.
- The site member owns the content graph type. This member imports the type and finds the graph constants by their name suffix.
<!-- /concern:ai-context -->
<!-- concern:domains -->
## Domains
This package serves these software domains, which `_manifest.json` declares in `domains` from the two-tier software-domain vocabulary (`meta → sub`):
- **developer-tooling** — code-generation, linting-quality
<!-- /concern:domains -->
<!-- concern:quality-governance -->
## Quality governance
The canonical quality catalog resolves the quality concepts that govern this package. `_manifest.json` declares them in `governedBy`, and a lint package derives them from the concepts its own rules enforce. Each maps to the custom lint rules that enforce it:
- **separation-of-concerns** — _complexity_
- **type-safety** — _correctness_
<!-- /concern:quality-governance -->
<!-- concern:disposal -->
## Disposal
- Remove the member's workspace entry from the root `package.json` and its `content` id from the docs members list in the governance config.
- Remove its governed-root entry from `containers` and `specialContainers` in `.govlab/shared/configs/taxonomy.config.ts`.
- Remove the `content` key from the `app` branch, the `content` key from the testing branch and the content reports branch of `project.paths/paths.yaml`.
- Remove its member row and its build and validation steps from the verify pipeline's stage list, delete the directory, reinstall, and run `npm run verify`.
<!-- /concern:disposal -->
<!-- concern:metrics -->
---
experimental · 0 exports · 12 deps · 0 principles · 2 concepts
<!-- /concern:metrics -->