domma-cms 0.44.0 → 0.45.1

package/admin/js/templates/docs/components-rules.html

@@ -1,5 +1,5 @@
 <div class="view-header">
-  <h1><span data-icon="component"></span> Components — Rules</h1>
+  <h1><span data-icon="component"></span> Components - Rules</h1>
   <a href="#/docs/components" class="btn btn-ghost btn-sm"><span data-icon="arrow-left"></span> Reference</a>
 </div>
 
@@ -16,18 +16,18 @@
       </nav>
 
       <p class="lead">The constraints the compiler enforces, and the handful of behaviours that commonly
-        trip people up. Everything here is validated at save time — a component that breaks a rule never
+        trip people up. Everything here is validated at save time - a component that breaks a rule never
         reaches disk.</p>
 
       <hr>
 
       <h2>Naming</h2>
       <ul>
-        <li>Names must match <code>^[a-z][a-z0-9-]*$</code> — start with a lowercase letter, then lowercase
+        <li>Names must match <code>^[a-z][a-z0-9-]*$</code> - start with a lowercase letter, then lowercase
           letters, digits and hyphens.</li>
         <li>Valid: <code>counter</code>, <code>copy-button</code>, <code>price-tag-2</code>. Invalid:
           <code>Counter</code>, <code>1counter</code>, <code>my_component</code>, <code>../etc/passwd</code>.</li>
-        <li>The name becomes the element tag <code>&lt;dm-<em>name</em>&gt;</code> and is <strong>permanent</strong> —
+        <li>The name becomes the element tag <code>&lt;dm-<em>name</em>&gt;</code> and is <strong>permanent</strong> -
           it can't be changed after creation. To rename, create a new component and delete the old one.</li>
       </ul>
 
@@ -46,7 +46,7 @@
       <h2>Props must be a typed JSON object</h2>
       <ul>
         <li>The <code>&lt;props&gt;</code> body must be valid JSON and an <strong>object</strong> (not an
-          array, not a bare value) — otherwise <code>INVALID_PROPS_JSON</code>.</li>
+          array, not a bare value) - otherwise <code>INVALID_PROPS_JSON</code>.</li>
         <li>Every prop must declare a <code>type</code> that is one of <code>string</code>,
           <code>number</code>, <code>boolean</code>, <code>array</code>, <code>object</code>. Anything else
           (or a missing type) fails validation.</li>
@@ -59,9 +59,9 @@
       <h2>The script must <code>export default</code> an object</h2>
       <ul>
         <li>The <code>&lt;script&gt;</code> body must be exactly one <code>export default { … };</code>
-          statement — the compiler strips that prefix and embeds the object. No <code>export default</code>
+          statement - the compiler strips that prefix and embeds the object. No <code>export default</code>
           means <code>SCRIPT_MISSING_EXPORT</code>.</li>
-        <li>Use an object expression — not a class, not multiple exports. An empty
+        <li>Use an object expression - not a class, not multiple exports. An empty
           <code>export default {};</code> is valid for a purely presentational component.</li>
       </ul>
 
@@ -84,13 +84,13 @@
 
       <div class="alert alert-warning">
         <strong>3. Attribute casing.</strong> On the raw custom element, camelCase props are written as
-        <code>kebab-case</code> attributes — <code>showReset</code> becomes <code>show-reset</code>. The
+        <code>kebab-case</code> attributes - <code>showReset</code> becomes <code>show-reset</code>. The
         <code>[component]</code> shortcode accepts the prop name as written.
       </div>
 
       <div class="alert alert-warning">
-        <strong>4. Array / object props are JSON in the attribute.</strong> Pass them as a JSON string —
-        e.g. <code>items='["a","b"]'</code> — and the runtime parses them to the declared type.
+        <strong>4. Array / object props are JSON in the attribute.</strong> Pass them as a JSON string -
+        e.g. <code>items='["a","b"]'</code> - and the runtime parses them to the declared type.
       </div>
 
       <div class="alert alert-warning">
@@ -101,7 +101,7 @@
 
       <div class="alert alert-warning">
         <strong>6. Clean up in <code>onUnmount()</code>.</strong> Anything you start in <code>onMount</code>
