@madojs/mado 0.11.1 → 0.12.0

package/docs/fr/17-shadow-dom-forms.md

@@ -1,196 +0,0 @@
-# Shadow DOM + formulaires
-
-L'utilisation de `useForm()` avec des composants input personnalisés en Shadow DOM
-nécessite de connaître deux comportements au niveau du navigateur :
-
-1. **Retargeting des événements** — les événements qui remontent du Shadow DOM ont
-   leur `e.target` redirigé vers l'élément host. `useForm().onInput` lit
-   `e.target.name` et `e.target.value`, mais un élément host `<x-input>`
-   ne possède pas nativement ces propriétés.
-
-2. **Association de formulaire** — un `<button type="submit">` à l'intérieur d'un
-   Shadow Root ne fait PAS partie de l'algorithme form-owner pour `<form>` dans
-   le Light DOM. Cliquer dessus ne déclenche pas le submit du formulaire.
-
-Ces deux limitations sont au niveau de la spécification, pas des bugs Mado. Mais
-le framework fournit des patterns qui les rendent indolores.
-
-## Pattern : Propriétés proxy sur les composants input
-
-En encapsulant un `<input>` dans un composant Shadow DOM, exposez `name` et
-`value` comme propriétés DOM sur le host pour que `useForm().onInput` fonctionne
-après le retargeting :
-
-```ts
-import { component, css, html } from "@madojs/mado";
-
-component("x-input", ({ host, attr }) => {
-  const name = attr("name", "");
-  const type = attr("type", "text");
-  const value = attr("value", "");
-
-  // Propriétés proxy pour la compatibilité useForm().
-  // Après le retargeting Shadow DOM de e.target : <input> → <x-input>,
-  // useForm lit e.target.name / e.target.value — ces getters font le pont.
-  Object.defineProperty(host, "name", {
-    get: () => host.getAttribute("name") ?? "",
-    configurable: true,
-  });
-  Object.defineProperty(host, "value", {
-    get: () => host.shadowRoot?.querySelector("input")?.value ?? "",
-    set: (v: string) => {
-      const input = host.shadowRoot?.querySelector("input");
-      if (input) input.value = v;
-    },
-    configurable: true,
-  });
-
-  return () => html`<input name=${name} type=${type} .value=${value} />`;
-});
-```
-
-L'événement `input` du `<input>` interne a `composed: true` par défaut, donc
-il remonte à travers la frontière shadow. Après le retargeting, `e.target` est
-`<x-input>`, mais maintenant il a les getters `.name` et `.value` → `useForm`
-fonctionne.
-
-## Pattern : Submit de formulaire depuis des boutons Shadow DOM
-
-Un `<button type="submit">` dans le Shadow DOM ne peut pas déclencher le submit
-d'un `<form>` dans le Light DOM. Pont via `requestSubmit()` :
-
-```ts
-import { component, css, html } from "@madojs/mado";
-
-component("x-button", ({ host, attr }) => {
-  const disabled = attr("disabled");
-
-  const handleClick = () => {
-    const typeAttr = host.getAttribute("type");
-    if (typeAttr === "button" || typeAttr === "reset") return;
-    const form = host.closest("form");
-    if (form && !host.hasAttribute("disabled")) form.requestSubmit();
-  };
-
-  return () => html`
-    <button ?disabled=${() => disabled() !== ""} @click=${handleClick}>
-      <slot></slot>
-    </button>
-  `;
-});
-```
-
-`host.closest("form")` fonctionne parce que l'élément host lui-même vit dans
-le Light DOM (seuls ses éléments internes sont dans l'ombre). `requestSubmit()`
-déclenche la validation et l'événement `submit` exactement comme si l'utilisateur
-avait cliqué sur un bouton submit natif à l'intérieur du formulaire.
-
-## Pattern : Attributs réactifs avec ctx.attr()
-
-Depuis la v0.7, `ctx.attr(name, defaultValue?)` retourne un `Signal<string>` qui
-se met à jour automatiquement quand l'attribut change sur le host. Plus besoin de
-`MutationObserver` :
-
-```ts
-component("x-badge", ({ attr }) => {
-  const variant = attr("variant", "default"); // Signal<string>
-
-  return () =>
-    html`<span class=${() => `badge badge-${variant()}`}>
-      <slot></slot>
-    </span>`;
-});
-```
-
-Le parent peut utiliser `?disabled=${() => !form.isValid()}` (attribut booléen)
-ou `.variant=${"danger"}` — le composant se re-rend de manière réactive dans
-les deux cas.
-
-## Exemple complet de formulaire
-
-```ts
-import { page, html, useForm, navigate } from "@madojs/mado";
-import "../components/x-input.js";
-import "../components/x-button.js";
-
-export default page({
-  title: "Connexion",
-  view: () => {
-    const form = useForm({
-      email: { required: true, type: "email" },
-      password: { required: true, minLength: 6 },
-    });
-
-    const handleLogin = async (values) => {
-      await api("/auth/login", { method: "POST", json: values });
-      navigate("/admin");
-    };
-
-    return html`
-      <form @submit=${form.onSubmit(handleLogin)}>
-        <x-input
-          name="email"
-          type="email"
-          label="Email"
-          required
-          @input=${form.onInput}
-          @blur=${form.onBlur}
-        ></x-input>
-        ${() =>
-          form.errors().email
-            ? html`<small class="err">${form.errors().email}</small>`
-            : null}
-
-        <x-input
-          name="password"
-          type="password"
-          label="Mot de passe"
-          required
-          @input=${form.onInput}
-          @blur=${form.onBlur}
-        ></x-input>
-
-        <x-button type="submit" ?disabled=${() => !form.isValid()}>
-          Se connecter
-        </x-button>
-      </form>
-    `;
-  },
-});
-```
-
-## Quand utiliser Light DOM à la place
-
-Si votre composant input est juste un wrapper stylisé sans besoin
-d'encapsulation, `shadow: false` évite les deux problèmes (retargeting et
-association de formulaire) :
-
-```ts
-component(
-  "x-field",
-  ({ attr }) => {
-    const label = attr("label", "");
-    return () => html`
-      <label>
-        <span>${label}</span>
-        <slot></slot>
-      </label>
-    `;
-  },
-  { shadow: false },
-);
-```
-
-Avec Light DOM, le `<input>` natif fait partie de l'arbre du document, les
-événements ne sont pas retargetés, et le submit fonctionne nativement.
-Le compromis : les styles ne sont pas encapsulés (vous devez les scoper
-vous-même).
-
-## Résumé
-
-| Problème                       | Solution Shadow DOM                          | Alternative Light DOM           |
-| ------------------------------ | -------------------------------------------- | ------------------------------- |
-| `useForm` + input personnalisé | Proxy `name`/`value` sur le host             | `<input>` natif dans un slot    |
-| Submit de formulaire           | `form.requestSubmit()` dans le click handler | Le bouton natif fonctionne      |
-| Attributs réactifs             | `ctx.attr()` → signal auto                   | `ctx.attr()` fonctionne partout |
-| Encapsulation des styles       | Oui (automatique)                            | `@scope` manuel ou BEM          |

