novaconium/AGENTS.md

# AGENTS.md

Context for any coding agent working in this repo — Claude, DeepSeek, or
otherwise; this file (and the maintenance rule below) applies regardless of
which model or CLI is driving. Full narrative docs live at `/admin/docs`
when the app is running (also the *only* place Twig upgrade instructions
live now — see `/admin/docs/upgrading-twig`; there's no separate
MAINTENANCE.md, keeping one copy in the docs page avoids drift). `README.md`
is the GitHub-facing pitch, `novaconium/ISSUES.md` is the roadmap/backlog,
and this file is the short, agent-facing version. The original design
rationale used to live in a standalone `plan.md`; it's now folded into
`/admin/docs/design-notes` (everything in it shipped) and the file was
deleted. There used to also be a
`GUIDE.md` mirroring `/admin/docs` for offline reading — it was removed to
cut a doc copy that had to be kept in sync; `/admin/docs` is the only
narrative reference now.

## Documentation is duplicated on purpose — keep all copies in sync

Every topic (routing, sidecars, libraries, layouts, caching, SEO, Matomo,
admin authentication, styling, project layout, third-party) exists in
**two** places: a page under `novaconium/pages/admin/docs/<topic>/index.twig`
(the canonical reference), and (for anything a README-reading human needs
up front) a mention in `README.md`. This is intentional — `/admin/docs` is
for reading against a running instance with no internet needed, and
`README.md` is the GitHub-facing pitch — but it means **any agent that
changes framework behavior or adds a feature must update both copies in
the same change**, not just the one that was open. Concretely, after
touching routing/rendering/caching/SEO behavior or adding a new top-level
docs topic:

1. Update (or add) the matching page under
   `novaconium/pages/admin/docs/<topic>/index.twig`, and if it's a new
   topic, link it from both `admin/docs/index.twig` and the nav in
   `admin/docs/_layout/layout.twig`.
2. Update `README.md` if the change affects the feature list, getting
   started steps, or the docs index there.
3. Update this file if the change affects a convention an agent needs to
   know before editing code (not just narrative docs).

A doc change that only touches one of these copies is incomplete —
verify the other copy before considering the task done.

## What this is

A dependency-light PHP + Twig micro-framework: directories under `pages/`
map directly to URLs (Hugo-style page bundles), optional `index.php`
sidecars supply data or short-circuit to a `Response`, and sidecar-less
pages get pre-rendered to static HTML on first request and served straight
from Apache after that. No Composer, no build step to install — Twig is
vendored as plain source files.

## The two-root split — read this before editing anything under `pages/` or `lib/`

Everything lives in one of two places:

