@shoalrun/cli 0.1.0-alpha.13 → 0.1.0-alpha.15

package/CHANGELOG.md

@@ -1,5 +1,38 @@
 # Changelog
 
+## 0.1.0-alpha.15 — 2026-11-03
+
+- Opt into `profiles.requireClassification` to reject unclassified public pages
+  before customer selection. Declare `shared: true` or page feature requirements;
+  shared pages can retain feature-gated sections. Generated API references accept
+  explicit API or OpenAPI operation declarations.
+- Packaged authoring, setup, and recipe skills explain customer-edition workflows,
+  including external profiles, SKU revisions, grandfathered grants, strict page
+  classification, conditional sections, and checks for excluded content.
+
+- Build customer-specific documentation from an external deployment profile.
+  Resolve versioned SKU mappings and direct feature grants, including
+  grandfathered features without a SKU; select pages and conditional sections
+  consistently in websites and content exports.
+- Supply deployment-owned titles, logos, favicons, theme choices, links, and
+  publication subsets without storing customer profiles in the shared repo.
+  Capture declared external inputs for validation and preview, and keep profile
+  sources out of published dependency metadata.
+- Profiled API builds support selected references and focused operation contracts;
+  full-source downloads and standalone schema embeds are rejected.
+
+See [deployment profiles](DEPLOYMENT-PROFILES.md) for configuration and current limits.
+
+## 0.1.0-alpha.14 — 2026-10-30
+
+- Keep selected text readable in light and dark modes by pairing the selection
+  background with its contrasting foreground color.
+- Let paragraphs and ordinary lists fill their containers in wide, landing, and
+  splash layouts, including nested sections. Standard pages retain the 68ch
+  reading measure; hero text and other components keep their own limits.
+
+Upgrade to alpha.14 and rebuild your site to receive these styling fixes.
+
 ## 0.1.0-alpha.13 — 2026-10-28
 
 Use documentation as content for applications, agents, services, and publishing

package/DEPLOYMENT-PROFILES.md

