@heroiclands/package-build 22.15.1 → 22.17.0

package/docs/guides/packs.md

@@ -0,0 +1,167 @@
+---
+shortcode: guidespacks
+name: { full: "Compendium packs" }
+type: doc
+subType: howto
+---
+
+# Compendium packs
+
+A Foundry content package declares its compendiums in `packs:` in
+`package-build.config.yaml`. Each entry names a pack and the Foundry document
+class it holds. The build uses the same list for the manifest and for its
+compilation passes. The [configuration reference](../configuration.md) defines
+every pack key; this guide covers how to choose and route packs as a package
+grows.
+
+## Choose the pack layout
+
+Start with one pack for each document class the notes produce. An Item, Actor,
+Macro, Scene, or Adventure note can also produce a JournalEntry for its prose,
+so a package with those notes generally needs a JournalEntry pack. A missing
+pack for a document a note actually produces is a finding on that note. An
+empty body produces no prose journal and needs no pack for it.
+
+```yaml
+packs:
+  - { name: items, type: Item, label: Items }
+  - { name: actors, type: Actor, label: Actors }
+  - { name: journals, type: JournalEntry, label: Journals }
+```
+
+Item and Actor packs for a system also need the system selection and version
+declarations described in [configuration](../configuration.md). A documentation
+package has no Foundry packs or manifest; the
+[getting started guide](../getting-started.md) shows that package kind.
+
+A pack name forms part of a compendium UUID. Choose it as a stable identifier;
+the label can change independently. Pack order in the configuration is the
+order shown in the generated manifest. The compiler arranges its passes so a
+pass that reads another pack's output runs after every pack of that document
+class. In particular, Actor compilation follows the Item packs it reads.
+
+## Route notes between packs of one class
+
+Multiple packs may hold one document class. A single pack of a class is its
+implicit default. With several, mark one `default: true` or give each relevant
+note an explicit `data.pack`:
+
+```yaml
+packs:
+  - { name: general, type: JournalEntry, default: true }
+  - { name: mysteries, type: JournalEntry }
+```
+
+```yaml
+shortcode: secondsight
+name: { full: Second Sight }
+type: doc
+subType: concept
+data: { pack: mysteries }
+```
+
+The note's pack declaration routes its own document. A derived prose journal
+uses the default JournalEntry pack, so an Item note's `data.pack` routes its
+Item and does not also route its prose. An unknown pack, a pack of another
+document class, or a companion pack is an error. If a class has several packs
+and no default, an unassigned note of that class is an error too.
+
+For a page that belongs on the site and in the content index but in no
+compendium, a journal-only note can declare `data: {pack: none}`. An Item,
+Actor, Macro, Scene, or Adventure note cannot use that value because it would
+drop the document the note creates. The
+[content format](../reference/format-details.md#the-pack-a-note-compiles-into) defines
+this field and its placement.
+
+## Build for more than one system
+
+A pack can declare `system`, and the router chooses a default separately for
+each document class and system. One Item pack for each system therefore needs
+no `default: true` flag. A note with both system blocks produces a document
+for each block, shaped by that system's item builder and stamped with that
+system's version. A note with only one block produces only that system's
+document.
+
+```yaml
+itemBuilders: [sohl, hm3]
+systems:
+  sohl: { compatibility: { verified: "0.9.0" } }
+  hm3: { compatibility: { verified: "1.6.3" } }
+packs:
+  - { name: items-sohl, type: Item, system: sohl }
+  - { name: items-hm3, type: Item, system: hm3 }
+  - { name: actors-sohl, type: Actor, system: sohl }
+  - { name: actors-hm3, type: Actor, system: hm3 }
+  - { name: journals, type: JournalEntry }
+```
+
+A system block's `pack` selects that system's document pack. A block naming a
+pack for another system is an error. A shared `data.pack` that names a pack
+for one system does not route the other system into it; that system uses its
+own default. A pack with no `system` may serve as a default for either.
+
+The `itemBuilders` registry supplies the accepted item types and the builder
+for each type. The named `sohl` and `hm3` registries ship with the package.
+When both define a type, the build selects the builder for the pack's system.
+The [configuration reference](../configuration.md) covers the version and
+registry declarations.
+
+## Supply a custom item builder
+
+A package whose item builders are code uses `package-build.config.mjs` and
+passes the builder table to `defineConfig`. Import `defineConfig` from the
+`content-config` entry point so the configuration module loads independently
+of the compilers:
+
+```js
+import { defineConfig } from "@heroiclands/package-build/content-config";
+import { ITEM_BUILDERS } from "./build/item-builders.mjs";
+
+export default defineConfig({
+  rootDir: import.meta.dirname,
+  contentPackage: "example",
+  foundryPackage: "example-module",
+  packageKind: "modules",
+  compatibility: { minimum: "14.359", verified: "14.364" },
+  stats: { lastModifiedBy: "examplebuilder000" },
+  itemBuilders: ITEM_BUILDERS,
+  packs: [{ name: "items", type: "Item" }],
+});
+```
+
+This form supplies values that a YAML configuration derives from its location
+and adjacent `package.json`. Declare one configuration file in the project:
+the loader refuses a directory containing both YAML and MJS configurations.
+The [API reference](../api.md) describes `defineConfig` and the builder
+contract.
+
+## Use prebuilt and companion packs
+
+`prebuilt` points to per-document JSON that the package maintains as input.
+The build compiles that JSON into LevelDB without running a note-generation
+pass for the pack. A prebuilt pack cannot have a default or companions, and
+cannot itself be a companion.
+
+A companion is emitted by its parent's pass. For example, a Scene pass can
+also write an Adventure pack that groups its scenes. Declare the companion
+under the parent; no note routes directly into it:
+
+```yaml
+packs:
+  - name: scenes
+    type: Scene
+    companions:
+      - { name: adventures, type: Adventure }
+```
+
+The [pack configuration reference](../configuration.md) lists the remaining
+constraints and fields.
+
+## Compile and inspect
+
+Run `package-build package compile` to compile every configured pack. Run it
+with a pack name to compile one pack; if that pass reads another pack's output,
+the needed output must already exist. The full compile orders those passes for
+you. `package-build package unpack` reads a built pack back into JSON for
+inspection. See the [command reference](../commands.md) for their arguments
+and output paths.

package/docs/guides/reference-pages.md

@@ -0,0 +1,148 @@
+---
+shortcode: guidesreferencepages
+name: { full: "Reference pages and content indexes" }
+type: doc
+subType: howto
+---
+
+# Reference pages and content indexes
+
+A reference page gives readers an entry point into a group of notes. Author it
+as a normal content note, so it has a stable Address, can link to its subjects,
+and can be selected for the site or book. The JSON Lines content index serves a
+different reader: build passes and tools use it to find notes, assets, names,
+relationships, and generated document destinations.
+
+The [content format](../content-format.md) defines note types, Address fields,
+and links. The [command reference](../commands.md) gives the index and generated
+page commands; [configuration](../configuration.md) defines their paths.
+
+## Author an entry page
+
+Use `type: doc` and `subType: reference` for an out-of-world lookup page. A
+page introducing a content type conventionally uses that type as its
+shortcode. Its body supplies the explanation, links, and any SQL tables a
+reader needs:
+
+````markdown
+---
+shortcode: affiliation
+name: { full: Affiliations }
+type: doc
+subType: reference
+data: { pack: none }
+---
+
+# Affiliations
+
+Affiliations describe the groups a person belongs to and the offices they may
+hold. Start with [[affiliation-watch|The Watch]] for a local example.
+
+```sql
+SELECT address.slug AS _ref, name.full AS "Name"
+FROM notes
+WHERE type = 'affiliation'
+```
+````
+
+`data.pack: none` is appropriate when the page belongs on the site and in the
+index but does not need a Foundry compendium entry. A documentation package
+has no packs at all. A page with an empty body is a stub: it remains in the
+index for data references, but publishes no page address or anchors. Write a
+description for a stub and leave off the `draft` tag; use `draft` for a page
+with prose still in progress. The [stub rules](../reference/format-details.md#a-stub-is-a-note-with-an-empty-body)
+and [pack routing](packs.md) cover these cases.
+
+## Link to the intended target
+
+An Address identifies a package, system, type, and shortcode. In a normal
+`[[link|label]]`, an omitted package means the current package and an omitted
+system means `note`, the readable content. For example,
+`[[affiliation-watch|The Watch]]` names the local readable note. An explicit
+game system names an Actor or Item, and `none` names a systemless asset,
+Scene, Macro, or Folder. A link to another package states all four segments:
+`[[thalorna-note-affiliation-watch|The Watch]]`.
+
+An image embed `![[image-watchcrest|Watch crest]]` defaults to system `none`.
+Frontmatter Address fields take the defaults declared for their position; an
+image field defaults to `none`, while most shared `data:` references default
+to `note`. Use a complete Address in generated content and SQL comparisons:
+`thalorna-note-affiliation-watch`, rather than its bare `watch` shortcode.
+The [Address reference](../reference/format-details.md#addresses) lists the accepted
+short forms and defaults.
+
+## Generate a field reference from item builders
+
+A package with Item builders can generate its Item frontmatter page from the
+builder field declarations. Set `docs.itemFields` to give the page its title,
+destination, and introductory prose:
+
+```yaml
+docs:
+  itemFields:
+    title: Item Fields
+    out: assets/content/Reference/Item_Fields.md
+    preamble:
+      - These tables list the fields accepted by the configured Item builders.
+```
+
+```bash
+package-build docs item-fields
+package-build docs item-fields --check
+```
+
+When the output is under `paths.content`, the generator writes a complete
+`doc/reference` note with a shortcode derived from the output filename, a
+title in `name.full`, and `data.pack: none`. `docs.itemFields.frontmatter` can
+add or override its envelope. Outside the content tree, the output is a
+standalone Markdown page without note frontmatter. `--check` compares the
+whole generated file with the committed copy and exits unsuccessfully when
+they differ. A documentation package cannot declare Item builders or this
+reference generator.
+
+## Use the content index
+
+Run the index command in a content package to produce
+`build/content-index/<contentPackage>-metadata.jsonl`, or use the configured
+`paths.contentIndex` directory:
+
+```bash
+package-build content-index
+jq -r 'select(.type == "affiliation") | .name.full' \
+  build/content-index/thalorna-metadata.jsonl
+```
+
+Each note record carries its authored frontmatter together with derived
+`package`, `file`, `address`, `anchors`, and document destinations. It also has
+ASCII-folded `nameAscii` and `aliasesAscii` for searching names typed without
+diacritics. Asset files under `assets/icons`, `assets/images`, and
+`assets/audio` have records in the same index, identified by an `asset` block.
+The index is disposable build output; regenerate it from the authored tree
+when the content changes.
+
+The record's `address.canonical` is the full Address. Its `address.slug` is a
+local web link target. A stub has `address: null` and `anchors: null`; its
+frontmatter remains queryable. An Item or Actor note can have both a readable
+`note` record and a game-system document destination. A generated
+`documentation` pointer connects a system document to its readable note.
+Consumers can use the index's own addresses and file paths rather than
+reconstructing them from filenames.
+
+## Resolve another package
+
+In a Foundry package, declare a content-bearing dependency under
+`relationships`, then fetch its published index before a build that links into
+it:
+
+```bash
+package-build deps fetch
+```
+
+The fetch stores the versioned metadata in `paths.metadataCache`. A local
+dependency build can be read with `package-build deps fetch --from <path>`.
+The dependency's published manifest advertises its metadata URL. A build
+reports a missing index instead of downloading it while rendering. A
+relationship with `contentIndex: false` is for a Foundry dependency whose
+content is not addressable from this package. See the
+[dependency configuration](../configuration.md#relationships) for the
+declaration and cache rules.

package/docs/guides/release-and-deploy.md

@@ -0,0 +1,114 @@
+---
+shortcode: guidesreleaseanddeploy
+name: { full: "Release and deploy a package" }
+type: doc
+subType: howto
+---
+
+# Release and deploy a package
+
+A Foundry package has two delivery paths. `package-build release` prepares
+files for a GitHub release that Foundry can install. `package-build deploy`
+places the staged build directly in one Foundry data directory for testing or
+operation. Both start with the package built from its source and configuration.
+The [command reference](../commands.md) gives each command's options; the
+[configuration reference](../configuration.md) defines the stage and manifest.
+
+## Check published addresses before a release
+
+An Item address is an interface other packages can resolve against. Compare a
+candidate build with an explicit released artifact when changing note
+shortcodes or withdrawing Items:
+
+```bash
+package-build addresses diff --from build/baseline/module.zip
+package-build addresses diff --from build/baseline/module.zip --strict
+```
+
+The baseline can be a release ZIP or an unpacked build directory; the command
+does not download one. It reports an address as **renamed** when the same
+document ID appears under another address, and **withdrawn** when that ID
+appears under none. Findings are warnings by default. `--strict` turns them
+into errors for a release gate. The comparison reads shipped Item packs, so it
+reports the surface consumers actually resolve rather than inferring changes
+from filenames. Use the [Address reference](../reference/format-details.md#addresses)
+when choosing a durable shortcode.
+
+## Build the release files
+
+Build the repository's staged package and content index, then run:
+
+```bash
+package-build release
+```
+
+The command writes a Foundry ZIP and its `system.json` or `module.json`
+manifest under `build/dist/`. The ZIP contains the staged tree at its root,
+which is the shape Foundry installs. When the manifest advertises a content
+index, the corresponding metadata JSONL is also placed beside the ZIP. A
+manifest that advertises an index the build has not produced fails the
+release. An opted-in staged `schema.json` is published beside it too.
+
+When the package publishes content and has a book configuration, the release
+also builds a PDF beside the archive. Book findings are reported without
+discarding the installable archive. `package-build release --no-pdf` skips the
+book step. The [book guide](book.md) covers selecting and checking its pages.
+
+The repository's build scripts decide how the staged tree is assembled. A
+typical content build runs `package-build content-index`,
+`package-build assets`, `package-build package compile`, and
+`package-build manifest` before release. Run `package-build bundle check` when
+the package ships a JavaScript bundle; it checks that the staged manifest
+loads that bundle once and in the right module form.
+
+## Deploy a staged build to Foundry
+
+Create `.env.local` at the repository root for machine-specific stage paths
+and credentials. Keep it ignored by git:
+
+```dotenv
+FOUNDRYVTT_DEV_DATA=/path/to/foundry-data
+FOUNDRYVTT_QA_DATA=yourhost:/srv/docker/data/foundryvtt-qa
+FOUNDRYVTT_PROD_DATA=yourhost:/srv/docker/data/foundryvtt-prod
+```
+
+The CLI loads `.env.local` before `.env`. A variable already in the shell takes
+precedence over either file; `.env.local` takes precedence over `.env`. A
+separate git worktree needs its own copy of this ignored file. Deploy the
+build already under `packageBuild.stageDir`:
+
+```bash
+package-build deploy dev
+package-build container dev status
+package-build container dev restart
+```
+
+The data root can be an absolute local path or a `[user@]host:/absolute/path`
+SFTP destination. The CLI appends `Data/systems/<id>` or `Data/modules/<id>`
+for the package. Paths in `.env.local` are literal: `~` and shell variables
+are not expanded. Keep stage paths pointed at distinct Foundry data roots.
+The deploy command stages a complete copy beside the installed package and
+swaps it into place, so it does not rewrite open LevelDB files one by one.
+For a remote destination it uses the SSH agent unless the stage names an
+explicit key. The `container` command manages the Foundry Docker instance for
+the same stage;
+`restart` stops it, clears a stale lock, then starts it. See the
+[container command](../commands.md#package-build-container-stage-action) for
+the other actions and environment variables.
+
+## Publish a package-build npm version
+
+For this toolchain's own npm release, a pull request with a change installers
+meet carries one changeset. An internal or documentation-only change carries
+none. The shared repository rules choose the bump: a non-optional user-visible
+change is minor; an optional command, flag, or key is patch. A major bump
+requires the maintainer's direct decision. `package-build changelog check`
+checks the quality of any pending changeset.
+
+Merging a changeset to `main` makes the **Version Packages** pull request. Its
+generated changelog section is reviewed as the release note. Merging that
+pull request runs the **Publish to npm** workflow: npm Trusted Publishing
+publishes the version, and the workflow creates its version tag and GitHub
+Release. The workflow's manual dispatch can retry publishing a version already
+merged to `main`. The [npm package page](https://www.npmjs.com/package/@heroiclands/package-build)
+shows the published version and README.

package/docs/guides/site.md

@@ -0,0 +1,152 @@
+---
+shortcode: guidessite
+name: { full: "Build a content website" }
+type: doc
+subType: howto
+---
+
+# Build a content website
+
+`package-build site` turns the package's content notes into a Hugo source
+tree. Hugo renders that tree with the shared theme. The build reads the same
+note addresses used by content indexes and links, so a page's URL follows the
+note it publishes.
+
+The site has an authored homepage and one page for each other publishable note
+in the content tree. The [configuration reference](../configuration.md)
+defines the site settings; the [command reference](../commands.md) lists the
+build actions and options.
+
+## Author the homepage
+
+Every content package needs exactly one note with `type: homepage`. Its
+`shortcode` makes it linkable from another note, while the site serves its
+body at the package root:
+
+```markdown
+---
+shortcode: root
+name: { full: The Setting Guide }
+type: homepage
+---
+
+# The Setting Guide
+
+Start with [Introduction](doc-introduction/).
+```
+
+The homepage's body is published as Markdown. Write ordinary Markdown links
+there, with addresses relative to the package root. Another note can refer to
+it with `[[homepage-root|The Setting Guide]]`. The homepage creates no
+Foundry compendium document and has no document ID. Its filename does not
+decide its role; the frontmatter does.
+
+The content tree controls the rest of the site. A tree containing only its
+homepage publishes that page alone. Each additional publishable note becomes
+its own page. The content index is a separate build artifact emitted by
+`package-build content-index`.
+
+Remove `publish.site` from package configurations. The presence of content
+notes determines whether the site and book contain pages beyond the homepage.
+
+## Configure the site frame
+
+A site with content pages declares its asset host and description. A
+documentation package can give the site its own title; a
+Foundry package can use its manifest title:
+
+```yaml
+site:
+  title: The Setting Guide
+  assets: https://cdn.heroiclands.org
+  description: A guide to the setting and its people.
+```
+
+The site title goes into Hugo's generated configuration. `site.description`
+is plain text for the page's metadata. `site.assets` is an absolute HTTP or
+HTTPS host for imagery. `package.json` supplies the homepage URL; it must
+agree with the content package's address. The
+[configuration reference](../configuration.md#site) covers the other site
+keys, including `base`, `packages`, `notfound`, and `hugo`.
+
+`site.hugo` can add Hugo options the build does not derive. Keys the build
+owns, such as `baseURL`, `title`, and the generated menu, are refused there.
+The menu comes from the navigation fetched by `package-build deps fetch`.
+The site build reads that cached navigation and reports a missing cache.
+
+## Make entry pages and indexes
+
+Each content note publishes one page at its Address-derived path. A `doc`
+note can serve as a reader-facing index, with links and a SQL content table
+over the notes it introduces:
+
+````markdown
+---
+shortcode: beings
+name: { full: Beings }
+type: doc
+subType: concept
+data: { pack: none }
+---
+
+# Beings
+
+People and creatures of the setting.
+
+```sql
+SELECT address.slug AS _ref, name.full AS "Name"
+FROM notes
+WHERE type = 'being'
+ORDER BY name.full
+```
+````
+
+Link that page from the homepage. `data.pack: none` keeps this journal-only
+note out of Foundry compendiums while leaving its web page and content-index
+record available. A SQL fence queries the content index; the
+[content format](../content-format.md) defines its result columns and fence
+options.
+
+The build writes no automatic section, type, tag, or listing pages between
+the homepage and the authored pages. Hugo's section, taxonomy, term, and RSS
+kinds are disabled for these sites. A package's navigation above individual
+notes is therefore a set of authored pages, each choosing its own contents.
+
+## Use links, relations, and maps
+
+Wikilinks resolve through the address index. Each emitted page receives
+derived `related` entries for its outgoing links and backlinks. Place pages
+can receive `contains` and `held_by` entries from place parents and
+affiliation domains; affiliation pages can receive `holdings`. These values
+come from the content graph and should be read as generated page metadata.
+
+Place relationships can also produce a map alongside the page. The page
+links to that map as a local page resource; a place with no applicable
+relationship has no map. Set `site.maps: false` to omit these drawings. The
+[book guide](book.md) covers full-page maps in PDF, and the
+[packs guide](packs.md) covers documents compiled for Foundry.
+
+A package with a named `site.pass` can apply its own body transformation
+before wikilinks resolve. The pass runs inside code-fence protection, so a
+fenced example remains literal. `site.passOptions` supplies that named pass's
+options. This is a package-specific extension point; keep the general note
+format and link behavior in the [content format](../content-format.md).
+
+## Build and serve
+
+```bash
+package-build deps fetch
+package-build content-index
+package-build site
+hugo --source build/hugo
+```
+
+`package-build site` writes `build/hugo/hugo.toml` and its content mount
+under `build/hugo/content/`. Hugo writes rendered pages under `build/site/`.
+`package-build site-root` adds the root headers and search index after Hugo
+runs. The output under `build/` is disposable; a site build replaces its
+content mount so a deleted note cannot leave a page behind.
+
+A package created by `package-build init` includes `npm run build:site` for
+this sequence and `npm run serve:site` for a local Hugo server. The site
+requires Hugo Extended and the shared theme in the project's dependencies.

package/docs/guides/system-project.md

@@ -0,0 +1,45 @@
+---
+shortcode: guidessystemproject
+name: { full: "Building a Foundry system" }
+type: doc
+subType: howto
+---
+
+# Building a Foundry system
+
+A system repository owns its Foundry source and its content package. The system's JavaScript, templates, styles, and localization are repository source; Markdown notes under `assets/content/` describe setting material and compile into the configured packs, site, book, and content index. Both sides are assembled by the same `package-build.config.yaml`.
+
+## Initialize the project
+
+```bash
+npm exec --package=@heroiclands/package-build -- package-build init my-system --kind systems --name my-system --title "My System" --description "A Foundry game system." --author "Your Name" --license original
+cd my-system
+npm install
+npm run lint
+```
+
+The initializer writes `package.json`, `package-build.config.yaml`, shared formatting configuration, a homepage and introduction note, `book.yaml`, localization, and npm scripts. It configures a JournalEntry pack, website, and book. It does not invent your Actor and Item DataModels or source bundle. Add those as the system grows, and declare every staged asset and pack in the build configuration. [Configuration](../configuration.md) gives the exact keys; [project setup](../project-setup.md) explains the scripts and generated directories.
+
+`packageKind: systems` determines Foundry's package kind. `contentPackage` is the first segment of every content Address and must contain lowercase letters and digits. `package.json` supplies the package ID, version, and repository URL. The Foundry manifest is generated from these sources; keep no hand-edited second manifest.
+
+## Add source and content
+
+Put system code under `src/`, templates under `templates/`, styles under `styles/`, and localization under `lang/`. Configure the build to stage the outputs Foundry loads and to validate the bundle against the generated manifest. [Project setup](../project-setup.md) describes the stage, language and bundle scripts; [localization](localization.md) covers keys and templates.
+
+Put authored notes under `assets/content/` in any folder arrangement that helps the team. The note's frontmatter determines its content type and system document. Start with [one note](../authoring/first-note.md), then add [system blocks](../authoring/frontmatter.md) to a being or Item. The shared body makes one JournalEntry even if both SoHL and HM3 blocks appear; game-specific fields come from the respective block.
+
+A system can own images, icons, and audio under their addressable roots. Keep provenance with each authored asset. [Assets](../authoring/assets.md) explains the roots and records. Set `packs` in the configuration for the compendiums the system ships; [packs](packs.md) explains routing and document compilation.
+
+## Build and review
+
+```bash
+npm run build:db
+npm run build:site
+npm run serve:site
+npm run build:book
+npm run build:noci
+```
+
+`build:db` writes the content index, stages assets, and compiles configured packs. `build:site` writes site content and renders it with Hugo Extended; `serve:site` starts a local Hugo preview. `build:book` uses Typst. `build:noci` runs lint, database, and manifest steps without reinstalling dependencies. Inspect `build/packs-json/` for compiled document data and `build/stage/` for what Foundry receives. Everything under `build/` is generated and can be deleted.
+
+The [testing guide](e2e.md) covers a disposable Foundry world. The [release guide](release-and-deploy.md) covers packaging and deployment. Site deployment needs its own hosting configuration; local builds do not.

package/docs/index.md

@@ -0,0 +1,16 @@
+---
+shortcode: root
+name: { full: Package Build Documentation }
+type: homepage
+description: Guides and reference for building HeroicLands Foundry systems, modules, and content.
+---
+
+# Package Build Documentation
+
+Build a Foundry system or module, author its content once, and publish it to Foundry, the web, and a book.
+
+- [Getting started](getting-started.md)
+- [Authoring content](content-format.md)
+- [Commands](commands.md)
+- [Configuration](configuration.md)
+- [API reference](api.md)