nibula 2.4.2 → 2.4.4

package/docs/Deploy.md

@@ -1,279 +0,0 @@
-# Deploy
-
-Nibula builds your finished site into a folder called `out`. Publishing means
-copying that folder onto a web server so people can reach it.
-
-How you do that depends on two things: **where** you are publishing, and **which
-backend** you picked when you created the project (see `docs/Backend.md`).
-
-## Start here
-
-If you don't know which case you are in, answer this first:
-
-**Did you choose the PHP backend or the Node backend?**
-
-- **PHP** → almost anywhere works, including cheap hosting plans. Jump to
-  *Shared hosting* or *Windows hosting*.
-- **Node** → you need a server you control. Jump to *Your own server*.
-- **No `/api` endpoints at all?** Your site is fully static. Anything works,
-  including free hosting like Netlify or GitHub Pages.
-
-## Why the backend decides everything
-
-The two backends run in completely different ways, and this is the one thing
-worth understanding before you pick a host.
-
-**PHP** runs **once per visit**. A request arrives, the web server starts PHP,
-PHP answers, PHP exits. Nothing stays running, so there is nothing to look after.
-
-**Node is itself a server**. It is a program that must stay running all the time,
-listening in the background, while the web server forwards `/api` requests to it.
-Somebody has to start that program and restart it if the machine reboots or the
-program crashes.
-
-That is why **cheap shared hosting cannot run the Node backend**. On plans like
-Aruba or cPanel you upload files into a folder and that's all you can do — there
-is no way to start a program and keep it alive. If that's your host, choose PHP.
-It isn't a limitation of Nibula.
-
-> **Shared hosting** means a plan where you share a server with other customers
-> and only get a folder to upload into. **A VPS** is a whole machine that is
-> yours, where you can install and run whatever you want.
-
-## Where you can publish
-
-| Target | Frontend | PHP backend | Node backend |
-|---|---|---|---|
-| Shared hosting (Apache — Aruba, cPanel) | ✅ | ✅ | ❌ no program can stay running |
-| Windows hosting (IIS) | ✅ | ✅ | ⚠️ only with the ARR module |
-| Your own VPS (Nginx on Ubuntu) | ✅ | ✅ | ✅ |
-| Static hosting (Netlify, Vercel, GitHub Pages) | ✅ | ❌ | ❌ |
-
-Static hosting serves files and nothing else. Perfect if your site has no `/api`
-endpoints, unusable if it does.
-
-## What you need
-
-**PHP backend:** a host with PHP support, and Composer to install the backend's
-dependencies.
-
-**Node backend:** Node.js 18 or newer, and command-line access to the server so
-you can start the backend program.
-
-## Editing the server config
-
-Every server needs a configuration file telling it how to behave — which page to
-show on a 404, which files to keep private, where to send `/api` requests. Nibula
-writes these for you.
-
-`.htaccess` (Apache) and `web.config` (IIS) are already inside `out`, ready to
-upload. To change a rule, edit the original in `src/frontend/hosting/` — anything
-you change directly inside `out` is erased the next time you build.
-
-`nginx.conf` is different. It sits in your project root and is **not** copied into
-`out`, because Nginx does not read config files from the site folder. You install
-it on the server yourself, as described below.
-
----
-
-## Shared hosting (Apache)
-
-Upload **the contents of `out`** — not the folder itself — into your web root.
-Depending on the host it is called `htdocs`, `public_html` or `www`.
-
-That's it. `.htaccess` is already in there and Apache reads it automatically:
-folder listings are off, errors show your `/404.html`, sensitive files are
-blocked, the backend source is sealed off, and `/api/*` is routed.
-
-**How `/api` gets routed:** if the server has a module called `mod_proxy`, `/api`
-is forwarded to Node. If it doesn't — the usual case on shared hosting — `/api`
-goes to PHP instead. To force PHP on a server that does have `mod_proxy`, comment
-out the `mod_proxy` block in `.htaccess`.
-
-## Windows hosting (IIS)
-
-Same as above: upload the contents of `out`. `web.config` is already there and
-read automatically.
-
-**How `/api` gets routed:** to PHP, by default. To use Node instead, uncomment
-the `ApiToNode` rule in `web.config` and delete `ApiToPhp`. This only works if
-the server has the ARR and URL Rewrite modules with proxying turned on — which
-means a server you control, not shared hosting.
-
-> ⚠️ **If you chose Node and your host has no ARR** (Aruba and most Windows
-> shared hosting), do **not** upload the `backend` folder. Without it the static
-> site works fine and `/api/*` simply shows your `404.html`. Upload it and every
-> `/api` request returns an empty 404 instead, because IIS sends the request to
-> the PHP front controller — a file a Node project doesn't have.
-
----
-
-## Your own server (Nginx on a VPS)
-
-Nginx doesn't read config files from the site folder: the whole site is described
-in one file kept elsewhere on the machine. Nibula ships that file, ready to use,
-as `nginx.conf` in your project root.
-
-It **handles both backends with no edits**: `/api` goes to Node, and if Node
-isn't running the request falls through to PHP automatically.
-
-Upload the contents of `out` to `/var/www/SITE_FOLDER`, then work through the
-steps below.
-
-### 1. Fill in the placeholders
-
-Open `nginx.conf` on your computer and replace these four words with your own
-values:
-
-| Placeholder | What to put there |
-|---|---|
-| `YOUR_DOMAIN` | your domain — appears twice, once for port 80 and once for 443 |
-| `SITE_FOLDER` | the folder name you used under `/var/www/` |
-| `YOUR_CERTIFICATE` | the folder name under `/etc/letsencrypt/live/` |
-| `SITE_NAME` | the file name you'll use in the commands below — pick anything |
-
-### 2. Install what's missing
-
-Skip anything already installed.
-
-```bash
-sudo apt update
-sudo apt install -y nginx certbot python3-certbot-nginx
-```
-
-With the PHP backend, also:
-
-```bash
-sudo apt install -y php-fpm
-```
-
-### 3. Get an HTTPS certificate
-
-This is what makes your site load over `https://` instead of `http://`.
-Certificates are free and last 90 days; the second command renews them
-automatically.
-
-```bash
-sudo certbot certonly --nginx --cert-name SITE_NAME -d YOUR_DOMAIN
-sudo systemctl enable --now certbot.timer
-```
-
-### 4. Install the site file
-
-```bash
-# Go to the folder where Nginx keeps site files
-cd /etc/nginx/sites-available
-
-# Create the file and paste in the contents of your edited nginx.conf
-sudo nano SITE_NAME
-# Paste, then: CTRL + O, ENTER, CTRL + X
-
-# Switch the site on by copying it into sites-enabled
-sudo cp SITE_NAME ../sites-enabled/
-
-# Check the config for mistakes, then apply it
-sudo nginx -t && sudo systemctl reload nginx
-```
-
-If `nginx -t` reports an error, fix it before reloading — Nginx keeps running on
-the old config until the reload succeeds, so your site stays up.
-
-### If something goes wrong
-
-| What you see | What it usually means |
-|---|---|
-| `cannot load certificate ... Permission denied` | you ran `nginx -t` without `sudo` |
-| `cannot load certificate ... No such file` | wrong certificate name |
-| `no alternative certificate subject name` | the certificate doesn't cover this domain |
-| `unknown directive "http2"` | Nginx older than 1.25 — check with `nginx -v` |
-| NXDOMAIN or a timeout during certbot | your domain's DNS isn't pointing at this server yet |
-| A blank 500 instead of your 404 page | `404.html` is missing from the upload |
-| 502 on `/api`, Node backend | the Node program isn't running |
-| 502 on `/api`, PHP backend | wrong php-fpm socket path in the config |
-
----
-
-## Starting the Node backend on the server
-
-Only for the Node backend. After uploading `out`:
-
-**1. Install its dependencies**
-
-```bash
-cd /var/www/SITE_FOLDER/backend
-npm install
-```
-
-**2. Create its config file**
-
-Make sure `config.js` exists in `out/backend/`. If it doesn't, copy
-`example.config.js` to `config.js` and fill in your values.
-
-**3. Try it out first**
-
-`screen` lets you start a program, walk away, and come back to it later. Use it
-to check the backend actually works before setting it up properly.
-
-```bash
-screen -S node-backend
-# Inside the new screen:
-sudo node /var/www/SITE_FOLDER/backend/_core/index.js
-curl http://127.0.0.1:3000/api/example-public
-```
-
-If `curl` prints a JSON response, the backend is alive. Press `CTRL + A` then `D`
-to leave the screen without stopping the program; `screen -r node-backend` brings
-you back.
-
-**4. Then set it up for real**
-
-`screen` is for testing — the program dies if the server reboots. For a live site
-use **systemd**, the part of Linux that manages background programs. It starts
-your backend at boot and restarts it if it crashes.
-
-Create `/etc/systemd/system/backend-node.service`:
-
-```ini
-[Unit]
-Description=Nibula Node backend
-After=network.target
-
-[Service]
-Type=simple
-User=www-data
-WorkingDirectory=/var/www/SITE_FOLDER/backend
-ExecStart=/usr/bin/node /var/www/SITE_FOLDER/backend/_core/index.js
-Restart=always
-RestartSec=5
-
-[Install]
-WantedBy=multi-user.target
-```
-
-Adjust `WorkingDirectory`, and check the path to `node` with `which node`. Then:
-
-```bash
-sudo systemctl daemon-reload
-sudo systemctl enable --now backend-node
-sudo systemctl status backend-node
-```
-
-The last command should say `active (running)`.
-
-(If you already use `pm2`, that works too:
-`pm2 start _core/index.js --name backend-node`.)
-
-### Settings the Node backend reads at startup
-
-These are set in the systemd file, on their own lines, as
-`Environment=KEY=value`. All three have sensible defaults — you usually don't
-need to touch them.
-
-| Setting | Default | What it does |
-|---|---|---|
-| `PORT` | `3000` | the port Node listens on — must match the one in `nginx.conf` |
-| `HOST` | `127.0.0.1` | keep this as-is: it means "local only", so Node is reachable through the web server and not directly from the internet |
-| `DOCUMENT_ROOT` | detected automatically | where `404.html` lives — the folder above `backend/` |
-
-> Error detail is **not** set here. That's the `APP_ENV` key inside `config.js` /
-> `config.php` — see `docs/Backend.md`.