@@ -0,0 +1,287 @@
+# Deployment-specific documentation
+
+Build separate documentation editions from one content project. Each deployment
+supplies its own profile file; profiles do not need to live together or belong in
+the shared repository. A profile selects purchased SKU revisions, additional
+features, branding, and documentation versions.
+
+All names and domains below are fictional. Keep actual customer profiles and
+branding in their deployment environments.
+
+## Define products in the shared project
+
+Add a `profiles` section to `docs.config.yaml`:
+
+```yaml
+profiles:
+  manifest: ./sku-manifest.yaml
+  required: true
+  pruneNavigation: true
+```
+
+`manifest` resolves relative to the configuration file declaring it. `required`
+defaults to `true`; builds must explicitly supply a profile. `pruneNavigation`
+defaults to `false`. Enable it to remove navigation targets known to be excluded
+and collapse empty groups. Unknown targets still fail validation.
+
+Define stable feature IDs and explicitly versioned SKU mappings:
+
+```yaml
+# sku-manifest.yaml
+schemaVersion: 1
+features:
+  analytics: { description: Analytics reports }
+  connectors: { description: External data connectors }
+  reports.classic: { lifecycle: deprecated }
+skus:
+  professional:
+    revisions:
+      "2025-04":
+        features: [analytics, reports.classic]
+      "2026-10":
+        features: [analytics, connectors]
+```
+
+Keep historical revisions unchanged when packaging changes. The compiler cannot
+reconstruct an old purchase from today's catalog or enforce that past revisions
+were never edited. Retain the manifest revision used for each deployment.
+
+Feature definitions accept optional `description` and `lifecycle` (`active`,
+`deprecated`, or `retired`). Lifecycle labels do not grant or remove features.
+
+## Supply one profile per deployment
+
+The deployment can mount or generate this file outside the documentation repo:
+
+```yaml
+schemaVersion: 1
+skus:
+  - { id: professional, revision: "2026-10" }
+features:
+  - reports.classic
+site:
+  title: Example Partner documentation
+  origin: https://docs.partner.example
+  logo: ./brand/logo.svg
+  favicon: ./brand/icon.png
+theme:
+  palette: kelp
+publications:
+  enabled:
+    - { channel: production, version: current, language: en }
+```
+
+SKU features and explicit `features` form an additive set. An explicit feature
+needs no SKU: use it for standalone purchases or grandfathered functionality.
+Duplicate grants are harmless. To build only shared content, supply `features: []`
+with no SKU grants. Missing input never falls back to granting every feature.
+Unknown features, SKUs, and SKU revisions fail the build. Use an empty list rather
+than `null`; malformed grant lists are rejected.
+
+Publication selection is optional and must be a nonempty subset of the shared
+project's `publications.enabled`. Use existing versions for older instructions.
+A grandfathered feature does not automatically enable old-version content.
+
+```sh
+shoalrun build docs.config.yaml site-dist --profile /run/config/docs-profile.yaml
+shoalrun export docs.config.yaml --out content-dist --profile /run/config/docs-profile.yaml
+```
+
+Exports with multiple enabled publications still need their normal explicit
+publication selection. Each deployment should use its own output directory.
+
+The CLI profile path resolves from the current working directory. Profile logo
+and favicon paths resolve from the profile's directory and must stay inside it.
+Only explicitly declared assets are read; Shoalrun does not discover other
+profiles in the directory. Shared configuration paths keep their existing origins.
+
+Profiles accept these settings:
+
+| Setting | Supported values |
+| --- | --- |
+| `schemaVersion` | Required; `1`. |
+| `skus` | List of explicit `{ id, revision }` pairs. |
+| `features` | List of directly granted feature IDs. Declare this or `skus`, even when empty. |
+| `site` | `title`, `origin`, `basePath`, `logo`, `favicon`, `header`, `footer`, `indexing`. |
+| `theme` | `preset`, a built-in `palette` name, `mode`, `toggle`. |
+| `variables` | Project-level string, number, or boolean values for existing typed snippets. |
+| `publications` | An `enabled` subset using existing publication coordinates. |
+
+Settings use their ordinary Shoalrun shapes and validation. A profile is not a
+general configuration overlay: it cannot change content sources, register plugins,
+replace the SKU catalog, change access policy, or inherit another profile.
+Profile-level CSS, custom fonts, and file-backed palettes are not supported.
+Existing snippet variable precedence and snippet-only `<Var>` placement remain
+unchanged; profile variables are not immutable branding tokens.
+
+`site.logo` accepts a local SVG or PNG, also in ordinary shared config. The masthead
+keeps the site title as its accessible label and displays the logo alongside it.
+
+## Select pages and sections
+
+By default, you do not need to mark every page. Pages declare feature requirements, not SKU
+IDs. A page with no `requires`, either authored or inherited from frontmatter
+defaults, is shared across customer editions. Common setup and introductions can
+remain unmarked.
+
+Shared pages still need to pass access, publication, language, and facet rules.
+Draft pages stay excluded from ordinary builds; older instructions need their
+publication enabled.
+
+After those rules pass, feature selection follows this table. Grants may come
+from SKUs or direct entries:
+
+| Page requirements | No granted features | Analytics only | Analytics and Connectors |
+| --- | --- | --- | --- |
+| No authored or inherited requirements | Included | Included | Included |
+| `allOf: [analytics]` | Omitted | Included | Included |
+| `allOf: [analytics, connectors]` | Omitted | Omitted | Included |
+| `anyOf: [analytics, connectors]` | Omitted | Included | Included |
+
+Forgetting a requirement makes a feature-specific page shared. Shoalrun does not
+infer requirements from folders, titles, product metadata, or navigation labels.
+Enable `profiles.requireClassification: true` to require a deliberate
+classification on each publishable source page.
+
+### Require explicit classification
+
+For customer deployments that should reject unclassified content, add
+`requireClassification: true` to the shared `profiles` configuration. It defaults
+to `false`, preserving shared-by-default behavior in existing projects.
+
+```yaml
+profiles:
+  manifest: ./sku-manifest.yaml
+  required: true
+  pruneNavigation: true
+  requireClassification: true
+```
+
+Each public page in the shared project's enabled publications must explicitly
+write `shared: true` or `requires` in its source frontmatter. Missing classification
+fails with the source filename before customer feature or publication selection.
+Drafts and pages outside the shared enabled publications do not need classification
+for that build. A later SKU or publication selection cannot bypass this check.
+Builds, exports, and isolated authoring validation use the same policy.
+
+```yaml
+# Shared page frontmatter fragment
+shared: true
+```
+
+Do not combine `shared: true` and `requires` on one page; `shared: false` is invalid.
+`shared` cannot appear in frontmatter defaults or enforced settings. Inherited
+feature requirements still restrict content, but do not satisfy classification.
+Review pages reported by build errors rather than automatically marking them all
+shared. Templates can write the chosen classification into each new page.
+
+This catches missing declarations, not incorrect choices or ungated paragraphs
+inside a shared page. Classification is a publishing policy, not authentication.
+
+### Restrict a whole page or section
+
+Restrict a feature-specific page in its frontmatter:
+
+```yaml
+requires:
+  allOf: [analytics, connectors]
+```
+
+Use `anyOf` for alternatives. If both clauses appear, both must pass. Clauses must
+be nonempty lists of declared feature IDs. A page whose resolved requirements do
+not match the profile is omitted. Requirements combine with existing access,
+publication, and facet selection; they cannot widen those rules.
+
+For part of a shared page, including one marked `shared: true`:
+
+```mdx
+<ForFeature allOf="analytics connectors">
+
+## Connect your reports <Anchor id="connect-reports" />
+
+Instructions requiring both features.
+
+</ForFeature>
+```
+
+`allOf` and `anyOf` attributes contain whitespace-separated IDs. Conditions are
+validated before rendering. Excluded branches contribute no links, snippets,
+API embeds, images, or text to the output. Explicit root section anchors remain
+stable when adjacent conditional content disappears. Conditions also work in
+snippets and named snippet exports.
+
+Text outside `<ForFeature>` stays shared. Excluding a block leaves the rest of
+the page in the edition. A matching block cannot restore a page excluded by its
+page-level requirements. With `features: []` and no SKU grants, eligible shared
+pages and text remain while feature-dependent pages and blocks are omitted.
+
+Links remaining in prose must target selected content. Shoalrun reports excluded
+document targets as errors instead of deleting the links. Put the surrounding
+paragraph in an appropriate condition, or link a shared overview. A migration
+overview can use `anyOf: [reports.classic, reports.next]` when either audience needs
+it. Replacement and migration references must still resolve in their publication.
+
+`site.contentFilter` retains its existing relevance-filter behavior. Browser reader
+filters only change visibility; use requirements for build-time exclusion.
+
+### Classify generated API pages
+
+Strict mode accepts an explicit `shared: true` or `requires` on the API definition
+beside `generateReferences`. An OpenAPI operation can instead declare
+`x-shoalrun-shared: true` or `x-shoalrun-requires: {allOf: [analytics]}`.
+API-level feature requirements still restrict every operation. Do not combine
+shared and requirements on the same declaration. General frontmatter defaults
+do not count; classify operations individually when their requirements differ.
+Authored API reference pages follow the ordinary source-page rule.
+
+## Validate the deployment edition
+
+Use the same profile when recording a baseline and validating:
+
+```sh
+shoalrun docs baseline --out .shoalrun/baseline.json --profile /run/config/docs-profile.yaml
+shoalrun docs validate --baseline .shoalrun/baseline.json --profile /run/config/docs-profile.yaml
+```
+
+Explicit `--file` and `--id` validation also accept `--profile`. Project inspection
+and source reads accept it too. Review and preview use the resulting report as
+usual and serve the captured edition. Profiles and declared branding files are
+captured into bounded private validation artifacts even when mounted outside the
+project. Other deployment files are not scanned. Symlink substitutions of
+captured branding inputs invalidate validation and cannot enter a later snapshot. Profile, asset, and catalog edits
+make prior validation stale. Excluded affected pages remain listed in coverage with
+a warning that their rendered content was not checked; validate another profile
+that includes them before accepting their content changes. Treat validation reports and artifact directories as
+private; they contain selected customer inputs.
+
+A successful normal site build writes `.shoalrun/profile-selection.json` with
+resolved features, grant sources, and page/section decisions. The compile/export
+APIs also return `profileSelection` to their caller. These reports are local build
+information, not served metadata. The report describes a build candidate; match
+its `buildId` to the output before treating it as a receipt for that output. A
+report write failure leaves the previous website intact. Public outputs omit the profile and branding
+source filenames; the intended branding is present in the website.
+
+## API and hosting boundaries
+
+Generated OpenAPI operations can declare `x-shoalrun-requires` with the same
+`allOf`/`anyOf` shape. API definitions and explicit operation bindings also accept
+`requires`. An authored reference page's requirements remain effective when
+automatic reference generation is enabled. Generated reference pages also respect
+requirements inherited through frontmatter defaults.
+
+Profiled builds reject full OpenAPI source publication, because hiding reference
+pages does not remove operations from that source. Use `source.publish: false`
+and `source.focused: true` for focused operation downloads. Operation embeds
+respect selection. Standalone `<ApiSchema api="..." schema="..." />` embeds are
+not supported in profiled builds; use an eligible operation embed instead.
+
+Static `vercel build --profile FILE` is supported. Profiled chat-function builds
+are not supported. Other commands without a profile option, including `dev` and
+checked-plan authoring, do not yet resolve deployment editions; use build/serve
+or captured validation/preview.
+
+Shoalrun does not fetch billing records, infer contract terms, expire grants, or
+authenticate customers. The deployment supplies the declared edition and the
+host controls who can retrieve it. Reuse an artifact only when all inputs,
+including branding, origin, publication selection, and grants, are identical.

