@uniweb/unipress 0.2.2 → 0.2.4

package/CHANGELOG.md

@@ -1,5 +1,93 @@
 # Changelog
 
+## Unreleased
+
+### Changed
+
+- **Release binaries are now signed.** macOS binaries are signed with
+  Apple Developer ID Application + Apple-notarized; Windows binaries
+  are signed via Azure Trusted Signing. macOS users no longer see a
+  Gatekeeper warning on first run. The 0.2.3 release assets were
+  re-signed in place — re-download from the release page if you
+  grabbed an unsigned copy before this change landed.
+
+### Removed
+
+- `.github/workflows/release.yml`. Binaries are no longer built in
+  this public repo — they're built and signed in a private Proximify
+  pipeline. Pushing a `unipress@<version>` tag no longer triggers a
+  binary build; the maintainer dispatches the signed pipeline manually
+  after each tag, and the resulting binaries are uploaded to the same
+  GitHub Release on this repo. Source code, docs, npm publishing, and
+  the foundation-deploy workflow are unchanged.
+
+## 0.2.3
+
+The first complete-out-of-the-box release. `npm i -g @uniweb/unipress`
++ `unipress create my-book --template book` + `unipress compile my-book`
+produces a real PDF on the first try, no setup, no auth, no local
+servers, no `--foundation` overrides.
+
+### Added
+
+- **GitHub Pages distribution for bundled foundations.**
+  `https://uniweb.github.io/unipress/foundations/<name>/<version>/foundation.js`
+  serves every published foundation. A new workflow
+  (`.github/workflows/deploy-foundations.yml`) builds each
+  `foundations/<name>/` on every push to main and accumulates versions
+  on the `gh-pages` branch — older versions stay reachable indefinitely.
+  No registry namespace claim, no Cloudflare worker, no platform
+  authorization needed for the open-source foundations.
+- **`scripts/ci-flip-workspace-deps.js`** — pre-install rewrite that
+  translates `workspace:*` deps to npm version ranges in CI. Both
+  workflows (foundation deploy, binary release) call it as the first
+  step. Closes the standalone-install gap that the workspace:*
+  resolution introduced.
+- **`prepublishOnly` regenerates `templates-data.js`.** `pnpm publish`
+  now refreshes the bundled template data from `documents/<name>/`
+  before packing, so a stale generated file can't ship even if a
+  developer forgot to regenerate before commit.
+
+### Fixed
+
+- **EPUB cover image no longer skipped.** The foundation's
+  `buildEpubOptions` was using a `fetch`-based URL resolver that
+  silently 404'd in unipress's Node compile context. Replaced with
+  the same `loadAsset` abstraction the typst path uses. Cover image
+  now embeds at `OEBPS/images/<hash>.jpg` alongside a synthesized
+  `cover.xhtml` page.
+- **DOCX inline-image path threaded through `loadAsset`.**
+  `framework/press`'s docx adapter walker now plumbs the host-supplied
+  byte loader from `buildDocument` → `convertChildren` →
+  `irToImageParagraph` → `fetchImageData` → `fetchAsset`. Future
+  docx-emitting templates with inline images compile cleanly in
+  unipress.
+- **Cover round-trip in scaffolded projects** — front + back JPGs
+  ship via the binary-asset support added to the template generator.
+  EPUB readers + most PDF viewers now show the book's thumbnail
+  without the user adding any artwork.
+
+### Changed
+
+- Catalog URLs in `src/foundations-data.js` flipped from local-registry
+  (`http://localhost:4001/...`) to GH Pages
+  (`https://uniweb.github.io/unipress/foundations/...`). The 0.2.0
+  caveat in the changelog is resolved.
+- `foundation-loader.js`'s `DEFAULT_REGISTRY_BASE` flipped to
+  `https://uniweb.github.io/unipress`. `UNIWEB_REGISTRY_URL` env var
+  remains the override for local dev / private alternatives.
+- `@uniweb/*` deps in `package.json` are `workspace:*` again (dev
+  resolves local siblings); `pnpm publish` translates them to real
+  version specs in the published tarball.
+
+### Notes
+
+- Binary downloads (darwin-arm64, linux-x64, windows-x64) ship via
+  the existing `unipress@<version>` tag-driven release workflow. The
+  npm path is now equivalent for users with Node 20+.
+- See `RELEASING.md` for the framework-publish + workspace:* flip-back
+  dance the next maintainer release follows.
+
 ## 0.2.0
 
 The credibility-shifting release. Two production-shaped foundations