package/docs/fr/18-api-freeze-map.md

@@ -1,63 +0,0 @@
-# Carte de gel de l'API
-
-> Ce qui est public, ce qui est interne, et ce que SemVer protégera en v1.
-
-Le contrat v1 de Mado est volontairement petit. Le code applicatif importe
-depuis la racine du package :
-
-```ts
-import { component, html, resource, routes, signal } from "@madojs/mado";
-```
-
-Le seul subpath public est le module side-effect devtools :
-
-```ts
-import "@madojs/mado/devtools.js";
-```
-
-Tout le reste sous `dist/src/` est un détail d'implémentation, même si le
-fichier est visible dans le dépôt.
-
-## API publique stable
-
-Ces noms sont publics et protégés par SemVer une fois v1 publiée :
-
-- Réactivité : `signal`, `computed`, `effect`, `untracked`, `batch`,
-  `flushSync`.
-- Templates et directives : `html`, `render`, `each`, `list`, `unsafeHTML`,
-  `ref`, `classMap`, `styleMap`.
-- Composants et CSS : `component`, `css`, `cssVars`.
-- Routage et pages : `routes`, `router`, `page`, `layout`,
-  `navigate`, `queryParam`, `prefetchPath`.
-- Data : `resource`, `mutation`, `invalidate`, `jsonFetcher`, `HttpError`.
-- Formulaires : `useForm`.
-- Head et persistence : `applyHead`, `persisted`.
-- Context : `createContext`, `provide`, `inject`.
-- Helpers lifecycle avancés : `createLifecycle`, `runInLifecycle`,
-  `getCurrentLifecycle`.
-- Types TypeScript publics exportés depuis `@madojs/mado`.
-
-## Interne ou instable
-
-Ce n'est pas de l'API publique :
-
-- Subpaths du package autres que `@madojs/mado` et
-  `@madojs/mado/devtools.js`.
-- Internals du parser/binding comme `html/parser.js`, `html/bindings.js`,
-  `ChildState` et `EachEntry`.
-- Internals du routeur comme `router/match.js`, `router/navigation.js` et
-  `router/manifest.js`.
-- Internals de diagnostics et tous les `_testHooks`.
-- Texte exact du bundle généré, noms des chunks et layout interne des fichiers.
-
-Les tests du dépôt peuvent importer des fichiers internes via des chemins
-relatifs `dist/`. Le code applicatif ne doit pas le faire.
-
-## Ce qui peut changer
-
-Les patch et minor releases peuvent ajouter des root exports, options,
-diagnostics, docs ou starters. Elles peuvent aussi changer les internals, la
-forme du bundle et les détails d'implémentation tant que l'API stable et le
-comportement documenté restent compatibles.
-
-Les changements cassants de l'API stable nécessitent une version majeure.