package/README.md

@@ -9,13 +9,13 @@ This package provides the `shoalrun` CLI, starter projects, agent skills, and of
 From the project where you want to keep your documentation:
 
 ```sh
-npm install --save-dev --save-exact @shoalrun/cli@0.1.0-alpha.13
+npm install --save-dev --save-exact @shoalrun/cli@0.1.0-alpha.15
 ```
 
 If you previously used the private GitHub Packages alpha, check `npm config get @shoalrun:registry`. Remove or replace any `@shoalrun:registry=https://npm.pkg.github.com` entry in your project or user `.npmrc`. You can explicitly select the public registry for the upgrade:
 
 ```sh
-npm install --save-dev --save-exact @shoalrun/cli@0.1.0-alpha.13 --@shoalrun:registry=https://registry.npmjs.org
+npm install --save-dev --save-exact @shoalrun/cli@0.1.0-alpha.15 --@shoalrun:registry=https://registry.npmjs.org
 ```
 
 Commit the updated package manifest and lockfile together. Check that the lockfile resolves `@shoalrun/cli` from `registry.npmjs.org`. Keep any credentials needed by other private dependencies; Shoalrun itself no longer needs a package token.
@@ -99,6 +99,9 @@ not section redaction or host authorization.
 See [the runnable faceted-sites example](example-configs/faceted-sites/README.md)
 for main, developer, and regional sites built from one source directory.
 
