release: 1.5.1, the theme release

The viewer and leji.org follow the operating system's light or dark mode, a layer may fix its viewer's appearance with viewer.theme.appearance, and leji.org gains a reader's appearance control. A feature now starts as a public request measured against ROADMAP.md, and the collapsed menu button keeps its own language across a press; detail in CHANGELOG.md.

Signed-off-by: Vuong Nguyen <vuong@contexing.com>

Author: ContexingVN

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,21 @@
+---
+name: Feature request
+about: 'A capability Leji does not have yet: the problem, the lived case, the surface'
+labels: feature-request
+---
+
+**Which surface**: <!-- spec · schemas · SDKs and CLI · MCP server · create-leji · viewer · site -->
+
+**The problem**
+
+<!-- What you cannot do today, stated as the problem rather than the fix you have in mind. -->
+
+**The lived case**
+
+<!-- What a real team does today and where it breaks. Leji specifies proven practice, so a case someone lives carries more weight than an idea in the abstract. -->
+
+**Roadmap fit**
+
+<!-- Which theme in ROADMAP.md this serves, or the theme it would add. -->
+
+<!-- Note: you get an answer normally within 14 days, one of three: accepted (naming the release it targets), not now (naming what would change that), or declined (with the reason, kept on the issue). Acceptance authorizes building toward that release, subject to review and, for anything normative, to the comment periods GOVERNANCE.md sets; it is not a merge and not a guarantee that the change ships. Code follows an accepted request. -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,4 +1,4 @@
-<!-- What does this change, and why? Link the issue if there is one. -->
+<!-- What does this change, and why? A fix links its issue if there is one. A feature links its accepted feature request; a feature without one is triaged as a request first, and its code waits on the answer. -->
 
 ## Checklist
 

.github/workflows/ci.yml

@@ -305,7 +305,7 @@ jobs:
         uses: goreleaser/goreleaser-action@f06c13b6b1a9625abc9e6e439d9c05a8f2190e94 # v7.2.3
         with:
           # The same goreleaser the release job installs (scripts/release-pins.env).
-          version: "v2.18.1"
+          version: "v2.18.2"
           workdir: packages/sdk-go
           args: check
 

.github/workflows/release-checks.yml

@@ -183,7 +183,7 @@ jobs:
         uses: goreleaser/goreleaser-action@f06c13b6b1a9625abc9e6e439d9c05a8f2190e94 # v7.2.3
         with:
           # The same goreleaser the release job installs (scripts/release-pins.env).
-          version: "v2.18.1"
+          version: "v2.18.2"
           workdir: packages/sdk-go
           args: release --clean --skip=publish
         env:

.github/workflows/release-finalize.yml

@@ -13,7 +13,7 @@ on:
       release_tag:
         description: "Tag the draft release is attached to (the goreleaser/Go tag)"
         required: true
-        default: "packages/sdk-go/v1.5.0"
+        default: "packages/sdk-go/v1.5.1"
 
 permissions:
   contents: write # publish the release

.github/workflows/release.yml

@@ -247,7 +247,7 @@ jobs:
         with:
           # The action is pinned by SHA; this input pins the goreleaser it
           # installs, and mirrors GORELEASER_VERSION in scripts/release-pins.env.
-          version: "v2.18.1"
+          version: "v2.18.2"
           workdir: packages/sdk-go
           args: release --clean --skip=publish
         env:

CHANGELOG.json

@@ -157,6 +157,23 @@
       ],
       "proposedBy": "Vuong Nguyen",
       "approvedBy": "Vuong Nguyen"
+    },
+    {
+      "id": "release-1-5-1",
+      "date": "2026-09-17",
+      "type": "added",
+      "summary": "viewer.theme.appearance, an optional manifest field naming the color scheme the viewer renders in (system, light, or dark), additive on the frozen 1.0 line with the schema $id unchanged; the viewer and leji.org follow the operating system's color scheme; all reference packages to 1.5.1.",
+      "paths": [
+        "schemas/",
+        "templates/",
+        "packages/sdk/",
+        "packages/sdk-py/",
+        "packages/sdk-go/",
+        "packages/mcp/",
+        "packages/site/"
+      ],
+      "proposedBy": "Vuong Nguyen",
+      "approvedBy": "Vuong Nguyen"
     }
   ]
 }