package/docs/Head and SEO.md

@@ -1,198 +0,0 @@
-# Head & SEO
-
-The `<head>` of an HTML page holds the information *about* the page rather than
-its content: the title shown in the browser tab, the description search engines
-display, the image that appears when someone shares the link. Nibula writes all
-of it for you — you just fill in the values.
-
-There are two files to fill in:
-
-- **`src/frontend/data/site.json`** — settings for the whole site
-- **`src/frontend/data/pages.json`** — settings for one page at a time
-
-A page uses its own value when it has one, and falls back to the site-wide value
-when it doesn't. So filling in `site.json` well means most pages need nothing.
-
-## Site-wide settings
-
-Everything in `site.json` is available anywhere in your templates as
-`{{ site.something }}`.
-
-```json
-{
-  "site_name": "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",
-  "theme": "dark",
-  "theme_color": "#2a2150",
-  "logo": "/assets/brand/logo.svg",
-  "legal": {
-    "privacy": "",
-    "cookie": "",
-    "terms": "",
-    "copyright": {
-      "year": "2026",
-      "text": "Copyright text"
-    }
-  }
-}
-```
-
-| Field | What it's for |
-|---|---|
-| `site_name` | Your brand or project name |
-| `title` | Default page title — used by any page that doesn't set its own |
-| `description` | Default description — same idea |
-| `keywords` | Default keywords — same idea |
-| `domain` / `url` | Used to build full page addresses for search engines and social previews |
-| `lang` | The language of your site (`en`, `it`, ...) |
-| `author` | Your name |
-| `theme` | Colour scheme of the site: `light` or `dark` |
-| `theme_color` | Colour of the browser bar on phones — should match your theme |
-| `logo` | Path to your logo, also used as the image in social previews |
-| `legal.privacy` / `cookie` / `terms` | Addresses of your legal pages — the footer links to them |
-| `legal.copyright.year` / `text` | The copyright line in the footer |
-
-## Per-page settings
-
-`pages.json` holds one entry per page, and the assistant creates it for you when
-you add a page. Each entry is keyed by the page's `title` from its front matter —
-the camelCase one.
-
-```json
-{
-  "examplePage": {
-    "seo": {
-      "title": "Example Page",
-      "description": "Description",
-      "keywords": "",
-      "noindex": false,
-      "canonical": ""
-    },
-    "cdn": {
-      "css": ["https://example.com/lib.min.css"],
-      "js": ["https://example.com/lib.min.js"]
-    }
-  }
-}
-```
-
-| Field | What it's for | If you leave it empty |
-|---|---|---|
-| `seo.title` | The page's title, shown in the browser tab and in search results | Uses the site-wide `title` |
-| `seo.description` | The short summary search engines show under the title | Uses the site-wide `description` |
-| `seo.keywords` | Keywords for this page | Uses the site-wide `keywords` |
-| `seo.noindex` | Set to `true` to ask search engines **not** to list this page | The page can be found normally |
-| `seo.canonical` | The one official address of this page, if the same content is reachable at more than one URL | Worked out automatically |
-| `cdn.css` / `cdn.js` | Extra stylesheets or scripts loaded from the internet, on this page only | Nothing extra is loaded |
-
-> ⚠️ The assistant fills new entries with placeholder text like `"Description"`.
-> Replace it — a page left that way tells search engines and AI crawlers that its
-> description is literally "Description".
-
-### How the fallback works
-
-Site-wide values are defaults, not duplicates. You don't need to repeat them per
-page. This is what the template actually does:
-
-```njk
-{{ pageData.seo.title or title or site.title }}
-{{ pageData.seo.description or site.description }}
-{{ pageData.seo.keywords or site.keywords }}
-```
-
-Read it as: use the page's value; if there isn't one, use the site's.
-
-`noindex` and `canonical` work per-page only — there's no site-wide version,
-because "hide the whole site from search" and "one address for the whole site"
-aren't things you'd want.
-
-## Theme
-
-One value in `site.json` controls the colour scheme everywhere:
-
-```html
-<html data-theme="{{ site.theme }}" data-bs-theme="{{ site.theme }}">
-<meta name="color-scheme" content="{{ site.theme }}">
-<meta name="theme-color" content="{{ site.theme_color }}">
-```
-
-| What it sets | Why it's there |
-|---|---|
-| `data-theme` | Your own hook — target it in your SCSS to define theme colours |
-| `data-bs-theme` | Bootstrap's dark mode switch. Harmlessly ignored with other frameworks |
-| `color-scheme` | Standard CSS — makes scrollbars, form fields and autofill match your theme |
-| `theme-color` | The colour of the browser bar on phones |
-
-Keep `theme` and `theme_color` in agreement: a dark theme with a white
-`theme_color` gives a white browser bar sitting on top of a dark page.
-
-See the **Styling with SCSS** DOC file for how to hook your own colours to
-`data-theme`.
-
-## Favicon
-
-The favicon is the small icon in the browser tab. The three tags are written
-directly in `base.njk`. To change the icons, replace the files in
-`src/frontend/assets/brand/` **keeping the same names**:
-
-```html
-<link rel="icon" type="image/svg+xml" href="{{ '/assets/brand/favicon.svg' | url }}">
-<link rel="icon" type="image/png" sizes="32x32" href="{{ '/assets/brand/favicon-32.png' | url }}">
-<link rel="apple-touch-icon" sizes="180x180" href="{{ '/assets/brand/apple-touch-icon.png' | url }}">
-```
-
-| File | What uses it |
-|---|---|
-| `favicon.svg` | Modern browsers — scales to any size |
-| `favicon-32.png` | Older browsers and some crawlers |
-| `apple-touch-icon.png` | The icon iOS uses when someone saves your site to their home screen. Must be 180×180 and **not** transparent — iOS turns transparency into black |
-
-> ⚠️ Without `apple-touch-icon.png`, iOS uses a screenshot of your page as the
-> home screen icon instead.
-
-## Where all this is written
-
-Everything above is produced by `src/frontend/layouts/base.njk`, which looks up
-the current page's entry like this:
-
-```njk
-{% set pageKey = title %}
-{% set pageData = pages[pageKey] %}
-```
-
-You only need to edit `base.njk` for something the boilerplate doesn't cover — a
-web font, an analytics snippet. For everything documented here, change the values
-in `site.json` and `pages.json` instead.
-
-> ⚠️ Paths in `base.njk` go through `| url`. That filter makes them work when the
-> site is published in a subfolder rather than at the root of a domain — GitHub
-> Pages being the common case. Remove it and every stylesheet and script breaks
-> there.
-
-## Files for search engines and AI
-
-Three files are generated automatically and published with your site:
-
-| File | What it's for | Reachable at |
-|---|---|---|
-| `llms.txt` | Describes your site and lists its pages, for AI models | `yoursite.com/llms.txt` |
-| `robots.txt` | Tells search engines what they may and may not crawl | `yoursite.com/robots.txt` |
-| `sitemap.xml` | Lists your pages so search engines find them all | `yoursite.com/sitemap.xml` |
-
-They are built from templates in `src/frontend/indexing/`. `llms.txt` and
-`sitemap.xml` build their page lists the same way: they go through every page and
-leave out drafts, the 404 page, and anything marked `noindex`. Creating a page
-with the assistant is enough for it to appear in both — there is no list to keep
-up to date by hand.
-
-To change the wording or the fixed parts, edit
-`src/frontend/indexing/llms.njk` or `src/frontend/indexing/robots.njk`.
-
-> These three files must stay publicly reachable. If you block them in your server
-> config, search engines and AI models can't read them.