+For deployment-owned SKU selections, direct or grandfathered feature grants, and
+branding supplied outside the shared repository, see [deployment profiles](DEPLOYMENT-PROFILES.md).
+
 ## Export content into an application
 
 Export pages from the same source into a portable directory for an application's

package/agent-docs/.well-known/shoalrun/navigation/project-updates-50f26fe22670.txt

@@ -16,13 +16,17 @@ Full-page token counts use cl100k_base. Navigation section ID: project-updates.
 
 - [Content delivery, verification dates, and clearer references](https://www.shoalrun.com/changelog/2026-10-28.md) — ID: change.2026-10-28. changelog-entry; 1393 tokens. Reuse documentation through static bundles or REST, display technical verification dates, and find clearer API and layout guidance.
 
+- [Readable selections and wider layouts](https://www.shoalrun.com/changelog/2026-10-30.md) — ID: change.2026-10-30. changelog-entry; 507 tokens. Keep selected text readable and let paragraphs and lists fill expanded layouts.
+
+- [Customer documentation editions](https://www.shoalrun.com/changelog/2026-11-03.md) — ID: change.2026-11-03. changelog-entry; 779 tokens. Build branded customer editions from purchased and grandfathered features without storing customer profiles in the shared repository.
+
 - [Authoring snapshot previews and review reports](https://www.shoalrun.com/changelog/authoring-preview.md) — ID: change.authoring-preview. changelog-entry; 551 tokens. Snapshot previews with coverage and freshness reports.
 
 - [Agent authoring, search, and documentation answers](https://www.shoalrun.com/changelog/authoring-search.md) — ID: change.authoring-search. changelog-entry; 466 tokens. Reviewed agent drafts, search improvements, and answer context.
 
 - [Working-tree authoring tools](https://www.shoalrun.com/changelog/authoring-tools.md) — ID: change.authoring-tools. changelog-entry; 378 tokens. Project discovery and captured working-tree validation.
 
-- [Changelog](https://www.shoalrun.com/changelog.md) — ID: reference.changelog. reference; 1074 tokens. Compiler, CLI, and reader changes.
+- [Changelog](https://www.shoalrun.com/changelog.md) — ID: reference.changelog. reference; 1202 tokens. Compiler, CLI, and reader changes.
 
 - [MCP hosting, analytics, and component improvements](https://www.shoalrun.com/changelog/2026-10-17-mcp-hosting.md) — ID: change.mcp-hosting. changelog-entry; 1145 tokens. MCP hosting, analytics, and shared component content.
 

package/agent-docs/SNAPSHOT.json

@@ -1,9 +1,9 @@
 {
   "schemaVersion": 1,
   "sourceRepository": "https://github.com/shoalrun/docs",
-  "sourceCommit": "fe92983e9f5710d9c2265972a2477448df4ae82d",
-  "siteBuildId": "38aac8472fa1fad778acd5b5bdc30067474eca35755706d09f916914326ed2f0",
-  "manifestDigest": "c99f0684ea93c4add58ddee1fd19dc82fa1acd9099d6cc2b4b226a0ef85302fe",
-  "indexDigest": "f38899eb2e53af8600714002a64538fb436d3cf90fa8e1247d3e892ef703fc48",
-  "packageIntegrity": "sha512-Qs6yv+QFvt6L5huiKFQfIT5FYexxbSokwUVUnxIrXUx2TtY/VTdG0EKAJJuCLLi6FcrYVbnI/mC9uWqJ9nflsw=="
+  "sourceCommit": "52c055cc160abbcb931bacbd8fcd209ce834cb26",
+  "siteBuildId": "c8c2a551d388148cf830e85bea3a58118a3a935dc91fa043ab2cd2a178ff9c6c",
+  "manifestDigest": "3c6af9a8161232cd4e824e72a427fb2b2a21963939a761a5f0f3557415dba580",
+  "indexDigest": "a6153f8a9a12541db3a6d1608c33da30ad329a6ad1653324f308dbd824bd9c10",
+  "packageIntegrity": "sha512-2Of7hhwylA4zWfoWIISM+0E63RzMhK9yI/NErSoNaUhquYQSD8iED1AWiUzqabnE0hg9rdtxCt82ws5+R9D3bQ=="
 }

package/agent-docs/changelog/2026-10-30.md

@@ -0,0 +1,43 @@
+---
+id: change.2026-10-30
+title: Readable selections and wider layouts
+summary: Keep selected text readable and let paragraphs and lists fill expanded layouts.
+type: changelog-entry
+area:
+  - appearance
+  - project
+subarea:
+  - appearance-layouts
+  - project-releases
+canonical: /changelog/2026-10-30
+date: 2026-10-30
+releaseVersion: 0.1.0-alpha.14
+---
+
+# Readable selections and wider layouts
+
+> Documentation index: [llms.min.txt](https://www.shoalrun.com/llms.min.txt) · Document manifest: [documents.json](https://www.shoalrun.com/documents.json)
+
+Navigation section: [Project](https://www.shoalrun.com/.well-known/shoalrun/navigation/project-updates-50f26fe22670.txt) (ID: project-updates). [All sections and pages](https://www.shoalrun.com/llms.min.txt)
+
+Breadcrumbs: [Project](https://www.shoalrun.com/status.md) > Changelog > Readable selections and wider layouts
+
+**Published: 2026-10-30.**
+
+**Version: 0.1.0-alpha.14.**
+
+Alpha.14 fixes selected-text contrast and paragraph widths in expanded layouts. Upgrade to CLI `0.1.0-alpha.14` and rebuild your site to receive both fixes. No configuration changes are needed.
+
+## Read selected text
+
+Text selection now pairs the highlight background with its contrasting foreground. Previously, selection used the heading ink color, which could become difficult to read in dark mode. The selection pair passes the contrast checks across all six built-in palettes in light and dark modes.
+
+## Fill expanded layouts
+
+Paragraphs and ordinary lists now fill their available containers in `wide`, `landing`, and `splash` layouts, including nested sections. Previously, these elements kept a 68-character reading limit even when the surrounding layout was wider.
+
+Standard documentation pages retain that reading limit. Splash sections remain centered within the landing width, and hero text and other components keep their own limits. See [page layouts](https://www.shoalrun.com/styling/layouts.md).
+
+## HTML, Markdown, and agents
+
+These fixes affect browser colors and line widths. Markdown content, page identities, and agent retrieval contracts stay the same. Selecting text and resizing the page need no JavaScript.

package/agent-docs/changelog/2026-11-03.md

@@ -0,0 +1,56 @@
+---
+id: change.2026-11-03
+title: Customer documentation editions
+summary: Build branded customer editions from purchased and grandfathered
+  features without storing customer profiles in the shared repository.
+type: changelog-entry
+area:
+  - publishing
+  - authoring
+  - project
+subarea:
+  - publishing-configuration
+  - authoring-metadata
+  - project-releases
+canonical: /changelog/2026-11-03
+date: 2026-11-03
+releaseVersion: 0.1.0-alpha.15
+---
+
+# Customer documentation editions
+
+> Documentation index: [llms.min.txt](https://www.shoalrun.com/llms.min.txt) · Document manifest: [documents.json](https://www.shoalrun.com/documents.json)
+
+Navigation section: [Project](https://www.shoalrun.com/.well-known/shoalrun/navigation/project-updates-50f26fe22670.txt) (ID: project-updates). [All sections and pages](https://www.shoalrun.com/llms.min.txt)
+
+Breadcrumbs: [Project](https://www.shoalrun.com/status.md) > Changelog > Customer documentation editions
+
+**Published: 2026-11-03.**
+
+**Version: 0.1.0-alpha.15.**
+
+Alpha.15 lets independent deployments build customer documentation editions from one shared content project. Each deployment supplies its own profile for purchased products, grandfathered features, branding, and publication selection. Customer profiles can stay outside the shared repository.
+
+Upgrade to CLI `0.1.0-alpha.15` and rebuild your site and content exports to use the feature. Existing projects keep their current behavior unless they enable deployment profiles. See [Build customer documentation editions](https://www.shoalrun.com/publish/deployment-profiles.md) for the complete workflow.
+
+## Select purchased and grandfathered features
+
+A shared stock keeping unit (SKU) manifest maps explicit product revisions to feature IDs. Profiles combine those grants with direct feature entries, including features customers still own without a SKU. Historical revisions remain selectable; lifecycle labels do not revoke grants or automatically select older documentation versions.
+
+Pages use feature requirements, and `<ForFeature>` selects sections inside shared pages. Selection removes excluded content from the build instead of hiding it in the browser. Deployment profiles can also apply supported titles, logos, favicons, theme choices, links, and publication subsets.
+
+## Require deliberate page classification
+
+By default, pages without feature requirements remain shared. Enable `profiles.requireClassification: true` to require each eligible source page to explicitly declare `shared: true` or feature requirements. Inherited defaults do not satisfy the check, and missing classification fails before customer selection.
+
+Shared pages can still contain feature-specific sections. Classification catches forgotten declarations; authors must still review the content and place requirements around product-specific instructions.
+
+## Validate each edition
+
+Pass the same external profile to baseline capture, authoring validation, build, and export. Validation captures the profile and its declared assets; later changes make that evidence stale. The packaged authoring, setup, and recipe skills explain this workflow and how to check included and excluded content.
+
+Profiled API builds support selected references and focused operation contracts. Full raw OpenAPI downloads, standalone schema embeds, and profiled chat-function builds are not supported. Use build/serve or snapshot validation/preview rather than `dev` for customer editions.
+
+## HTML, Markdown, and agents
+
+The compiler applies feature selection to HTML, Markdown, search, discovery, and content exports. Agents receive the selected content rather than browser-hidden alternatives. Pages excluded by the chosen profile have not had their rendered content validated; check another profile that includes a changed page before accepting that edit. Customer access to the resulting edition remains the deployment's responsibility.

package/agent-docs/changelog.md

@@ -16,12 +16,28 @@ Navigation section: [Project](https://www.shoalrun.com/.well-known/shoalrun/navi
 
 Breadcrumbs: [Project](https://www.shoalrun.com/status.md) > Changelog > All changes
 
-**Updated: 2026-10-29.**
+**Updated: 2026-11-03.**
 
 Updates to Shoalrun and its documentation. Each entry identifies the affected versions and any upgrade steps. Earlier entries retain their private-prototype release context.
 
 ## Latest changes
 
+- 2026-11-03
+
+  Version 0.1.0-alpha.15
+
+  [Customer documentation editions](https://www.shoalrun.com/changelog/2026-11-03.md)
+
+  Build branded customer editions from purchased and grandfathered features without storing customer profiles in the shared repository.
+
+- 2026-10-30
+
+  Version 0.1.0-alpha.14
+
+  [Readable selections and wider layouts](https://www.shoalrun.com/changelog/2026-10-30.md)
+
+  Keep selected text readable and let paragraphs and lists fill expanded layouts.
+
 - 2026-10-28
 
   Version 0.1.0-alpha.13