package/docs/fr/19-reactivity-ordering.md

@@ -1,97 +0,0 @@
-# Ordre de la réactivité
-
-> Le petit ensemble de garanties d'ordre que Mado traite comme comportement public.
-
-La réactivité de Mado est synchrone pour les lectures et planifiée pour les
-side effects. Le but est une mise à jour UI prévisible plutôt qu'un grand modèle
-de scheduling.
-
-## Signals
-
-`signal(value)` renvoie une fonction getter. `set(next)` change la valeur
-immédiatement sauf si `Object.is(previous, next)` vaut `true`.
-
-```ts
-const count = signal(0);
-count.set(1);
-count(); // 1, immédiatement
-```
-
-Les computed values sont marquées avant l'exécution des effects : un effect qui
-lit un computed observe les dépendances courantes, pas un cache obsolète.
-
-## Effects
-
-`effect(fn)` s'exécute une première fois immédiatement. Les changements
-ultérieurs de dépendances planifient une seule exécution en microtask. Les tests
-peuvent appeler `flushSync()` pour vider cette file de façon synchrone.
-
-Si un effect retourne une fonction de cleanup, Mado l'exécute avant l'exécution
-suivante de l'effect et à nouveau quand le disposer est appelé.
-
-```ts
-const stop = effect(() => {
-  const id = setInterval(tick, 1000);
-  return () => clearInterval(id);
-});
-
-stop();
-```
-
-Dans les composants et pages, préférez `ctx.onDispose()` / page `onDispose()`
-pour le cleanup à l'unmount. Le cleanup d'un effect est un cleanup par run.
-
-## Batch
-
-`batch(fn)` regroupe les écritures de signals en un seul passage des
-subscribers. Les effects ne s'exécutent pas avant la sortie du batch le plus
-extérieur, y compris avec des batches imbriqués.
-
-```ts
-batch(() => {
-  first.set("Ada");
-  batch(() => last.set("Lovelace"));
-});
-// les effects ne voient que la paire finale
-```
-
-Les `computed({ equals })` observés préservent aussi l'atomicité du batch : ils
-se recalculent une fois après le batch extérieur, sur l'état entièrement
-appliqué. Ils ne doivent pas observer un batch à moitié appliqué comme
-`(new x, old y)`.
-
-## Mises à jour DOM
-
-`render(result, container)` réutilise l'instance de template existante quand le
-render suivant a les mêmes template strings. Pour les child bindings qui
-retournent un `html``` imbriqué, la même règle s'applique : mêmes strings =
-mise à jour sur place, autres strings = reconstruction de cette branche.
-
-Ainsi, des changements de signals sans rapport ne recréent pas un `<input>`
-dans un template imbriqué stable : focus, état DOM et listeners survivent.
-
-Les listes doivent utiliser `each(items, key, renderItem)`. Les keys définissent
-l'identité DOM. Les duplicate keys avertissent en development et retombent sur
-un suffixe positionnel pour que chaque item soit rendu, mais les duplicate keys
-sont un bug de données.
-
-## Teardown des composants
-
-Les custom elements peuvent recevoir `disconnectedCallback()` puis
-`connectedCallback()` pendant un déplacement dans le même tick. Mado diffère le
-teardown du composant jusqu'à une microtask et l'annule si l'élément est
-reconnecté, donc les reorders keyed préservent l'état du composant. Une vraie
-suppression lance tout de même le cleanup lifecycle à la microtask suivante.
-
-## Non garanti
-
-Mado ne garantit pas le nombre exact de microtasks internes du scheduler,
-l'ordre des effects indépendants sans dépendances communes, la forme du bundle
-généré ni le layout interne des modules. Ce sont des détails d'implémentation.
-
-Les tests invariants de ce contrat vivent dans :
-
-- `test/reactivity-ordering.test.mjs`
-- `test/signal-batch-equals.test.mjs`
-- `test/update-nested-reuse.test.mjs`
-- `test/each-component-state.test.mjs`