CHANGELOG.md

@@ -1,5 +1,61 @@
 # Changelog
 
+## 1.5.1 · 2026-09-17
+
+### Added
+
+- **A dark theme for the viewer, following the operating system.** `leji view` and the
+  exported viewer read `prefers-color-scheme` and paint the brand's dark surfaces when the
+  reader's system is dark. There is no toggle and no stored choice: one dark stylesheet,
+  linked with `media="(prefers-color-scheme: dark)"`, re-values the theme tokens and
+  overrides the stock grounds, rules, tones, and syntax colors that read no token, every
+  text tone the dark palette declares at 4.5:1 or better on every dark ground.
+  `viewer.theme.link` governs the light scheme only, because the guard measures an authored
+  color against the light grounds; the dark scheme's link tone is fixed. The authored
+  `viewer.theme.primary` keeps its light-scheme role; in dark it colors no text and
+  diagrams take a fixed palette. Mermaid diagrams take a palette per scheme and re-render
+  from their authored source when the system scheme changes, with no reload. A reader whose
+  system is light, on a layer that names no scheme, sees the 1.5.0 viewer unchanged.
+  Requested in #14 by Daniel Montilla; the feature request on the record is #16.
+- **`viewer.theme.appearance`**: an optional manifest field naming which color scheme the
+  viewer renders in. `system` (the default) follows the reader's operating system, as
+  above; `light` and `dark` render that scheme on every system. A named scheme is stamped
+  on the page's root element and in the `color-scheme` meta, which reads `light dark` where
+  the choice stays the reader's; the dark stylesheet is linked under the dark media query
+  for `system`, unconditionally for `dark`, and not at all for `light`; the Mermaid
+  initializer reads the stamp before the system. A layer that sets nothing renders as
+  `system`, its page differing from 1.5.0's by that stylesheet link, the `color-scheme`
+  meta, and an inline style block that reads the palette tokens where it restated the same
+  light colors, and, where the layer names a link tone, that declaration scoped to the
+  light scheme. Additive schema field, `$id` unchanged; the schema page on leji.org
+  describes it in six languages. The choice is the layer's: the viewer carries no reader
+  control.
+- **leji.org follows the operating system's color scheme, and the reader may choose.** One
+  dark palette over the site's role tokens, on the viewer's charcoal grounds, every text
+  pair at AA; the light and dark palettes ship as their own stylesheets. A control at the
+  lower right of every page cycles system, light, and dark in the page's language, keeps
+  the choice in the browser where storage allows, and applies it before the first paint. A
+  reader whose system is light and has chosen nothing sees the 1.5.0 page with the control
+  added and the footer's last row clear of its corner.
+
+### Changed
+
+- **A feature starts as a request.** `CONTRIBUTING.md` gains "Before you build": a bug
+  fix, a correction, or a test for behavior the docs already promise is a direct pull
+  request; anything that adds behavior, a surface, a dependency, a toolchain path, or a
+  manifest field opens as a feature request first, answered normally within 14 days with
+  accepted (naming the release it targets), not now (naming what would change that), or
+  declined (with the reason kept on the issue). A feature-request issue template and the
+  pull request template's request line carry the path, and `ROADMAP.md` at the repository
+  root states the direction requests are measured against, linked from `README.md`,
+  `CONTRIBUTING.md`, and `GOVERNANCE.md`.
+
+### Fixed
+
+- **The collapsed menu button keeps its own language across a press.** On a translated page
+  the header script rewrote the button's accessible name in English on every press; the
+  rendered name now stays, and `aria-expanded` carries the state.
+
 ## 1.5.0 · 2026-09-14
 
 ### Added

CONTRIBUTING.md

@@ -1,6 +1,24 @@
 # Contributing
 