-        — intervals, timeouts, external listeners — must be torn down in <code>onUnmount</code> so it
+        - intervals, timeouts, external listeners - must be torn down in <code>onUnmount</code> so it
         doesn't leak when the element is removed.
       </div>
 
@@ -112,7 +112,7 @@
         <li>Components contributed by a plugin show a <span class="badge badge-secondary">plugin</span>
           badge, are served from memory, and <strong>cannot be edited or deleted</strong> from the admin
           (attempting it returns <code>PLUGIN_OWNED</code>).</li>
-        <li>You also can't save a disk component whose name a plugin already owns — pick a different name.</li>
+        <li>You also can't save a disk component whose name a plugin already owns - pick a different name.</li>
       </ul>
 
       <hr>
@@ -120,7 +120,7 @@
       <h2>Import / export constraints</h2>
       <ul>
         <li>A bundle must have a numeric <code>format</code> no newer than the CMS supports, plus
-          <code>name</code> and <code>source</code> strings — otherwise <code>INVALID_BUNDLE</code>.</li>
+          <code>name</code> and <code>source</code> strings - otherwise <code>INVALID_BUNDLE</code>.</li>
         <li>Importing over an existing name returns <code>CONFLICT</code> unless you confirm the overwrite
           (the Import button prompts you).</li>
         <li>Imported source is compiled like any save, so a broken bundle is rejected with the same errors.</li>
@@ -132,7 +132,7 @@
       <ul>
         <li><code>{{ }}</code> interpolation is HTML-escaped, so prop values can't inject markup.</li>
         <li>The markdown sanitiser keeps a live allowlist of <code>dm-*</code> tags, refreshed whenever you
-          save or delete a component — a component you just created is immediately usable in page content.
+          save or delete a component - a component you just created is immediately usable in page content.
           <code>on*</code> handler attributes and <code>javascript:</code> URLs are still stripped globally.</li>
         <li>Saving recompiles and invalidates the cached module, so edits take effect on the next page load
           without a server restart.</li>

package/admin/js/templates/docs/components-walkthrough.html

@@ -1,5 +1,5 @@
 <div class="view-header">
-  <h1><span data-icon="component"></span> Components — Walkthrough</h1>
+  <h1><span data-icon="component"></span> Components - Walkthrough</h1>
   <a href="#/components/new" class="btn btn-primary btn-sm"><span data-icon="plus"></span> New Component</a>
 </div>
 
@@ -24,7 +24,7 @@
 
       <hr>
 
-      <h2>Step 1 — Create the component</h2>
+      <h2>Step 1 - Create the component</h2>
       <p>Open <a href="#/components">Data → Components</a> → <strong>New Component</strong> and name it
         <code>star-rating</code>. Remember: lowercase + hyphens, and the name is permanent because it
         becomes the element tag <code>&lt;dm-star-rating&gt;</code>. The four source tabs
@@ -33,7 +33,7 @@
 
       <hr>
 
