plum-cms 0.2.2 → 0.3.0

data/docs/comments.md

@@ -0,0 +1,140 @@
+# Comments and discussions
+
+Plum 0.3 adds optional discussions for CMS entries and application models. The feature is off by default. The new engine migration is required on every upgrade to 0.3.0, even if comments remain disabled:
+
+```sh
+bin/rails plum:install:migrations
+bin/rails db:migrate
+```
+
+## Enable and connect authentication
+
+```ruby
+Plum.configure do |config|
+  config.comments.enabled = true
+  # A persisted, GlobalID-compatible account, authenticated by YOUR application.
+  # Check email verification, suspension, membership, etc. here as appropriate.
+  config.comments.commenter_resolver = ->(controller) {
+    user = controller.current_reader
+    user if user&.email_verified? && !user.suspended?
+  }
+  config.comments.author_name_resolver = ->(user) { user.display_name }
+  config.comments.login_url_resolver = ->(controller) { controller.main_app.new_session_path }
+  config.comments.subject_url_resolver = ->(controller, subject) {
+    controller.main_app.lesson_path(subject.slug)
+  }
+end
+```
+
+Reader authentication is independent of `Plum.current_user` and never grants CMS access. By default there is no commenter, names display as “Reader,” no badge is added, and new comments require approval. The host must supply a verified account, a safe public display name, and any additional account/IP abuse protection. The built-in write limit is one comment per reader per discussion every ten seconds; it is not a global anti-spam service.
+
+Enable comments on a content type in the control panel, or set `comments_enabled: true` on `Plum::ContentType`. Each entry has a `comments_mode`: `inherit`, `open`, `closed` (readable), or `disabled` (hidden). Unpublished/future entries are never publicly accessible through the built-in entry endpoint. Closing a discussion stops new comments and replies; reports remain possible.
+
+For restricted content, configure **all** relevant actions. Read authorization is also required for creating and reporting. Moderator authorization deliberately can include unpublished content:
+
+```ruby
+config.comments.entry_authorizer = ->(controller, action, entry) {
+  action == :moderate ? controller.can_moderate?(entry) : controller.can_read?(entry)
+}
+```
+
+The callbacks receive `:read`, `:create`, `:report`, or `:moderate`. Enforce parent course visibility, enrollment, paid access, and group membership here: a published lesson alone does not prove access to its course. Site membership is independently checked on every request.
+
+## Application models
+
+```ruby
+class Lesson < ApplicationRecord
+  include Plum::Commentable
+  belongs_to :site, class_name: "Plum::Site"
+
+  # Override these methods when your schema differs:
+  def plum_comment_site = site
+  def plum_discussion_title = title
+  def plum_comments_enabled? = published?
+  def plum_comments_open? = published? && !archived?
+end
+
+Plum.configure do |config|
+  config.comments.register :lessons,
+    resolve: ->(controller, site, id) { Lesson.where(site: site).find(id) },
+    authorize: ->(controller, action, lesson) { controller.allowed?(action, lesson) }
+end
+```
+
+Registration is required. Request parameters never choose arbitrary model classes or resolve arbitrary GlobalIDs. Integer and UUID subject IDs are supported. Each subject has one discussion, with dependent cleanup when the subject is destroyed. Register a single stable handle per model; changing handles requires migrating existing discussion `subject_handle` values. `entries` is reserved for Plum entries.
+
+## Rendering
+
+By default, discussions render inside the active Plum theme's `layouts/base.liquid`, inheriting the same theme settings, custom CSS, fonts and colors. Override any of these files in your theme:
+
+```
+templates/comments/show.liquid
+templates/comments/_comment.liquid
+templates/comments/_form.liquid
+templates/comments/_report.liquid
+```
+
+Liquid entry templates receive `entry.discussion_url` when comments are enabled for that entry. The bundled entry templates display a link automatically. Custom themes can use:
+
+```liquid
+{% if entry.discussion_url %}
+  <a href="{{ entry.discussion_url }}">Questions &amp; discussion</a>
+{% endif %}
+```
+
+This link is safe in static content; authorization and personalized forms are evaluated on the dynamic discussion page.
+
+Normal parent-theme inheritance applies to each template independently, then falls back to the bundled default. You can change the page structure, form layout, empty state, sign-in prompt, wording and styling without changing the gem. The discussion controller still enforces authorization, CSRF, validation and moderation.
+
+`discussion` includes `title`, `open`, `signed_in`, `back_url`, `login_url`, `previous_url`, `next_url`, `notices`, `stylesheet_url`, `comments`, `comments_html`, and `form_html`. Each approved comment includes `id`, `body`, `author_name`, `author_badge`, `date`, `created_at`, `parent_id`, `parent_author_name`, `pinned`, `video_seconds`, `video_time`, `reply_form_html`, and `report_form_html`. User-supplied text is **already HTML escaped** before entering Liquid: output it directly as `{{ comment.body }}`, without `escape` or decoding it. The HTML fragments are rendered from the theme's partials. No author account IDs, report details or unpublished comment bodies are exposed.
+
+Custom forms must retain the hidden `authenticity_token` with `discussion.csrf_token`, `method="post"`, and the supplied `discussion.post_url` or `comment.report_url`. Field names are `comment[body]`, optional `comment[parent_id]`/`comment[video_seconds]`, and `report[reason]`. Form partials receive `form.id` and `form.parent_id`. Themes can style the stable `.plum-discussion`, `.plum-comment`, `.plum-comment-body`, `.plum-comment-form`, and `.plum-comment-report-form` classes. The baseline CSS inherits fonts/colors and exposes `--plum-comment-border`, `--plum-discussion-title-size`, `--plum-comment-button-background`, and `--plum-comment-button-color` variables. Override the page template to omit the baseline stylesheet entirely.
+
+For an application such as Redeemer that renders its public site in Rails ERB, use `config.comments.renderer = :rails`. Override the engine's ERB views/layout in the host (see below) to reuse that application's design system.
+
+In a dynamic host Rails view, include `Plum::CommentsHelper` in the host helper module, then:
+
+```erb
+<%= plum_comments_link(@entry) %>
+<%= plum_comments_link(@lesson, handle: "lessons", label: "Ask a question") %>
+```
+
+Links open the engine's accessible discussion page, with forms, one level of replies, pagination, pinned comments and reporting. No JavaScript dependency is required. Replies to hidden/pending parents are hidden too. Bodies are plain text, escaped on output, and limited to 10,000 characters. Optional `comment[video_seconds]` stores a nonnegative integer timestamp (up to seven days); it does not synchronize YouTube comments.
+
+Override `app/views/layouts/plum/discussion.html.erb` or `app/views/plum/discussions/{show,_comments,_form}.html.erb` in the host for full branding. The default layout loads `plum/comments.css`. Controller paths and route helpers are engine scoped; use `plum.discussion_path(handle: "entries", subject_id: entry.id)` from a host. The helper uses the mounted engine route proxy.
+
+Do not put user-specific comment forms in Liquid/static page caches. Discussion responses use `private, no-store`; the default design links from cached content to a dynamic page. No comments are added to the public content API automatically.
+
+## Moderation
+
+The Comments control-panel queue supports pending/approved/hidden/reported views, approval, hiding/restoring, pinning, report resolution, and closing/reopening discussions. Comment moderation actions record actor GlobalID, action, previous status and timestamp. Discussion close/reopen changes are not part of that comment audit trail. A moderator must pass both normal CMS authorization and the separate comments moderator check. Entry/model authorization is applied to each record too.
+
+Plum-managed editor/admin accounts can moderate by default. Host-authenticated applications **must explicitly configure** the moderator callback; generic CMS access alone is insufficient:
+
+```ruby
+config.comments.moderator_resolver = ->(controller, site) {
+  controller.current_user.can_moderate_comments?(site)
+}
+```
+
+`Plum.current_user` must return a persisted GlobalID-compatible moderator for the audit trail. Optional trusted-author settings:
+
+```ruby
+config.comments.auto_approve = ->(controller, author, subject) { author.trusted? }
+config.comments.author_badge_resolver = ->(controller, author) { "Pastor" if author.pastor? }
+```
+
+Badges, authors and approval status are always assigned by server callbacks, never request parameters. Author name/badge are snapshots. Applications own policies for account deletion, pseudonyms, retention, and removal of historical display names. GlobalIDs are stored as references, not automatically dereferenced when rendering, so deleted accounts do not break threads.
+
+## Notifications and backups
+
+After commit, `comment.created.plum` and `comment.updated.plum` events carry `comment_id`, `discussion_id`, `site_id`, and `status`. Subscribe with `ActiveSupport::Notifications` and enqueue your own job or Noticed notification. Fetch the current record and re-check publication and recipient authorization before sending; never email pending/private comments to unauthorized readers. Subscribers should handle their own delivery failures and avoid synchronous mail delivery.
+
+```ruby
+ActiveSupport::Notifications.subscribe("comment.created.plum") do |*args|
+  payload = args.last
+  CommentModerationNotificationJob.perform_later(payload[:comment_id])
+end
+```
+
+Comments, reports and audit records are application data: include the `plum_discussions`, `plum_comments`, `plum_comment_reports` and `plum_comment_moderations` tables in database backups. Site archive/config exports include comment settings, **not conversations or account identities**. Replacing/deleting a site's content deletes its discussions, so take a database backup before archive replacement. A site archive alone is not a backup of community data.

