@pagenary/publisher 2026.6.13 → 2026.6.15

package/README.md

@@ -31,7 +31,7 @@ npx pagenary serve                           # serve on http://localhost:5173
 
 ## What It Is
 
-The publisher takes a catalog of shared section templates plus per-tenant content and configuration and produces a self-contained documentation bundle for each tenant. Each bundle is a static single-page app — hash-based routing (`#/page-id`), no server-side rendering, no runtime dependencies — that you build once and host anywhere that serves files. A per-tenant `<base>` resolves asset and module URLs to the tenant root, so the same bundle serves correctly at a domain root *or* under a subpath mount. Tenants share the template catalog but keep isolated content, branding, navigation, and domains — each with ranked client-side search and SEO-ready output — so one repository can publish a dozen distinct sites.
+The publisher takes a catalog of shared section templates plus per-tenant content and configuration and produces a self-contained documentation bundle for each tenant. Each bundle is a static single-page app — hash-based routing (`#page-id`), no server-side rendering, no runtime dependencies — that you build once and host anywhere that serves files. A per-tenant `<base>` resolves asset and module URLs to the tenant root, so the same bundle serves correctly at a domain root *or* under a subpath mount. Tenants share the template catalog but keep isolated content, branding, navigation, and domains — each with ranked client-side search and SEO-ready output — so one repository can publish a dozen distinct sites.
 
 ---
 
@@ -47,8 +47,10 @@ npx pagenary build:tenants my-docs   # build your tenant (see Tenant Registry be
 npx pagenary serve                   # preview on http://localhost:5173
 ```
 
-Commands: `build`, `build:tenants [id]`, `tenants:list`, `serve` (run
-`npx pagenary --help`). The package also ships a compiled reference site under `site/` — the Pagenary docs, built by Pagenary itself.
+Commands: `build`, `build:tenants [id]`, `tenants:list`,
+`managed-hosting`, `serve` (run `npx pagenary --help`). The package also
+ships a compiled reference site under `site/` — the Pagenary docs, built by
+Pagenary itself.
 
 **Building from source** (contributors / modifying Pagenary):
 
@@ -265,6 +267,7 @@ npx pagenary build                    # build the default bundle to dist/
 npx pagenary build:tenants            # build all enabled tenants
 npx pagenary build:tenants my-tenant  # build a specific tenant
 npx pagenary tenants:list             # list configured tenants
+npx pagenary managed-hosting plans    # inspect public hosting entitlements
 npx pagenary serve                    # serve dist/ on localhost:5173
 ```
 
@@ -352,6 +355,36 @@ Use a non-privileged port: `DOCS_TOOLKIT_PORT=5173 npm run caddy:up`
 
 ---
 