-      <h2>Step 2 — Declare the props</h2>
+      <h2>Step 2 - Declare the props</h2>
       <p>Start with the inputs, because they shape everything else. A rating needs a maximum number of
         stars and a current value. Put this in the <code>&lt;props&gt;</code> tab:</p>
       <pre class="code-block"><code>{
@@ -45,7 +45,7 @@
 
       <hr>
 
-      <h2>Step 3 — Write the template</h2>
+      <h2>Step 3 - Write the template</h2>
       <p>We render <code>max</code> stars and mark each as filled if its index is below the current rating.
         Because <code>{{#each}}</code> needs a list, we'll build a <code>stars</code> array in state
         (next step) where each item knows whether it's <code>on</code>. For now, the markup:</p>
@@ -61,7 +61,7 @@
 
       <hr>
 
-      <h2>Step 4 — Add the script (state + behaviour)</h2>
+      <h2>Step 4 - Add the script (state + behaviour)</h2>
       <p>Three jobs: build the <code>stars</code> array from <code>value</code>, rebuild it whenever the
         rating changes, and handle clicks. Remember <code>data()</code> can't see props, so we seed state
         in <code>onMount()</code>.</p>
@@ -102,7 +102,7 @@ export default {
 
       <hr>
 
-      <h2>Step 5 — Style it (scoped)</h2>
+      <h2>Step 5 - Style it (scoped)</h2>
       <pre class="code-block"><code>&lt;style&gt;
 .dm-stars { display: inline-flex; gap: .15rem; }
 .dm-stars .star {
@@ -116,15 +116,15 @@ export default {
 
       <hr>
 
-      <h2>Step 6 — Watch the preview, then save</h2>
+      <h2>Step 6 - Watch the preview, then save</h2>
       <p>As you typed, the editor recompiled and re-mounted the component in the preview iframe. Toggle
         <code>readonly</code> and change <code>value</code> in the <em>Preview props</em> panel to sanity-check
-        both modes. When it looks right, hit <strong>Save Component</strong> — the source compiles before it
+        both modes. When it looks right, hit <strong>Save Component</strong> - the source compiles before it
         is written, so a typo surfaces as a clear error rather than a broken page.</p>
 
       <hr>
 
-      <h2>Step 7 — Use it on a page</h2>
+      <h2>Step 7 - Use it on a page</h2>
       <p>Display-only, in any Markdown page:</p>
       <pre class="code-block"><code>[component name="star-rating" max="5" value="4" readonly="true" /]</code></pre>
       <p>Interactive, reacting to the custom event with a little page script:</p>
@@ -137,9 +137,9 @@ document.getElementById('r1').addEventListener('rating-change', (e) =&gt; {
 
       <hr>
 
-      <h2>Step 8 — Share it</h2>
+      <h2>Step 8 - Share it</h2>
       <p>Back on <a href="#/components">Components</a>, the <span data-icon="download"></span> Export button
-        gives you <code>star-rating.dmcomponent.json</code> — import that on another Domma site to reuse the
+        gives you <code>star-rating.dmcomponent.json</code> - import that on another Domma site to reuse the
         widget verbatim.</p>
 
       <hr>
@@ -154,8 +154,8 @@ document.getElementById('r1').addEventListener('rating-change', (e) =&gt; {
         <li><strong>Scoped CSS</strong>, the live preview, and export/import</li>
       </ul>
 
-      <p>For the rules that keep components well-behaved — naming, the <code>data()</code>-can't-see-props
-        gotcha, boolean coercion, plugin-owned names — read <a href="#/docs/components-rules">Rules</a>.</p>
+      <p>For the rules that keep components well-behaved - naming, the <code>data()</code>-can't-see-props
+        gotcha, boolean coercion, plugin-owned names - read <a href="#/docs/components-rules">Rules</a>.</p>
 
       <hr>
       <p class="text-muted" style="font-size:.9rem;">

package/admin/js/templates/docs/tutorial-crud.html

@@ -8,7 +8,7 @@
     <div class="docs-body" id="tutorial-crud">
 
       <p class="lead">
-        A "CRUD app" — Create, Read, Update, Delete — is the shape of almost every business
+        A "CRUD app" - Create, Read, Update, Delete - is the shape of almost every business
         tool you'll ever build. Onboarding, bookings, contacts, tickets, orders, RSVPs,
         classified ads. Domma CMS gives you everything to build one without writing
         JavaScript, but the trick is understanding <em>why</em> the pieces compose the way
@@ -26,10 +26,10 @@
         Domma CMS gives each of those a name:</p>
 
       <ul>
-        <li><strong>Collection</strong> — the data store. Think "spreadsheet": rows are records, columns are fields with types.</li>
-        <li><strong>Form</strong> — how new records get added. It writes to a Collection on submit.</li>
-        <li><strong>Action</strong> — a server-side button that changes existing records. "Approve", "Withdraw", "Send invoice".</li>
-        <li><strong>Page</strong> — a Markdown page with <em>shortcodes</em> that render forms and lists from your collections.</li>
+        <li><strong>Collection</strong> - the data store. Think "spreadsheet": rows are records, columns are fields with types.</li>
+        <li><strong>Form</strong> - how new records get added. It writes to a Collection on submit.</li>
+        <li><strong>Action</strong> - a server-side button that changes existing records. "Approve", "Withdraw", "Send invoice".</li>
+        <li><strong>Page</strong> - a Markdown page with <em>shortcodes</em> that render forms and lists from your collections.</li>
       </ul>
 
       <p>These are deliberately separate. A single Collection might be written to by three different Forms
@@ -38,7 +38,7 @@
         separate is what lets the same data drive multiple experiences.</p>
 
       <div class="alert alert-info">
-        <strong>Why not a database?</strong> Collections store as flat JSON files on disk by default —
+        <strong>Why not a database?</strong> Collections store as flat JSON files on disk by default -
         no database to install, no SQL to learn, no migrations. When you outgrow that, switch
         individual collections to MongoDB without changing any of your pages or forms. The
         compatibility layer is the point.
@@ -46,18 +46,18 @@
 
       <hr>
 
-      <h2>Step 1 — Create the Collection (your data store)</h2>
+      <h2>Step 1 - Create the Collection (your data store)</h2>
 
       <p>Open <a href="#/collections">Collections</a> → <strong>New collection</strong>. You'll give it a
         slug (the URL-safe name we use in shortcodes), a title, and a list of fields.</p>
 
       <p><strong>The slug matters more than you'd think.</strong> It's what every Form, Action, and shortcode
-        uses to refer to this collection — so pick a noun and stick with it. <code>jobs</code>,
+        uses to refer to this collection - so pick a noun and stick with it. <code>jobs</code>,
         <code>applications</code>, <code>contacts</code>, <code>events</code>. Don't pluralise inconsistently
-        and don't include the word "data" or "collection" in the slug — that's redundant.</p>
+        and don't include the word "data" or "collection" in the slug - that's redundant.</p>
 
       <p><strong>Fields are where the design lives.</strong> Each field has a <em>type</em>, and the type isn't
-        just for show — it drives every downstream behaviour:</p>
+        just for show - it drives every downstream behaviour:</p>
 
       <ul>
         <li><code>text</code> renders a text input on forms and is searchable in the Browser</li>
@@ -66,7 +66,7 @@
         <li><code>multiselect</code> becomes a checkbox group AND a filterable tag chip set</li>
         <li><code>date</code> renders a date picker AND gets a from/to range filter</li>
         <li><code>file</code> renders a file upload with mime/size validation</li>
-        <li><code>reference</code> stores a link to another collection's entry — auto-renders as a populated dropdown</li>
+        <li><code>reference</code> stores a link to another collection's entry - auto-renders as a populated dropdown</li>
       </ul>
 
       <p>Pick the right type at design time and you get the right form input, the right filter UI, and the
@@ -80,7 +80,7 @@
 
       <hr>
 
-      <h2>Step 2 — Read the data (display it on a page)</h2>
+      <h2>Step 2 - Read the data (display it on a page)</h2>
 
       <p>You don't need code to list a Collection on a public page. Drop this in any Markdown page:</p>
 
@@ -89,25 +89,25 @@
   fields="company,location,salary,type" /]</code></pre>
 
       <p>That single shortcode gives you a server-rendered, cached, SEO-friendly grid of cards. The server
-        reads the collection at request time, filters it, sorts it, and produces static HTML — every
+        reads the collection at request time, filters it, sorts it, and produces static HTML - every
         visitor gets the same instant render. The page is cached per role, so a million visitors viewing
         a public page hit the cache and never touch the data store.</p>
 
       <p><strong>Five display modes are built in:</strong></p>
 
       <ul>
-        <li><code>display="table"</code> — sortable, paginated, with a search box</li>
-        <li><code>display="cards"</code> — visual grid (default 3 columns; configurable)</li>
-        <li><code>display="list"</code> — vertical stack with title + meta</li>
-        <li><code>display="accordion"</code> — expandable rows, title visible, body hidden until clicked</li>
-        <li><code>display="timeline"</code> — chronological with dates and statuses</li>
+        <li><code>display="table"</code> - sortable, paginated, with a search box</li>
+        <li><code>display="cards"</code> - visual grid (default 3 columns; configurable)</li>
+        <li><code>display="list"</code> - vertical stack with title + meta</li>
+        <li><code>display="accordion"</code> - expandable rows, title visible, body hidden until clicked</li>
+        <li><code>display="timeline"</code> - chronological with dates and statuses</li>
       </ul>
 
       <p>All five display the same data; you pick the right shape for the page. A directory might use
         <code>cards</code>; an admin overview might use <code>table</code>; a history page might use
         <code>timeline</code>.</p>
 
-      <h3>Make it interactive — flip on the Browser</h3>
+      <h3>Make it interactive - flip on the Browser</h3>
 
       <p>Adding any of <code>searchable</code>, <code>filterable</code>, or <code>sortable</code> upgrades the
         static list to a full <strong>Collection Browser</strong>:</p>
@@ -119,7 +119,7 @@
   page-size="9"
   empty="No matching jobs." /]</code></pre>
 
-      <p>Now the page has a search box, a filter rail down the left side, a sort dropdown, and pagination —
+      <p>Now the page has a search box, a filter rail down the left side, a sort dropdown, and pagination -
         all generated automatically from the schema you wrote in Step 1. The Browser is the moment your
         app starts to feel like an app rather than a brochure.</p>
 
@@ -131,14 +131,14 @@
 
       <hr>
 
-      <h2>Step 3 — Create new records (the Form)</h2>
+      <h2>Step 3 - Create new records (the Form)</h2>
 
-      <p>Open <a href="#/forms">Forms</a> → <strong>New form</strong>. The slug here is the form's identity —
+      <p>Open <a href="#/forms">Forms</a> → <strong>New form</strong>. The slug here is the form's identity -
         what you embed on a page with <code>[form name="..." /]</code>.</p>
 
       <p>Form fields can mirror the collection fields exactly, or they can be a subset. <strong>You almost
         always want a subset.</strong> Fields like <code>status</code> shouldn't appear on a public-facing
-        submission form — the form should set status to <em>"pending"</em> automatically. Fields like
+        submission form - the form should set status to <em>"pending"</em> automatically. Fields like
         <code>internalNotes</code> shouldn't be visible to the submitter at all. The form is your
         audience-facing slice of the collection; design it for who's filling it in.</p>
 
@@ -152,13 +152,13 @@
         form fires. That's how the "My applications" view later works without any extra config: you ask
         for "entries created by the current user" and the platform already has that data.</p>
 
-      <p>Anonymous submissions still work — <code>createdBy</code> is null and the action receives an empty
+      <p>Anonymous submissions still work - <code>createdBy</code> is null and the action receives an empty
         user. So one form can serve both anonymous contact-us submissions AND authenticated apply-for-this-job
         submissions; the difference shows up in what the action templates can resolve.</p>
 
       <hr>
 
-      <h2>Step 4 — Change records over time (the Action)</h2>
+      <h2>Step 4 - Change records over time (the Action)</h2>
 
       <p>This is where most no-code platforms top out. An Action is a server-side button: visitors click it
         on a page, the server runs a sequence of steps against the entry they clicked on, and the page
@@ -166,13 +166,13 @@
 
       <p>Steps include: <code>updateField</code> (set one field to a new value), <code>deleteEntry</code>
         (remove the entry), <code>createInCollection</code> (write a related entry to another collection
-        — this is how "apply for this job" creates an application without losing the job), <code>email</code>
+        - this is how "apply for this job" creates an application without losing the job), <code>email</code>
         (send a notification using the entry's fields as template variables), and <code>webhook</code>
         (POST to an external service).</p>
 
       <h3>The transition is the magic word</h3>
 
-      <p>Actions can declare a <strong>transition</strong> — "this action moves the entry's status from
+      <p>Actions can declare a <strong>transition</strong> - "this action moves the entry's status from
         <em>pending</em> to <em>reviewing</em>". That single addition unlocks two huge things:</p>
 
       <ol>
@@ -207,15 +207,15 @@
 
       <hr>
 
-      <h2>Step 5 — Who sees what (Visibility + scope)</h2>
+      <h2>Step 5 - Who sees what (Visibility + scope)</h2>
 
       <p>Pages have a <code>visibility</code> frontmatter field that decides who can load the page at all.
         It accepts a single role (<em>"editor and everyone above"</em>) or an array of roles
-        (<em>"candidates OR employers"</em>). Roles are hierarchical — higher-privilege roles inherit
+        (<em>"candidates OR employers"</em>). Roles are hierarchical - higher-privilege roles inherit
         access to lower-privilege gated pages without you adding them explicitly.</p>
 
-      <p>For per-user data <em>within</em> a page that mixed-role users share — like a "My applications"
-        block on a dashboard that both candidates and employers visit — use <code>scope="mine"</code>:</p>
+      <p>For per-user data <em>within</em> a page that mixed-role users share - like a "My applications"
+        block on a dashboard that both candidates and employers visit - use <code>scope="mine"</code>:</p>
 
       <pre class="code-block"><code>[collection slug="applications" scope="mine"
   display="cards" title-field="jobId"
@@ -227,7 +227,7 @@
         tamper with which user's data they see). Anonymous visitors see a sign-in prompt where the block
         would render.</p>
 
-      <p>For cross-collection scoping — <em>"recruiter sees only applications for jobs they posted"</em> —
+      <p>For cross-collection scoping - <em>"recruiter sees only applications for jobs they posted"</em> -
         use the <code>reference</code> row-access mode in your action's <code>access.rowLevel</code>. The
         platform resolves the reference to check ownership on the target. <a
             href="/docs/configuration.md" target="_blank">Full row-access reference</a> covers all three
@@ -235,7 +235,7 @@
 
       <hr>
 
-      <h2>Step 6 — Files, references, and "feels like a real app"</h2>
+      <h2>Step 6 - Files, references, and "feels like a real app"</h2>
 
       <p>Three field types deserve their own mention because they're where Domma stops looking like a CMS
         and starts looking like a development platform:</p>
@@ -244,7 +244,7 @@
         to <code>/content/media/</code> with mime + size validation, then stores a reference object
         <code>{url, name, size, mime}</code> on the entry. Image mimes auto-display as thumbnails on the
         page; PDFs and docs become "download" links. The form switches to multipart submission
-        automatically the moment any file input has a selection — no extra config.</p>
+        automatically the moment any file input has a selection - no extra config.</p>
 
       <p><strong>Reference fields</strong> (<code>type: "reference"</code>) store the id of another
         collection's entry. The form picker becomes a populated dropdown of the target collection's
@@ -261,32 +261,32 @@
 
       <hr>
 
-      <h2>Step 7 — The Browser tour (advanced reading UI)</h2>
+      <h2>Step 7 - The Browser tour (advanced reading UI)</h2>
 
       <p>We touched on the Browser in Step 2. Here's the rest of what it does for free once you turn it
         on with <code>searchable filterable=... sortable</code>:</p>
 
       <ul>
-        <li><strong>Faceted filter counts</strong> — every filter chip shows the count of entries that
+        <li><strong>Faceted filter counts</strong> - every filter chip shows the count of entries that
           would match if that option were toggled with current other filters. Standard ecommerce-style
           faceted browsing.</li>
-        <li><strong>Empty state with "Clear filters"</strong> — when the user narrows to zero results,
+        <li><strong>Empty state with "Clear filters"</strong> - when the user narrows to zero results,
           one click resets and gets them un-stuck.</li>
-        <li><strong>Saved searches</strong> — dropdown in the header lets users name and recall their
+        <li><strong>Saved searches</strong> - dropdown in the header lets users name and recall their
           favourite filter combinations.</li>
-        <li><strong>CSV export</strong> — add <code>exportable</code> and a button generates a CSV of the
+        <li><strong>CSV export</strong> - add <code>exportable</code> and a button generates a CSV of the
           current filtered set.</li>
-        <li><strong>Mobile filter drawer</strong> — narrow viewports get a "Filters (n)" button that
+        <li><strong>Mobile filter drawer</strong> - narrow viewports get a "Filters (n)" button that
           slides the rail in from the left as an overlay.</li>
-        <li><strong>URL state sync</strong> — every change writes to the URL query string, so deep-links
+        <li><strong>URL state sync</strong> - every change writes to the URL query string, so deep-links
           and the browser back button work.</li>
-        <li><strong>Relevance sort during search</strong> — when the search box has a term, results
+        <li><strong>Relevance sort during search</strong> - when the search box has a term, results
           re-order by match count with a 3× boost on matches in the title field.</li>
-        <li><strong>Keyboard shortcuts</strong> — <code>/</code> focuses search, <code>←</code>/<code>→</code>
+        <li><strong>Keyboard shortcuts</strong> - <code>/</code> focuses search, <code>←</code>/<code>→</code>
           pages.</li>
-        <li><strong>Infinite scroll</strong> — <code>pagination="scroll"</code> replaces the pager with
+        <li><strong>Infinite scroll</strong> - <code>pagination="scroll"</code> replaces the pager with
           a sentinel that loads more on scroll.</li>
-        <li><strong>Server-mode for huge datasets</strong> — <code>mode="server"</code> makes every
+        <li><strong>Server-mode for huge datasets</strong> - <code>mode="server"</code> makes every
           change round-trip to the API; the storage adapter (Mongo or File) handles the query;
           authoring stays identical.</li>
       </ul>
@@ -295,7 +295,7 @@
 
       <hr>
 
-      <h2>Pulling it together — the worked example</h2>
+      <h2>Pulling it together - the worked example</h2>
 
       <p>A <strong>job board</strong> uses every primitive in this tutorial:</p>
 
@@ -308,7 +308,7 @@
         <li>A dashboard at <code>/dashboard</code> with <code>visibility: [candidate, employer]</code> and
           two <code>[collection scope="mine"]</code> blocks (one per role)</li>
         <li>Transition actions: <em>start-review</em>, <em>invite-to-interview</em>, <em>make-offer</em>,
-          <em>reject</em>, <em>withdraw</em> — each with its own role + state guards</li>
+          <em>reject</em>, <em>withdraw</em> - each with its own role + state guards</li>
         <li>The candidate dashboard adds <code>transitions</code> and each row gets the right buttons
           for its current status</li>
         <li>Recruiters get <code>access.rowLevel: { mode: 'reference', field: 'jobId', targetCollection: 'jobs' }</code>
@@ -320,7 +320,7 @@
 
       <hr>
 
-      <h2>Skip ahead — scaffold a working CRUD system in one click</h2>
+      <h2>Skip ahead - scaffold a working CRUD system in one click</h2>
 
       <p>Reading is one thing; having a real working subsystem to poke at is another. The CMS ships with
         starter <em>recipes</em> that scaffold a complete Collection + Form + Actions in a single
@@ -329,7 +329,7 @@
       <div id="tutorial-scaffolder-mount" style="margin-top:1rem;"></div>
 
       <p class="text-muted" style="margin-top:1rem;font-size:.9rem;">
-        Recipes are JSON files under <code>server/services/recipes/</code> — copy one as a starting
+        Recipes are JSON files under <code>server/services/recipes/</code> - copy one as a starting
         point for your own. The <a href="/docs/scaffolding.md" target="_blank">scaffolding docs</a>
         cover the recipe format in full.
       </p>

package/admin/js/templates/docs/tutorial-forms.html

@@ -52,16 +52,16 @@ Subject Prefix:   [Contact Form]</code></pre>
         <li>Select the Action from the dropdown and save.</li>
       </ol>
       <p>The Action runs server-side, after the entry is saved. If it fails (e.g. MongoDB is not
-        configured), the submission is still stored — the action failure is non-fatal and logged as a
+        configured), the submission is still stored - the action failure is non-fatal and logged as a
         warning.</p>
 
       <h3>4. Success message vs. redirect</h3>
       <p>After a successful submission the visitor sees one of two things:</p>
       <ul>
-        <li><strong>Inline success message</strong> — the form is replaced by the text set in
+        <li><strong>Inline success message</strong> - the form is replaced by the text set in
           <em>Settings → Success Message</em>. Good for simple acknowledgements.
         </li>
-        <li><strong>Page redirect</strong> — the visitor is sent to the URL set in
+        <li><strong>Page redirect</strong> - the visitor is sent to the URL set in
           <em>Settings → Success Redirect URL</em>. Good for registration flows, checkouts, or when you
           want a full thank-you page with additional content. <strong>Takes priority</strong> if both are
           set.
@@ -80,7 +80,7 @@ Subject Prefix:   [Contact Form]</code></pre>
         <li>Execute CMS Action (if set)</li>
         <li>Return success response → client redirects or shows message</li>
       </ol>
-      <p>Steps 3–5 are non-fatal: a failure in any of them is logged as a warning but does not prevent the
+      <p>Steps 3-5 are non-fatal: a failure in any of them is logged as a warning but does not prevent the
         submission from being stored or the success response from being returned.</p>
 
       <hr>

package/admin/js/templates/docs/tutorial-plugin.html

@@ -28,7 +28,7 @@
 
       <hr>
 
-      <h3>1. plugin.json — the manifest</h3>
+      <h3>1. plugin.json - the manifest</h3>
       <p>All fields below are <strong>required</strong>. Missing any will cause the plugin to be skipped on
         startup with a warning in the server log.</p>
       <pre class="code-block"><code>{
@@ -81,10 +81,10 @@
 
       <hr>
 
-      <h3>2. plugin.js — the Fastify plugin</h3>
+      <h3>2. plugin.js - the Fastify plugin</h3>
       <p>This is the server-side entry point. It must export a default <strong>async function</strong> that
         Fastify will call with <code>(fastify, options)</code>.</p>
-      <p>The CMS injects auth middleware through <code>options.auth</code> — always destructure from there
+      <p>The CMS injects auth middleware through <code>options.auth</code> - always destructure from there
         rather than importing directly.</p>
 
       <pre class="code-block"><code>import { getPluginSettings, savePluginState } from '../../server/services/plugins.js';
@@ -92,7 +92,7 @@
 export default async function myPlugin(fastify, options) {
     const { authenticate, requireAdmin } = options.auth;
 
-    // Public endpoint — no auth needed
+    // Public endpoint - no auth needed
     fastify.get('/hello', async () => {
         return { message: 'Hello from my plugin!' };
     });
@@ -109,11 +109,11 @@ export default async function myPlugin(fastify, options) {
 }</code></pre>
 
       <p>Routes are registered under the prefix <code>/api/plugins/{name}</code> automatically. You do not
-        set the prefix yourself — it is always locked to your plugin's directory name.</p>
+        set the prefix yourself - it is always locked to your plugin's directory name.</p>
 
       <hr>
 
-      <h3>3. config.js — settings defaults</h3>
+      <h3>3. config.js - settings defaults</h3>
       <p>Export a plain object of default settings. These are merged with any user overrides stored in
         <code>config/plugins.json</code> when <code>getPluginSettings()</code> is called.</p>
 
@@ -156,7 +156,7 @@ export default async function myPlugin(fastify, options) {
     }
 }</code></pre>
 
-      <p>The view file follows the standard Domma view pattern — a <code>templateUrl</code> and an
+      <p>The view file follows the standard Domma view pattern - a <code>templateUrl</code> and an
         <code>onMount($container)</code> function:</p>
 
       <pre class="code-block"><code>// admin/views/my-view.js
@@ -205,7 +205,7 @@ export const myPluginView = {
 })();
 &lt;/script&gt;</code></pre>
 
-      <p>Snippet paths are validated — they must stay within the plugin's own directory. Paths containing
+      <p>Snippet paths are validated - they must stay within the plugin's own directory. Paths containing
         <code>..</code> are blocked.</p>
 
       <hr>
@@ -213,7 +213,7 @@ export const myPluginView = {
       <h3>6. Registering and testing</h3>
       <ol>
         <li>Create the <code>plugins/my-plugin/</code> directory with all three required files.</li>
-        <li>Restart the server — you should see <code>[plugins] Loaded N plugins: …, my-plugin</code> in
+        <li>Restart the server - you should see <code>[plugins] Loaded N plugins: …, my-plugin</code> in
           the log.
         </li>
         <li>Go to the <a href="#/plugins">Plugins page</a> and enable your plugin.</li>
@@ -221,7 +221,7 @@ export const myPluginView = {
         <li>Verify your endpoint: <code>GET /api/plugins/my-plugin/hello</code></li>
       </ol>
 
-      <p class="text-muted" style="font-size:.9rem">Tip: use <code>npm run dev</code> during development —
+      <p class="text-muted" style="font-size:.9rem">Tip: use <code>npm run dev</code> during development -
         the server restarts automatically on file changes.</p>
 
       <hr>