-The Leji spec is at 1.0, extracted from lived practice; the reference SDKs and tooling are at 1.5.0. The 1.0 spec line is GA and frozen at the v1.3.0 reference-tooling release: schema changes within it are additive only, and breaking changes require a new line per spec/versioning.md.
+The Leji spec is at 1.0, extracted from lived practice; the reference SDKs and tooling are at 1.5.1. The 1.0 spec line is GA and frozen at the v1.3.0 reference-tooling release: schema changes within it are additive only, and breaking changes require a new line per spec/versioning.md.
+
+## Before you build
+
+**A direct pull request is welcome** for a bug fix, a typo, a documentation or translation correction, or a test for behavior the docs already promise. Open it whenever you like, and link an issue if one exists.
+
+**Anything else starts as a feature request**: anything that adds behavior, a surface, a dependency, a toolchain path, or a manifest field, in any package or on the site.
+
+**You get an answer normally within 14 days**, one of three:
+
+- **Accepted**, naming the release it targets.
+- **Not now**, naming what would change that.
+- **Declined**, with the reason, kept on the issue ([Governance](GOVERNANCE.md#how-the-specification-changes)).
+
+**What acceptance means.** It authorizes building toward the named release, subject to review and, for anything normative, to the public comment periods [Governance](GOVERNANCE.md#steward-proposals-and-conflicts-of-interest) sets. It is not a merge, and it is not a guarantee that the change ships. Code follows an accepted request: a feature pull request that arrives without one is triaged as a request first, and its code waits on the answer.
+
+**Why this way.** A request costs you minutes and a declined pull request costs you days. The answer is measured against [ROADMAP.md](ROADMAP.md), so you can read what a request is weighed against before you write anything.
+
+**The steward uses the same door.** The steward's own features start as public feature requests too, and where one touches an area a steward product depends on it is labeled and slowed down, per [Governance](GOVERNANCE.md#steward-proposals-and-conflicts-of-interest).
 
 ## Development setup
 
@@ -22,7 +40,7 @@ Prerequisites: Node 24+, a Python >=3.10 (the Python SDK pins 3.12 via `packages
 - `npm run cli:mode` says which is active (version strings can't); `npm run cli:assert -- live|packed`
   fails loudly on a mismatch. Full discipline: `docs/practice/testing-cli-adoptions.md`.
 
-- **Spec proposals.** Open an issue first: the problem, the intent, and the lived case behind it. Leji specifies proven practice; proposals grounded in something a real team does carry more weight than ideas in the abstract.
+- **Spec proposals.** Open an issue first: the problem, the intent, and the lived case behind it. Leji specifies proven practice; proposals grounded in something a real team does carry more weight than ideas in the abstract. The answer you can expect, and when, is in [Before you build](#before-you-build).
 - **Pull requests.** Normative changes (anything under `spec/` or `schemas/`) ride PR review and require a `CHANGELOG.md` entry plus a machine-readable `CHANGELOG.json` entry. Yes, the spec dogfoods itself.
 - **Contributor terms.** Every commit needs a DCO sign-off (`git commit -s`); contributions ship under the license for their content type. See [Contributor terms](#contributor-terms).
 - **Tooling.** SDK changes need tests and must keep `leji validate` passing against `examples/`. The Node, Python, and Go SDKs (`packages/sdk`, `packages/sdk-py`, `packages/sdk-go`) are behaviorally identical: a behavior change in one rides into all three, pinned by the shared `fixtures/` suite. Behavior develops and proves out fully in the TypeScript SDK first, the canonical implementation, against the LIVE channel ([testing-cli-adoptions](docs/practice/testing-cli-adoptions.md)); the Go and Python ports are made only from settled TypeScript behavior, pinned by the shared fixtures at port time. The Go SDK builds with Go 1.26.6+; `gofmt`, `go vet ./...`, and `go test ./...` must pass.

GOVERNANCE.md

@@ -49,7 +49,7 @@ Full terms, including what a fork may call its binary and what the logo requires
 
 Changes happen by proposal, in the open:
 
-1. Open an issue describing the problem and the intent behind the change, not just a fix.
+1. Open an issue describing the problem and the intent behind the change, not just a fix. Tooling and site features take the same first step: a feature request, answered normally within 14 days, as [CONTRIBUTING.md](CONTRIBUTING.md) describes; the roadmap those answers are measured against is [ROADMAP.md](ROADMAP.md).
 2. Propose the change as a pull request against `spec/`, and the schemas where the machine-readable surface is affected.
 3. Normative changes carry a changelog entry and a version bump under the spec's own [versioning rules](spec/versioning.md).