@olonjs/cli 3.0.121 → 3.0.123

package/assets/src_tenant_alpha.sh

@@ -1631,9 +1631,9 @@ cat << 'END_OF_FILE_CONTENT' > "package.json"
     "dev": "vite",
     "dev:clean": "vite --force",
     "verify:webmcp": "node scripts/webmcp-feature-check.mjs",
-    "prebuild": "node scripts/sync-pages-to-public.mjs",
+    "prebuild": "node scripts/sync-pages-to-public.mjs && node scripts/generate-llms-txt.mjs",
     "build": "tsc && vite build",
-    "dist": "bash ./src2Code.sh --template alpha src .cursor vercel.json index.html tsconfig.json tsconfig.node.json vite.config.ts scripts specs package.json public/assets/images/plug-graded-square.jpg",
+    "dist": "bash ./src2Code.sh --template alpha src .cursor vercel.json index.html tsconfig.json tsconfig.node.json vite.config.ts scripts ../../specs package.json public/assets/images/plug-graded-square.jpg",
     "preview": "vite preview",
     "bake:email": "tsx scripts/bake-email.tsx",
     "bakemail": "npm run bake:email --",
@@ -1644,7 +1644,7 @@ cat << 'END_OF_FILE_CONTENT' > "package.json"
     "@tiptap/extension-link": "^2.11.5",
     "@tiptap/react": "^2.11.5",
     "@tiptap/starter-kit": "^2.11.5",
-    "@olonjs/core": "^1.0.110",
+    "@olonjs/core": "^1.0.112",
     "class-variance-authority": "^0.7.1",
     "clsx": "^2.1.1",
     "lucide-react": "^0.474.0",
@@ -1959,11 +1959,7 @@ import { build } from 'vite';
 import path from 'path';
 import { fileURLToPath, pathToFileURL } from 'url';
 import fs from 'fs/promises';
-import { createRequire } from 'module';
-
-const require = createRequire(import.meta.url);
-const corePkgPath = require.resolve('@olonjs/core/package.json');
-const contractsUrl = pathToFileURL(corePkgPath.replace('package.json', 'src/lib/webmcp-contracts.mjs')).href;
+import { webmcp } from '@olonjs/core';
 
 const {
   buildPageContract,
@@ -1971,7 +1967,7 @@ const {
   buildPageManifestHref,
   buildSiteManifest,
   buildLlmsTxt,
-} = await import(contractsUrl);
+} = webmcp;
 
 const __dirname = path.dirname(fileURLToPath(import.meta.url));
 const root = path.resolve(__dirname, '..');
@@ -2055,7 +2051,9 @@ await build({
     },
   },
   ssr: {
-    noExternal: ['@olonjs/core'],
+    // SSG must be self-contained: the SSR artifact should not depend on
+    // runtime resolution of app/framework packages at bake time.
+    noExternal: true,
   },
 });
 console.log('[bake] SSR build done.');