data/docs/plum-cli.md

@@ -84,12 +84,78 @@ accepted since the content is public. The host key persists at
 `~/.config/plum/tutorial_host_ed25519` so returning visitors don't get
 host-key warnings.
 
+## plum new — zero to running site
+
+```
+plum new client-site
+```
+
+Scaffolds a deploy-ready Plum site: `rails new`, the plum-cms gem, the
+install generator mounted at `/`, a prepared database, and a git history.
+It bootstraps its own toolchain the way connect bootstraps a server — no
+Ruby? It offers to install mise, then Ruby, then Rails, each step
+confirm-gated. It also refuses (clearly) to run inside an existing Rails
+app, and registers the new project in the global registry.
+
+## plum deploy — no registry, no CI
+
+```
+plum deploy [remote]
+```
+
+Ships the site with nothing but local Docker and SSH: builds the image
+locally (`--platform linux/amd64`), streams it to the server through the
+SSH connection (`docker save | gzip | ssh docker load` — no registry
+account anywhere), then has Once roll the app to it (`once update
+--image`, or `once deploy --host <once_app>` on first deploy) and waits
+for the container's health check to go green. Auto-update is switched
+off for these apps: there's no registry to poll, so the site changes
+when you deploy it — never by surprise. Currently `via: once` remotes.
+
+```
+plum deploy --preview
+```
+
+Ships the same image as a **separate Once app under a preview hostname** —
+the agency workflow: share the work-in-progress with a client before
+their domain points anywhere. With `preview_host:` set on the remote in
+plum.yml (e.g. `client.preview.your-agency.com` behind a wildcard A
+record) you get clean branded preview URLs; with nothing configured it
+auto-derives `<app>.<server-ip>.sslip.io` — magic wildcard DNS that
+resolves to your server with zero setup. Preview and production are
+independent apps, so previews never touch a live site.
+
+```
+plum promote [remote]
+```
+
+Go-live for a preview, in place: re-homes the preview app onto the
+production domain (`once update --host`) — same container, same
+database, all the content built during the preview — with TLS
+provisioned on the spot. Preflights that a preview exists, that the
+production hostname isn't already a separate app, and that DNS reaches
+the server (confirm to override for proxied DNS).
+
+The full story — one droplet, several client sites, honest costs — is
+[the zero-to-agency guide](zero-to-agency.md).
+
 ## Two layers of configuration
 
 This mirrors the Firebase CLI's model deliberately, because it solves the
 same two problems: "how does this directory reach its server" and "how do I
 work with a project without cd-ing into its directory first."
 