+## Managed Hosting MVP
+
+Pagenary can be operated as a concierge managed-hosting service before the
+self-serve control panel exists. The public package includes the static
+publisher, plan/entitlement contract, routing generator, and build-worker
+examples; Stripe secrets, OAuth apps, customer records, and the control panel
+belong in the private hosting/control-plane repository.
+
+```bash
+npm run managed-hosting -- plans
+npm run managed-hosting -- onboarding-intake examples/managed-hosting.tenants.json examples/managed-hosting-onboarding-pro.json
+npm run managed-hosting -- account-usage examples/managed-hosting.tenants.json
+npm run managed-hosting -- dashboard-state examples/managed-hosting.tenants.json --account-id acme
+npm run managed-hosting -- validate examples/managed-hosting.tenants.json
+npm run managed-hosting -- caddy examples/managed-hosting.tenants.json
+npm run managed-hosting -- billing-action examples/managed-hosting.tenants.json acme
+npm run managed-hosting -- site-event examples/managed-hosting.tenants.json examples/managed-hosting-site-created.json
+npm run managed-hosting -- domain-event examples/managed-hosting.tenants.json acme examples/managed-hosting-domain-verified.json
+npm run managed-hosting -- repo-event examples/managed-hosting.tenants.json acme examples/managed-hosting-repo-connected.json
+npm run managed-hosting -- rollback-plan examples/managed-hosting.tenants.json acme
+npm run managed-hosting -- deploy-manifest examples/managed-hosting.tenants.json acme
+npm run managed-hosting -- artifact-index examples/managed-hosting.tenants.json acme
+```
+
+See [Managed Hosting MVP](docs/MANAGED-HOSTING.md) for the concierge flow,
+plan gates, Caddy routing, worker example, post-sync support packet, worker
+status events, and private control-panel boundary.
+
+---
+
 ## Repository Layout
 
 ```
@@ -384,6 +417,7 @@ The full documentation site is published at **[docs.pagenary.com](https://docs.p
 - [Getting Started](docs/GETTING-STARTED.md) — **start here**: zero to a published site with the npm package
 - [Quick Start Guide](docs/QUICKSTART.md) — step-by-step tenant creation
 - [Publish with GitHub/Gitea Actions](docs/PUBLISHING.md) — make any docs repo Pagenary-ready: copy-paste CI workflows + auto-discovery
+- [Managed Hosting MVP](docs/MANAGED-HOSTING.md) — concierge hosting, plan gates, Caddy routing, and worker examples
 - [Tenant Configuration](docs/TENANT-CONFIG.md) — all config options (branding, theme, SEO)
 - [Theming Recipes](docs/THEMING-RECIPES.md) — copy-paste recipes for colors, fonts, and nav positions, with screenshots
 - [Architecture](docs/ARCHITECTURE.md) — system design

package/bin/pagenary.mjs

@@ -37,6 +37,11 @@ const COMMANDS = {
     script: 'serve.js',
     baseArgs: [],
     summary: 'Serve the built output over HTTP.'
+  },
+  'managed-hosting': {
+    script: 'managed-hosting.js',
+    baseArgs: [],
+    summary: 'Validate concierge hosting plans, routing, and onboarding records.'
   }
 };
 
@@ -67,6 +72,7 @@ function printHelp() {
     '  pagenary build:tenants pagenary   # build one tenant',
     '  pagenary tenants:list',
     '  pagenary serve',
+    '  pagenary managed-hosting plans',
     '',
     'Any extra options are passed through to the underlying script, e.g.',
     '  pagenary build:tenants --incremental',

package/examples/blog-demo/.public/images/hero-1.svg

@@ -0,0 +1,11 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1200 600" role="img" aria-label="Abstract gradient">
+  <defs>
+    <linearGradient id="g1" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#0ea5e9"/>
+      <stop offset="1" stop-color="#6366f1"/>
+    </linearGradient>
+  </defs>
+  <rect width="1200" height="600" fill="url(#g1)"/>
+  <circle cx="320" cy="200" r="180" fill="#ffffff" opacity="0.10"/>
+  <circle cx="900" cy="440" r="240" fill="#ffffff" opacity="0.08"/>
+</svg>

package/examples/blog-demo/.public/images/hero-2.svg

@@ -0,0 +1,11 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1200 600" role="img" aria-label="Abstract gradient">
+  <defs>
+    <linearGradient id="g2" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#f59e0b"/>
+      <stop offset="1" stop-color="#ec4899"/>
+    </linearGradient>
+  </defs>
+  <rect width="1200" height="600" fill="url(#g2)"/>
+  <rect x="120" y="120" width="360" height="360" rx="40" fill="#ffffff" opacity="0.10"/>
+  <rect x="760" y="240" width="300" height="300" rx="40" fill="#ffffff" opacity="0.08"/>
+</svg>

package/examples/blog-demo/.public/images/hero-3.svg

@@ -0,0 +1,11 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1200 600" role="img" aria-label="Abstract gradient">
+  <defs>
+    <linearGradient id="g3" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#10b981"/>
+      <stop offset="1" stop-color="#0ea5e9"/>
+    </linearGradient>
+  </defs>
+  <rect width="1200" height="600" fill="url(#g3)"/>
+  <path d="M0 460 Q 300 360 600 460 T 1200 460 V600 H0 Z" fill="#ffffff" opacity="0.10"/>
+  <path d="M0 520 Q 300 430 600 520 T 1200 520 V600 H0 Z" fill="#ffffff" opacity="0.08"/>
+</svg>

package/examples/blog-demo/config.json

@@ -0,0 +1,28 @@
+{
+  "title": "Fieldnotes — the Pagenary blog demo",
+  "brandMark": "Fieldnotes",
+  "brandSub": "Blog",
+  "tagline": "A blog-layout demo built with Pagenary.",
+  "description": "Demonstrates the Pagenary blog layout: a chronological index, post pages with hero images, bylines, and tags — driven by the collections engine.",
+  "accentColor": "#0ea5e9",
+  "layout": "blog",
+  "blog": {
+    "sidebar": "hidden",
+    "indexTitle": "Latest posts",
+    "livingScroll": true
+  },
+  "collections": [
+    {
+      "path": "posts",
+      "route": "/posts",
+      "title": "Posts",
+      "manifest": true,
+      "feed": true,
+      "sortBy": "date",
+      "order": "desc",
+      "showDate": true,
+      "showSummary": true,
+      "showReadingTime": true
+    }
+  ]
+}

package/examples/blog-demo/posts/accessible-by-default.md

@@ -0,0 +1,84 @@
+---
+title: Accessible by default
+date: 2026-04-30
+author: Pagenary Team
+summary: Semantic landmarks, real links and buttons, keyboard order, and progressive enhancement are not add-ons in Pagenary — they are the baseline the blog layout is built on.
+tags: [accessibility]
+hero: assets/images/hero-3.svg
+---
+
+# Accessible by default
+
+A blog that looks modern but traps keyboard users, or hides its text behind an
+animation that never finishes, is not modern — it is broken with nicer paint. The
+Pagenary blog layout starts from the opposite premise: the accessible version
+*is* the version. Everything else is layered on top of a page that already works
+for everyone.
+
+## The baseline
+
+Before any styling or motion, a post page is built from real, meaningful HTML:
+
+- Real `<article>`, `<time>`, `<a>`, and `<nav>` elements — not click handlers
+  bolted onto `<div>`s.
+- One `<h1>` per page, with headings in order, so the document outline makes
+  sense to a screen reader and to a search crawler.
+- Semantic landmarks and a working skip link, so keyboard and assistive-tech
+  users can jump straight to the content.
+- Focus order that follows reading order — you tab through the page the way you
+  read it.
+- Text and background colors drawn from theme tokens that are checked for
+  contrast, in light and dark alike.
+
+If you turned off the stylesheet entirely, you would still have a coherent,
+navigable document. That is the test.
+
+## Progressive enhancement, not graceful degradation
+
+The order of operations matters. We do not build a flashy page and then try to
+claw back accessibility for the readers it excluded. We build the readable page
+first and *enhance* it for readers who can take the enhancement.
+
+Concretely: the reveal-on-scroll base state is hidden only when scripting is
+present (`html.has-js`) and the reader allows motion. So the no-JavaScript reader
+and the reduced-motion reader never have content hidden from them — there is
+nothing to "recover", because they were never excluded in the first place.
+
+> Accessibility is not a feature you add at the end. It is the shape of the thing
+> you started with.
+
+## Motion is a preference, and we honor it
+
+Every animation in the blog — reveal-on-scroll, hero parallax, the works — is
+wrapped in `@media (prefers-reduced-motion: no-preference)`. When the reader has
+told their operating system they want less motion, the page obliges completely:
+no fades, no parallax, no movement. The content is simply present.
+
+This is not a fallback we tolerate; it is a first-class path we test. A reduced-
+motion reader should get a blog that feels intentional and calm, not a stripped
+one that feels broken.
+
+## Navigation you can actually operate
+
+The post navigation at the foot of every page is a labelled `<nav>` of real
+links. You can reach it by keyboard, you can tell where each link goes from its
+text alone, and screen readers announce it as a navigation region. The same is
+true of the command palette, the theme picker, and the sidebar: real controls,
+real focus management, real labels.
+
+## Why bother being strict
+
+Two reasons, and only one of them is ethics.
+
+The first is that the readers excluded by inaccessible design are real and many —
+keyboard-only users, screen-reader users, people with vestibular conditions for
+whom unbidden motion is genuinely unpleasant. A docs or blog tool that quietly
+locks them out is failing at its one job: communication.
+
+The second is that accessible markup is *better engineering*. Semantic HTML is
+more robust, more searchable, easier to style, and easier to maintain than a pile
+of `<div>`s wearing ARIA as a costume. Doing it right is not a tax on the modern,
+dynamic feel — it is the foundation that lets the dynamic layer be added safely.
+
+Accessible and dynamic were never in tension. One is just the floor the other
+stands on.

package/examples/blog-demo/posts/designing-for-living-scroll.md

@@ -0,0 +1,98 @@
+---
+title: Designing for living scroll
+date: 2026-05-22
+author: Pagenary Team
+summary: A blog should feel alive as you read it — content arriving as it enters view, a sense of progress, motion that flows. Here is how we think about it, accessibly.
+tags: [design, motion, accessibility]
+hero: assets/images/hero-2.svg
+---
+
+# Designing for living scroll
+
+"Living scroll" is the feeling that a page is responding to you as you move
+through it. Sections settle into place as they enter the viewport. A slim bar at
+the top tracks how far you have read. Nothing snaps; everything flows. Done well,
+you stop noticing the mechanics and simply feel that the page is *with* you.
+
+This post is itself an example. As you scroll, each block you are reading arrived
+a moment ago, and the bar along the top has been creeping rightward the whole
+time. If you have reduced motion turned on, none of that happened — and you have
+not missed a single word. That is the whole design philosophy in one sentence.
+
+## The reader sets the terms
+
+Motion is an enhancement, never a requirement. We hold three rules, in order:
+
+1. **The words come first.** With JavaScript disabled, the full article is on the
+   page — nothing is hidden waiting for a script to run. The reveal only ever
+   *delays* paint for readers who can run it; it never gates content.
+2. **Reduced motion wins.** Every animation lives inside
+   `@media (prefers-reduced-motion: no-preference)`. If the reader has asked the
+   operating system for less motion, the content is simply there, fully visible,
+   with no transitions at all.
+3. **It degrades to plain.** Old browser, flaky connection, script error — any
+   failure leaves a complete, readable blog behind, because the dynamic layer is
+   added on top of a page that already works.
+
+If a feature cannot honor all three, it does not ship.
+
+## How the reveal actually works
+
+The trick is where the hidden state lives. It would be easy — and wrong — to hide
+every block in JavaScript and reveal it on scroll, because then a reader with no
+JavaScript sees nothing. Instead the base "hidden" state is **CSS**, scoped under
+three conditions at once: the page has opted in, scripting is present, and the
+reader allows motion.
+
+```css
+html.has-js body[data-blog-living-scroll] .doc-content > * {
+  opacity: 0;
+  transform: translateY(14px);
+}
+```
+
+The `html.has-js` class is only added when scripts run, so a no-JavaScript page
+never matches this rule and shows everything. The media query handles reduced
+motion. Only when all three line up does a block start hidden — and then an
+`IntersectionObserver` adds a `revealed` class as it scrolls into view.
+
+Blocks already on screen when the page loads reveal at once, as a gentle
+entrance. Everything below the fold arrives as you reach it. There is no list of
+hard-coded timings to maintain; the viewport is the timeline.
+
+## A sense of progress
+
+The reading-progress bar is deliberately the quietest element on the page: three
+pixels tall, the accent color, pinned to the top, and marked `aria-hidden`
+because it carries no information a screen reader needs — it mirrors the scrollbar
+the reader already has. It exists for the same reason a book's thickness in your
+hand does: a glanceable sense of *how much is left*.
+
+## Motion that flows, not motion that shows off
+
+It is tempting to reach for parallax on everything, snap-scrolling between
+full-screen panels, and text that types itself out. Each of those can be lovely
+and each can be exhausting. Our test for any effect is simple:
+
+> Does it help the reader move through the writing, or does it ask the reader to
+> watch it perform?
+
+Reveal-on-scroll passes — it paces the page to your scrolling. A hero parallax
+passes in small doses — it adds depth without demanding attention. A full-screen
+typewriter on the article body fails — it slows the one thing the reader came to
+do. So we ship the first two as defaults, keep the rest opt-in, and gate all of
+it on the reader's stated preference.
+
+## Turning it on
+
+Living scroll is one key:
+
+```json
+{ "blog": { "livingScroll": true } }
+```
+
+That sets two body hooks at build time — one for the reveal, one for the progress
+bar — and the runtime does the rest, per render, tearing the observers down when
+you navigate away. Leave it off and the blog is calm and static. Turn it on and
+the blog feels alive — for every reader who wants it, and invisibly out of the
+way for every reader who doesn't.

package/examples/blog-demo/posts/launching-pagenary-blogs.md

@@ -0,0 +1,99 @@
+---
+title: Launching the Pagenary blog layout
+date: 2026-06-10
+author: Pagenary Team
+summary: Pagenary is no longer just a knowledge-base tool — the new blog layout turns a folder of dated Markdown into a chronological, hero-led publication.
+tags: [announcement, layout]
+hero: assets/images/hero-1.svg
+---
+
+# Launching the Pagenary blog layout
+
+For a long time every Pagenary site shared one silhouette: a header, a left
+sidebar, and a reading column tuned for reference material. That shape is right
+for documentation — you want the whole tree in front of you, and you jump around
+more than you read top to bottom. It is the wrong shape for writing that is meant
+to be *read*: a changelog, a field journal, a release blog, an essay.
+
+So we added a second layout family. Set `layout: "blog"` and the same Markdown,
+the same collections engine, and the same build produce a chronological index of
+post cards and reading-first post pages — hero image, byline, tags, and a
+comfortable measure. Nothing about your content changes. Only the silhouette does.
+
+## What you get
+
+A blog tenant is still just a folder of files, but the build now understands a
+few new conventions:
+
+- **A chronological index.** The landing page becomes a card grid built from your
+  collection's `index.json`, newest first. Each card carries the hero thumbnail,
+  title, date, author, reading time, tags, and excerpt.
+- **Reading-first post pages.** The hero banner renders above the title, the
+  byline (`date · By author · N min read`) sits below it, and tag chips follow
+  the summary. The reading column holds a comfortable line length.
+- **A feed.** Turn on `feed: true` for a collection and the build emits
+  `feed.xml` alongside the index — RSS readers get your posts for free.
+- **Two silhouettes.** `blog.sidebar: "hidden"` gives a single centered column;
+  `blog.sidebar: "rail"` keeps a slim posts rail on the trailing edge.
+
+None of this is a new content type. A post is a Markdown file with frontmatter,
+exactly like a docs page — it just lives in a collection folder and carries a
+`date`.
+
+## Quick start
+
+Declare the layout and a collection in `config.json`:
+
+```json
+{
+  "title": "Fieldnotes",
+  "layout": "blog",
+  "blog": { "sidebar": "hidden", "indexTitle": "Latest posts", "livingScroll": true },
+  "collections": [
+    { "path": "posts", "route": "/posts", "manifest": true, "feed": true,
+      "sortBy": "date", "order": "desc", "showDate": true, "showSummary": true }
+  ]
+}
+```
+
+Then write one Markdown file per post under `posts/`, each with a `title`,
+`date`, `summary`, and optional `tags` and `hero`. Build with
+`npm run build:examples` and open `dist/blog-demo/`. That is the entire workflow —
+there is no admin panel, no database, and no per-post wiring.
+
+## Moving between posts
+
+With the sidebar hidden there is nowhere to put a full navigation tree, so each
+post ends with a small, persistent control: previous post, back to the index,
+next post. It is a real `<nav>` of links, scoped to the collection, and it is
+keyboard-navigable. Readers never reach the end of a post and find themselves
+stranded.
+
+## It is still a static site
+
+The blog layout inherits everything that makes a Pagenary docs site cheap and
+durable. The output is plain static files: deploy them to any free static host or
+CDN. Ranked search still works across your posts. The SEO pipeline still
+prerenders a snapshot of every page, so crawlers and no-JavaScript readers get
+the full article, not an empty shell.
+
+> A blog should not cost more to run than a folder of text files. With Pagenary,
+> it doesn't — it *is* a folder of text files.
+
+## Make it yours
+
+Because a blog themes exactly like a docs site, the same `theme` presets, accent
+and surface colors, and fonts all apply. Want a dark journal, a warm serif
+review, or a bright editorial palette? That is a few keys in `config.json`, not a
+fork. The theme gallery ships several ready-made blog looks to start from.
+
+## Where this is going
+
+This first release is deliberately small: the layout, the index, the post page,
+a feed, and post navigation. From here the interesting work is in how a post
+*reads* — content that arrives as you scroll, a sense of progress, motion that
+flows but never gets in the way. The next post digs into that, and into why every
+bit of it stays optional and accessible.
+
+If you keep your writing in a git repo today, you are already most of the way to
+a blog. Point Pagenary at it, set `layout: "blog"`, and publish.

package/examples/managed-hosting-billing-cancel.json

@@ -0,0 +1,4 @@
+{
+  "type": "subscription.canceled",
+  "effectiveAt": "2026-06-22T00:00:00.000Z"
+}

package/examples/managed-hosting-billing-pro.json

@@ -0,0 +1,6 @@
+{
+  "type": "subscription.active",
+  "plan": "pro",
+  "paymentStatus": "active",
+  "effectiveAt": "2026-06-22T00:00:00.000Z"
+}

package/examples/managed-hosting-domain-failed.json

@@ -0,0 +1,6 @@
+{
+  "type": "custom_domain.failed",
+  "domain": "docs.acme.com",
+  "reason": "DNS record did not resolve to acme.pagenary.app",
+  "effectiveAt": "2026-06-22T00:05:00.000Z"
+}

package/examples/managed-hosting-domain-verified.json

@@ -0,0 +1,5 @@
+{
+  "type": "custom_domain.verified",
+  "domain": "docs.acme.com",
+  "effectiveAt": "2026-06-22T00:00:00.000Z"
+}

package/examples/managed-hosting-gitea.yml

@@ -0,0 +1,118 @@
+# Example managed-hosting build worker for a single concierge tenant.
+# Copy into the private hosting/control-plane repo and replace the tenant id,
+# deploy target, and secrets there. Keep payment/OAuth/customer secrets out of
+# this public repository.
+
+name: Managed Hosting Tenant Build
+
+on:
+  push:
+    branches: [main]
+  workflow_dispatch:
+
+concurrency:
+  group: managed-hosting-${{ vars.PAGENARY_TENANT_ID }}
+  cancel-in-progress: true
+
+jobs:
+  build-and-deploy:
+    runs-on: ubuntu-latest
+    container: node:20@sha256:8f693eaa7e0a8e71560c9a82b55fd54c2ae920a2ba5d2cde28bac7d1c01c9ba5
+    timeout-minutes: 10
+    defaults:
+      run:
+        shell: bash
+
+    steps:
+      - name: Checkout hosting registry
+        uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Validate public hosting contract
+        working-directory: apps/publisher
+        run: node scripts/managed-hosting.js validate examples/managed-hosting.tenants.json
+
+      - name: Build tenant bundle
+        working-directory: apps/publisher
+        env:
+          GIT_TERMINAL_PROMPT: "0"
+          GIT_SSH_COMMAND: "ssh -i ${{ secrets.CUSTOMER_DEPLOY_KEY }} -o StrictHostKeyChecking=accept-new"
+        run: node scripts/build-tenants.js "${{ vars.PAGENARY_TENANT_ID }}" --registry examples/managed-hosting.tenants.json
+
+      - name: Verify build output
+        env:
+          TENANT_ID: ${{ vars.PAGENARY_TENANT_ID }}
+        run: |
+          set -euo pipefail
+          OUT="apps/publisher/dist/${TENANT_ID}"
+          test -f "${OUT}/index.html"
+          test -d "${OUT}/sections"
+          test -d "${OUT}/search-index"
+
+      - name: Write public deployment status
+        working-directory: apps/publisher
+        run: |
+          node scripts/managed-hosting.js status examples/managed-hosting.tenants.json "${{ vars.PAGENARY_TENANT_ID }}" \
+            --commit "${{ gitea.sha }}" \
+            --log-url "${{ gitea.server_url }}/${{ gitea.repository }}/actions/runs/${{ gitea.run_id }}" \
+            --verified-domain "${{ vars.PAGENARY_VERIFIED_DOMAIN }}" \
+            > "dist/${{ vars.PAGENARY_TENANT_ID }}/pagenary-hosting-status.json"
+
+      - name: Gate launch readiness
+        working-directory: apps/publisher
+        run: |
+          node scripts/managed-hosting.js readiness examples/managed-hosting.tenants.json "${{ vars.PAGENARY_TENANT_ID }}" \
+            --commit "${{ gitea.sha }}" \
+            --log-url "${{ gitea.server_url }}/${{ gitea.repository }}/actions/runs/${{ gitea.run_id }}" \
+            --verified-domain "${{ vars.PAGENARY_VERIFIED_DOMAIN }}" \
+            > "dist/${{ vars.PAGENARY_TENANT_ID }}/pagenary-hosting-readiness.json"
+
+      - name: Write publish plan
+        working-directory: apps/publisher
+        run: |
+          node scripts/managed-hosting.js publish-plan examples/managed-hosting.tenants.json "${{ vars.PAGENARY_TENANT_ID }}" \
+            --commit "${{ gitea.sha }}" \
+            --log-url "${{ gitea.server_url }}/${{ gitea.repository }}/actions/runs/${{ gitea.run_id }}" \
+            --verified-domain "${{ vars.PAGENARY_VERIFIED_DOMAIN }}" \
+            --deploy-root "${{ secrets.PAGENARY_DEPLOY_ROOT }}" \
+            > "dist/${{ vars.PAGENARY_TENANT_ID }}/pagenary-hosting-publish-plan.json"
+
+      - name: Sync static output
+        env:
+          TENANT_ID: ${{ vars.PAGENARY_TENANT_ID }}
+          DEPLOY_ROOT: ${{ secrets.PAGENARY_DEPLOY_ROOT }}
+        run: |
+          set -euo pipefail
+          rsync -av --delete "apps/publisher/dist/${TENANT_ID}/" "${DEPLOY_ROOT%/}/${TENANT_ID}/"
+
+      - name: Verify published output
+        working-directory: apps/publisher
+        run: |
+          node scripts/managed-hosting.js publish-check examples/managed-hosting.tenants.json "${{ vars.PAGENARY_TENANT_ID }}" \
+            --commit "${{ gitea.sha }}" \
+            --log-url "${{ gitea.server_url }}/${{ gitea.repository }}/actions/runs/${{ gitea.run_id }}" \
+            --verified-domain "${{ vars.PAGENARY_VERIFIED_DOMAIN }}" \
+            --deploy-root "${{ secrets.PAGENARY_DEPLOY_ROOT }}" \
+            > "dist/${{ vars.PAGENARY_TENANT_ID }}/pagenary-hosting-publish-result.json"
+
+      - name: Write deploy/CDN manifest
+        working-directory: apps/publisher
+        run: |
+          node scripts/managed-hosting.js deploy-manifest examples/managed-hosting.tenants.json "${{ vars.PAGENARY_TENANT_ID }}" \
+            --commit "${{ gitea.sha }}" \
+            --log-url "${{ gitea.server_url }}/${{ gitea.repository }}/actions/runs/${{ gitea.run_id }}" \
+            --verified-domain "${{ vars.PAGENARY_VERIFIED_DOMAIN }}" \
+            --deploy-root "${{ secrets.PAGENARY_DEPLOY_ROOT }}" \
+            > "dist/${{ vars.PAGENARY_TENANT_ID }}/pagenary-hosting-deploy-manifest.json"
+
+      - name: Write managed-hosting artifact index
+        working-directory: apps/publisher
+        run: |
+          node scripts/managed-hosting.js artifact-index examples/managed-hosting.tenants.json "${{ vars.PAGENARY_TENANT_ID }}" \
+            --commit "${{ gitea.sha }}" \
+            --log-url "${{ gitea.server_url }}/${{ gitea.repository }}/actions/runs/${{ gitea.run_id }}" \
+            --verified-domain "${{ vars.PAGENARY_VERIFIED_DOMAIN }}" \
+            --deploy-root "${{ secrets.PAGENARY_DEPLOY_ROOT }}" \
+            > "dist/${{ vars.PAGENARY_TENANT_ID }}/pagenary-hosting-artifact-index.json"

package/examples/managed-hosting-onboarding-pro.json

@@ -0,0 +1,16 @@
+{
+  "tenantId": "beta",
+  "accountId": "beta",
+  "plan": "pro",
+  "subdomain": "beta",
+  "siteCount": 1,
+  "paymentStatus": "manual-pending",
+  "privateRepo": true,
+  "domains": ["docs.beta.example.com"],
+  "source": {
+    "type": "git",
+    "url": "ssh://git@git.example.com/beta/docs.git",
+    "ref": "main",
+    "path": "docs"
+  }
+}

package/examples/managed-hosting-repo-connected.json

@@ -0,0 +1,12 @@
+{
+  "type": "repository.connected",
+  "privateRepo": true,
+  "credentialRef": "secret:CUSTOMER_DEPLOY_KEY/acme",
+  "source": {
+    "type": "git",
+    "url": "ssh://git@git.example.com/acme/docs.git",
+    "ref": "main",
+    "path": "docs"
+  },
+  "effectiveAt": "2026-06-22T00:00:00.000Z"
+}

package/examples/managed-hosting-repo-failed.json

@@ -0,0 +1,5 @@
+{
+  "type": "repository.failed",
+  "reason": "provider rejected webhook setup",
+  "effectiveAt": "2026-06-22T00:10:00.000Z"
+}

package/examples/managed-hosting-site-created.json

@@ -0,0 +1,17 @@
+{
+  "type": "site.created",
+  "effectiveAt": "2026-06-22T00:00:00.000Z",
+  "tenant": {
+    "tenantId": "acme-api",
+    "accountId": "acme",
+    "plan": "pro",
+    "paymentStatus": "active",
+    "subdomain": "acme-api",
+    "source": {
+      "type": "git",
+      "url": "ssh://git@git.example.com/acme/api-docs.git",
+      "ref": "main"
+    },
+    "webhookSecretRef": "secret:WEBHOOK_SECRET/acme-api"
+  }
+}

package/examples/managed-hosting-site-removed.json

@@ -0,0 +1,5 @@
+{
+  "type": "site.removed",
+  "effectiveAt": "2026-06-22T00:00:00.000Z",
+  "tenantId": "acme-api"
+}