stnd.buildSTANDARD MANUAL2026-07-15

Standard::Code

The laws, the layers, and the Lightroom rule — how Standard is built and documented.

Standard::Code

The norm of construction. These are the non-negotiables that keep a
one-person framework coherent across years and across agents. Every rule
here is enforceable by reading the code — several are enforced by scripts.

4.1 The laws

  1. No backward compatibility — pre-release; deprecated code is deleted,
    never shimmed. (The golden rule.)
  2. DRY — reuse before you write.
  3. .astro holds no logic — views render; models and helpers think.
  4. Vertical slices — one feature, one folder, one manifest
    (index.module.js). Delete the folder, the feature disappears cleanly.
  5. Fail loud — every fatal error links a stnd.build/manual/<slug> page.
  6. English in the repo — all files, code, and published docs.

4.2 The layers

SHARED  (pure: utils, dom, log, styles, fonts, themes)
   ↑
CORE    (infrastructure: core, modules, server, store)
   ↑
FEATURE (capabilities: press, loader, launcher, account…)

Features never import a sibling feature’s logic. Boundaries are checked
mechanically (pnpm boundaries, dependency-cruiser).

4.3 No assumption bleed

A shared code path must not bake an assumption true for only one app. Per-app
intent is declared in that app’s config; shared code stays source-agnostic.
Litmus test: would this code do the wrong thing if a different app imported
it unchanged?

4.4 The Lightroom rule (documentation)

Information is ordered by frequency of need, not by internal
architecture.
Lightroom’s develop panel opens with exposure and white
balance and ends with camera calibration; documentation does the same:

  • Every README opens with an ELI5 — the problem, the install, the
    smallest example — before any reference material.
  • Reference detail follows, then Notes / Observations, then Todo.
  • The manual’s bookshelf itself obeys the rule: simplest book
    first, calibration last.

Cognitive load is a budget; spend it on what the reader came for.

4.5 Errors are documentation

Every fatal error the framework can throw has a manual page explaining the
what, the why, and the fix — written when the error is written, not after
the third support question.