package/docs/JavaScript.md

@@ -1,127 +0,0 @@
-# JavaScript
-
-> 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/`.
-
-## Page JS
-
-Each page has its own JS entry point in `src/frontend/js/pages/`, bundled and minified by esbuild and loaded automatically by `base.njk`.
-
-Import only what the page needs.
-
-### examplePage.js <small>(`src/frontend/js/pages/`)</small>
-
-```js
-import '../global.js';
-
-// import { initExampleModule } from '../modules/exampleModule.js';
-
-document.addEventListener("DOMContentLoaded", () => {
-    // initExampleModule();
-});
-
-// Page logic here
-```
-
-## Global JS
-
-Some code has to run on every page: a header menu, a theme toggle, a cookie banner. Repeating it in every page entry point means you'll eventually forget it on one of them, and the bug only shows up on that single page.
-
-That's what `global.js` is for. It lives in `src/frontend/js/`, every page entry point imports it, and it takes care of running the shared modules.
-
-### global.js <small>(`src/frontend/js/`)</small>
-
-```js
-// import { initExampleModule } from './modules/exampleModule.js';
-
-function initGlobal() {
-    // initExampleModule();
-}
-
-// Global logic here
-
-// Do not touch
-// This instruction starts global.js itself
-document.addEventListener('DOMContentLoaded', initGlobal);
-```
-
-Pages import it without curly braces, since there is nothing to export — the module runs on its own as soon as it's part of the bundle:
-
-```js
-import '../global.js';
-```
-
-Note the difference in import paths. A page entry point sits inside `js/pages/`, so it reaches a module with `'../modules/exampleModule.js'`. `global.js` sits directly in `js/`, one level up, so the same module is `'./modules/exampleModule.js'`.
-
-### A concrete example: the header menu
-
-A responsive header has a burger button that opens the navigation on small screens. The header is included in `base.njk`, so it's on every page — a textbook case for `global.js`.
-
-Write the behaviour as a normal module:
-
-### header.js <small>(`src/frontend/js/modules/`)</small>
-```js
-export function initHeader() {
-    const toggle = document.querySelector('.menu-toggle');
-    const menu = document.querySelector('.menu');
-
-    if (!toggle || !menu) return;
-
-    toggle.addEventListener('click', () => {
-        menu.classList.toggle('is-open');
-    });
-}
-```
-
-Then wire it up once, in `global.js`:
-
-```js
-import { initHeader } from './modules/header.js';
-
-function initGlobal() {
-    initHeader();
-}
-
-// Do not touch
-// This instruction starts global.js itself
-document.addEventListener('DOMContentLoaded', initGlobal);
-```
-
-The burger now works on every page, and no page entry point had to change. Adding another global behaviour later is two lines: one import, one call inside `initGlobal()`.
-
-The early `return` matters: if a page has no header, the module does nothing instead of throwing an error that would stop your other scripts.
-
-### Global or page module?
-
-Use `global.js` for behaviour tied to something present on every page — anything included in `base.njk`, essentially.
-
-Keep it in the page entry point when only one or two pages need it. Everything imported by `global.js` ends up in *every* page bundle, so a heavy module used by a single page belongs in that page instead.
-
-## Modules
-
-Modules live in `src/frontend/js/modules/`. Modules that interact with the DOM must be called inside `DOMContentLoaded`; others can be called anywhere.
-
-## Adding a module
-
-Create a new `.js` file in `src/frontend/js/modules/`. Subfolders are allowed.
-
-Use ESM syntax — esbuild handles the bundling:
-
-### exampleModule.js <small>(`src/frontend/js/modules/`)</small>
-
-```js
-export function exampleModule() {
-    // Module logic here
-}
-```
-
-Then import it in the pages that need it:
-
-```js
-import { exampleModule } from '../modules/exampleModule.js';
-```
-
-In TypeScript, omit the extension:
-
-```ts
-import { exampleModule } from '../modules/exampleModule';
-```

package/docs/Project structure.md

@@ -1,66 +0,0 @@
-# Project Structure
-
-> 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/`.
-
-Nibula ships a fixed layout so you always know where to put your hands. Inside these folders you're free to organize as you like — subfolders in `components/`, `modules/` and `api/` are all fair game.
-
-## The tree
-
-```
-your-project/
-├── .eleventy.js          # Eleventy configuration
-├── nginx.conf            # nginx site file
-├── package.json
-├── out/                  # Build output — never edit, never commit
-└── src/
-    ├── backend/          # REST API — see docs/Backend.md
-    └── frontend/
-        ├── assets/       # Images, fonts, brand files
-        │   └── brand/    # Favicons, logo etc
-        ├── components/   # Reusable .njk fragments and .md content
-        │   └── global/   # Header and footer, included in every page
-        ├── data/         # site.json and pages.json
-        ├── hosting/      # .htaccess and web.config
-        ├── indexing/     # llms, robots and sitemap templates
-        ├── js/           # global.js, modules/, pages/
-        ├── layouts/      # base.njk — the HTML skeleton every page extends
-        ├── routes/       # One file per page
-        └── scss/         # _root.scss, _global.scss, modules/, pages/
-```
-
-## Where things happen
-
-| I want to... | Go to |
-|---|---|
-| Add a page | `nib cli` → creates the files in `routes/`, `scss/pages/`, `js/pages/` |
-| Write the content of a page | `routes/` |
-| Build a reusable block of markup | `components/` |
-| Write long prose in Markdown | `components/` — see docs/Components.md |
-| Change the header or footer | `components/global/` |
-| Style one page | `scss/pages/` |
-| Style every page | `scss/_global.scss` |
-| Define a variable used across the site | `scss/_root.scss` |
-| Run a script on one page | `js/pages/` |
-| Run a script everywhere | `js/global.js` |
-| Change the site name, URL, author | `data/site.json` |
-| Change a page's SEO | `data/pages.json` |
-| Edit the HTML `<head>` | `layouts/base.njk` |
-| Give one page a different skeleton | `layouts/` — add your own, see docs/Components.md |
-| Add an API endpoint | `backend/api/` |
-
-## Two folders worth a note
-
-**`out/`** is generated by every build. Editing anything in it means losing the change the next time you run `nib run` or `nib build`. Always edit the source in `src/` — including `.htaccess` and `web.config`, whose sources live in `src/frontend/hosting/`.
-
-**`data/`** feeds the build but is never published: it holds the full page map, including pages you marked `noindex`, so it stays out of the output on purpose.
-
-## What you can rearrange
-
-Subfolders are allowed wherever content is yours to organize:
-
-- `components/` — nest as deep as you like; includes take the path relative to `components/`, and so does the `markdownPath` filter
-- `scss/modules/` and `js/modules/` — same idea, remember to update the relative import paths
-- `layouts/` — extra layouts alongside `base.njk`; routes pick one by filename
-- `backend/api/public/` and `protected/` — subfolders become part of the URL
-
-The folders in the tree above are the part to leave alone: paths are wired into `.eleventy.js`, the build scripts and the assistant, so renaming one breaks the build.