@@ -64,15 +152,16 @@ separates create-time templates from runtime foundations.
 - `templates/` directory; `package.json`'s `files:` array now ships
   `documents/`.
 
-### Caveat
+### Caveat (resolved in a follow-up release)
 
-Catalog entries currently point at the **local registry**
-(`http://localhost:4001/registry/packages/<ns>/<name>/<ver>/foundation.js`).
-Scaffolded documents will fail to fetch the foundation unless the
-foundations are published locally via `uniweb publish --local` against
-a running unicloud, OR the user passes `--foundation <path>` explicitly.
-A follow-up release switches the catalog URLs to the production
-registry once `@uniweb/book` and `@uniweb/data` publish there.
+Catalog entries in 0.2.0 pointed at a local registry
+(`http://localhost:4001/...`), so scaffolded documents required the
+user to run a registry locally or to pass `--foundation <path>`
+explicitly. A subsequent release switches the catalog URLs to GitHub
+Pages (`https://uniweb.github.io/unipress/foundations/...`); the
+foundations are deployed there by `.github/workflows/deploy-foundations.yml`
+on every push to main, and `unipress create + compile` works end-to-end
+from a fresh npm install.
 
 ## 0.1.0 (unreleased)
 

package/README.md

@@ -26,15 +26,25 @@ Equations work in the standard LaTeX style — `$E = mc^2$` for inline, `$$...$$
 
 **For authors.** unipress is a tool. Pick a template, write markdown, compile. The template knows the conventions for its kind of document — typography, structure, the bits that make a book look like a book and a directory look like a directory. You handle the content; the template handles everything else.
 
-**For developers.** unipress is an engine. A *foundation* is a component system that declares what section types exist (`type: Chapter`, `type: Bibliography`), where data comes from (`data:` declarations), and what output formats it can emit (`outputs: { docx, xlsx, pdf, custom-format }`). Authors write markdown against your vocabulary; unipress runs your foundation against their content. Same content directory, multiple outputs your foundation chooses to support — typeset book, accessible EPUB, regulatory report, structured data feed. The same foundation can also drive a [Uniweb](https://uniweb.io) website, so the work is never single-purpose.
+**For developers.** unipress is an engine. A *foundation* you write declares what section types exist (`type: Chapter`, `type: Bibliography`), where their data comes from (markdown content, file-based or API-backed collections, [Loom](https://github.com/uniweb/loom) expressions templating against hierarchical data), and what output formats it can emit (`outputs: { docx, xlsx, pdf, custom-format }`). Authors mix prose with structured records and computed values in the same document; unipress runs your foundation against their content and produces whatever your foundation declares — typeset book, accessible EPUB, regulatory report, structured data feed. The same foundation can also drive a [Uniweb](https://uniweb.io) website, so the work is never single-purpose.
 
-Foundations consume [`@uniweb/press`](https://github.com/uniweb/press) for the bytes-emitting work. Press is the output layer (Word, Excel, Typst today; more formats shipping); the foundation is your vocabulary.
+Foundations consume [@uniweb/press](https://github.com/uniweb/press) for the bytes-emitting work. Press is the output layer (Word, Excel, Typst today; more formats shipping); the foundation is your vocabulary.
+
+→ For the deeper pitch — mixed prose-and-data, Loom templating, custom output adapters — see [docs/for-developers.md](./docs/for-developers.md).
 
 ## Install
 
-**Standalone binary (recommended for most users).** No Node, no npm. Download the asset for your platform from [the releases page](https://github.com/uniweb/unipress/releases), make it executable, and put it somewhere on your `PATH` — `/usr/local/bin/unipress` is a common choice on macOS and Linux. Then you can run `unipress` from any directory.
+**Homebrew (macOS and Linux — recommended).** No Node, no manual download:
+
+```bash
+brew install uniweb/unipress/unipress
+```
+
+Updates land via `brew upgrade unipress`. The macOS binary is signed with the Proximify Inc. Developer ID and Apple-notarized — no Gatekeeper warnings.
+
+**Manual download (Windows, or any platform without Homebrew).** Grab the asset for your platform from [the releases page](https://github.com/uniweb/unipress/releases), make it executable (Unix), and put it somewhere on your `PATH`. On macOS and Linux, `/usr/local/bin/unipress` is a common location.
 
-**npm.** If you already have Node:
+**npm.** If you already have Node ≥ 20.19:
 
 ```bash
 npm i -g @uniweb/unipress