- **`App/`** — the actual project: `App/pages/` (routes/content) and
  `App/lib/` (project's own `Lib\` classes). This is the only directory a
  site author is expected to touch.
- **`novaconium/`** — the framework itself: router/renderer core
  (`novaconium/src/`), default pages (`novaconium/pages/` — root layout,
  404, the `/admin` tools), default `Lib\` classes (`novaconium/lib/`),
  vendored Twig, autoloader, config, bootstrap.

Routing and rendering resolve against **both roots, in order** —
`App/pages/` first, `novaconium/pages/` as fallback — via
`novaconium/src/Overlay.php`. Same mechanism for `Lib\` classes:
`App/lib/` is checked before `novaconium/lib/` in `novaconium/autoload.php`.
Concretely: dropping a file at the same relative path in `App/` overrides
the `novaconium/` default; nothing needs to be duplicated for the site to
work, since `novaconium/pages/` already supplies a working layout and 404.

Twig's `FilesystemLoader` is constructed with both paths as an array, so
`{% extends %}` / `{% include %}` get this override-then-fallback
resolution for free — no custom logic needed there.

The same override-by-presence pattern applies to `novaconium/config.php`:
if `App/config.php` exists, `novaconium/bootstrap.php` and
`novaconium/bin/clear-cache.php` shallow-merge it over the framework defaults
with `array_merge()`. A project only needs to list the keys it's changing
— never edit `novaconium/config.php` directly.

`config['matomo_url']` / `config['matomo_site_id']` (both default `''`)
gate the Matomo tracking script emitted by the root layout — set both via
`App/config.php` to enable it, since either being empty disables tracking
entirely. `bootstrap.php` normalizes a missing trailing slash on
`matomo_url` before passing it to `Renderer`, which exposes `matomo_url`,
`matomo_site_id`, and `is_404` as Twig globals (`is_404` is overridden to
`true` in the 404 template's local render context by
`Renderer::renderNotFound()`, per Twig's local-context-over-global
precedence). Any new Twig global added to `Renderer`'s constructor should
follow this same pattern: default value, `addGlobal()` call, documented
here and in `/admin/docs`.

`config['site_name']` (default `'My Site'`) is the same pattern — passed to
`Renderer` and exposed as the `site_name` Twig global, used by
`novaconium/pages/_layout/layout.twig` for the default `title` block,
`og:site_name`, and the footer copyright line. Any other hardcoded
site-identity string that shows up in a shared template (as opposed to a
per-page override) should become a `config.php` key the same way, not stay
hardcoded in the template.

`config['admin_username']` / `config['admin_password_hash']` (username
defaults to `'admin'`, password hash defaults to `''`) gate every
`/admin/*` route behind HTTP Basic Auth — this replaced the old
`docs_enabled` flag entirely (removed); a single gate over all of
`/admin/*` (docs included) made a docs-only toggle redundant. Unlike the
Twig-global pattern above, the gate itself is enforced in `bootstrap.php`,
before rendering: `AdminAuth::requireLogin(...)`
(`novaconium/src/AdminAuth.php`) is called once for any resolved route
whose path is `admin` or starts with `admin/`. **Any new admin page
dropped under `App/pages/admin/` or `novaconium/pages/admin/` is
automatically protected — no per-page wiring needed.** `bootstrap.php`
also special-cases the literal path `/admin/logout` *before* router
resolution — no page exists there — to call `AdminAuth::logout()`, which
always issues a fresh 401 so the browser drops its cached credentials
(there's no server-side session to invalidate). `Renderer` separately
exposes an `admin_auth_enabled` Twig global (true when a password hash is
set) so `admin/index.twig` can conditionally show the "Logout" link — this
is a derived display flag, not the enforcement mechanism itself, which
never depends on Twig. `novaconium/pages/admin/password-hash/` is a
built-in `password_hash()` form (no CLI needed) for generating
`admin_password_hash` — a normal admin page, so it's covered by the same
gate: reachable while no password is set yet (to generate the first
one), then protected like everything else under `/admin/*` afterward. It
computes and displays the hash per-request only; nothing is persisted or
logged. This is a single-user HTTP Basic Auth stopgap, not
the full multi-user system tracked in `novaconium/ISSUES.md` ("Admin login & user
management"); don't extend this class toward multi-user/session-based
auth — that's a separate, larger feature that
will replace it.

`Lib\Db` (`novaconium/lib/Db.php`) is the SQLite/MySQL groundwork tracked
in `novaconium/ISSUES.md` — a thin, no-ORM PDO wrapper, `Lib\` (not `App\`)
so a project can override it via `App/lib/Db.php` like any other `Lib\`
class. It supports multiple, independently-configured, **simultaneously
open** named connections (`config['db_connections']`, keyed by name) rather
than one global connection — because sidecars are plain PHP with full
access to any `Lib\` class, a single request can legitimately need more
than one database at once (e.g. this site's own SQLite data alongside a
MySQL connection to a legacy database). `Db::query(string $sql, array
$params = [], string $connection = 'default')` (prepare+execute) is the
only query-running helper — never add a string-interpolation shortcut; see
`Lib\Input`'s doc-comment, which already commits this project to
parameterized queries as the sole SQL-injection defense. Each connection is
lazy and independent (opened on first `Db::query()`/`Db::connection()` call
naming it, same shape as `Lib\Csrf`'s lazy session start), and migrates
automatically at that point: plain `.sql` files under that connection's own
`migrations_dir` — a single path, or (since the content index shipped) an
**ordered list of roots**, each root's own files filename-ordered and
roots processed fully in the order given, not interleaved by filename
across roots (so a framework root always finishes before a project root on
the same connection). Tracked by path **relative to the repo root** (e.g.
`novaconium/migrations/0001_x.sql`), not bare filename — two roots can
each contain a same-named file, and tracking by bare filename would make
the second one seen look "already applied" and silently skip it; a
repo-relative path is also portable across environments, unlike a full
absolute path, which would make every migration look new again after a
clone/deploy to a different directory. `realpath()` normalizes any `..` a
`migrations_dir` like `__DIR__ . '/../App/migrations'` would otherwise
leave in the tracked name. Each connection's own auto-created
`schema_migrations` table tracks its migrations independently of any other
connection's; each is only ever run once. `novaconium/bin/migrate.php`
loops every configured connection and runs the same migration step
explicitly (e.g. from a deploy script) without serving a request first.
Only `'sqlite'` and `'mysql'` drivers are implemented; a connection's
`migrations_dir` is optional — omit it to never run migrations against
that connection (e.g. a legacy database this project shouldn't manage
schema for).

**`db_connections` is the one config key in the project that isn't plain
shallow-merge** — `bootstrap.php`/`bin/*.php`'s usual `array_merge($config,
$appConfig)` would let a project's `App/config.php` silently delete the
framework's `default` connection just by adding a second named connection
(a shallow merge replaces the whole key, it doesn't merge inside it). So
`Lib\Db::config()` (and the copy of this logic duplicated in
`bin/migrate.php`, same duplication precedent as the two-step config load
already duplicated across `bootstrap.php`/`bin/clear-cache.php`) merges
`db_connections` one level deeper, by connection name, **after** capturing
the framework defaults — capture the defaults *before* the top-level
`array_merge()` overwrites `$config['db_connections']`, not after, or the
deeper merge silently operates on the already-overwritten value and the
`default` connection vanishes anyway. (This exact bug was hit once while
building this feature — verified by testing a real `App/config.php`
override end-to-end, not just reading the code — so it's worth re-checking
by hand if this logic is ever touched again.) See
`/admin/docs/database` for the worked example.

**`config['db_connections']['default']['path']` must stay outside both
`public/` (would be web-accessible) and `novaconium/`** — unlike
`cache_dir`/`contact-log.txt`, which are disposable, a SQLite file is data a
project can't afford to lose, and `novaconium/` gets wholesale-replaced by
the "Updating the framework" workflow (`/admin/docs/getting-started`: `rm
-rf novaconium && cp -r <new-novaconium>`). The default
(`data/novaconium.sqlite`) lives in a new top-level `data/` directory
instead — project-owned like `App/`, gitignored per-file
(`*.sqlite`/`-journal`/`-wal`/`-shm`, with a tracked `.gitkeep` so the
directory exists in a fresh clone) rather than wholesale like
`public/cache/`, since a project might reasonably want other non-DB files
there later. The default connection's `migrations_dir` scans
`novaconium/migrations/` (framework-shipped schema, e.g. the content
index below) before `App/migrations/` (project schema) — see the
`migrations_dir` array-form paragraph above. Any *other* connection a
project adds still defaults to no `migrations_dir` at all unless it sets
one; the two-root default is specific to `default`.

`Lib\Session` (`novaconium/lib/Session.php`) is a thin wrapper around
native PHP sessions (`session_start()`/`$_SESSION`, not a custom store),
all-static and lazy-start like `Lib\Csrf` — nothing calls `session_start()`
until the first real call to a `Session` method. Its `ensureSession()` is a
**deliberate duplicate** of `Csrf::ensureSession()` (same cookie params,
same `session_status()` guard) rather than a shared helper — keeps `Csrf`
standalone with zero new dependencies on a class that didn't exist when it
shipped, same tolerance for small duplication already established by the
config-load block duplicated across `bootstrap.php`/`bin/clear-cache.php`/
`Lib\Db::config()`. Both classes touching the same native session in the
same request is safe either way, since `session_start()` silently no-ops
if a session is already active — there's no ordering requirement between
`Csrf::token()`/`::verify()` and any `Session` method.

Flash data (`Session::flash()`/`::getFlash()`) is one swap, not a
sweep/expiry pass: the first `Session` method call in a request snapshots
whatever was flashed on the *previous* request into an in-memory static
(`self::$currentFlash`) for that request's `getFlash()` reads, then
immediately empties the stored flash bucket so `flash()` calls made
*during* the current request start filling a fresh bucket for the request
after this one. This relies on static properties not persisting across
requests (true under `php -S`, mod_php, and PHP-FPM alike — each request
gets fresh PHP state regardless of worker-process reuse) — don't add any
caching/memoization to `Session` that assumes static state survives
between requests, since none of it does. See `/admin/docs/session` for a
worked flash example.

**Standing rule: any mechanism that conditionally hides page content from
the public must also be threaded into `Renderer::render()`'s
`$excludeFromCache` decision, not just a pre-render auth gate.** This
bit twice already — once as a designed-around gotcha (draft pages), once
as a real pre-existing bug found while testing that feature (`/admin/*`
itself). The reason: `Renderer::render()` writes a sidecar-less page's
output to the static HTML cache (`novaconium/src/Cache.php`), and
`.htaccess` serves a cached file *before PHP, and therefore any auth
check, ever runs again* (see `/admin/docs/caching`). A route can be
gated by `AdminAuth::requireLogin()`/`::isAuthenticated()` and still leak
completely to the public the moment it's viewed once by someone
authorized, if the page has no sidecar and nothing tells `Renderer` to
skip the cache write for that route. `draft_routes` (see
`/admin/docs/drafts`, `novaconium/config.php`) and every `/admin/*` route
both pass `true` for `Renderer::render()`'s `$excludeFromCache` param
from `novaconium/bootstrap.php` for exactly this reason — most pages
under `novaconium/pages/admin/` (e.g. `admin/index.twig`) have no
sidecar, so before this was wired up, visiting `/admin` once as an
authenticated admin would cache the admin panel and serve it to every
subsequent visitor, unauthenticated, straight from `public/cache/admin/`.
Any future feature that gates a route by anything other than a sidecar
check (paywall content is the next one on the roadmap likely to hit this)
needs to make the same check here, not just at the point where the
request is first authorized.

`AdminAuth::isAuthenticated(string $username, string $passwordHash): bool`
(`novaconium/src/AdminAuth.php`) is the credential check on its own, with
no response side effects, extracted out of `requireLogin()` (which still
does the same check, then issues the `401` challenge on failure) so a
different caller can react to failure differently. The draft-page gate in
`bootstrap.php` is the first such caller: on failure it renders a plain
404 via the same path an unmatched route takes, not a login prompt —
prompting for credentials at a draft URL would itself reveal that
something is gated there, which defeats the point of hiding it. Returns
`true` (open access) when `$passwordHash` is empty, mirroring
`requireLogin()`'s existing no-op-when-unset posture, so a draft behaves
consistently with the rest of `/admin/*`: wide open until a password is
configured, gated once one is.

`App\ContentIndexer` (`novaconium/src/ContentIndexer.php`) is the shared
crawler behind `/sitemap.xml`, `/search`, and blog tag browsing (see
`/admin/docs/content-index`) — `App\`, not `Lib\`, since it's rendering
infrastructure akin to `Renderer`/`Router`, not project-overridable
content. Content stays in files; only metadata is indexed. Per-page
metadata is four Twig blocks declared in the root layout next to the SEO
blocks (`keywords`, `tags`, `changefreq`, `priority` — the last three
never rendered into the page, only harvested) and pulled via
`Renderer::renderForIndex()`, which calls Twig's own
`TemplateWrapper::renderBlock()` per block rather than parsing `.twig`
source — this is deliberate: it gets App-over-novaconium override and
layout-inheritance resolution for free, the same way a real render does.
**`config['content_index_enabled']` defaults to `false`** — same posture
as `matomo_url`/`admin_password_hash`, since this is a real SQLite
dependency plenty of sites won't want. Every consumer route checks the
flag *before* touching `Lib\Db` and 404s if it's off, so the feature has
zero filesystem footprint (no `data/novaconium.sqlite`) when disabled —
verified end-to-end, not assumed, since "off" silently still creating a
database file would defeat the point.

**Reentrancy hazard, already hit once:** `ContentIndexer::reindex()`
renders every routable page as part of the crawl — including `/search`
itself, which is also a real page and also calls
`ContentIndexer::ensureFresh()` from its own sidecar. Without a guard,
crawling `/search` would trigger a nested `reindex()` call mid-transaction
and fatal on a second `PDO::beginTransaction()`. `ContentIndexer` guards
this with a `private static bool $indexing` flag, checked at the top of
both `ensureFresh()` and `reindex()` — either no-ops while a reindex is
already running on the call stack. Any future consumer route added under
this mechanism inherits the same hazard for free (it'll also get crawled,
and if its sidecar also calls `ensureFresh()`, the guard already covers
it) — don't remove the flag thinking it's unnecessary.

`reindex()` also forces `$_SERVER['REQUEST_METHOD']` to `'GET'` for the
duration of the crawl (restoring whatever it was before, in a `finally`)
— sidecars are expected to be side-effect-free for non-POST requests
anyway (ordinary HTTP-safe-method hygiene), but this guarantees a lazy
reindex triggered from within a POST request can never leak that POST
into an unrelated page's sidecar purely because the crawler happened to
render it. A crawl is a full truncate-and-rebuild inside one transaction,
not incremental — simple and correct at this site's scale; don't add
incremental/diffing logic without a real need for it.

**Standing rule: a vendored dependency's files go under `novaconium/vendor/`
only if they're server-side (PHP, autoloaded, never fetched by a browser)
— anything the browser has to fetch (`.js`, `.css`, images) has to live
under `public/vendor/` instead, since `public/` is the only web-reachable
directory (`novaconium/` isn't reachable at all — see `public/.htaccess`).**
Twig lives under `novaconium/vendor/twig/` correctly, since it's pure PHP
source. highlight.js (`/admin/docs/upgrading-highlightjs`,
`public/vendor/highlightjs/`) is the first vendored dependency that's
actually browser-servable, and originally almost got vendored to
`novaconium/vendor/` too, following Twig's precedent blindly — that would
have silently 404ed on every request, since nothing under `novaconium/`
is ever served to a browser. This has a real consequence beyond just
placement: `public/` is project-owned and untouched by the "Updating the
framework" workflow (`rm -rf novaconium && cp -r <new-novaconium>` — see
`/admin/docs/getting-started`), so a future framework release that bumps
a `public/vendor/`-placed dependency will **not** carry that upgrade to
an existing project automatically the way a `novaconium/vendor/` bump
would — re-vendoring it is a separate manual step every time, documented
per-dependency (see `/admin/docs/upgrading-highlightjs`).

**`class="nohighlight"` marks a `<pre><code>` block whose content is
literal Twig template syntax** (`{% %}`/`{{ }}`), so highlight.js's
auto-detection (`novaconium/pages/_layout/syntax-highlight.twig`,
restricted to `configure({ languages: ['php', 'bash', 'xml', 'css',
'python', 'javascript', 'yaml', 'json', 'ini'] })` — `yaml`/`json`/`ini`
are vendored as separate per-language files under
`public/vendor/highlightjs/languages/`, not part of the core bundle like
the other six; see `/admin/docs/upgrading-highlightjs`) doesn't
force-match it to whichever configured language scores highest — Twig has
no highlight.js grammar, and a restricted auto-detect still always
returns its best guess among the allowed set, never "give up," so an
unmarked Twig block would get colored *wrong*, not just left plain.
Currently on:
`novaconium/pages/admin/docs/{layouts,content-index,rss,sitemap,forms,seo}/index.twig`
and `App/pages/blog/{style-guide,twig-syntax-guide}/index.twig`. A new
Twig-syntax code sample added anywhere needs the same class — a PHP or
Bash sample doesn't (auto-detection handles those reliably on its own,
via strong signals like a leading `<?php`).

## Running it

```
php -S 127.0.0.1:8000 -t public public/router.php
```

`public/router.php` is dev-only, mimics `public/.htaccess`. There is no
test suite — verification is manual route-by-route (see
`/admin/docs/design-notes`'s Verification section for the checklist used
after any framework change).
After testing, clear stray cache with `php novaconium/bin/clear-cache.php` or
POST `/admin/clear-cache`, and remove anything written to `App/lib/` or
`App/pages/` that was only for testing an override — nothing here is
gitignored except `public/cache/*` and `novaconium/contact-log.txt`, so
test debris left in `App/` will otherwise get committed or silently change
site behavior for the next person.

## Conventions worth knowing

- Reserved segments: any path segment starting with `_` (e.g. `_layout/`)
  or literally named `404` is never routable — `Router::resolve()` 404s on
  sight, don't try to serve content directly at those paths.
- Sidecars (`index.php`) return either an array (Twig context) or a
  `Response` (redirect/json/xml/html — `novaconium/src/Response.php`).
  `$params` (route captures) and `$cache` (the `Cache` instance, e.g. for
  `$cache->clear()`) are both in scope automatically — see
  `novaconium/src/Renderer.php::runSidecar()`.
- No Composer — `novaconium/autoload.php` is a hand-rolled PSR-4 loader.
  Adding a new framework-core class means adding it under `App\` in
  `novaconium/src/`; a new `Lib\` class goes in `App/lib/` or
  `novaconium/lib/` depending on whether it's project- or
  framework-specific.
- `novaconium/bin/` holds standalone CLI entry points meant to be run
  directly (`php novaconium/bin/<script>.php`) — distinct from
  `bootstrap.php`/`autoload.php`/`config.php`, which are only ever
  `require`'d, never invoked directly. `clear-cache.php` and
  `create-static-page.php` (scaffolds a new page from the `/admin/docs/seo`
  starter template) both live there; a new CLI tool goes there too.
- CSS is compiled from `novaconium/sass/main.sass` (indented syntax) to
  `public/css/main.css`. `dart-sass` is installed in this environment
  (Arch: `pacman -S dart-sass`) — after editing Sass source, run:
  `sass --load-path=App/sass --load-path=novaconium/sass/defaults --no-source-map novaconium/sass/main.sass public/css/main.css`
  and commit the regenerated `public/css/main.css` (`--no-source-map`
  avoids a stray `main.css.map` the project doesn't otherwise use). If
  `sass` isn't available in whatever environment you're in, either run it
  via Docker — `/admin/docs/styling` has a copy-pasteable
  Dockerfile that installs the same standalone Dart Sass release used in
  this environment (`1.101.0`) directly from GitHub, not via npm, plus
  the `docker build`/`docker run` commands adjusted to this repo's paths
  — or hand-edit both files in parallel and keep them in sync — that's
  how the dark/teal theme and the homepage hero/animation
  styling were originally written before `sass` was installed here.
- The Sass color palette follows the same App-over-novaconium override
  pattern as pages/lib, but with a twist worth understanding before
  touching it: `novaconium/sass/main.sass` does `@use 'colors' as *`, and
  its own directory (`novaconium/sass/`) deliberately has **no**
  `_colors.sass` sibling. Dart Sass resolves a bare `@use` relative to the
  importing file's own directory *before* consulting `--load-path`
  entries, so if `novaconium/sass/_colors.sass` existed next to
  `main.sass`, it would always win regardless of load-path order —
  silently defeating the override. Keeping the framework default at
  `novaconium/sass/defaults/_colors.sass` (a different directory) forces
  resolution through the load path, where `App/sass` (checked first) can
  actually override it with `App/sass/_colors.sass`. Don't move
  `defaults/_colors.sass` back next to `main.sass` — it was moved out on
  purpose, and doing so reintroduces this bug.
- Every color rule in `main.sass` reads a CSS custom property
  (`var(--bg)`, `var(--accent)`, etc.), never a Sass variable directly —
  that indirection is what makes the dark/light theme toggle possible,
  since Sass only runs at compile time and can't react to a runtime
  choice on its own. The two `_colors.sass` files seed `:root` (dark,
  the default) and `:root[data-theme="light"]` (via `-light`-suffixed
  variables — `$bg-light`, `$accent-light`, etc., same files, same
  override mechanism) once at compile time; the toggle button in
  `novaconium/pages/_layout/nav.twig` flips the `data-theme` attribute on
  `<html>` at runtime and persists it to `localStorage`.
  `novaconium/pages/_layout/theme-init.twig` re-applies a saved choice
  early in `<head>` (before the stylesheet link) to avoid a flash of the
  wrong theme on load. If you add a new color to the palette, add both
  the plain and `-light` variable in **both** `_colors.sass` files and
  wire it into both `:root` blocks in `main.sass` — a color that's only
  themed in one direction will look wrong after a toggle.
- Sidecars should read request data via `Lib\Input::post()`/`::get()`
  (`novaconium/lib/Input.php`) rather than `$_POST`/`$_GET` directly — it
  trims, strips tags, and strips null bytes automatically. This is
  defense-in-depth against HTML/script injection, **not** SQL-injection
  protection (no string transform makes input safe to concatenate into a
  query — use PDO prepared statements once a database layer exists); don't
  add an `sqlSafe()`-style method to `Input`. One documented exception: a
  field needing an exact, unmodified value (e.g. a password about to be
  hashed) should read `$_POST` directly instead — see
  `novaconium/pages/admin/password-hash/index.php`. `Lib\Csrf`
  (`novaconium/lib/Csrf.php`) is standalone session-token CSRF protection, not
  wired into `FormValidator` — a sidecar calls `Csrf::verify()` directly.
  It's the first thing in the framework to start a native PHP session (only
  lazily, when a form actually calls it), which is otherwise unrelated to
  `AdminAuth`'s own session-free Basic Auth.
- Don't use Twig's `|slice` filter on a **string** (as opposed to an
  array) — it unconditionally calls PHP's `mb_substr()` with no fallback
  (`novaconium/vendor/twig/src/Extension/CoreExtension.php`), which
  hard-requires the `mbstring` extension and will fatal
  (`Call to undefined function Twig\Extension\mb_substr()`) on a PHP
  install without it — a real regression this project hit once already,
  back when `/blog/hello-world` had a sidecar computing an excerpt this
  way (see the footnote on `App/pages/blog/twig-syntax-guide/index.twig`
  for the full story). Truncate strings in PHP instead, guarded with
  `function_exists('mb_substr')` falling back to `substr()`, and pass the
  already-truncated value into the template.
- Same class of bug, different filter: don't use Twig's `|escape('js')` (or
  the `'js'` arg to `|e`) either — it calls `Twig\Runtime\mb_ord()`
  (`novaconium/vendor/twig/src/Extension/EscaperExtension.php`), which
  hard-requires `mbstring` the same way `|slice` does, and fatals
  identically without it. Hit for real when
  `novaconium/pages/_layout/code-copy.twig` used it to pass SVG icon
  markup into an inline `<script>` as a JS string literal. Fixed by not
  needing string-escaped markup in JS at all: render the markup as plain
  HTML into a `<template>` element (default autoescaping, no mbstring
  dependency) and read it in JS via that template element's `.innerHTML`
  getter instead. Prefer that pattern — or a `data-*` attribute if the
  value is plain text, not markup — over `|escape('js')` any time a Twig
  value needs to reach JS.