nibula 2.4.3 → 2.4.4

package/CHANGELOG.md

@@ -5,6 +5,30 @@ All notable changes to Nibula are documented here.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [2.4.4] - 2026-08-26
+
+### Changed
+- **`site_name` is now `siteName` and `author` is an object** with `fullName` and
+  `website`. The author's site feeds the JSON-LD `Person.url` and the `llms.txt`
+  header, which previously reused the site URL for both.
+- The documentation moved out of the repository and onto
+  [rhaastrake.github.io/Nibula](https://rhaastrake.github.io/Nibula/docs/). The
+  `docs/` folder now holds the built site and is excluded from the published
+  package, so `npm install` no longer carries the Markdown files.
+- The README follows the same structure as the documentation's introduction, and
+  points at the site instead of the files that used to live in `docs/`.
+
+### Fixed
+- The documentation card in `welcome.njk` linked to `Nibula/tree/main/docs`,
+  which now holds the built site rather than readable Markdown.
+- `welcome.njk` shipped with a leftover `{{ test.prova }}` referencing a data
+  file no scaffolded project has.
+
+### Notes
+- **Existing projects need two edits to `src/frontend/data/site.json`** if you
+  update their templates: rename `site_name` to `siteName`, and turn `author`
+  into `{ "fullName": "...", "website": "..." }`. Leaving the file as it is keeps
+  the old templates working — the two only have to move together.
 
 ## [2.4.3] 2026-08-24
 

package/README.md

@@ -4,52 +4,75 @@
 [![License](https://img.shields.io/npm/l/nibula?color=blue)](LICENSE)
 ![Eleventy](https://img.shields.io/badge/built%20on-11ty-black?logo=eleventy)
 
-**Nibula** is an open source static site generator built on top of [Eleventy](https://www.11ty.dev/), with one clear mission: make the jump from small hand-written practice sites to a real project setup as gentle as possible.
+**Nibula** is an open source static site generator built on top of
+[Eleventy (11ty)](https://www.11ty.dev/), with one clear mission: make the jump
+from small hand-written practice sites to a real project setup as gentle as
+possible.
 
-If you've only ever written HTML, CSS, and a bit of JavaScript, moving to a "framework" usually feels like starting over: new syntax, new rules, new folder structures, and a pile of documentation before you can even see a page on screen. Nibula is designed to avoid exactly that. You keep working with the **three languages that matter — HTML, CSS, and JavaScript** — and the tool quietly handles the tedious parts around them. The goal is simple: even someone with little experience should always know *where to put their hands*.
+📖 **[Read the documentation](https://rhaastrake.github.io/nibula/docs/)**
 
-### ✨ Why choose Nibula?
+## 🎯 Why choose Nibula
 
-It's a great fit for **showcase and brochure-style websites** (portfolios, landing pages, small business sites), when you want something clean and fast without dragging in a framework that takes weeks to learn and handle.
+### Beginner friendly
 
-Building a website from scratch means putting together a lot of moving parts: SEO, dependency setup, deployment and server configuration, project structure. Nibula takes care of all of that for you, so you can focus on your content — while still picking up conventions and working habits that are common to the most widely used frameworks, Angular among them.
+If you've only ever written HTML, CSS and a bit of JavaScript, moving to a
+framework usually feels like starting over. A new syntax, new rules, new folder
+structures, and a pile of documentation to get through before you can even see a
+page on screen.
 
-### 📌 Other things worth knowing
+Nibula is designed to avoid exactly that. You stay close to the three languages
+you already know, and the folder structure stays small enough to hold in your
+head — a handful of folders whose names say what's inside, instead of a
+convention you have to study before it makes sense.
 
-- 🔎 **SEO made simple** — managed from one central place; `sitemap`, `llms.txt`, and `robots.txt` are generated automatically
-- 🖱️ **A helpful CLI** — create a page with one command instead of hand-writing ten separate files
-- ⚙️ **Server configs handled for you** — `.htaccess` and `web.config` are generated automatically, and an `nginx.conf` is provided so that anyone comfortable with nginx already has what they need to run the site outside of shared hosting
-- 🎨 **Pick your CSS framework** — choose from 4 pre-installed options (or none), and switch later in a few guided steps
-- 🔌 **Pick your backend** — Node.js or PHP, chosen at creation (choose carefully, based on where you plan to publish)
-- 🧩 **Your own modules** — add your own SCSS and JS/TS modules freely and easily
-- 🪶 **Lightweight by default** — SCSS frameworks can be filtered so you ship only what you actually use
+Everything else is optional. Nunjucks adds loops and includes to your HTML,
+Markdown files can carry the same logic, data files can feed a whole page — but
+none of it is needed on day one.
 
-### 🤔 When not to choose it?
+### Ready to publish
 
-- **Heavily stateful interfaces** — dashboards, admin panels, editors, anything that keeps changing under the user's hands. A single-page application with React, Vue, or Angular is the right tool there.
-- **Pages generated at request time** — catalogues that depend on the logged-in user, personalised pricing, content that changes by the minute. Nibula builds pages beforehand, not during the visit.
+The hard part of a first site usually isn't building it — it's everything that
+comes after. Meta tags, a sitemap, a `robots.txt`, the server config your host
+expects: four things nobody taught you, all at once, right when you thought you
+were done.
 
-## ⚙️ Backend included
+Nibula writes them while you work. Fill in two data files and the SEO tags, the
+sitemap and `llms.txt` build themselves from your pages. `.htaccess` and
+`web.config` are already in the output folder, ready to upload, and an
+`nginx.conf` is waiting if you have your own server.
 
-Essential server-side functionality comes built in — no extra setup required. At project creation you **choose your backend: Node.js or PHP**. Both expose the **same REST API** — same routing, `X-Api-Key` auth, CORS and rate limiting — so you can even switch later without rewriting your endpoints. See [docs/Backend.md](docs/Backend.md) for details.
+### Nothing is hidden
 
-## 🧭 Customizable, but with sensible defaults
+Every one of those files lives in the project, in the folder you'd expect, in the
+form you'd have written by hand. When you need to change something, you open it
+and change it — there's no configuration layer to learn first, and no generated
+code you're not supposed to touch.
 
-Nibula ships with a clean, opinionated layout so beginners are never lost. But it isn't a cage: as long as you follow a few small conventions and the defined paths, you're free to customize the subpaths of your **components, backend endpoints, and JS/SCSS modules** however you like.
+### Backend included
 
-## 📋 Prerequisites
+At project creation you choose your backend: **Node.js or PHP**. Both expose the
+same REST API — same routing, `X-Api-Key` auth, CORS and rate limiting — so a
+contact form or a small API works on whatever hosting you end up with.
+
+## 🤔 When not to use it
 
-### Required
+**Nibula builds static pages.** If your site needs users to log in, save
+something, or see different content depending on who they are, you want a
+framework with a server behind it — Next.js, Nuxt, Laravel.
 
-* **Node.js**: v18.0.0 or higher
-* **Composer** *(only if you choose the PHP backend)*: latest version
-* **Better Nunjucks** — VS Code extension by **Ed Heltzel**
+**It doesn't scale to hundreds of pages** coming from a database or a CMS. The
+assistant creates pages one at a time, which is right for a site with ten or
+twenty of them and wrong for a catalogue.
 
-### Recommended
+**If you already work with React, Vue or Angular, stay there.** Nibula's whole
+point is being a first step for people who don't.
+
+## 📋 Prerequisites
 
-* **Material Icon Theme** — VS Code extension by **Philipp Kief**
+- **Node.js** — v18.0.0 or higher
+- **Composer** — latest version, only if you pick the PHP backend
 
-## 📦 Installation
+## 🚀 Getting started
 
 Install Nibula once, globally:
 
@@ -57,54 +80,60 @@ Install Nibula once, globally:
 npm install -g nibula
 ```
 
-This gives you the `nib` command (alternatives: `nbl`, `nibula`).
+This gives you the `nib` command, with `nbl` and `nibula` as aliases.
 
-## 🚀 Create a project
-
-From the folder where you keep your websites, run:
+From the folder where you keep your websites:
 
 ```
 nib new your-project
 ```
 
-The scaffolder is interactive: you choose the **language** (JavaScript/TypeScript), the **CSS framework**, and the **backend** (Node.js or PHP). All dependencies are installed automatically — and if you pick **Node**, the PHP/Composer step is skipped, so you don't need Composer at all.
-
-Once the dependencies are installed, move into the project folder and start the dev server (`localhost:8080`):
+The scaffolder asks you three things — the language, the CSS framework and the
+backend — then installs everything for you. Move into the project and start the
+dev server:
 
 ```
 cd your-project
 nib run
 ```
 
-## 📄 Managing pages
-
-Instead of creating and wiring up multiple files by hand, let the interactive assistant do it for you. To create, remove, or rename pages and configure the output path, run:
-
-```bash
-nib cli
-```
-
-See [docs/Assistant CLI.md](docs/Assistant%20CLI.md) for details.
+Your site is now at `localhost:8080`, and it rebuilds every time you save.
 
 ## 💻 Commands
 
-Run these from anywhere inside a project — except `nib new`, which must be run **outside** a project, in the folder where you want the new one created.
+Run these from anywhere inside a project — except `nib new`, which must be run
+**outside** a project, in the folder where you want the new one created.
 
 | Command | Description |
 |---|---|
-| `nib new <name>` | Create your new project |
-| `nib run` | Start the dev server and build the output folder at runtime |
+| `nib new <name>` | Create a new project |
+| `nib run` | Start the dev server and rebuild as you save |
 | `nib cli` | Open the page-management assistant |
 | `nib build` | Build the output folder |
 | `nib clean` | Remove the output directory |
-| `nib update` | Update Nibula to the latest version (applies from your next project on) |
+| `nib update` | Update Nibula (applies from your next project on) |
+
+Creating a page by hand means writing three files and a data record that all have
+to agree on the name. `nib cli` does it for you, and handles renaming and
+removing too.
+
+## 📖 Documentation
+
+Everything else — the page structure, components, styling, the backend, SEO and
+deployment — is at
+**[rhaastrake.github.io/Nibula](https://rhaastrake.github.io/nibula/docs/)**.
 
-## 🙌 Wrapping up
+## ⭐ Support Nibula
 
-Thanks for giving Nibula a try.
+Thanks for giving **Nibula** a try.
 
-It's a one-person project, so every bit of feedback counts more than you'd think: if something breaks, if the documentation isn't clear, or if a feature is missing, open an [issue](https://github.com/Rhaastrake/Nibula/issues) — even just to tell me what you built with it.
+It's a one-person project, so every bit of feedback counts more than you'd think:
+if something breaks, if the documentation isn't clear, or if a feature is
+missing, open an [issue](https://github.com/Rhaastrake/nibula/issues).
 
-If Nibula was useful to you, leaving a ⭐ on the repository is the easiest way to help other people find it.
+If **Nibula** was useful to you, leaving a ⭐ on the
+[repository](https://github.com/Rhaastrake/nibula) is the easiest way to help
+other people find it.
 
-You can support the project by [buying me a coffee](https://paypal.me/rhaastrake) ☕🫡
+You can also support the project by buying me a coffee on
+[PayPal](https://paypal.me/rhaastrake) ☕🫡

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nibula",
-  "version": "2.4.3",
+  "version": "2.4.4",
   "description": "A beginner-friendly static site generator built on Eleventy that stays close to vanilla HTML, CSS and JS — with a page-management CLI, an optional PHP backend, and SEO files generated for you.",
   "keywords": [
     "11ty",
@@ -54,19 +54,19 @@
     "assistant": "node tools/assistant.js"
   },
   "devDependencies": {
-    "@11ty/eleventy": "^3.1.2",
-    "@11ty/eleventy-img": "^6.0.4",
+    "@11ty/eleventy": "^3.1.6",
+    "@11ty/eleventy-img": "^7.0.0",
     "@11ty/eleventy-plugin-syntaxhighlight": "^5.0.2",
     "bootstrap": "^5.3.8",
     "bootstrap-icons": "^1.13.1",
     "bulma": "^1.0.4",
-    "concurrently": "^9.2.1",
-    "esbuild": "^0.27.3",
+    "concurrently": "^9.2.4",
+    "esbuild": "^0.28.2",
     "foundation-sites": "^6.9.0",
     "glob": "^13.0.6",
     "markdown-it-anchor": "^9.2.1",
     "markdown-it-attrs": "^5.0.1",
-    "sass": "^1.77.0",
-    "uikit": "^3.25.13"
+    "sass": "^1.103.1",
+    "uikit": "^3.25.21"
   }
 }

package/src/frontend/components/global/footer.njk

@@ -16,7 +16,7 @@
 
   <div class="copyright">
     <p>
-      &copy; {{ site.legal.copyright.year }} {{ site.site_name }} - {{ site.legal.copyright.text }}
+      &copy; {{ site.legal.copyright.year }} {{ site.siteName }} - {{ site.legal.copyright.text }}
     </p>
   </div>
 </footer>

package/src/frontend/components/global/header.njk

@@ -1,7 +1,7 @@
 <header>
   <nav>
       <a class="logo" href="/">
-        <img src="{{ site.logo }}"> {{ site.site_name }}
+        <img src="{{ site.logo }}"> {{ site.siteName }}
       </a>
   </nav>
 </header>

package/src/frontend/components/welcome.njk

@@ -16,7 +16,7 @@
             </svg>
           </span>
         </a>
-        <a href="https://github.com/rhaastrake/nibula/tree/main/docs" class="card" target="_blank" rel="noopener noreferrer" style="flex: 1; min-width: 250px;">
+        <a href="https://rhaastrake.github.io/nibula/docs/" class="card" target="_blank" rel="noopener noreferrer" style="flex: 1; min-width: 250px;">
           <svg class="card-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true">
             <path d="M2 3h6a4 4 0 0 1 4 4v14a3 3 0 0 0-3-3H2z"></path>
             <path d="M22 3h-6a4 4 0 0 0-4 4v14a3 3 0 0 1 3-3h7z"></path>
@@ -31,7 +31,6 @@
         </a>
       </div>
     </div>
-    <div class="prova">{{ test.prova }}</div>
 <style>
   .layout-container {
     width: 100%;

package/src/frontend/data/site.json

@@ -1,12 +1,15 @@
 {
-  "site_name": "Site name",
+  "siteName": "Site name",
   "title": "Site title",
   "description": "Site description",
   "keywords": "keyword1, keyword2, keyword3",
   "domain": "yoursite.com",
   "url": "https://yoursite.com",
   "lang": "en",
-  "author": "Name and surname",
+  "author": {
+      "fullName": "Name and surname",
+      "website": "https://example.com"
+  },
   "theme": "dark",
   "logo": "/assets/brand/logo.svg",
   "legal": {

package/src/frontend/indexing/llms.njk

@@ -2,11 +2,11 @@
 permalink: /llms.txt
 eleventyExcludeFromCollections: true
 ---
-# {{ site.site_name }}
+# {{ site.siteName }}
 
 > {{ site.description }}
 
-Built by {{ site.author }} — {{ site.url }}
+Built by {{ site.author.fullName }} — {{ site.author.website }}
 
 ## Pages
 

package/src/frontend/layouts/base.njk

@@ -23,7 +23,7 @@
         <title>{{ pageData.seo.title or title or site.title }}</title>
         <meta name="description" content="{{ pageData.seo.description or site.description }}">
         <meta name="keywords" content="{{ pageData.seo.keywords or site.keywords }}">
-        <meta name="author" content="{{ site.author }}">
+        <meta name="author" content="{{ site.author.fullName }}">
         <meta name="theme-color" content="{{ site.theme }}">
 
         {% if pageData.seo.noindex %}
@@ -36,7 +36,7 @@
         <meta property="og:type" content="website">
         <meta property="og:url" content="{{ site.url }}{{ page.url }}">
         <meta property="og:image" content="{{ site.url }}{{ site.logo }}">
-        <meta property="og:site_name" content="{{ site.site_name }}">
+        <meta property="og:site_name" content="{{ site.siteName }}">
 
         {# Twitter Card #}
         <meta name="twitter:card" content="summary_large_image">
@@ -57,11 +57,12 @@
             "url": {{ (site.url + page.url) | dump }},
             "author": {
                 "@type": "Person",
-                "name": {{ site.author | dump }}
+                "name": {{ site.author.fullName | dump }},
+                "url": {{ site.author.website | dump }}
             },
             "publisher": {
                 "@type": "Organization",
-                "name": {{ site.site_name | dump }},
+                "name": {{ site.siteName | dump }},
                 "logo": {
                     "@type": "ImageObject",
                     "url": {{ (site.url + site.logo) | dump }}

package/docs/Assistant CLI.md

@@ -1,70 +0,0 @@
-# Assistant CLI
-
-> Examples use JavaScript, but everything applies equally to TypeScript. The only difference is the file extension (`.ts` instead of `.js`), that imports do **not** include the extension, and that paths use `src/frontend/ts/` instead of `src/frontend/js/`.
-
-An interactive CLI to manage pages without touching files manually.
-
-Run it from anywhere inside a project:
-
-```
-nib cli
-```
-
-## Menu
-
-```
-1. Create page
-2. Remove page
-3. Rename page
-4. Configure output path
-```
-
-Use `CTRL/CMD + C` (or `CTRL + D`) to exit.
-
-## Create page
-
-Enter a page name in any format — the CLI converts it to kebab-case automatically.
-
-For a page named `my-page`, the following files are created:
-
-| File | Purpose |
-|---|---|
-| `src/frontend/scss/pages/myPage.scss` | SCSS entry point |
-| `src/frontend/js/pages/myPage.js` | JS entry point |
-| `src/frontend/routes/my-page.njk` | Nunjucks template |
-
-It also adds a stub entry in `pages.json`:
-
-```json
-    "myPage": {
-      "seo": {
-        "title": "My page",
-        "description": "Description",
-        "keywords": "",
-        "noindex": false,
-        "canonical": ""
-      },
-      "cdn": {
-        "css": [],
-        "js": []
-      }
-    }
-```
-
-The route is created with an empty body and a commented example — you decide which components go in it. See **Components** DOC file.
-
-## Remove page
-
-Deletes all source files for the page, cleans up the output directory, and removes the record from `pages.json`.
-
-## Rename page
-
-Renames all three source files, updates the `permalink` in the route's front matter, and renames the record in `pages.json`. Nothing inside the record is touched — your SEO title, description and CDN links stay exactly as you wrote them.
-
-The includes you wrote inside the route move with the file, since the route itself is renamed rather than rewritten.
-
-## Configure output path
-
-Updates the output directory across `.eleventy.js` and all relevant `package.json` scripts in one shot. The old output folder is deleted automatically.
-
-> ⚠️ `homepage` and `404` are protected — they cannot be created, removed, or renamed via the CLI.

package/docs/Backend.md

@@ -1,219 +0,0 @@
-# Backend
-
-Nibula ships **two interchangeable backends** — PHP and Node.js. You pick one
-when you scaffold a project with `nib new`, and **only that one is copied into
-your project**: a Node project contains no PHP files and vice versa. Shared,
-backend-agnostic files (SQL migrations, `.htaccess`, `web.config`) are always
-included.
-
-Both provide the same REST API: same routing, same `Response` envelope, same
-`X-Api-Key` auth, same CORS model, same rate limiter. Only the syntax differs.
-
-> **The examples below are in JavaScript (the Node backend).** If you chose PHP,
-> everything works exactly the same way — same routing, same variables, same
-> `Response` helper, same behaviour. Only the syntax differs.
-
-For **where each backend can run** and how to deploy it, see `docs/Deploy.md`.
-
-## Structure
-
-The tree below shows both backends for reference; your project will have only
-one side of each pair.
-
-```
-src/backend/
-├── api/
-│   ├── public/       # Endpoints accessible without an API key
-│   └── protected/    # Endpoints requiring the X-Api-Key header
-├── _core/            # Framework internals (routing, modules) — do not edit
-│   ├── index.php     # PHP front controller           (PHP project)
-│   ├── index.js      # Node front controller + server (Node project)
-│   ├── init.php / init.js
-│   └── modules/      # Response, RateLimiter
-├── database/
-│   ├── Database.php  # PDO singleton                  (PHP project)
-│   ├── Database.js   # mysql2 pool singleton          (Node project)
-│   └── migrations/   # shared
-├── example.config.php / example.config.js   # versioned template
-└── config.php / config.js                   # generated on setup, never commit
-```
-
-> `config.php` / `config.js` are created automatically by `nib new` as a copy of
-> the matching `example.config.*`, and are git-ignored so your secrets stay
-> local. If `config.*` is missing (e.g. after a fresh clone), copy the example.
-
-### Installing Composer packages (PHP)
-
-Backend dependencies live in `src/backend/_core`, next to `composer.json`.
-Install from there, not from the project root:
-
-```bash
-cd src/backend/_core
-composer require vendor/package
-```
-
-`_core/init.php` already requires Composer's autoloader, so an installed package
-is usable in your endpoints straight away — there is no extra `require` to add.
-
-Packages land in `src/backend/_core/vendor/`, which is git-ignored. After a fresh
-clone that folder is missing and the backend won't start at all: run
-`composer install` from `src/backend/_core` to restore it.
-
-## How routing works
-
-The file path inside `api/` maps directly to the URL. The `public` / `protected`
-folder does **not** appear in the URL — it only decides whether the `X-Api-Key`
-check applies:
-
-- `api/public/example-public` → `/api/example-public` (no key)
-- `api/protected/example-protected` → `/api/example-protected` (requires key)
-
-Subfolders **do** appear: `api/public/users/list` → `/api/users/list`.
-
-Extra URL segments become route parameters, resolved from the deepest match
-backwards: `/api/posts/42` looks for `posts/42` first, then falls back to
-`posts` with `42` as a parameter.
-
-Every endpoint receives:
-
-| Field | Description |
-|---|---|
-| `method` | HTTP method (`GET`, `POST`, `PUT`, `PATCH`, `DELETE`) |
-| `requestParams` | Extra URL segments (e.g. `/api/posts/42` → `['42']`) |
-
-The Node handler also gets `query`, `body` (parsed JSON), `rawBody`, `headers`,
-`config`, `req`, `res`.
-
-> ⚠️ If two files share the same path — one in `public/`, one in `protected/` —
-> the public one wins, so the endpoint ends up **without** authentication. Don't
-> duplicate names across the two folders.
-
-## Creating an endpoint
-
-Create a file anywhere inside `api/public/` or `api/protected/`. For protected
-endpoints the API-key check runs automatically before your file does.
-
-```js
-module.exports = ({ method, requestParams, Response }) => {
-    if (method !== 'GET') Response.error('Method not allowed', 405);
-    const id = requestParams[0] ? parseInt(requestParams[0], 10) : null;
-    Response.success({ id });
-};
-```
-
-## The Response helper
-
-Same envelope in both backends.
-
-```js
-Response.success(data, code);            // default 200
-Response.error(message, code, details);  // default 400
-Response.noContent();                    // 204
-```
-
-Shapes:
-
-- success → `{ "status": "success", "data": ... }`
-- error → `{ "status": "error", "message": "...", "code": ... }` (+ optional `details`)
-
-## Configuration
-
-`config.php` / `config.js` work like a `.env` file: they hold secrets and
-environment settings that stay local and out of version control. Same keys in
-both, PHP-array vs JS-object syntax.
-
-```js
-module.exports = {
-    // Default key for protected endpoints that don't have a specific key in CUSTOM_ENDPOINT_KEYS
-    GENERAL_API_KEY: 'DEFAULT_KEY',
-
-    // If you want to restrict access to protected endpoints to specific clients, define custom keys per endpoint.
-    // For subfolder endpoints, use the relative path ('subfolder/endpoint')
-    CUSTOM_ENDPOINT_KEYS: {
-        'subfolder/example-protected': 'custom-key',
-    },
-
-    GENERAL_ALLOWED_ORIGINS: [
-        '*',
-        // 'https://example.com',
-    ],
-
-    CUSTOM_ENDPOINT_ORIGINS: {
-        'subfolder/example-protected': ['https://app.example.com'],
-    },
-
-    // Database configuration
-    DB_HOST: '127.0.0.1',
-    DB_NAME: 'example_db',
-    DB_USER: 'root',
-    DB_PASS: '',
-
-    // Environment: 'production' hides error details; anything else = debug.
-    APP_ENV: 'production',
-};
-```
-
-### API keys
-
-`GENERAL_API_KEY` is the fallback for all protected endpoints.
-`CUSTOM_ENDPOINT_KEYS` assigns a different key to a specific endpoint, keyed by
-its relative path (`'subfolder/endpoint'`).
-
-> ⚠️ The key travels in the `X-Api-Key` header on every request. Use it only for
-> server-to-server calls over HTTPS. Never embed it in frontend code, where it
-> would be publicly visible.
-
-### CORS
-
-Mirrors the API-key model: `GENERAL_ALLOWED_ORIGINS` is the default list,
-`CUSTOM_ENDPOINT_ORIGINS` overrides it per endpoint using the same relative path.
-
-Origins must be exact (scheme + host, no trailing slash). A matching `Origin` is
-reflected in `Access-Control-Allow-Origin` with `Vary: Origin`. An empty list
-sends no CORS header — the most restrictive setting; same-origin requests still
-work. `'*'` as the only element allows any origin (not recommended for protected
-endpoints).
-
-Resolution order: `CUSTOM_ENDPOINT_ORIGINS[path]` if present, otherwise
-`GENERAL_ALLOWED_ORIGINS`.
-
-### Error verbosity
-
-`APP_ENV` decides what an unhandled exception tells the client.
-
-| Value | Response to a 500 |
-|---|---|
-| `'production'` (default) | `{"status":"error","message":"Internal server error","code":500}` |
-| anything else | the real exception message, plus `stack` (Node) or `file` and `line` (PHP) |
-
-On PHP it does one extra thing: `'production'` also turns off `display_errors`
-and `error_reporting`, so a stray warning can't be printed before the JSON and
-corrupt the response body.
-
-Set it to something like `'development'` while building, and back to
-`'production'` before you publish. Missing key means `'production'`.
-
-> This is a config key, **not** an environment variable. Setting `APP_ENV` in a
-> shell or in a systemd unit has no effect — both backends read it from
-> `config.js` / `config.php` only.
-
-## Database
-
-Both backends expose a connection singleton reading the same config —
-`database/Database.js` (a `mysql2` pool) or `database/Database.php` (a PDO
-singleton).
-
-```js
-const pool = Database.getInstance();
-const [rows] = await pool.execute(sql, params);
-```
-
-`mysql2` is installed at scaffold time and loaded lazily, so the backend boots
-fine without a database.
-
-## Pre-built endpoints
-
-| Route | Method | Description |
-|---|---|---|
-| `/api/example-public` | `GET` | Example endpoint requiring no key |
-| `/api/example-protected` | `GET` | Example endpoint requiring `X-Api-Key` |