+Two words, two meanings — keep them straight:
+
+- A **project** is a site: `the-final-word`, `client-site`. That's what
+  the registry, `plum use`, and `--project NAME` refer to.
+- A **remote** is one *environment* of a site: `production`, `staging`.
+  That's the positional argument on commands — `plum pull production`,
+  `plum logs staging` — and the keys under `remotes:` in plum.yml.
+
+So `plum pull --project client-site staging` means "the staging
+environment of the client-site project."
+
 1. **`plum.yml`** — lives in a site's own repo, defines its **remotes**
    (servers). This is the source of truth for how to reach that one site.
 2. **The global project registry** (`~/.config/plum/config.yml`, or

data/docs/releases/0.3.0-validation.md

@@ -0,0 +1,15 @@
+# 0.3.0 release validation
+
+Validated October 5, 2026.
+
+- Ruby 3.3.1 / Rails 8.0.5: 238 tests, 950 assertions pass on SQLite and PostgreSQL.
+- Browser discussion lifecycle: posting, approval, public display and closing pass (10 assertions).
+- Redeemer mounted-engine consumer on Ruby 4.0.6 / Rails 8.1.3.1: 17 tests, 231 assertions pass. Mobile/desktop discussion pages render without overflow or JavaScript errors.
+- RuboCop: 227 files, no offenses. Importmap audit: no vulnerable versioned packages (Lexxy is unversioned and skipped by the audit).
+- Brakeman: seven existing findings outside comments; no new feature findings.
+- Full legacy CMS browser suite remains red. Failures in blueprint editing, writing mode, uploads and other existing CMS interactions were reproduced in a separate, unchanged 0.2.3 checkout. The new discussion browser test passes independently.
+- Engine/standalone migrations match. A fresh isolated database generated the committed schema; unrelated local analytics schema artifacts were removed. The built gem includes migrations, theme templates, controllers, helpers, styles and documentation.
+
+The owner requested independent review through the Claude CLI using `claude-fable-5-1`. Two read-only reviews were performed with that exact model. Initial findings about schema pollution and mandatory upgrade migrations were resolved. The follow-up reviewed theme inheritance, escaping, CSRF, authorization/context disclosure, assets and engine mounting and concluded: “no blockers found” and “0.3.0 is ready to publish.” Suggested polish for renderer configuration, page titles, inherited forms and nil predicates was implemented and tested afterward.
+
+Comments remain disabled by default. Database migration is required for every upgrade to 0.3.0. Reader authentication, notification delivery and account policy belong to the host application. Redeemer has branded discussion pages and moderation available, but public reader posting remains disabled until its member-account flow is implemented.

data/docs/zero-to-agency.md

@@ -0,0 +1,172 @@
+# Zero to Agency
+
+How to go from an empty directory to hosting client sites — with one
+cheap VPS, the `plum` CLI, and nothing else. No GitHub required, no
+container registry, no CI pipeline, no platform-as-a-service bill. Your
+laptop builds, your server runs, SSH connects them.
+
+The stack under the hood: Rails + Plum in a Docker container, managed by
+[Once](https://once.com) (37signals' single-container deploy tool) behind
+its bundled TLS-terminating proxy, on any Linux box. The examples use
+DigitalOcean; any VPS provider works the same way.
+
+## What you need
+
+- A [DigitalOcean](https://digitalocean.com) account (or any VPS provider)
+- Docker on your laptop (Docker Desktop or Docker Engine) — `plum deploy`
+  builds images locally
+- The `plum` CLI
+- Ruby and Rails — and if you don't have them, `plum new` offers to
+  install both for you (via [mise](https://mise.jdx.dev))
+
+## 1. Create the server
+
+In DigitalOcean: **Create → Droplet**. Ubuntu LTS, the $6/month size is
+enough to start (pick $12 for headroom). Add your SSH key if you have one
+— if you don't, that's fine: `plum connect` will generate one and offer
+to copy it over with the root password DigitalOcean emails you. Note the
+droplet's IP.
+
+That's the last time you touch a cloud dashboard.
+
+## 2. Create the site
+
+```bash
+plum new client-site
+cd client-site
+bin/rails server
+```
+
+You have a running Plum site at `http://localhost:3000` — the control
+panel is at `/cp`. Build the client's theme in `app/themes/`, model
+their content types in the CP (or as YAML in `plum/` — see
+`docs/config-as-code.md`), and load in their content.
+
+## 3. Connect the server
+
+```bash
+plum connect 203.0.113.5      # your droplet's IP
+```
+
+The wizard handles the entire first-contact ritual: SSH keys, passwordless
+login, detecting that this is a Once-shaped app, and — on a fresh droplet —
+**installing Docker Engine and Once for you** (each with your
+confirmation). When it asks for the app hostname, give it the client's
+real domain (`clientname.com`): that's how the server routes requests and
+provisions TLS.
+
+## 4. Point DNS
+
+At the client's DNS: an **A record** for their domain (and `www`) to the
+droplet's IP. **This must happen before the first deploy** — Once
+verifies `https://<domain>` end-to-end as the final step of a first
+deploy and rolls back if the domain doesn't reach the server yet
+(`plum deploy` checks this up front and warns you). Proxied DNS
+(Cloudflare in Full strict mode) is fine.
+
+Building ahead of a domain cutover? That's what previews are for:
+
+```bash
+plum deploy --preview
+```
+
+This ships the site as a *separate* Once app under a preview hostname —
+by default `<app>.<server-ip>.sslip.io`, magic wildcard DNS that reaches
+your server with zero configuration, so you have a shareable client
+preview URL before any real DNS exists. For branded previews, point one
+wildcard record (`*.preview.your-agency.com`) at the droplet and set
+`preview_host: client.preview.your-agency.com` on the remote in
+plum.yml.
+
+Iterate on the preview as long as you like — build the content, tune the
+theme, let the client click around. Then, when they flip DNS to the
+droplet:
+
+```bash
+plum promote
+```
+
+The preview app *becomes* the site: same container, same database, every
+word of content you built during the preview — it simply starts answering
+to the real domain, with TLS provisioned on the spot. No rebuild, no
+content migration, no separate go-live deploy. (If the site should live
+on its own droplet instead, `plum connect` it there and `plum deploy` —
+site archives carry the content across.)
+
+## 5. Deploy
+
+```bash
+plum deploy
+```
+
+Watch it go: the image builds on your laptop, streams to the server over
+SSH (`docker save | docker load` — this is why no registry account
+exists in this guide), Once starts it behind the proxy, and the CLI waits
+for the container to report healthy. `https://clientname.com` is live.
+
+Deploys are explicit — the site changes when you run `plum deploy`,
+never by surprise. Ship again any time with the same command.
+
+## 6. The agency rhythm
+
+Day-to-day, the CLI is your relationship with every client site:
+
+```bash
+plum pull                # production content → your laptop, any DB engine
+plum push                # content-model changes (plum/ YAML) → production
+plum check               # did anyone drift the model? (CI-friendly)
+plum logs --follow       # heroku-style tail, prettified
+plum backup              # timestamped archive on the server
+plum run -- TASK         # any rake task, any remote
+```
+
+Content pulls down, structure pushes up. Clients edit in `/cp` on
+production; you develop locally against a full copy of their real
+content. Turn on **static caching** (`docs/static-caching.md`) and the
+site serves rendered pages from disk — SQLite happily runs a
+production site on the smallest droplet, because cached reads never
+touch the database at all.
+
+## 7. The second client
+
+This is where it becomes an agency:
+
+```bash
+plum new second-client
+cd second-client
+plum connect             # the host prompt offers your existing server
+plum deploy
+```
+
+Once runs each site in its own container on the same box, routing by
+hostname, each with its own TLS certificate. A $6–12 droplet comfortably
+hosts several small client sites; each new client is marginal-cost-zero
+until the box runs hot. Manage the fleet from anywhere:
+
+```bash
+plum projects list       # every site you run
+plum use second-client   # switch the active project
+plum pull --project client-site   # or target one explicitly
+```
+
+## 8. When you outgrow one box
+
+- **More sites than one droplet likes**: create a second droplet,
+  `plum connect` the new sites there. The registry doesn't care how many
+  servers are behind it.
+- **A client needs Postgres** (heavy dynamic features): switch that app's
+  database and redeploy — `plum pull` still works across engines.
+- **Backups off the box**: `plum backup` writes archives on the server;
+  Once's auto-backup handles scheduling. Pull copies down with `plum pull`
+  or scp them to storage you control.
+
+## Costs, honestly
+
+| Thing | Cost |
+| --- | --- |
+| Droplet (several small sites) | $6–12/mo |
+| Domains | the client's problem |
+| Registry, CI, PaaS, per-seat CMS pricing | $0 — none exist in this setup |
+
+The whole model: you charge for design and content strategy; the
+infrastructure is a rounding error.

data/lib/generators/plum/install/install_generator.rb

@@ -30,7 +30,19 @@ module Plum
       def mount_engine
         return if options[:skip_route]
 
-        route %(mount Plum::Engine, at: "#{options[:mount_path]}")
+        # Mounted at "/", Plum serves every path the app doesn't claim — so
+        # it must come AFTER the app's own routes (notably `get "up"`, the
+        # health check load balancers and deploy tooling probe). Rails'
+        # `route` helper prepends, which would shadow them; append at the
+        # bottom of the block instead.
+        inject_into_file "config/routes.rb", before: /^end\s*\z/ do
+          <<~RUBY.indent(2)
+
+            # Plum last: mounted at #{options[:mount_path].inspect} it serves every path
+            # the app doesn't claim, so app routes (like /up) must come first.
+            mount Plum::Engine, at: #{options[:mount_path].inspect}
+          RUBY
+        end
       end
 
       def print_next_steps

data/lib/plum/comments/configuration.rb

@@ -0,0 +1,43 @@
+module Plum
+  module Comments
+    class Configuration
+      attr_accessor :enabled, :commenter_resolver, :moderator_resolver,
+                    :author_name_resolver, :author_badge_resolver, :auto_approve,
+                    :entry_authorizer, :login_url_resolver, :subject_url_resolver
+      attr_reader :subjects, :renderer
+
+      def initialize
+        @enabled = false
+        @renderer = :theme
+        # Deliberately separate from CMS authentication. Hosts supply verified readers.
+        @commenter_resolver = ->(_controller) { nil }
+        @moderator_resolver = lambda { |controller, _site|
+          user = Plum.current_user(controller)
+          Plum.configuration.authorize_with == :plum && user.is_a?(Plum::User) && %w[editor admin].include?(user.role)
+        }
+        @author_name_resolver = ->(_author) { "Reader" }
+        @author_badge_resolver = ->(_controller, _author) { nil }
+        @auto_approve = ->(_controller, _author, _subject) { false }
+        @entry_authorizer = ->(_controller, _action, _entry) { true }
+        @login_url_resolver = ->(_controller) { nil }
+        @subject_url_resolver = ->(_controller, _subject) { nil }
+        @subjects = {}
+      end
+
+      def renderer=(value)
+        raise ArgumentError, "Comments renderer must be theme or rails" unless %w[theme rails].include?(value.to_s)
+        @renderer = value.to_sym
+      end
+
+      # The resolver must return a record from the host's authorized tenant scope.
+      # Neither a model class nor a GlobalID is accepted from the HTTP client.
+      def register(handle, resolve:, authorize:)
+        key = handle.to_s
+        unless key.match?(/\A[a-z][a-z0-9_]*\z/) && key != "entries"
+          raise ArgumentError, "Use a lowercase subject handle other than entries"
+        end
+        @subjects[key] = { resolve: resolve, authorize: authorize }
+      end
+    end
+  end
+end

data/lib/plum/configuration.rb

@@ -1,4 +1,5 @@
 require_relative "content_source_registry"
+require_relative "comments/configuration"
 
 module Plum
   class Configuration
@@ -9,7 +10,7 @@ module Plum
                   :powered_by_name, :powered_by_url,
                   :static_cache_enabled, :static_cache_path, :config_path
     attr_writer :theme_paths
-    attr_reader :content_sources
+    attr_reader :content_sources, :comments
 
     def initialize
       @authorize_with = :plum
@@ -37,6 +38,7 @@ module Plum
       # nil = default to Rails.root/plum when the tasks are invoked.
       @config_path = nil
       @content_sources = ContentSourceRegistry.new
+      @comments = Comments::Configuration.new
       @current_site_resolver = ->(_controller) { Plum::Site.first_or_create_standalone! }
       @current_user_resolver = lambda { |controller|
         Plum::User.find_by(id: controller.session[:plum_user_id]) if controller.session[:plum_user_id]

data/lib/plum/engine.rb

@@ -30,10 +30,17 @@ module Plum
       end
     end
 
-    initializer "plum.importmap", before: "importmap" do |app|
-      if app.config.respond_to?(:importmap)
-        app.config.importmap.paths << root.join("config/plum_importmap.rb")
-      end
+    # Build a Plum-scoped importmap instead of merging Plum's pins into the
+    # host app's global importmap. Plum's layouts render this map (host JS stack
+    # + Plum's additions), while the host app's own pages keep a clean importmap
+    # free of Plum's controllers/lexxy/activestorage pins. Runs after the host's
+    # importmap is configured so we can copy its paths.
+    initializer "plum.importmap", after: "importmap" do |app|
+      next unless defined?(Importmap::Map) && app.config.respond_to?(:importmap)
+
+      Plum.importmap = Importmap::Map.new
+      Array(app.config.importmap.paths).each { |path| Plum.importmap.draw(path) }
+      Plum.importmap.draw(root.join("config/plum_importmap.rb"))
     end
   end
 end

data/lib/plum/version.rb

@@ -1,6 +1,6 @@
 module Plum
   module Version
-    STRING = "0.2.2"
+    STRING = "0.3.0"
   end
 
   VERSION = Version::STRING

data/lib/plum.rb

@@ -3,6 +3,13 @@ require_relative "plum/content_source"
 require_relative "plum/configuration"
 
 module Plum
+  class << self
+    # A Plum-scoped importmap (host pins + Plum's own pins), used only by Plum's
+    # layouts. Keeps Plum's controllers/lexxy/activestorage out of the host
+    # app's global importmap so a mounted Plum can't pollute the host's JS.
+    attr_accessor :importmap
+  end
+
   def self.table_name_prefix
     "plum_"
   end