package/docs/fr/20-v1-stability.md

@@ -1,88 +0,0 @@
-# Stabilité v1
-
-> Ce que Mado promet après v1, et ce qui reste libre d'évoluer.
-
-Mado v1 signifie que le contrat public côté application est assez stable pour
-de vraies applications métier. Cela ne veut pas dire que chaque fichier interne,
-octet généré, starter copy ou diagnostic string est gelé pour toujours.
-
-À lire avec :
-
-- [Carte de gel de l'API](./18-api-freeze-map.md)
-- [Ordre de la réactivité](./19-reactivity-ordering.md)
-
-## Stable sous SemVer
-
-Après v1, Mado considère comme protégés par SemVer :
-
-- Les exports publics de `@madojs/mado`.
-- Les types TypeScript publics exportés depuis `@madojs/mado`.
-- Le subpath side-effect `@madojs/mado/devtools.js`.
-- La syntaxe de template binding : child `${}`, `@event`, `.prop`,
-  `?boolean`, attribute bindings, directives et `each()`.
-- Les semantics des signals documentées dans le guide d'ordre de réactivité.
-- Les semantics du lifecycle composant : setup une fois par connection
-  lifetime, teardown différé pour les same-tick moves, cleanup via
-  `ctx.onDispose`.
-- Les contrats router/page/resource/form documentés dans les docs anglaises.
-- Les noms de commandes CLI et leur intention générale (`build`, `dev`,
-  `release`, `bake`, `preview`, `init`, `new`).
-
-Casser cela nécessite une version majeure.
-
-## Autorisé en minor releases
-
-Les minor releases peuvent ajouter :
-
-- De nouveaux root exports.
-- De nouvelles options sur des API existantes.
-- De nouveaux diagnostics et warnings.
-- De nouveaux starters, examples, docs et flags CLI.
-- Des améliorations de performance et des rewrites internes.
-
-Une minor release ne devrait pas forcer les apps correctes existantes à changer
-leur code.
-
-## Autorisé en patch releases
-
-Les patch releases peuvent corriger des bugs, durcir les diagnostics, améliorer
-les docs et faire des changements d'implémentation compatibles. Un patch peut
-changer le timing seulement si l'ancien timing était un bug non documenté et
-que le changement conserve le contrat d'ordre de réactivité.
-
-## Non stable
-
-Ne sont volontairement pas protégés par SemVer :
-
-- Les subpaths internes du package autres que `@madojs/mado/devtools.js`.
-- Les fichiers sous `src/`, `dist/src/` et les frontières de modules
-  d'implémentation.
-- `_testHooks`, internals de diagnostics et warning codes.
-- Le JavaScript exact généré, les noms de chunks, le contenu sourcemap et le
-  byte layout du bundle.
-- Les structures internes du parser, des bindings, du routeur et du cache
-  resource.
-- Le texte visuel et les données de démonstration des starters.
-
-Les apps ne doivent pas importer de fichiers internes ni vérifier l'output exact
-du bundle.
-
-## Bundle et output de release
-
-Mado gardera un size budget et des tests de release déterministe, mais la
-stabilité v1 ne fige pas l'output du bundler octet par octet. Les hashes,
-frontières de chunks et noms d'assets générés peuvent changer tant que le
-contrat de déploiement documenté continue de fonctionner.
-
-## Si une release vous casse
-
-Si une mise à jour casse du code qui utilise seulement les exports publics et le
-comportement documenté, traitez-le comme un bug. Ouvrez une issue avec :
-
-- la version de Mado avant et après ;
-- l'API publique impliquée ;
-- une reproduction minimale ;
-- si la casse concerne le runtime, les types TypeScript, l'output CLI ou les docs.
-
-Si la casse dépend d'un subpath interne ou de l'output généré exact, cela peut
-quand même valoir un rapport, mais ce n'est pas considéré comme une casse SemVer.

package/docs/fr/README.md

@@ -1,27 +0,0 @@
-# Mado docs — Français
-
-Documentation française.
-
-| Section                       | Fichier                                                      |
-| ----------------------------- | ------------------------------------------------------------ |
-| La voie Mado                  | [00-the-mado-way.md](./00-the-mado-way.md)                   |
-| Routage                       | [01-routing.md](./01-routing.md)                             |
-| Structure du projet           | [02-project-layout.md](./02-project-layout.md)               |
-| Prérendu statique & SEO       | [03-static-bake.md](./03-static-bake.md)                     |
-| Configuration IDE             | [04-ide-setup.md](./04-ide-setup.md)                         |
-| Pourquoi Mado                 | [05-why-mado.md](./05-why-mado.md)                           |
-| Pour les développeurs backend | [06-for-backenders.md](./06-for-backenders.md)               |
-| Pièges LLM                    | [07-llm-pitfalls.md](./07-llm-pitfalls.md)                   |
-| Test LLM sans historique      | [08-llm-zero-history-test.md](./08-llm-zero-history-test.md) |
-| Shadow DOM vs Light DOM       | [09-shadow-vs-light-dom.md](./09-shadow-vs-light-dom.md)     |
-| Architecture d'application    | [10-app-architecture.md](./10-app-architecture.md)           |
-| Mises en page (layouts)       | [11-layouts.md](./11-layouts.md)                             |
-| Auth et API                   | [12-auth-and-api.md](./12-auth-and-api.md)                   |
-| Déploiement                   | [13-deployment.md](./13-deployment.md)                       |
-| Tests                         | [14-testing.md](./14-testing.md)                             |
-| Gestion des erreurs           | [15-error-handling.md](./15-error-handling.md)               |
-| Guide de recettes bake        | [16-bake-cookbook.md](./16-bake-cookbook.md)                 |
-| Shadow DOM + formulaires      | [17-shadow-dom-forms.md](./17-shadow-dom-forms.md)           |
-| Carte de gel de l'API         | [18-api-freeze-map.md](./18-api-freeze-map.md)               |
-| Ordre de la réactivité        | [19-reactivity-ordering.md](./19-reactivity-ordering.md)     |
-| Stabilité v1                  | [20-v1-stability.md](./20-v1-stability.md)                   |

package/docs/ru/00-the-mado-way.md

@@ -1,84 +0,0 @@
-# The Mado Way
-
-> Один правильный путь. Жёсткие контракты. Никакой магии.
-
-Mado — фреймворк для команд, которые строят админки, внутренние инструменты и
-business SPA. Такие приложения должны быть простыми в разработке и скучными в
-поддержке. Поэтому Mado задает соглашения, а не предлагает пять равноценных
-стилей.
-
-## Принципы
-
-1. **Один способ.** Если пишешь что-то необычное, сначала проверь, нет ли уже
-   каноничного helper/API.
-2. **Явность над магией.** Никаких file-system scanners, implicit globals и
-   скрытых side effects.
-3. **Платформа сначала.** Web Components, History API, `<form>`, `fetch` и
-   Shadow DOM остаются платформой, а не прячутся под тяжелыми абстракциями.
-4. **Strict types.** `tsc --strict --noUncheckedIndexedAccess` всегда.
-5. **No runtime dependencies.** Dev/build tooling допустим, runtime Mado
-   остается нативным.
-
-## Структура проекта
-
-```txt
-src/
-├── main.ts           ← boot: global CSS/providers + render router
-├── app.routes.ts     ← readable app map, exports `manifest` + default routes()
-├── layouts/          ← app-zone wrappers (`page({ view: ({ child }) => ... })`)
-├── shared/           ← UI bricks, http client, pure lib, global CSS
-└── modules/          ← bounded contexts
-    └── billing/
-        ├── billing.routes.ts
-        ├── billing.public.ts
-        ├── billing.types.ts
-        ├── pages/
-        ├── data/
-        ├── api/
-        └── _contracts/
-```
-
-Default starter — каноничная версия этой формы. Если docs и старые примеры
-расходятся, starter и `docs/10-app-architecture.md` главнее.
-
-## Один компонент = один файл
-
-```ts
-import { component, css, html } from "@madojs/mado";
-
-component("x-user-card", () => () => html`<div class="card"><slot></slot></div>`, {
-  styles: css`
-    .card { padding: 1rem; }
-  `,
-});
-```
-
-Import component file registers the element. Import it where the tag is used.
-
-## Один способ описать страницу
-
-```ts
-import { html, page, resource, jsonFetcher } from "@madojs/mado";
-
-export default page({
-  title: ({ id }) => `User #${id}`,
-  view: ({ params }) => {
-    const user = resource(() => `/api/users/${params.id}`, jsonFetcher());
-    return html`...`;
-  },
-});
-```
-
-Page-local signals, resources and forms live inside `view()`. Module-wide state
-belongs in `*.service.ts`.
-
-## Чего НЕ делаем
-
-- Не используем JSX/Vue/Svelte syntax.
-- Не пишем custom elements без дефиса.
-- Не читаем signals через `.value`; signal читается как function.
-- Не используем `innerHTML` напрямую.
-- Не добавляем runtime packages без обсуждения.
-
-Когда сомневаешься, лучше записать один честный рецепт в docs, чем добавить
-новый primitive в core.

package/docs/ru/01-routing.md

@@ -1,119 +0,0 @@
-# Routing
-
-> Один app map. Никаких folder scanners. Никаких специальных path symbols.
-
-Mado не выводит routes из файлов. Composition должна читаться в одном месте.
-
-## App Manifest
-
-Используйте `src/app.routes.ts` как карту приложения:
-
-```ts
-import { layout, routes } from "@madojs/mado";
-import { requireAuth } from "./modules/auth/auth.public";
-import { authRoutes } from "./modules/auth/auth.routes";
-import { billingRoutes } from "./modules/billing/billing.routes";
-
-export const manifest = {
-  "/": () => import("./modules/home/home.page.js"),
-  "/login": layout({
-    layout: () => import("./layouts/auth-shell.layout.js"),
-    routes: authRoutes,
-  }),
-  "/billing": layout({
-    layout: () => import("./layouts/app-shell.layout.js"),
-    guard: requireAuth,
-    routes: billingRoutes,
-  }),
-  "*": () => import("./modules/home/not-found.page.js"),
-};
-
-export default routes(manifest);
-```
-
-Открываешь `app.routes.ts` и видишь все зоны приложения: public pages, auth,
-protected app zones, guards и shells.
-
-`manifest` экспортируется отдельно, чтобы `mado bake` мог его прочитать.
-
-## Module Routes
-
-Modules экспортируют plain route maps. Они не вызывают `layout()` и не решают,
-какой shell их оборачивает.
-
-```ts
-export const billingRoutes = {
-  "/invoices": () => import("./pages/invoices-list.page.js"),
-  "/invoices/:id": () => import("./pages/invoice-detail.page.js"),
-};
-```
-
-Prefix применяет `src/app.routes.ts`, когда module монтируется под
-`"/billing"`.
-
-## Layout Group
-
-```ts
-"/admin": layout({
-  layout: () => import("./layouts/app-shell.layout.js"),
-  guard: requireAuth,
-  routes: adminRoutes,
-}),
-```
-
-Layout — обычный `page({...})` file:
-
-```ts
-import { html, page } from "@madojs/mado";
-
-export default page({
-  view: ({ child }) => html`
-    <div class="layout layout--app">
-      <main class="app-main">${child}</main>
-    </div>
-  `,
-});
-```
-
-Layout view держим stateless. Page-specific signals, resources и forms живут в
-pages/components/resources, не в layout locals.
-
-## Page Contract
-
-```ts
-import { html, page } from "@madojs/mado";
-
-export default page<{ id: string }>({
-  title: ({ id }) => `User ${id}`,
-  view: ({ params }) => html`<h1>${params.id}</h1>`,
-});
-```
-
-## Navigation
-
-```ts
-import appRoutes from "./app.routes.js";
-
-appRoutes.navigate("/billing/invoices");
-appRoutes.navigate("/billing/invoices?page=2");
-appRoutes.navigate("/login", { replace: true });
-```
-
-## Query Parameters
-
-```ts
-import { queryParam } from "@madojs/mado";
-
-const page = queryParam("page", "1");
-page();
-page.set("2");
-page.set(null);
-page.set("3", { push: true });
-```
-
-## Чего нет намеренно
-
-- Auto-scan of page folders.
-- Filesystem syntax вроде `[id]`, `(group)`, `_layout`.
-- Server routes в client manifest.
-- Hidden layout discovery.