@@ -2168,6 +2166,47 @@ for (const { slug, out, depth } of targets) {
 
 console.log('\n[bake] All pages baked. OK\n');
 
+END_OF_FILE_CONTENT
+echo "Creating scripts/generate-llms-txt.mjs..."
+cat << 'END_OF_FILE_CONTENT' > "scripts/generate-llms-txt.mjs"
+import fs from 'fs';
+import path from 'path';
+import { fileURLToPath } from 'url';
+import { webmcp } from '@olonjs/core';
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const rootDir = path.resolve(__dirname, '..');
+const { buildLlmsTxt } = webmcp;
+
+const pagesDir = path.join(rootDir, 'src', 'data', 'pages');
+const siteConfig = JSON.parse(fs.readFileSync(path.join(rootDir, 'src', 'data', 'config', 'site.json'), 'utf-8'));
+
+function listJsonFilesRecursive(dir) {
+  const items = fs.readdirSync(dir, { withFileTypes: true });
+  const files = [];
+  for (const item of items) {
+    const fullPath = path.join(dir, item.name);
+    if (item.isDirectory()) {
+      files.push(...listJsonFilesRecursive(fullPath));
+      continue;
+    }
+    if (item.isFile() && item.name.toLowerCase().endsWith('.json')) files.push(fullPath);
+  }
+  return files;
+}
+
+const pages = {};
+for (const fullPath of listJsonFilesRecursive(pagesDir)) {
+  const slug = path.relative(pagesDir, fullPath).replace(/\\/g, '/').replace(/\.json$/i, '');
+  pages[slug] = JSON.parse(fs.readFileSync(fullPath, 'utf-8'));
+}
+
+const llmsTxt = buildLlmsTxt({ pages, schemas: {}, siteConfig });
+
+const outPath = path.join(rootDir, 'public', 'llms.txt');
+fs.writeFileSync(outPath, llmsTxt, 'utf-8');
+console.log('[generate-llms-txt] Written -> public/llms.txt');
+
 END_OF_FILE_CONTENT
 echo "Creating scripts/sync-pages-to-public.mjs..."
 cat << 'END_OF_FILE_CONTENT' > "scripts/sync-pages-to-public.mjs"
@@ -2180,6 +2219,9 @@ const __dirname = path.dirname(__filename);
 const rootDir = path.resolve(__dirname, '..');
 const sourceDir = path.join(rootDir, 'src', 'data', 'pages');
 const targetDir = path.join(rootDir, 'public', 'pages');
+const sourceSiteConfigPath = path.join(rootDir, 'src', 'data', 'config', 'site.json');
+const targetConfigDir = path.join(rootDir, 'public', 'config');
+const targetSiteConfigPath = path.join(targetConfigDir, 'site.json');
 
 if (!fs.existsSync(sourceDir)) {
   console.warn('[sync-pages-to-public] Source directory not found:', sourceDir);
@@ -2190,7 +2232,12 @@ fs.rmSync(targetDir, { recursive: true, force: true });
 fs.mkdirSync(targetDir, { recursive: true });
 fs.cpSync(sourceDir, targetDir, { recursive: true });
 
-console.log('[sync-pages-to-public] Synced pages to public/pages');
+if (fs.existsSync(sourceSiteConfigPath)) {
+  fs.mkdirSync(targetConfigDir, { recursive: true });
+  fs.cpSync(sourceSiteConfigPath, targetSiteConfigPath);
+}
+
+console.log('[sync-pages-to-public] Synced pages to public/pages and site config to public/config/site.json');
 
 END_OF_FILE_CONTENT
 echo "Creating scripts/webmcp-feature-check.mjs..."
@@ -2494,615 +2541,6 @@ main().catch((error) => {
   process.exit(1);
 });
 
-END_OF_FILE_CONTENT
-mkdir -p "specs"
-echo "Creating specs/olonjsSpecs_V.1.3.md..."
-cat << 'END_OF_FILE_CONTENT' > "specs/olonjsSpecs_V.1.3.md"
-# 📐 OlonJS Architecture Specifications v1.3
-
-**Status:** Mandatory Standard  
-**Version:** 1.3.0 (Sovereign Core Edition — Architecture + Studio/ICE UX, Path-Deterministic Nested Editing)  
-**Target:** Senior Architects / AI Agents / Enterprise Governance  
-
-**Scope v1.3:** This edition preserves the complete v1.2 architecture (MTRP, JSP, TBP, CIP, ECIP, JAP + Studio/ICE UX contract: IDAC, TOCC, BSDS, ASC, JEB + Tenant Type & Code-Generation Annex) as a **faithful superset**, and adds strict path-based/nested-array behavior for Studio selection and Inspector expansion.  
-**Scope note (breaking):** In strict v1.3 Studio semantics, the legacy flat protocol (`itemField` / `itemId`) is removed in favor of `itemPath` (root-to-leaf path segments).
-
----
-
-## 1. 📐 Modular Type Registry Pattern (MTRP) v1.2
-
-**Objective:** Establish a strictly typed, open-ended protocol for extending content data structures where the **Core Engine** is the orchestrator and the **Tenant** is the provider.
-
-### 1.1 The Sovereign Dependency Inversion
-The **Core** defines the empty `SectionDataRegistry`. The **Tenant** "injects" its specific definitions using **Module Augmentation**. This allows the Core to be distributed as a compiled NPM package while remaining aware of Tenant-specific types at compile-time.
-
-### 1.2 Technical Implementation (`@olonjs/core/kernel`)
-```typescript
-export interface SectionDataRegistry {} // Augmented by Tenant
-export interface SectionSettingsRegistry {} // Augmented by Tenant
-
-export interface BaseSection<K extends keyof SectionDataRegistry> {
-  id: string;
-  type: K;
-  data: SectionDataRegistry[K];
-  settings?: K extends keyof SectionSettingsRegistry
-    ? SectionSettingsRegistry[K]
-    : BaseSectionSettings;
-}
-
-export type Section = {
-  [K in keyof SectionDataRegistry]: BaseSection<K>
-}[keyof SectionDataRegistry];
-```
-
-**SectionType:** Core exports (or Tenant infers) **`SectionType`** as **`keyof SectionDataRegistry`**. After Tenant module augmentation, this is the union of all section type keys (e.g. `'header' | 'footer' | 'hero' | ...`). The Tenant uses this type for the ComponentRegistry and SECTION_SCHEMAS keys.
-
-**Perché servono:** Il Core deve poter renderizzare section senza conoscere i tipi concreti a compile-time; il Tenant deve poter aggiungere nuovi tipi senza modificare il Core. I registry vuoti + module augmentation permettono di distribuire Core come pacchetto NPM e mantenere type-safety end-to-end (Section, registry, config). Senza MTRP, ogni nuovo tipo richiederebbe cambi nel Core o tipi deboli (`any`).
-
----
-
-## 2. 📐 JsonPages Site Protocol (JSP) v1.8
-
-**Objective:** Define the deterministic file system and the **Sovereign Projection Engine** (CLI).
-
-### 2.1 The File System Ontology (The Silo Contract)
-Every site must reside in an isolated directory. Global Governance is physically separated from Local Content.
-*   **`/config/site.json`** — Global Identity & Reserved System Blocks (Header/Footer). See Appendix A for typed shape.
-*   **`/config/menu.json`** — Navigation Tree (SSOT for System Header). See Appendix A.
-*   **`/config/theme.json`** — Theme tokens (optional but recommended). See Appendix A.
-*   **`/pages/[slug].json`** — Local Body Content per page. See Appendix A (PageConfig).
-
-**Application path convention:** The runtime app typically imports these via an alias (e.g. **`@/data/config/`** and **`@/data/pages/`**). The physical silo may be `src/data/config/` and `src/data/pages/` so that `site.json`, `menu.json`, `theme.json` live under `src/data/config/`, and page JSONs under `src/data/pages/`. The CLI or projection script may use `/config/` and `/pages/` at repo root; the **contract** is that the app receives **siteConfig**, **menuConfig**, **themeConfig**, and **pages** as defined in JEB (§10) and Appendix A.
-
-### 2.2 Deterministic Projection (CLI Workflow)
-The CLI (`@olonjs/cli`) creates new tenants by:
-1.  **Infra Projection:** Generating `package.json`, `tsconfig.json`, and `vite.config.ts` (The Shell).
-2.  **Source Projection:** Executing a deterministic script (`src_tenant_alpha.sh`) to reconstruct the `src` folder (The DNA).
-3.  **Dependency Resolution:** Enforcing specific versions of React, Radix, and Tailwind v4.
-
-**Perché servono:** Una struttura file deterministica (config vs pages) separa governance globale (site, menu, theme) dal contenuto per pagina; il CLI può rigenerare tenant e tooling può trovare dati e schemi sempre negli stessi path. Senza JSP, ogni tenant sarebbe una struttura ad hoc e ingestione/export/Bake sarebbero fragili.
-
----
-
-## 3. 🧱 Tenant Block Protocol (TBP) v1.0
-
-**Objective:** Standardize the "Capsule" structure for components to enable automated ingestion (Pull) by the SaaS.
-
-### 3.1 The Atomic Capsule Structure
-Components are self-contained directories under **`src/components/<sectionType>/`**:
-*   **`View.tsx`** — The pure React component (Dumb View). Props: see Appendix A (SectionComponentPropsMap).
-*   **`schema.ts`** — Zod schema(s) for the **data** contract (and optionally **settings**). Exports at least one schema (e.g. `HeroSchema`) used as the **data** schema for that type. Must extend BaseSectionData (§8) for data; array items must extend BaseArrayItem (§8).
-*   **`types.ts`** — TypeScript interfaces inferred from the schema (e.g. `HeroData`, `HeroSettings`). Export types with names **`<SectionType>Data`** and **`<SectionType>Settings`** (or equivalent) so the Tenant can aggregate them in a single types module.
-*   **`index.ts`** — Public API: re-exports View, schema(s), and types.
-
-### 3.2 Reserved System Types
-*   **`type: 'header'`** — Reserved for `site.json`. Receives **`menu: MenuItem[]`** in addition to `data` and `settings`. Menu is sourced from `menu.json` (see Appendix A). The Tenant **must** type `SectionComponentPropsMap['header']` as `{ data: HeaderData; settings?: HeaderSettings; menu: MenuItem[] }`.
-*   **`type: 'footer'`** — Reserved for `site.json`. Props: `{ data: FooterData; settings?: FooterSettings }` only (no `menu`).
-*   **`type: 'sectionHeader'`** — A standard local block. Must define its own `links` array in its local schema if used.
-
-**Perché servono:** La capsula (View + schema + types + index) è l’unità di estensione: il Core e il Form Factory possono scoprire tipi e contratti per tipo senza convenzioni ad hoc. Header/footer riservati evitano conflitti tra globale e locale. Senza TBP, aggregazione di SECTION_SCHEMAS e registry sarebbe incoerente e l’ingestion da SaaS non sarebbe automatizzabile.
-
----
-
-## 4. 🧱 Component Implementation Protocol (CIP) v1.5
-
-**Objective:** Ensure system-wide stability and Admin UI integrity.
-
-1.  **The "Sovereign View" Law:** Components receive `data` and `settings` (and `menu` for header only) and return JSX. They are metadata-blind (never import Zod schemas).
-2.  **Z-Index Neutrality:** Components must not use `z-index > 1`. Layout delegation (sticky/fixed) is managed by the `SectionRenderer`.
-3.  **Agnostic Asset Protocol:** Use `resolveAssetUrl(path, tenantId)` for all media. Resolved URLs are under **`/assets/...`** with no tenantId segment in the path (e.g. relative `img/hero.jpg` → `/assets/img/hero.jpg`).
-
-### 4.4 Local Design Tokens (v1.2)
-Section Views that control their own background, text, borders, or radii **shall** define a **local scope** via an inline `style` object on the section root: e.g. `--local-bg`, `--local-text`, `--local-text-muted`, `--local-surface`, `--local-border`, `--local-radius-lg`, `--local-accent`, mapped to theme variables. All Tailwind classes that affect color or radius in that section **must** use these variables (e.g. `bg-[var(--local-bg)]`, `text-[var(--local-text)]`). No naked utilities (e.g. `bg-blue-500`). An optional **`label`** in section data may be rendered with class **`jp-section-label`** for overlay type labels.
-
-### 4.5 Z-Index & Overlay Governance (v1.2)
-Section content root **must** stay at **`z-index` ≤ 1** (prefer `z-0`) so the Sovereign Overlay can sit above with high z-index in Tenant CSS (§7). Header/footer may use a higher z-index (e.g. 50) only as a documented exception for global chrome.
-
-**Perché servono (CIP):** View “dumb” (solo data/settings) e senza import di Zod evita accoppiamento e permette al Form Factory di essere l’unica fonte di verità sugli schemi. Z-index basso evita che il contenuto copra l’overlay di selezione in Studio. Asset via `resolveAssetUrl`: i path relativi vengono risolti in `/assets/...` (senza segmento tenantId nel path). Token locali (`--local-*`) rendono le section temabili e coerenti con overlay e tema; senza, stili “nudi” creano drift visivo e conflitti con l’UI di editing.
-
----
-
-## 5. 🛠️ Editor Component Implementation Protocol (ECIP) v1.5
-
-**Objective:** Standardize the Polymorphic ICE engine.
-
-1.  **Recursive Form Factory:** The Admin UI builds forms by traversing the Zod ontology.
-2.  **UI Metadata:** Use `.describe('ui:[widget]')` in schemas to pass instructions to the Form Factory.
-3.  **Deterministic IDs:** Every object in a `ZodArray` must extend `BaseArrayItem` (containing an `id`) to ensure React reconciliation stability during reordering.
-
-### 5.4 UI Metadata Vocabulary (v1.2)
-Standard keys for the Form Factory:
-
-| Key | Use case |
-|-----|----------|
-| `ui:text` | Single-line text input. |
-| `ui:textarea` | Multi-line text. |
-| `ui:select` | Enum / single choice. |
-| `ui:number` | Numeric input. |
-| `ui:list` | Array of items; list editor (add/remove/reorder). |
-| `ui:icon-picker` | Icon selection. |
-
-Unknown keys may be treated as `ui:text`. Array fields must use `BaseArrayItem` for items.
-
-### 5.5 Path-Only Nested Selection & Expansion (v1.3, breaking)
-In strict v1.3 Studio/Inspector behavior, nested editing targets are represented by **path segments from root to leaf**.
-
-```typescript
-export type SelectionPathSegment = { fieldKey: string; itemId?: string };
-export type SelectionPath = SelectionPathSegment[];
-```
-
-Rules:
-*   Expansion and focus for nested arrays **must** be computed from `SelectionPath` (root → leaf), not from a single flat pair.
-*   Matching by `fieldKey` alone is non-compliant for nested structures.
-*   Legacy flat payload fields **`itemField`** and **`itemId`** are removed from strict v1.3 selection protocol.
-
-**Perché servono (ECIP):** Il Form Factory deve sapere quale widget usare (text, textarea, select, list, …) senza hardcodare per tipo; `.describe('ui:...')` è il contratto. BaseArrayItem con `id` su ogni item di array garantisce chiavi stabili in React e reorder/delete corretti nell’Inspector. In v1.3 la selezione/espansione path-only elimina ambiguità su array annidati: senza path completo root→leaf, la sidebar può aprire il ramo sbagliato o non aprire il target.
-
----
-
-## 6. 🎯 ICE Data Attribute Contract (IDAC) v1.1
-
-**Objective:** Mandatory data attributes so the Stage (iframe) and Inspector can bind selection and field/item editing without coupling to Tenant DOM.
-
-### 6.1 Section-Level Markup (Core-Provided)
-**SectionRenderer** (Core) wraps each section root with:
-*   **`data-section-id`** — Section instance ID (e.g. UUID). On the wrapper that contains content + overlay.
-*   Sibling overlay element **`data-jp-section-overlay`** — Selection ring and type label. **Tenant does not add this;** Core injects it.
-
-Tenant Views render the **content** root only (e.g. `<section>` or `<div>`), placed **inside** the Core wrapper.
-
-### 6.2 Field-Level Binding (Tenant-Provided)
-For every **editable scalar field** the View **must** attach **`data-jp-field="<fieldKey>"`** (key matches schema path: e.g. `title`, `description`, `sectionTitle`, `label`).
-
-### 6.3 Array-Item Binding (Tenant-Provided)
-For every **editable array item** the View **must** attach:
-*   **`data-jp-item-id="<stableId>"`** — Prefer `item.id`; fallback e.g. `legacy-${index}` only outside strict mode.
-*   **`data-jp-item-field="<arrayKey>"`** — e.g. `cards`, `layers`, `products`, `paragraphs`.
-
-### 6.4 Compliance
-**Reserved types** (`header`, `footer`): ICE attributes optional unless Studio edits them. **All other section types** in the Stage and in `SECTION_SCHEMAS` **must** implement §6.2 and §6.3 for every editable field and array item.
-
-### 6.5 Strict Path Extraction for Nested Arrays (v1.3, breaking)
-For nested array targets, the Core/Inspector contract is path-based:
-*   The runtime selection target is expressed as `itemPath: SelectionPath` (root → leaf).
-*   Flat identity (`itemField` + `itemId`) is not sufficient for nested structures and is removed in strict v1.3 payloads.
-*   In strict mode, index-based identity fallback is non-compliant for editable object arrays.
-
-**Perché servono (IDAC):** Lo Stage è in un iframe e l’Inspector deve sapere **quale campo o item** corrisponde al click (o alla selezione) senza conoscere la struttura DOM del Tenant. **`data-jp-field`** associa un nodo DOM al path dello schema (es. `title`, `description`): così il Core può evidenziare la riga giusta nella sidebar, applicare opacità attivo/inattivo e aprire il form sul campo corretto. **`data-jp-item-id`** e **`data-jp-item-field`** fanno lo stesso per gli item di array (liste, reorder, delete). In v1.3, `itemPath` rende deterministico anche il caso nested (array dentro array), eliminando mismatch tra selezione canvas e ramo aperto in sidebar.
-
----
-
-## 7. 🎨 Tenant Overlay CSS Contract (TOCC) v1.0
-
-**Objective:** The Stage iframe loads only Tenant HTML/CSS. Core injects overlay **markup** but does **not** ship overlay styles. The Tenant **must** supply CSS so overlay is visible.
-
-### 7.1 Required Selectors (Tenant global CSS)
-1. **`[data-jp-section-overlay]`** — `position: absolute; inset: 0`; `pointer-events: none`; base state transparent.
-2. **`[data-section-id]:hover [data-jp-section-overlay]`** — Hover: e.g. dashed border, subtle tint.
-3. **`[data-section-id][data-jp-selected] [data-jp-section-overlay]`** — Selected: solid border, optional tint.
-4. **`[data-jp-section-overlay] > div`** (type label) — Position and visibility (e.g. visible on hover/selected).
-
-### 7.2 Z-Index
-Overlay **z-index** high (e.g. 9999). Section content at or below CIP limit (§4.5).
-
-### 7.3 Responsibility
-**Core:** Injects wrapper and overlay DOM; sets `data-jp-selected`. **Tenant:** All overlay **visual** rules.
-
-**Perché servono (TOCC):** L’iframe dello Stage carica solo HTML/CSS del Tenant; il Core inietta il markup dell’overlay ma non gli stili. Senza CSS Tenant per i selettori TOCC, bordo hover/selected e type label non sarebbero visibili: l’autore non vedrebbe quale section è selezionata né il label del tipo. TOCC chiarisce la responsabilità (Core = markup, Tenant = aspetto) e garantisce UX uniforme tra tenant.
-
----
-
-## 8. 📦 Base Section Data & Settings (BSDS) v1.0
-
-**Objective:** Standardize base schema fragments for anchors, array items, and section settings.
-
-### 8.1 BaseSectionData
-Every section data schema **must** extend a base with at least **`anchorId`** (optional string). Canonical Zod (Tenant `lib/base-schemas.ts` or equivalent):
-
-```typescript
-export const BaseSectionData = z.object({
-  anchorId: z.string().optional().describe('ui:text'),
-});
-```
-
-### 8.2 BaseArrayItem
-Every array item schema editable in the Inspector **must** include **`id`** (optional string minimum). Canonical Zod:
-
-```typescript
-export const BaseArrayItem = z.object({
-  id: z.string().optional(),
-});
-```
-
-Recommended: required UUID for new items. Used by `data-jp-item-id` and React reconciliation.
-
-### 8.3 BaseSectionSettings (Optional)
-Common section-level settings. Canonical Zod (name **BaseSectionSettingsSchema** or as exported by Core):
-
-```typescript
-export const BaseSectionSettingsSchema = z.object({
-  paddingTop: z.enum(['none', 'sm', 'md', 'lg', 'xl', '2xl']).default('md').describe('ui:select'),
-  paddingBottom: z.enum(['none', 'sm', 'md', 'lg', 'xl', '2xl']).default('md').describe('ui:select'),
-  theme: z.enum(['dark', 'light', 'accent']).default('dark').describe('ui:select'),
-  container: z.enum(['boxed', 'fluid']).default('boxed').describe('ui:select'),
-});
-```
-
-Capsules may extend this for type-specific settings. Core may export **BaseSectionSettings** as the TypeScript type inferred from this or a superset.
-
-**Perché servono (BSDS):** anchorId permette deep-link e navigazione in-page; id sugli array item è necessario per `data-jp-item-id`, reorder e React reconciliation. BaseSectionSettings comuni (padding, theme, container) evitano ripetizione e allineano il Form Factory tra capsule. Senza base condivisi, ogni capsule inventa convenzioni e validazione/add-section diventano fragili.
-
----
-
-## 9. 📌 AddSectionConfig (ASC) v1.0
-
-**Objective:** Formalize the "Add Section" contract used by the Studio.
-
-**Type (Core exports `AddSectionConfig`):**
-```typescript
-interface AddSectionConfig {
-  addableSectionTypes: readonly string[];
-  sectionTypeLabels: Record<string, string>;
-  getDefaultSectionData(sectionType: string): Record<string, unknown>;
-}
-```
-
-**Shape:** Tenant provides one object (e.g. `addSectionConfig`) with:
-*   **`addableSectionTypes`** — Readonly array of section type keys. Only these types appear in the Add Section Library. Must be a subset of (or equal to) the keys in SectionDataRegistry.
-*   **`sectionTypeLabels`** — Map type key → display string (e.g. `{ hero: 'Hero', 'cta-banner': 'CTA Banner' }`).
-*   **`getDefaultSectionData(sectionType: string): Record<string, unknown>`** — Returns default `data` for a new section. Must conform to the capsule’s data schema so the new section validates.
-
-Core creates a new section with deterministic UUID, `type`, and `data` from `getDefaultSectionData(type)`.
-
-**Perché servono (ASC):** Lo Studio deve mostrare una libreria “Aggiungi sezione” con nomi leggibili e, alla scelta, creare una section con dati iniziali validi. addableSectionTypes, sectionTypeLabels e getDefaultSectionData sono il contratto: il Tenant è l’unica fonte di verità su quali tipi sono addabili e con quali default. Senza ASC, il Core non saprebbe cosa mostrare in modal né come popolare i dati della nuova section.
-
----
-
-## 10. ⚙️ JsonPagesConfig & Engine Bootstrap (JEB) v1.1
-
-**Objective:** Bootstrap contract between Tenant app and `@olonjs/core`.
-
-### 10.1 JsonPagesConfig (required fields)
-The Tenant passes a single **config** object to **JsonPagesEngine**. Required fields:
-
-| Field | Type | Description |
-|-------|------|-------------|
-| **tenantId** | string | Passed to `resolveAssetUrl(path, tenantId)`; resolved asset URLs are **`/assets/...`** with no tenantId segment in the path. |
-| **registry** | `{ [K in SectionType]: React.FC<SectionComponentPropsMap[K]> }` | Component registry. Must match MTRP keys. See Appendix A. |
-| **schemas** | `Record<SectionType, ZodType>` or equivalent | SECTION_SCHEMAS: type → **data** Zod schema. Form Factory uses this. See Appendix A. |
-| **pages** | `Record<string, PageConfig>` | Slug → page config. See Appendix A. |
-| **siteConfig** | SiteConfig | Global site (identity, header/footer blocks). See Appendix A. |
-| **themeConfig** | ThemeConfig | Theme tokens. See Appendix A. |
-| **menuConfig** | MenuConfig | Navigation tree (SSOT for header menu). See Appendix A. |
-| **themeCss** | `{ tenant: string }` | At least **tenant**: string (inline CSS or URL) for Stage iframe injection. |
-| **addSection** | AddSectionConfig | Add-section config (§9). |
-
-Core may define optional fields. The Tenant must not omit required fields.
-
-### 10.2 JsonPagesEngine
-Root component: **`<JsonPagesEngine config={config} />`**. Responsibilities: route → page, SectionRenderer per section; in Studio mode Sovereign Shell (Inspector, Control Bar, postMessage); section wrappers and overlay per IDAC and JAP. Tenant does not implement the Shell.
-
-### 10.3 Studio Selection Event Contract (v1.3, breaking)
-In strict v1.3 Studio, section selection payload for nested targets is path-based:
-
-```typescript
-type SectionSelectMessage = {
-  type: 'SECTION_SELECT';
-  section: { id: string; type: string; scope: 'global' | 'local' };
-  itemPath?: SelectionPath; // root -> leaf
-};
-```
-
-Removed from strict protocol:
-*   `itemField`
-*   `itemId`
-
-**Perché servono (JEB):** Un unico punto di bootstrap (config + Engine) evita che il Tenant replichi logica di routing, Shell e overlay. I campi obbligatori in JsonPagesConfig (tenantId, registry, schemas, pages, siteConfig, themeConfig, menuConfig, themeCss, addSection) sono il minimo per far funzionare rendering, Studio e Form Factory; omissioni causano errori a runtime. In v1.3, il payload `itemPath` sincronizza in modo non ambiguo Stage e Inspector su nested arrays.
-
----
-
-# 🏛️ OlonJS_ADMIN_PROTOCOL (JAP) v1.2
-
-**Status:** Mandatory Standard  
-**Version:** 1.2.0 (Sovereign Shell Edition — Path/Nested Strictness)  
-**Objective:** Deterministic orchestration of the "Studio" environment (ICE Level 1).
-
----
-
-## 1. The Sovereign Shell Topology
-The Admin interface is a **Sovereign Shell** from `@olonjs/core`.
-1.  **The Stage (Canvas):** Isolated Iframe; postMessage for data updates and selection mirroring. Section markup follows **IDAC** (§6); overlay styling follows **TOCC** (§7).
-2.  **The Inspector (Sidebar):** Consumes Tenant Zod schemas to generate editors; binding via `data-jp-field` and `data-jp-item-*`.
-3.  **The Studio Actions:** Save to file, Hot Save, Add Section.
-
-## 2. State Orchestration & Persistence
-*   **Working Draft:** Reactive local state for unsaved changes.
-*   **Sync Law:** Inspector changes → Working Draft → Stage via `STUDIO_EVENTS.UPDATE_DRAFTS`.
-*   **Persistence Protocol:** Studio invokes tenant-provided `saveToFile` and `hotSave` callbacks for editorial persistence.
-
-## 3. Context Switching (Global vs. Local)
-*   **Header/Footer** selection → Global Mode, `site.json`.
-*   Any other section → Page Mode, current `[slug].json`.
-
-## 4. Section Lifecycle Management
-1.  **Add Section:** Modal from Tenant `SECTION_SCHEMAS`; UUID + default data via **AddSectionConfig** (§9).
-2.  **Reorder:** Inspector or Stage Overlay; array mutation in Working Draft.
-3.  **Delete:** Confirmation; remove from array, clear selection.
-
-## 5. Stage Isolation & Overlay
-*   **CSS Shielding:** Stage in Iframe; Tenant CSS does not leak into Admin.
-*   **Sovereign Overlay:** Selection ring and type labels injected per **IDAC** (§6); Tenant styles them per **TOCC** (§7).
-
-## 6. "Green Build" Validation
-Studio enforces `tsc && vite build`. No Studio or SSG build should proceed with TypeScript errors.
-
-## 7. Path-Deterministic Selection & Sidebar Expansion (v1.3, breaking)
-*   Section/item focus synchronization uses `itemPath` (root → leaf), not flat `itemField/itemId`.
-*   Sidebar expansion state for nested arrays must be derived from all path segments.
-*   Flat-only matching may open/close wrong branches and is non-compliant in strict mode.
-
-**Perché servono (JAP):** Stage in iframe + Inspector + Studio actions separano il contesto di editing dal sito; postMessage e Working Draft permettono modifiche senza toccare subito i file. Save to file e Hot Save richiedono uno stato coerente. Global vs Page mode evita confusione su dove si sta editando (site.json vs [slug].json). Add/Reorder/Delete sono gestiti in un solo modo (Working Draft + ASC). Green Build garantisce che Studio e SSG compilino correttamente. In v1.3, il path completo elimina ambiguità nella sincronizzazione Stage↔Sidebar su strutture annidate.
-
----
-
-## Compliance: Legacy vs Full UX (v1.3)
-
-| Dimension | Legacy / Less UX | Full UX (Core-aligned) |
-|-----------|-------------------|-------------------------|
-| **ICE binding** | No `data-jp-*`; Inspector cannot bind. | IDAC (§6) on every editable section/field/item. |
-| **Section wrapper** | Plain `<section>`; no overlay contract. | Core wrapper + overlay; Tenant CSS per TOCC (§7). |
-| **Design tokens** | Raw BEM / fixed classes. | Local tokens (§4.4); `var(--local-*)` only. |
-| **Base schemas** | Ad hoc. | BSDS (§8): BaseSectionData, BaseArrayItem, BaseSectionSettings. |
-| **Add Section** | Ad hoc defaults. | ASC (§9): addableSectionTypes, labels, getDefaultSectionData. |
-| **Bootstrap** | Implicit. | JEB (§10): JsonPagesConfig + JsonPagesEngine. |
-| **Selection payload** | Flat `itemField/itemId`. | Path-only `itemPath: SelectionPath` (JEB §10.3). |
-| **Nested array expansion** | Single-segment or field-only heuristics. | Root-to-leaf path expansion (ECIP §5.5, JAP §7). |
-| **Array item identity (strict)** | Index fallback tolerated. | Stable `id` required for editable object arrays. |
-
-**Rule:** Every page section (non-header/footer) that appears in the Stage and in `SECTION_SCHEMAS` must comply with §6, §7, §4.4, §8, §9, §10 for full Studio UX.
-
----
-
-## Summary of v1.3 Additions
-
-| § | Title | Purpose |
-|---|--------|--------|
-| 5.5 | Path-Only Nested Selection & Expansion | ECIP: root→leaf `SelectionPath`; remove flat matching in strict mode. |
-| 6.5 | Strict Path Extraction for Nested Arrays | IDAC: path-based nested targeting; no strict flat fallback. |
-| 10.3 | Studio Selection Event Contract | JEB: `SECTION_SELECT` uses `itemPath`; remove `itemField/itemId`. |
-| JAP §7 | Path-Deterministic Selection & Sidebar Expansion | Studio state synchronization for nested arrays. |
-| Compliance | Legacy vs Full UX (v1.3) | Explicit breaking delta for flat protocol removal and strict IDs. |
-| **Appendix A.6** | **v1.3 Path/Nested Strictness Addendum** | Type/export and migration checklist for path-only protocol. |
-
----
-
-# Appendix A — Tenant Type & Code-Generation Annex
-
-**Objective:** Make the specification **sufficient** to generate or audit a full tenant (new site, new components, new data) without a reference codebase. Defines TypeScript types, JSON shapes, schema contract, file paths, and integration pattern.
-
-**Status:** Mandatory for code-generation and governance. Compliance ensures generated tenants are typed and wired like the reference implementation.
-
----
-
-## A.1 Core-Provided Types (from `@olonjs/core`)
-
-The following are assumed to be exported by Core. The Tenant augments **SectionDataRegistry** and **SectionSettingsRegistry**; all other types are consumed as-is.
-
-| Type | Description |
-|------|-------------|
-| **SectionType** | `keyof SectionDataRegistry` (after Tenant augmentation). Union of all section type keys. |
-| **Section** | Union of `BaseSection<K>` for all K in SectionDataRegistry. See MTRP §1.2. |
-| **BaseSectionSettings** | Optional base type for section settings (may align with BSDS §8.3). |
-| **MenuItem** | Navigation item. **Minimum shape:** `{ label: string; href: string }`. Core may extend (e.g. `children?: MenuItem[]`). |
-| **AddSectionConfig** | See §9. |
-| **JsonPagesConfig** | See §10.1. |
-
-**Perché servono (A.1):** Il Tenant deve conoscere i tipi esportati dal Core (SectionType, MenuItem, AddSectionConfig, JsonPagesConfig) per tipizzare registry, config e augmentation senza dipendere da implementazioni interne.
-
----
-
-## A.2 Tenant-Provided Types (single source: `src/types.ts` or equivalent)
-
-The Tenant **must** define the following in one module (e.g. **`src/types.ts`**). This module **must** perform the **module augmentation** of `@olonjs/core` for **SectionDataRegistry** and **SectionSettingsRegistry**, and **must** export **SectionComponentPropsMap** and re-export from `@olonjs/core` so that **SectionType** is available after augmentation.
-
-### A.2.1 SectionComponentPropsMap
-
-Maps each section type to the props of its React component. **Header** is the only type that receives **menu**.
-
-**Option A — Explicit (recommended for clarity and tooling):** For each section type K, add one entry. Header receives **menu**.
-
-```typescript
-import type { MenuItem } from '@olonjs/core';
-// Import Data/Settings from each capsule.
-
-export type SectionComponentPropsMap = {
-  'header': { data: HeaderData; settings?: HeaderSettings; menu: MenuItem[] };
-  'footer': { data: FooterData; settings?: FooterSettings };
-  'hero': { data: HeroData; settings?: HeroSettings };
-  // ... one entry per SectionType, e.g. 'feature-grid', 'cta-banner', etc.
-};
-```
-
-**Option B — Mapped type (DRY, requires SectionDataRegistry/SectionSettingsRegistry in scope):**
-
-```typescript
-import type { MenuItem } from '@olonjs/core';
-
-export type SectionComponentPropsMap = {
-  [K in SectionType]: K extends 'header'
-    ? { data: SectionDataRegistry[K]; settings?: SectionSettingsRegistry[K]; menu: MenuItem[] }
-    : { data: SectionDataRegistry[K]; settings?: K extends keyof SectionSettingsRegistry ? SectionSettingsRegistry[K] : BaseSectionSettings };
-};
-```
-
-SectionType is imported from Core (after Tenant augmentation). In practice Option A is the reference pattern; Option B is valid if the Tenant prefers a single derived definition.
-
-**Perché servono (A.2):** SectionComponentPropsMap e i tipi di config (PageConfig, SiteConfig, MenuConfig, ThemeConfig) definiscono il contratto tra dati (JSON, API) e componente; l’augmentation è l’unico modo per estendere i registry del Core senza fork. Senza questi tipi, generazione tenant e refactor sarebbero senza guida e il type-check fallirebbe.
-
-### A.2.2 ComponentRegistry type
-
-The registry object **must** be typed as:
-
-```typescript
-import type { SectionType } from '@olonjs/core';
-import type { SectionComponentPropsMap } from '@/types';
-
-export const ComponentRegistry: {
-  [K in SectionType]: React.FC<SectionComponentPropsMap[K]>;
-} = { /* ... */ };
-```
-
-File: **`src/lib/ComponentRegistry.tsx`** (or equivalent). Imports one View per section type and assigns it to the corresponding key.
-
-### A.2.3 PageConfig
-
-Minimum shape for a single page (used in **pages** and in each **`[slug].json`**):
-
-```typescript
-export interface PageConfig {
-  id?: string;
-  slug: string;
-  meta?: {
-    title?: string;
-    description?: string;
-  };
-  sections: Section[];
-}
-```
-
-**Section** is the union type from MTRP (§1.2). Each element of **sections** has **id**, **type**, **data**, **settings** and conforms to the capsule schemas.
-
-### A.2.4 SiteConfig
-
-Minimum shape for **site.json** (and for **siteConfig** in JsonPagesConfig):
-
-```typescript
-export interface SiteConfigIdentity {
-  title?: string;
-  logoUrl?: string;
-}
-
-export interface SiteConfig {
-  identity?: SiteConfigIdentity;
-  pages?: Array<{ slug: string; label: string }>;
-  header: {
-    id: string;
-    type: 'header';
-    data: HeaderData;
-    settings?: HeaderSettings;
-  };
-  footer: {
-    id: string;
-    type: 'footer';
-    data: FooterData;
-    settings?: FooterSettings;
-  };
-}
-```
-
-**HeaderData**, **FooterData**, **HeaderSettings**, **FooterSettings** are the types exported from the header and footer capsules.
-
-### A.2.5 MenuConfig
-
-Minimum shape for **menu.json** (and for **menuConfig** in JsonPagesConfig). Structure is tenant-defined; Core expects the header to receive **MenuItem[]**. Common pattern: an object with a key (e.g. **main**) whose value is **MenuItem[]**.
-
-```typescript
-export interface MenuConfig {
-  main?: MenuItem[];
-  [key: string]: MenuItem[] | undefined;
-}
-```
-
-Or simply **`MenuItem[]`** if the app uses a single flat list. The Tenant must ensure that the value passed to the header component as **menu** conforms to **MenuItem[]** (e.g. `menuConfig.main` or `menuConfig` if it is the array).
-
-### A.2.6 ThemeConfig
-
-Minimum shape for **theme.json** (and for **themeConfig** in JsonPagesConfig). Tenant-defined; typically tokens for colors, typography, radius.
-
-```typescript
-export interface ThemeConfig {
-  name?: string;
-  tokens?: {
-    colors?: Record<string, string>;
-    typography?: Record<string, string | Record<string, string>>;
-    borderRadius?: Record<string, string>;
-  };
-  [key: string]: unknown;
-}
-```
-
----
-
-## A.3 Schema Contract (SECTION_SCHEMAS)
-
-**Location:** **`src/lib/schemas.ts`** (or equivalent).
-
-**Contract:**
-*   **SECTION_SCHEMAS** is a **single object** whose keys are **SectionType** and whose values are **Zod schemas for the section data** (not settings, unless the Form Factory contract expects a combined or per-type settings schema; then each value may be the data schema only, and settings may be defined per capsule and aggregated elsewhere if needed).
-*   The Tenant **must** re-export **BaseSectionData**, **BaseArrayItem**, and optionally **BaseSectionSettingsSchema** from **`src/lib/base-schemas.ts`** (or equivalent). Each capsule’s data schema **must** extend BaseSectionData; each array item schema **must** extend or include BaseArrayItem.
-*   **SECTION_SCHEMAS** is typed as **`Record<SectionType, ZodType>`** or **`{ [K in SectionType]: ZodType }`** so that keys match the registry and SectionDataRegistry.
-
-**Export:** The app imports **SECTION_SCHEMAS** and passes it as **config.schemas** to JsonPagesEngine. The Form Factory traverses these schemas to build editors.
-
-**Perché servono (A.3):** Un unico oggetto SECTION_SCHEMAS con chiavi = SectionType e valori = schema data permette al Form Factory di costruire form per tipo senza convenzioni ad hoc; i base schema garantiscono anchorId e id su item. Senza questo contratto, l’Inspector non saprebbe quali campi mostrare né come validare.
-
----
-
-## A.4 File Paths & Data Layout
-
-| Purpose | Path (conventional) | Description |
-|---------|---------------------|-------------|
-| Site config | **`src/data/config/site.json`** | SiteConfig (identity, header, footer, pages list). |
-| Menu config | **`src/data/config/menu.json`** | MenuConfig (e.g. main nav). |
-| Theme config | **`src/data/config/theme.json`** | ThemeConfig (tokens). |
-| Page data | **`src/data/pages/<slug>.json`** | One file per page; content is PageConfig (slug, meta, sections). |
-| Base schemas | **`src/lib/base-schemas.ts`** | BaseSectionData, BaseArrayItem, BaseSectionSettingsSchema. |
-| Schema aggregate | **`src/lib/schemas.ts`** | SECTION_SCHEMAS; re-exports base schemas. |
-| Registry | **`src/lib/ComponentRegistry.tsx`** | ComponentRegistry object. |
-| Add-section config | **`src/lib/addSectionConfig.ts`** | addSectionConfig (AddSectionConfig). |
-| Tenant types & augmentation | **`src/types.ts`** | SectionComponentPropsMap, PageConfig, SiteConfig, MenuConfig, ThemeConfig; **declare module '@olonjs/core'** for SectionDataRegistry and SectionSettingsRegistry; re-export from Core. |
-| Bootstrap | **`src/App.tsx`** | Imports config (site, theme, menu, pages), registry, schemas, addSection, themeCss; builds JsonPagesConfig; renders **<JsonPagesEngine config={config} />**. |
-
-The app entry (e.g. **main.tsx**) renders **App**. No other bootstrap contract is specified; the Tenant may use Vite aliases (e.g. **@/**) for the paths above.
-
-**Perché servono (A.4):** Path fissi (data/config, data/pages, lib/schemas, types.ts, App.tsx) permettono a CLI, tooling e agenti di trovare sempre gli stessi file; l’onboarding e la generazione da spec sono deterministici. Senza convenzione, ogni tenant sarebbe una struttura diversa.
-
----
-
-## A.5 Integration Checklist (Code-Generation)
-
-When generating or auditing a tenant, ensure the following in order:
-
-1. **Capsules** — For each section type, create **`src/components/<type>/`** with View.tsx, schema.ts, types.ts, index.ts. Data schema extends BaseSectionData; array items extend BaseArrayItem; View complies with CIP and IDAC (§6.2–6.3 for non-reserved types).
-2. **Base schemas** — **src/lib/base-schemas.ts** exports BaseSectionData, BaseArrayItem, BaseSectionSettingsSchema (and optional CtaSchema or similar shared fragments).
-3. **types.ts** — Define SectionComponentPropsMap (header with **menu**), PageConfig, SiteConfig, MenuConfig, ThemeConfig; **declare module '@olonjs/core'** and augment SectionDataRegistry and SectionSettingsRegistry; re-export from `@olonjs/core`.
-4. **ComponentRegistry** — Import every View; build object **{ [K in SectionType]: ViewComponent }**; type as **{ [K in SectionType]: React.FC<SectionComponentPropsMap[K]> }**.
-5. **schemas.ts** — Import base schemas and each capsule’s data schema; export SECTION_SCHEMAS as **{ [K in SectionType]: SchemaK }**; export SectionType as **keyof typeof SECTION_SCHEMAS** if not using Core’s SectionType.
-6. **addSectionConfig** — addableSectionTypes, sectionTypeLabels, getDefaultSectionData; export as AddSectionConfig.
-7. **App.tsx** — Import site, theme, menu, pages from data paths; build config (tenantId, registry, schemas, pages, siteConfig, themeConfig, menuConfig, themeCss: { tenant }, addSection); render JsonPagesEngine.
-8. **Data files** — Create or update site.json, menu.json, theme.json, and one or more **<slug>.json** under the paths in A.4. Ensure JSON shapes match SiteConfig, MenuConfig, ThemeConfig, PageConfig.
-9. **Tenant CSS** — Include TOCC (§7) selectors in global CSS so the Stage overlay is visible.
-10. **Reserved types** — Header and footer capsules receive props per SectionComponentPropsMap; menu is populated from menuConfig (e.g. menuConfig.main) when building the config or inside Core when rendering the header.
-
-**Perché servono (A.5):** La checklist in ordine evita di dimenticare passi (es. augmentation prima del registry, TOCC dopo le View) e rende la spec sufficiente per generare o verificare un tenant senza codebase di riferimento.
-
----
-
-## A.6 v1.3 Path/Nested Strictness Addendum (breaking)
-
-This addendum extends Appendix A without removing prior v1.2 obligations:
-
-1. **Type exports** — Core and/or shared types module should expose `SelectionPathSegment` and `SelectionPath` for Studio messaging and Inspector expansion logic.
-2. **Protocol migration** — Replace flat payload fields `itemField` / `itemId` with `itemPath?: SelectionPath` in strict v1.3 channels.
-3. **Nested array compliance** — For editable object arrays, item identity must be stable (`id`) and propagated to DOM attributes (`data-jp-item-id`), schema items (BaseArrayItem), and selection path segments (`itemId` when segment targets array item).
-4. **Backward compatibility policy** — Legacy flat fields may exist only in transitional adapters outside strict mode; normative v1.3 contract is path-only.
-
----
-
-**Validation:** Align with current `@olonjs/core` exports (SectionType, MenuItem, AddSectionConfig, JsonPagesConfig, and in v1.3 path types for Studio selection).  
-**Distribution:** Core via `.yalc`; tenant projections via `@olonjs/cli`. This annex makes the spec **necessary and sufficient** for tenant code-generation and governance at enterprise grade.
-
 END_OF_FILE_CONTENT
 mkdir -p "src"
 echo "Creating src/App.tsx..."
@@ -3138,6 +2576,7 @@ const CLOUD_API_URL =
   import.meta.env.VITE_OLONJS_CLOUD_URL ?? import.meta.env.VITE_JSONPAGES_CLOUD_URL;
 const CLOUD_API_KEY =
   import.meta.env.VITE_OLONJS_API_KEY ?? import.meta.env.VITE_JSONPAGES_API_KEY;
+const SAVE2REPO_ENABLED = import.meta.env.VITE_SAVE2REPO === 'true';
 
 const themeConfig = themeData as unknown as ThemeConfig;
 const menuConfig: MenuConfig = { main: [] };
@@ -3404,6 +2843,45 @@ function normalizeSlugForCache(slug: string): string {
   );
 }
 
+function buildPublishedPageHref(slug: string): string {
+  return `/pages/${normalizeSlugForCache(slug)}.json`;
+}
+
+async function loadPublishedStaticContent(
+  knownSlugs: string[]
+): Promise<{ pages: Record<string, PageConfig>; siteConfig: SiteConfig }> {
+  const siteResponse = await fetch('/config/site.json', { cache: 'no-store' });
+  if (!siteResponse.ok) {
+    throw new Error(`Static site config unavailable: ${siteResponse.status}`);
+  }
+
+  const sitePayload = (await siteResponse.json().catch(() => null)) as unknown;
+  const nextSite = coerceSiteConfig(sitePayload);
+  if (!nextSite) {
+    throw new Error('Static site config is invalid.');
+  }
+
+  const pageEntries = await Promise.all(
+    knownSlugs.map(async (slug) => {
+      const response = await fetch(buildPublishedPageHref(slug), { cache: 'no-store' });
+      if (!response.ok) {
+        throw new Error(`Static page unavailable for slug "${slug}": ${response.status}`);
+      }
+      return [slug, (await response.json().catch(() => null)) as unknown] as const;
+    })
+  );
+
+  const nextPages = normalizePageRegistry(Object.fromEntries(pageEntries));
+  if (Object.keys(nextPages).length === 0) {
+    throw new Error('Static published pages are empty.');
+  }
+
+  return {
+    pages: nextPages,
+    siteConfig: nextSite,
+  };
+}
+
 function readCachedCloudContent(fingerprint: string): CachedCloudContent | null {
   try {
     const raw = localStorage.getItem(CLOUD_CACHE_KEY);
@@ -3447,6 +2925,8 @@ function setTenantPreviewReady(ready: boolean): void {
 
 function App() {
   const isCloudMode = Boolean(CLOUD_API_URL && CLOUD_API_KEY);
+  const isSave2RepoMode = isCloudMode && SAVE2REPO_ENABLED;
+  const isHotSaveMode = isCloudMode && !isSave2RepoMode;
   const localInitialData = useMemo(() => (isCloudMode ? null : getInitialData()), [isCloudMode]);
   const localInitialPages = useMemo(() => {
     if (!localInitialData) return {};
@@ -3528,6 +3008,54 @@ function App() {
       logBootstrapEvent('boot.local.ready', { mode: 'local' });
       return;
     }
+
+    if (isSave2RepoMode) {
+      if (contentLoadInFlight.current) {
+        return;
+      }
+
+      setContentMode('cloud');
+      setContentFallback(null);
+      setShowTopProgress(true);
+      setHasInitialCloudResolved(false);
+      logBootstrapEvent('boot.start', { mode: 'save2repo-static', pageCount: Object.keys(filePages).length });
+
+      let inFlight: Promise<void> | null = null;
+      inFlight = loadPublishedStaticContent(Object.keys(filePages))
+        .then(({ pages: nextPages, siteConfig: nextSite }) => {
+          setPages(nextPages);
+          setSiteConfig(nextSite);
+          setContentMode('cloud');
+          setContentFallback(null);
+          setHasInitialCloudResolved(true);
+          logBootstrapEvent('boot.save2repo.success', {
+            mode: 'save2repo-static',
+            pageCount: Object.keys(nextPages).length,
+          });
+        })
+        .catch((error: unknown) => {
+          const failure = toCloudLoadFailure(error);
+          setContentMode('error');
+          setContentFallback(failure);
+          setHasInitialCloudResolved(true);
+          logBootstrapEvent('boot.save2repo.error', {
+            mode: 'save2repo-static',
+            reasonCode: failure.reasonCode,
+            correlationId: failure.correlationId ?? null,
+          });
+        })
+        .finally(() => {
+          setShowTopProgress(false);
+          if (contentLoadInFlight.current === inFlight) {
+            contentLoadInFlight.current = null;
+          }
+        });
+      contentLoadInFlight.current = inFlight;
+      return () => {
+        contentLoadInFlight.current = null;
+      };
+    }
+
     if (contentLoadInFlight.current) {
       return;
     }
@@ -3700,7 +3228,7 @@ function App() {
     });
     contentLoadInFlight.current = inFlight;
     return () => controller.abort();
-  }, [isCloudMode, CLOUD_API_KEY, CLOUD_API_URL, cloudApiCandidates, bootstrapRunId]);
+  }, [isCloudMode, isSave2RepoMode, CLOUD_API_KEY, CLOUD_API_URL, cloudApiCandidates, bootstrapRunId]);
 
   const runCloudSave = useCallback(
     async (
@@ -3862,8 +3390,12 @@ function App() {
           },
         });
       },
-      showLegacySave: !isCloudMode,
-      showHotSave: isCloudMode,
+      async coldSave(state: ProjectState, slug: string): Promise<void> {
+        await runCloudSave({ state, slug }, true);
+      },
+      showLocalSave: !isCloudMode,
+      showHotSave: isHotSaveMode,
+      showColdSave: isSave2RepoMode,
     },
     assets: {
       assetsBaseUrl: '/assets',
@@ -4093,7 +3625,6 @@ function App() {
 
 export default App;
 
-
 END_OF_FILE_CONTENT
 mkdir -p "src/components"
 echo "Creating src/components/NotFound.tsx..."
@@ -11548,8 +11079,8 @@ cat << 'END_OF_FILE_CONTENT' > "src/data/pages/home.json"
           "href": "#architecture"
         },
         "image": {
-          "url": "/assets/images/plug-graded-square.jpg",
-          "alt": "Olon interface port engraved into a dark stone surface"
+          "url": "/assets/images/1775421583171-Screenshot_2026-04-05_at_20-08-49_OlonJS_MCP___LinkedIn_Cover.png",
+          "alt": "1775421583171-Screenshot_2026-04-05_at_20-08-49_OlonJS_MCP___LinkedIn_Cover.png"
         }
       }
     },
@@ -11726,7 +11257,6 @@ cat << 'END_OF_FILE_CONTENT' > "src/data/pages/home.json"
     }
   ]
 }
-
 END_OF_FILE_CONTENT
 echo "Creating src/data/pages/home_.json..."
 cat << 'END_OF_FILE_CONTENT' > "src/data/pages/home_.json"
@@ -14010,7 +13540,6 @@ ReactDOM.createRoot(document.getElementById('root')!).render(
 
 
 END_OF_FILE_CONTENT
-# SKIP: src/registry-types.ts is binary and cannot be embedded as text.
 mkdir -p "src/types"
 echo "Creating src/types.ts..."
 cat << 'END_OF_FILE_CONTENT' > "src/types.ts"