@@ -52,7 +62,7 @@ Five built-in templates ship with the binary. Run `unipress list-templates` for
 | `data-report` | `@uniweb/data` | xlsx, docx | Aggregate metrics across structured records |
 | `directory` | `@uniweb/data` | xlsx, docx | Flat records listing with a filterable surface |
 
-Per-template guides: [`docs/templates/`](./docs/templates/).
+Per-template guides: [docs/templates/](./docs/templates/).
 
 More templates land as more foundations ship — `cv`, `resume`, `paper`, `thesis` are on the roadmap for upcoming releases.
 
@@ -200,12 +210,12 @@ unipress is **pre-1.0**. The CLI is stable enough to write real documents with
 
 ## Troubleshooting
 
-See [`docs/troubleshooting.md`](./docs/troubleshooting.md) for common errors and fixes — every named error class maps to a cause and a concrete next step.
+See [docs/troubleshooting.md](./docs/troubleshooting.md) for common errors and fixes — every named error class maps to a cause and a concrete next step.
 
 ## See also
 
-- [`@uniweb/press`](https://github.com/uniweb/press) — the output layer foundations consume to produce Word/Excel/Typst/EPUB. Foundation authors interact with it directly.
-- [`@uniweb/build`](https://github.com/uniweb/build) — the framework's content-collection pipeline. unipress consumes the sharp-free `/content` entry.
+- [@uniweb/press](https://github.com/uniweb/press) — the output layer foundations consume to produce Word/Excel/Typst/EPUB. Foundation authors interact with it directly.
+- [@uniweb/build](https://github.com/uniweb/build) — the framework's content-collection pipeline. unipress consumes the sharp-free `/content` entry.
 - [Uniweb](https://uniweb.io) — the larger framework. Foundations originate here; unipress brings them to the command line.
 
 ## License

package/RELEASING.md

@@ -2,7 +2,9 @@
 
 Notes for cutting a release tag (`unipress@<version>`). The release workflow at `.github/workflows/release.yml` watches for tag pushes matching that pattern, builds three binaries (darwin-arm64, linux-x64, windows-x64), and creates a GitHub Release with the binaries and SHA-256 sidecars attached.
 
-This file mostly exists to flag one thing the release workflow currently can't handle on its own.
+A separate workflow at `.github/workflows/deploy-foundations.yml` builds and deploys the bundled foundations (`foundations/<name>/`) to the unipress repo's GitHub Pages site under `https://uniweb.github.io/unipress/foundations/<name>/<version>/`. It runs on every push to main, accumulating versions on the `gh-pages` branch — older versions stay reachable indefinitely. No tag needed; foundation deployment is decoupled from the binary-release tag cadence.
+
+This file mostly exists to flag one thing the binary-release workflow currently can't handle on its own.
 
 ---
 

package/docs/for-developers.md

@@ -0,0 +1,113 @@
+# unipress for developers
+
+The developer-track companion to the README. Read this if you're considering writing a foundation that compiles to documents — or to documents *and* websites from the same source.
+
+## What you actually get
+
+A foundation is a [Uniweb](https://uniweb.io) component system. unipress is the **headless runtime** for it: run `unipress compile <dir>` and the same foundation that drives a Uniweb website produces a downloadable file from a content directory.
+
+That means everything the framework does for websites, you can do for documents. The visual editor goes away; the compile pipeline stays.
+
+## Section types are the vocabulary
+
+A foundation declares **section types** — addressable React components that content authors reference by name from markdown frontmatter:
+
+```markdown
+---
+type: Chapter
+title: "Chapter One"
+---
+
+Prose body here.
+```
+
+The foundation decides what `Chapter` means: its layout, its typography, what data it expects, how it renders across each output format the foundation declares. Authors don't think in components — they think in *kinds of section*. The component is the foundation developer's responsibility; the content is the author's.
+
+## Mix prose with structured data
+
+A document is rarely just prose. Foundations declare data inputs; authors fill them in. The data can come from any of these surfaces:
+
+- **Markdown content** — the prose body of each `.md` file, parsed into a structured tree (title, paragraphs, items, links, images, code blocks).
+- **Frontmatter params** — declared in each section's YAML frontmatter, typed by the foundation's `meta.js`.
+- **File-based collections** — `collections/publications.json`, `collections/team.yml`, or markdown frontmatter swept into a list at build time. Compile to one `/data/<name>.json` per collection.
+- **API-backed collections** — declare a fetcher in `document.yml`; the build pipeline resolves it at compile time. The foundation reads `content.data` and renders.
+- **Computed values via [Loom](https://github.com/uniweb/loom)** — Loom is an expression language for instantiating templates against hierarchical data. Pull a publications list from a collection, format each entry with a Loom expression, and the result lands typeset in your output.
+
+All of these flow through the same foundation pipeline — same primitives whether the data came from a YAML file, a JSON dump, or an API endpoint.
+
+### Academic writing: bibliographies and citations
+
+For scholarly work specifically, [`citestyle`](https://github.com/uniweb/csl) handles the formatting layer Loom is too general for. CSL-based, lightweight, used directly from foundations: pick from APA, MLA, Chicago author-date, IEEE, Vancouver, Harvard at the section level (`style: chicago-author-date`); citestyle dynamically loads only the styles you reference and formats every entry to spec — the author ordering, journal abbreviations, punctuation, and conventions academic readers expect.
+
+The combination is the powerful part. Loom interpolates ("In {section.title}, we describe…"); citestyle formats bibliographic entries (a complete back-matter `Bibliography`, or inline `[Author Year]` citation marks). A thesis, monograph, or annual research report uses both: Loom for dynamic prose and per-section metadata, citestyle for every bibliographic touch in the document.
+
+Working example: the `data-report` template ships a `PublicationsList` section backed by YAML bib data in `collections/members/*.yml`, with per-section style selection. Run `unipress create my-report --template data-report` to see it. Bibliography support in long-form prose templates (`book`, `monograph`, future `thesis`/`paper`) lands across upcoming releases.
+
+## Outputs are foundation-declared
+
+```js
+// foundation/src/foundation.js
+export default {
+  outputs: {
+    pdf:    { extension: 'pdf', via: 'typst', getOptions: buildTypstOptions },
+    epub:   { extension: 'epub', getOptions: buildEpubOptions },
+    docx:   { getOptions: buildDocxOptions },
+    'tax-form-2024': { getOptions: buildTaxFormOptions },  // your own adapter
+  },
+}
+```
+
+Each entry says: which Press adapter handles the format (`via:`), which file extension to default to (`extension:`), and how to assemble adapter-specific options from the website's resolved content (`getOptions(website, hostHints)`).
+
+Press ships adapters for Word, Excel, Typst (PDF), and HTML-shaped output. For a format Press doesn't ship — a CSV feed, a domain-specific XML, a one-of-a-kind regulatory submission — write a custom adapter using [`@uniweb/press/ir`](https://github.com/uniweb/press) and declare it on the foundation. unipress dispatches by name; nothing in unipress itself needs to know about your format.
+
+## Same foundation, two runtimes
+
+`unipress compile` is one consumer. The Uniweb website pipeline (`uniweb dev`, `uniweb build`) is the other. Same foundation, same content shape, same data declarations — different runtime.
+
+That's the structural payoff: the work of defining section types, theming, and rendering isn't single-purpose. A "regulatory report" foundation can drive both an HTML site that stakeholders browse and a PDF/XLSX/DOCX bundle filed quarterly. A "research output" foundation can drive a public-facing journal site and a print-ready PDF for archival. Authoring once produces every modality.
+
+## A worked example
+
+A research-group annual-report foundation (`@yourorg/annual-report`) might ship:
+
+- **Section types**: `Cover`, `ExecutiveSummary`, `Members`, `PublicationsList`, `FundingTable`, `Charts`, `Appendix`, `Bibliography`.
+- **Data**: a `publications.yml` collection (file-based) with full bibliographic fields per paper; a `funding.json` collection with grant data; an API-backed `metrics:` collection pulling live citation counts.
+- **citestyle for bibliographic precision**: pick a style at the section level (`style: chicago-author-date`) and citestyle formats every entry to spec — author ordering, journal abbreviations, the punctuation that marks the difference between a draft and a polished publication.
+- **Loom templates**: dynamic prose elsewhere — running headers (`{book.title} — Chapter {n}`), section subtitles, the table-of-contents introductions. Loom and citestyle cooperate: citestyle owns bibliographic formatting; Loom owns everything else.
+- **Outputs**: `pdf` (typeset for the dean's office), `xlsx` (one sheet per data block, for finance), `docx` (for collaborators who don't open PDFs), `pagedjs` (HTML for the public site).
+
+A content author writes:
+
+```markdown
+---
+type: PublicationsList
+title: "Publications"
+data: publications
+filter:
+  year: 2024
+---
+
+The group published 47 papers in 2024, a 30% increase over 2023.
+```
+
+`unipress compile annual-2024 --format pdf` walks the content through the foundation, resolves Loom expressions over the filtered collection, runs the typst adapter, ships a typeset PDF. `unipress compile annual-2024 --format xlsx` produces a workbook with one sheet per data section. The same source directory; two file types, both honest.
+
+## Where to go from here
+
+- **Foundation contract** — the `outputs:` map, `meta.js` section-type discovery, the `getOptions(website, hostHints)` signature: see [foundation configuration](https://github.com/uniweb/docs/blob/main/reference/foundation-config.md).
+- **Data fetching** — collections, fetchers, predicates, where-objects, deferred fields: see the [data fetching reference](https://github.com/uniweb/docs/blob/main/reference/data-fetching.md).
+- **Loom** — expression language for instantiating templates against hierarchical data: [`@uniweb/loom`](https://github.com/uniweb/loom).
+- **citestyle** — CSL-based citation and bibliography formatter. Domain-specific complement to Loom: Loom interpolates, citestyle formats academic-style references: [`citestyle`](https://github.com/uniweb/csl).
+- **Press (the output layer)** — [`@uniweb/press`](https://github.com/uniweb/press) docs cover the registration pattern foundations consume, the IR layer for custom adapters, and per-adapter notes (docx invariants, typst conventions, the EPUB pipeline).
+- **Building a foundation from scratch** — [Uniweb framework docs](https://github.com/uniweb/docs) cover the full authoring story; everything written for sites applies to documents.
+
+## A few things worth knowing upfront
+
+**Documents are static at compile time.** unipress produces bytes; once the file is on disk, it doesn't change. "Dynamic data" in a document means *the data backing the document can vary between compiles* (re-run `unipress compile` after the API has new data; get a new PDF). It does not mean the PDF live-updates while someone reads it. That's website territory.
+
+**Foundations stay environment-agnostic.** unipress runs in Node; the Uniweb editor runs in the browser. Foundations should not branch on `typeof window` or do their own asset I/O. The compile pipeline supplies a `loadAsset(src)` helper that hosts implement appropriately for their runtime; foundations just call it. The book foundation in this repo is the reference example.
+
+**Compile failures are debuggable.** `unipress compile <dir> --verbose` streams every step; `unipress inspect <dir>` dumps the parsed content tree as JSON before the foundation runs (useful when output looks wrong and you want to know whether the input was right). Press emits structured warnings when an adapter receives unexpected shapes.
+
+**Pre-1.0.** The contract is settling but not frozen. The foundation `outputs:` map, the `meta.js` discovery model, the `compileDocument` API, the section-type vocabulary — all stable enough to build against, with breaking changes possible (and documented in the CHANGELOG) before 1.0.

package/docs/templates/book.md

@@ -15,8 +15,7 @@ unipress compile . --format pdf --out my-book.pdf
 ```
 my-book/
 ├── document.yml          pinned to @uniweb/book@<version>
-├── pages/
-│   ├── folder.yml        activates folder mode
+├── content/
 │   ├── 01-preface.md     type: BackMatter — unnumbered front matter
 │   ├── 02-chapter-one.md
 │   └── 03-chapter-two.md
@@ -42,7 +41,7 @@ my-book/
 
 ## Add chapters
 
-Drop a markdown file under `pages/` and add its base name (without `.md`) to `document.yml`'s `pages:` list in the order you want it to appear. Chapters need no frontmatter — the foundation's `Chapter` section handles them by default. For non-chapter pages (acknowledgments, colophon, appendices), use `type: BackMatter` in frontmatter to skip chapter numbering.
+Drop a markdown file under `content/` and add its base name (without `.md`) to `document.yml`'s `content:` list in the order you want it to appear. Chapters need no frontmatter — the foundation's `Chapter` section handles them by default. For non-chapter pages (acknowledgments, colophon, appendices), use `type: BackMatter` in frontmatter to skip chapter numbering.
 
 ## Common customizations
 

package/docs/templates/data-report.md

@@ -20,7 +20,7 @@ q3-metrics/
 ├── collections/
 │   ├── members/          three sample records (19th-century naturalists)
 │   └── queries/          saved query examples for the Population dropdown
-└── pages/
+└── content/
     └── report/           cover, members, publications-by-{type,journal,year},
                           publications-list, funding, supervisions
 ```
@@ -33,7 +33,7 @@ The starter ships three sample members so the first compile produces a non-empty
 |----------------------------|--------------------------------------------------------|
 | `name`, `author`, `year`   | Workbook metadata (shown in the file's properties).    |
 | `format`                   | `xlsx` (default) or `docx`. Override on the CLI.       |
-| `index`                    | Routes `/` → `pages/<index>` (here: `report`).         |
+| `index`                    | Routes `/` → `content/<index>` (here: `report`).         |
 | `collections.members.path` | Where the records live (default `collections/members`).|
 | `collections.members.queryable` | Filterable surface — drives the FilterPanel UI.   |
 | `collections.queries.path` | Saved-view dropdown (Population selector).             |

package/docs/templates/directory.md

@@ -17,7 +17,7 @@ faculty/
 ├── document.yml          pinned to @uniweb/data@<version>; one queryable collection
 ├── collections/
 │   └── members/          three sample records
-└── pages/
+└── content/
     └── directory/        cover (Loom-rendered count) + listing
 ```
 
@@ -27,7 +27,7 @@ faculty/
 |-----------------------------|--------------------------------------------------------|
 | `name`                      | Workbook title.                                        |
 | `format`                    | `xlsx` (default) or `docx`.                            |
-| `index`                     | Routes `/` → `pages/directory`.                        |
+| `index`                     | Routes `/` → `content/directory`.                        |
 | `collections.members.path`  | Where the records live (`collections/members`).        |
 | `collections.members.queryable` | Filterable fields — drives the FilterPanel UI.    |
 
@@ -58,7 +58,7 @@ Add a `joined_year:` range field, for example, if filtering by start year matter
 
 ## Hand-pick the displayed columns
 
-The Members section reads every key from each record by default. To restrict the columns shown in the web preview and the xlsx export, set `columns:` on the section frontmatter in `pages/directory/members.md`.
+The Members section reads every key from each record by default. To restrict the columns shown in the web preview and the xlsx export, set `columns:` on the section frontmatter in `content/directory/members.md`.
 
 ## When to pick `directory` over `data-report`
 

package/docs/templates/monograph.md

@@ -15,8 +15,7 @@ unipress compile . --format pdf --out my-monograph.pdf
 ```
 my-monograph/
 ├── document.yml          pinned to @uniweb/book@<version>; royal-octavo, EB Garamond, tocDepth: 3
-├── pages/
-│   ├── folder.yml
+├── content/
 │   ├── 01-preface.md     type: BackMatter
 │   ├── 02-introduction.md
 │   └── 03-chapter-one.md

package/docs/templates/report.md

@@ -15,8 +15,7 @@ unipress compile . --format pdf --out q3-report.pdf
 ```
 q3-report/
 ├── document.yml          pinned to @uniweb/book@<version>; trade-7x10, block paragraphs
-├── pages/
-│   ├── folder.yml
+├── content/
 │   ├── 01-summary.md     executive summary + recommendations table
 │   ├── 02-findings.md    body, with code listing and pull-quote
 │   └── 03-methodology.md
@@ -46,7 +45,7 @@ Same shape as `book` (see [book.md](./book.md)). The differences are defaults:
 
 ## Common customizations
 
-- **Add an appendix**: a new markdown file with `type: BackMatter` in frontmatter, listed in `pages:`.
+- **Add an appendix**: a new markdown file with `type: BackMatter` in frontmatter, listed in `content:`.
 - **Wider code blocks**: bump `book.typography.codeMarginRelief` to `0.5in` (code extends 0.5in past each side of the body column).
 - **No TOC** for short reports: set `book.structure.toc: false`.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uniweb/unipress",
-  "version": "0.2.2",
+  "version": "0.2.4",
   "description": "Compile a content directory into a document (PDF, EPUB, Paged.js HTML, Typst source bundle, DOCX, XLSX) using a Uniweb foundation. Five built-in templates: book, monograph, report, data-report, directory.",
   "type": "module",
   "publishConfig": {
@@ -49,11 +49,11 @@
     "prompts": "^2.4.2",
     "react": "^18.0.0 || ^19.0.0",
     "react-dom": "^18.0.0 || ^19.0.0",
-    "@uniweb/content-reader": "1.1.5",
-    "@uniweb/semantic-parser": "1.1.11",
-    "@uniweb/runtime": "0.8.4",
-    "@uniweb/core": "0.7.3",
-    "@uniweb/build": "0.11.2"
+    "@uniweb/build": "0.11.3",
+    "@uniweb/runtime": "0.8.5",
+    "@uniweb/core": "0.7.4",
+    "@uniweb/semantic-parser": "1.1.12",
+    "@uniweb/content-reader": "1.1.6"
   },
   "scripts": {
     "test": "echo \"no tests yet\" && exit 0",

package/src/content-loader.js

@@ -10,10 +10,108 @@
 
 import { existsSync } from 'node:fs'
 import { resolve, join } from 'node:path'
-import { collectSiteContent } from '@uniweb/build/content'
+import { collectSiteContent, processCollections } from '@uniweb/build/content'
 import { detectConfigFile, CONFIG_FILE_NAMES } from './document-yml.js'
 import { ContentDirectoryError, DocumentYmlError } from './errors.js'
 
+// Match a parsed collection-backed fetch path. parseFetchConfig (in
+// @uniweb/build) normalises `{ collection: <name> }` into
+// `{ path: '/data/<name>.json', schema: <name>, ... }` — so this regex is
+// the inverse: pull the collection name back out of the resolved path.
+const COLLECTION_PATH_RE = /^\/data\/(.+)\.json$/
+
+function attachData(section, schema, data) {
+  if (!section || !schema) return
+  if (!section.parsedContent) section.parsedContent = {}
+  if (!section.parsedContent.data) section.parsedContent.data = {}
+  // Don't clobber a section-level value with a cascaded page-level one.
+  // The Block constructor will spread parsedContent.data through, so the
+  // first writer wins for a given schema.
+  if (section.parsedContent.data[schema] === undefined) {
+    section.parsedContent.data[schema] = data
+  }
+}
+
+function findCollectionRecords(fetchConfig, resolved) {
+  if (!fetchConfig?.path || !fetchConfig?.schema) return null
+  const m = COLLECTION_PATH_RE.exec(fetchConfig.path)
+  if (!m) return null
+  const records = resolved[m[1]]
+  if (!Array.isArray(records)) return null
+  return records
+}
+
+function attachSectionFetches(sections, resolved) {
+  if (!Array.isArray(sections)) return
+  for (const section of sections) {
+    const records = findCollectionRecords(section.fetch, resolved)
+    if (records) attachData(section, section.fetch.schema, records)
+    if (Array.isArray(section.subsections) && section.subsections.length) {
+      attachSectionFetches(section.subsections, resolved)
+    }
+  }
+}
+
+/**
+ * Materialize file-based collections into each section's
+ * `parsedContent.data` so the SSR render pipeline reads populated data
+ * synchronously (no `useFetched` round-trip; no `public/` directory).
+ *
+ * In a regular Uniweb site build, the Vite plugin runs `processCollections`
+ * + `writeCollectionFiles` and the runtime resolves `fetch:` declarations
+ * over HTTP at render time. Under `unipress compile` neither of those
+ * happens — there's no public dir, and SSR skips effects. We close the
+ * gap by resolving collections in-memory and attaching the records
+ * directly to each block's `parsedContent.data.<schema>`. The Block
+ * constructor (framework/core/src/block.js) preserves that field, and
+ * `prepareProps` then surfaces it as `content.data.<schema>` to the
+ * component — same shape the runtime would produce.
+ *
+ * Page-level fetch cascades to every section on the page; section-level
+ * fetch overrides on a per-section basis. Only collection-backed fetches
+ * (parsed `path: '/data/<name>.json'`) are resolved here — remote URL
+ * fetches, refine configs, and array-form `fetch: [...]` declarations
+ * are left untouched (those have their own gaps; out of scope here).
+ */
+async function resolveLocalCollections(siteContent, sitePath) {
+  const collectionsConfig = siteContent?.config?.collections
+  if (!collectionsConfig || typeof collectionsConfig !== 'object') return
+  if (Object.keys(collectionsConfig).length === 0) return
+
+  const resolved = await processCollections(
+    sitePath,
+    collectionsConfig,
+    sitePath,
+    '/',
+  )
+
+  for (const page of siteContent.pages || []) {
+    const pageRecords = findCollectionRecords(page.fetch, resolved)
+    if (pageRecords) {
+      for (const section of page.sections || []) {
+        attachData(section, page.fetch.schema, pageRecords)
+      }
+    }
+    attachSectionFetches(page.sections, resolved)
+  }
+
+  // Stash the resolved arrays on the website config too, so any section
+  // (regardless of its own page's fetch declaration) can self-bootstrap
+  // — e.g., a Cite inset rendering inside a Chapter on page A needs the
+  // bibliography records that the Bibliography section declared on page
+  // B. Foundations read this via `block.website.config.collections.<name>.records`
+  // as a synchronous fallback.
+  if (!siteContent.config) siteContent.config = {}
+  if (!siteContent.config.collections) siteContent.config.collections = {}
+  for (const name of Object.keys(resolved)) {
+    const existing = siteContent.config.collections[name]
+    siteContent.config.collections[name] = {
+      ...(existing && typeof existing === 'object' ? existing : {}),
+      records: resolved[name],
+    }
+  }
+}
+
 export async function loadContent(dir, options = {}) {
   const sitePath = resolve(dir)
 
@@ -52,5 +150,7 @@ export async function loadContent(dir, options = {}) {
     throw err
   }
 
+  await resolveLocalCollections(content, sitePath)
+
   return { content, configFile, sitePath }
 }

package/src/foundation-loader.js

@@ -41,7 +41,17 @@ const PATH_PATTERN = /^(\.\.?[\/\\]|[\/\\]|[A-Za-z]:[\/\\])/
 // Version is anything semver-shaped — exact match isn't enforced here; the
 // registry decides what's valid.
 const REGISTRY_REF_PATTERN = /^@([a-z0-9][a-z0-9._-]*)\/([a-z0-9][a-z0-9._-]*)@([0-9a-z][0-9a-z.\-+]*)$/i
-const DEFAULT_REGISTRY_BASE = 'https://site-router.uniweb-edge.workers.dev'
+
+// unipress's bundled foundations are distributed as static artifacts on
+// the unipress repo's GitHub Pages site. URL pattern:
+//
+//   https://uniweb.github.io/unipress/foundations/<name>/<version>/foundation.js
+//
+// The namespace portion of a registry ref is implicit — every foundation
+// served from this base is under @uniweb/. Set UNIWEB_REGISTRY_URL to
+// override (e.g., for testing against a local http.server during foundation
+// development, or for users with a private alternative).
+const DEFAULT_REGISTRY_BASE = 'https://uniweb.github.io/unipress'
 const DEFAULT_BUILT_ENTRY = 'dist/foundation.js'
 
 function getRegistryBase() {
@@ -49,8 +59,15 @@ function getRegistryBase() {
   return raw.replace(/\/$/, '')
 }
 
+// Build the URL for a registry ref. The namespace is preserved in the
+// returned URL only when the base wants it; for the GH Pages distribution
+// the namespace is implicit and the path is <base>/foundations/<name>/<ver>/.
+// If a custom UNIWEB_REGISTRY_URL needs the namespace in the path, it can
+// hold a path prefix that resolves accordingly (e.g., set
+// `UNIWEB_REGISTRY_URL=https://my.host/by-ns/uniweb` and live without the
+// per-namespace split, or maintain a redirect rule on that host).
 function buildRegistryUrl(namespace, name, version) {
-  return `${getRegistryBase()}/registry/packages/${namespace}/${name}/${version}/foundation.js`
+  return `${getRegistryBase()}/foundations/${name}/${version}/foundation.js`
 }
 
 export async function resolveFoundationRef(ref, { anchorDir, onProgress = () => {} } = {}) {