Reference

Exhaustive reference material: the facts a developer or an operator needs without narrative. Six documents in this section, all built the same way: every fact verified against the source code as of the version they describe.

In this section

• build.pl Reference: the static builder: invocation guardrails, lifecycle (staging → checks → manifest → promote), full vs incremental rules, the promotion guard, exit codes, and the environment-variable table.
• cms.pl Reference: the CMS application: startup requirements, the admin/API dispatch structure, scheduled tasks, and the helpers other tooling reuses.
• Environment Variables: every CHINASKI_* variable, its default, and its effect, including the required trio (CHINASKI_SECRET, CHINASKI_DB, CHINASKI_OUTPUT) and the MCP/form-suite-specific sets.
• Settings Reference: every settings key by tab, with defaults, validation rules, and which ones trigger a rebuild (plus which cannot be reset).
• Schema Reference: every database table and column: what each stores, the constraints, and how the tables relate.
• Template Reference: the variables each site/block template receives, the partial inventory, and the security rules.

How to read these pages

The reference pages are deliberately terse: tables and rules, no tutorials. If you want the story behind a fact (why the promotion guard exists, why there is no plugin system), the Philosophy section covers that; the Authoring/Admin sections cover the workflows.

Conventions

• Facts are stated as facts; flag-worthy edge cases sit inline in the relevant row.
• Where the same behavior has both a settings-field and an environment-variable control, both are listed with their precedence (env vars win).
• Numbers in the reference (limits, defaults, timeouts) are code-verified; when the docs and the code ever disagree, trust the code, and file a note so both can be corrected.