plutonium 0.56.0 → 0.56.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: fdb3a70cfc50828cc986040543d72e8e576497deffb3304aac601b113c507370
-  data.tar.gz: 7901dd81e5a9f11519224695071e1fe76c3121e8d311d1b1d6d7445fb2179667
+  metadata.gz: 17f6996a0503aeccb6070cb0c379d09bfd253e2356a839745368bcaf0110e377
+  data.tar.gz: 0603760cfc2a10d6bedaa4b225b33fc5cf5b632a36829c4e6c9e9c4ce7b7971b
 SHA512:
-  metadata.gz: 3d89dc0f91a27bb0e0e1ac5503cb11059d35309767fa006c200216819e0c123d6d2a558a03ac162964527b992fabc974184d5f357f3b0389405f2c63a13bdfed
-  data.tar.gz: 584146030273aeac56b898049f4f9e6a05f364c1b334bdca4ef2e044288548f1277c4d419cf7051504d36e0fd32ffbe48a4540c03f7b80f08405f43b4a0313ab
+  metadata.gz: b77a88b0c0e04b5a9e143c88b292ec305f7d5c8ef74efe3e0891f20c772e63eef35383a7785338863f4cd9a942c5b76c94c1fa6fedc2995c41da8df680f1e390
+  data.tar.gz: 7dd9fd4420c8145227929c4f6ec434520c6701ea387767d9395bb74b413d2e99ce451611c89797604a1cf5a62bb51368a4aa2f5c79d1b698a1c11842979dcb29

data/.claude/skills/plutonium/SKILL.md

@@ -127,7 +127,7 @@ Meta-generators (`pu:saas:setup`) propagate flags to the generators they chain.
 
 1. **Load the bootstrap bundle** (or the targeted skill from the router table).
 2. **Generate** — `rails g pu:res:scaffold Model field:type ... --dest=main_app`.
-3. **Migrate** — `rails db:migrate`.
+3. **Migrate** — `rails db:prepare`.
 4. **Connect** — `rails g pu:res:conn Model --dest=portal_name`.
 5. **Customize** — edit definition / policy as needed.
 6. **Verify** — hit the route in the browser.

data/.claude/skills/plutonium-app/SKILL.md

@@ -62,7 +62,7 @@ rails generate pu:pkg:portal admin --auth=user
 
 # 4. First resource
 rails generate pu:res:scaffold Post user:belongs_to title:string 'content:text?' --dest=main_app
-rails db:migrate
+rails db:prepare
 
 # 5. Connect resource to portal
 rails generate pu:res:conn Post --dest=admin_portal

data/.claude/skills/plutonium-auth/SKILL.md

@@ -279,7 +279,7 @@ rails g pu:profile:setup date_of_birth:date bio:text \
 rails generate pu:profile:install bio:text avatar:attachment 'timezone:string?' \
   --dest=customer
 
-rails db:migrate
+rails db:prepare
 
 rails generate pu:profile:conn --dest=customer_portal
 ```

data/.claude/skills/plutonium-resource/SKILL.md

@@ -29,7 +29,7 @@ For tenancy / `associated_with` / `relation_scope`, load [[plutonium-tenancy]].
 1. Pick destination: `--dest=main_app` or `--dest=package_name`.
 2. Run `rails g pu:res:scaffold ResourceName field:type ... --dest=<dest>`.
 3. Review the generated migration — add cascade deletes, composite indexes, defaults.
-4. `rails db:migrate`.
+4. `rails db:prepare`.
 5. `rails g pu:res:conn ResourceName --dest=<portal_name>`.
 6. Customize the policy's `permitted_attributes_for_*` as needed.
 7. Open the portal route in the browser.
@@ -1050,6 +1050,10 @@ action :name,
   collection_record_action: true,
   bulk_action: true,
 
+  # Conditional visibility — display-only toggle, NOT authorization (see below).
+  # `-> { false }` keeps the route live but hides the button (e.g. API-only).
+  condition: -> { params[:beta] == "1" },
+
   # Grouping
   category: :primary,               # :primary, :secondary, :danger
   position: 50,
@@ -1062,6 +1066,36 @@ action :name,
   size:  :lg                        # :sm / :md / :lg / :xl / :auto / :full — overrides definition's modal size
 ```
 
+### Conditional Actions (`condition:`)
+
+Like `condition:` on inputs/displays/columns — define an action but render its **button** only when a runtime proc is truthy. The action and its route stay live either way; `condition:` only toggles the UI.
+
+Headline use case: **expose an action's endpoint without a button** — one you call from the API, a webhook, or another service. Hide it with an always-falsy condition; the route still works:
+
+```ruby
+# Defined and callable (API / programmatic), but no button anywhere:
+action :sync_inventory, interaction: SyncInventoryInteraction, condition: -> { false }
+
+# Per-record display state — object is the row/shown record:
+action :reopen, interaction: ReopenInteraction, condition: -> { object.closed? }
+
+# View/request-level toggle (feature flag, beta mode):
+action :preview, interaction: PreviewInteraction, condition: -> { params[:beta] == "1" }
+```
+
+Inside the proc, `object`/`record` is the contextual record — the row/shown record for **record** and **collection-record** actions, **nil** for **resource** and **bulk** actions (guard with `object&.…` if shared). Every other call delegates to the **view context**: `current_user`, `current_parent`, `params`, `request`, `allowed_to?`, `resource_record!`, etc. `object` is evaluated per row in tables/grids, so per-record show/hide works there.
+
+🚨 **`condition:` is NOT authorization — it only hides the button.** A hidden action still has a live route; anyone with the URL can trigger it. "Who may run this" belongs in the policy:
+
+```ruby
+# 🚫 WRONG — does not stop non-admins; the route is live.
+action :wipe, interaction: WipeInteraction, condition: -> { current_user.admin? }
+# ✅ RIGHT — authorization in the policy, enforced regardless of condition:
+def wipe? = current_user.admin?
+```
+
+The two compose: an action's button shows only when the policy permits **and** the condition is truthy; execution is gated by the policy alone. Use `object` in `condition:` for per-record *display*; use the policy for per-record *authorization*.
+
 `Action#with(...)` — actions are frozen value objects; clone with overrides:
 
 ```ruby

data/CHANGELOG.md

@@ -1,3 +1,16 @@
+## [0.56.1] - 2026-06-05
+
+### 🚀 Features
+
+- *(actions)* Add display-only condition: to actions
+
+### 🐛 Bug Fixes
+
+- *(dummy)* Version-adapt kitchen_sinks migration
+
+### 📚 Documentation
+
+- Recommend db:prepare, firm up README, document conditional actions
 ## [0.56.0] - 2026-06-05
 
 ### 🚀 Features

data/CONTRIBUTING.md

@@ -153,7 +153,7 @@ Use the dummy app:
 ```bash
 cd test/dummy
 rails g pu:res:scaffold TestModel name:string --dest=main_app
-rails db:migrate
+rails db:prepare
 bin/dev
 ```
 

data/README.md

@@ -2,8 +2,11 @@
 
 [![Gem Version](https://badge.fury.io/rb/plutonium.svg)](https://badge.fury.io/rb/plutonium)
 [![Ruby](https://github.com/radioactive-labs/plutonium-core/actions/workflows/main.yml/badge.svg)](https://github.com/radioactive-labs/plutonium-core/actions/workflows/main.yml)
+[![License: MIT](https://img.shields.io/badge/License-MIT-green.svg)](LICENSE.txt)
 
-Build production-ready Rails apps in minutes, not days. Convention-driven, fully customizable, and AI-ready. Plutonium picks up where Rails left off, adding application-level concepts that make building complex apps faster.
+**The Rails framework for things you should never write again.**
+
+Convention over configuration, extended to everything you keep rebuilding: **CRUD. Auth. Authorization. Multi-tenancy. Admin portals. Search, filters, bulk actions.** All generated. All customizable. All Rails.
 
 ## Quick Start
 
@@ -12,20 +15,36 @@ rails new myapp -a propshaft -j esbuild -c tailwind \
   -m https://radioactive-labs.github.io/plutonium-core/templates/plutonium.rb
 ```
 
-Then create your first resource:
+Then scaffold a resource, create a portal, and connect them:
 
 ```bash
 cd myapp
-rails g pu:res:scaffold Post title:string body:text --dest=main_app
-rails db:migrate
+
+# Scaffold a resource — model, migration, definition, policy
+rails g pu:res:scaffold Post title:string body:text published_at:datetime --dest=main_app
+rails db:prepare
+
+# Create a portal (web interface) and connect the resource to it
+rails g pu:pkg:portal app --public
+rails g pu:res:conn Post --dest=app_portal
+
 bin/dev
 ```
 
-Visit `http://localhost:3000` - you have a complete CRUD interface.
+Visit `http://localhost:3000/app/posts` — you have a complete CRUD interface.
 
-## What You Get
+## What You Stop Writing
 
-**Resource-oriented architecture** - Models, policies, definitions, and controllers that work together:
+Same scaffold command you already know. A very different surface area.
+
+```bash
+rails g scaffold Post ...              # Rails:     just CRUD
+rails g pu:res:scaffold Post ...       # Plutonium: full CRUD + search + filters + bulk actions
+```
+
+And it doesn't stop at scaffolds:
+
+**Resource-oriented architecture** — models, policies, definitions, and controllers that work together:
 
 ```ruby
 # Policy controls WHO can do WHAT
@@ -47,7 +66,7 @@ class PostDefinition < ResourceDefinition
 end
 ```
 
-**Packages for organization** - Split your app into feature packages and portals:
+**Packages and portals** — split your app into feature engines and themed web interfaces:
 
 ```bash
 rails g pu:pkg:package blogging      # Business logic
@@ -65,7 +84,7 @@ rails g pu:rodauth:account user
 **Multi-tenancy** with entity scoping:
 
 ```ruby
-# In portal engine
+# In a portal engine
 scope_to_entity Organization, strategy: :path
 # Routes become /organizations/:organization_id/posts
 ```
@@ -86,6 +105,13 @@ class PublishInteraction < ResourceInteraction
 end
 ```
 
+## Why Plutonium
+
+- **Convention over configuration** — extended to resources, policies, portals, and tenancy, not just routes and views.
+- **It's just Rails** — generated code lives in your repo. Edit it, override it, delete it. The "magic" is regular Ruby mixins you can read.
+- **Multi-tenant ready** — path or domain tenancy, scoped relations, invites and memberships out of the box.
+- **AI-readable** — predictable file layout and naming, plus built-in [Claude Code skills](.claude/skills) that teach AI assistants the patterns.
+
 ## Documentation
 
 Full documentation at **[radioactive-labs.github.io/plutonium-core](https://radioactive-labs.github.io/plutonium-core/)**
@@ -97,18 +123,14 @@ Full documentation at **[radioactive-labs.github.io/plutonium-core](https://radi
 
 ## Requirements
 
-- Ruby 3.2+
-- Rails 7.1+ (Rails 8 recommended)
+- Ruby 3.2.2+
+- Rails 7.2+ (Rails 8 recommended)
 - Node.js 18+
 
 ## Contributing
 
 See [CONTRIBUTING.md](CONTRIBUTING.md) for development setup and guidelines.
 
-## Status
-
-Plutonium is used in production but still evolving. APIs may change between minor versions. Pin your version in Gemfile.
-
 ## License
 
-MIT License - see [LICENSE](LICENSE).
+MIT License — see [LICENSE.txt](LICENSE.txt).

data/docs/getting-started/installation.md

@@ -15,7 +15,7 @@ After the template completes:
 
 ```bash
 cd myapp
-rails db:migrate
+rails db:prepare
 bin/dev
 ```
 
@@ -51,7 +51,7 @@ rails generate pu:core:install
 ```bash
 rails generate pu:rodauth:install
 rails generate pu:rodauth:account user
-rails db:migrate
+rails db:prepare
 ```
 
 For account options and customization, see [Reference › Auth](/reference/auth/) and [Guides › Authentication](/guides/authentication).

data/docs/getting-started/tutorial/02-first-resource.md

@@ -113,7 +113,7 @@ end
 ## Running the Migration
 
 ```bash
-rails db:migrate
+rails db:prepare
 ```
 
 ## Creating a Portal

data/docs/getting-started/tutorial/03-authentication.md

@@ -28,7 +28,7 @@ Plutonium supports multiple account types. For admins, use the dedicated `pu:rod
 
 ```bash
 rails generate pu:rodauth:admin admin
-rails db:migrate
+rails db:prepare
 ```
 
 For self-service user accounts, the corresponding command is `rails generate pu:rodauth:account user`.
@@ -151,7 +151,7 @@ Our blog needs users (authors) who can create posts. Let's create a User account
 
 ```bash
 rails generate pu:rodauth:account user
-rails db:migrate
+rails db:prepare
 ```
 
 This creates a `User` model similar to `Admin`, but with public registration enabled.
@@ -177,7 +177,7 @@ end
 Run the migration:
 
 ```bash
-rails db:migrate
+rails db:prepare
 ```
 
 Update the Post model to include the association:

data/docs/guides/adding-resources.md

@@ -29,7 +29,7 @@ Plutonium generates a basic migration. Before running it, edit `db/migrate/<time
 ### 3. Run the migration
 
 ```bash
-rails db:migrate
+rails db:prepare
 ```
 
 ### 4. Connect to a portal

data/docs/guides/authentication.md

@@ -16,7 +16,7 @@ rails generate pu:rodauth:install
 rails generate pu:rodauth:account user
 
 # 3. Run migrations
-rails db:migrate
+rails db:prepare
 
 # 4. Wire auth into a portal
 #    (when you run `pu:pkg:portal admin --auth=user`, this happens automatically)

data/docs/guides/creating-packages.md

@@ -40,7 +40,7 @@ packages/blogging/
 
 ```bash
 rails g pu:res:scaffold Blogging::Post title:string --dest=blogging
-rails db:migrate
+rails db:prepare
 ```
 
 ### 4. Expose it via a portal

data/docs/guides/multi-tenancy.md

@@ -42,7 +42,7 @@ rails g pu:res:scaffold Organization name:string:uniq slug:string:uniq --dest=ma
 
 ```bash
 rails g pu:res:scaffold Post organization:belongs_to title:string content:text --dest=main_app
-rails db:migrate
+rails db:prepare
 ```
 
 ### 3. Scope the portal to the entity

data/docs/guides/nested-resources.md

@@ -20,7 +20,7 @@ All of this happens with no manual route wiring — Plutonium generates it from
 ```bash
 rails g pu:res:scaffold Company name:string --dest=main_app
 rails g pu:res:scaffold Property company:belongs_to name:string --dest=main_app
-rails db:migrate
+rails db:prepare
 ```
 
 ### 2. Connect both to the portal

data/docs/guides/user-invites.md

@@ -49,7 +49,7 @@ rails g pu:invites:install \
 ### 2. Migrate
 
 ```bash
-rails db:migrate
+rails db:prepare
 ```
 
 ### 3. Connect to your portal

data/docs/guides/user-profile.md

@@ -55,7 +55,7 @@ By default the model is `{UserModel}Profile` (`UserProfile`, `StaffUserProfile`,
 ### 2. Migrate
 
 ```bash
-rails db:migrate
+rails db:prepare
 ```
 
 ### 3. Connect to a portal

data/docs/reference/app/generators.md

@@ -455,7 +455,7 @@ rails generate pu:pkg:portal admin --auth=admin
 rails generate pu:res:conn Post Comment --dest=admin_portal
 
 # 6. Migrate
-rails db:migrate
+rails db:prepare
 
 # 7. Create the first admin
 rails rodauth_admin:create[admin@example.com,password123]
@@ -465,7 +465,7 @@ rails rodauth_admin:create[admin@example.com,password123]
 
 ```bash
 rails g pu:res:scaffold Product name:string price_cents:integer --dest=main_app
-rails db:migrate
+rails db:prepare
 rails g pu:res:conn Product --dest=admin_portal
 ```
 
@@ -474,7 +474,7 @@ rails g pu:res:conn Product --dest=admin_portal
 ```bash
 rails g pu:pkg:portal customer --auth=user --scope=Organization
 rails g pu:res:conn Order --dest=customer_portal
-rails db:migrate
+rails db:prepare
 ```
 
 ## Undoing generators

data/docs/reference/app/index.md

@@ -50,7 +50,7 @@ rails generate pu:pkg:portal admin --auth=user
 
 # 4. First resource
 rails generate pu:res:scaffold Post user:belongs_to title:string 'content:text?' --dest=main_app
-rails db:migrate
+rails db:prepare
 
 # 5. Connect resource to portal
 rails generate pu:res:conn Post --dest=admin_portal

data/docs/reference/app/portals.md

@@ -195,7 +195,7 @@ rails g pu:res:conn Profile --dest=customer_portal --singular
 ```
 
 ::: tip Run after migrations
-The generator reads model columns to seed the policy's `permitted_attributes_for_*`. Run `rails db:migrate` first.
+The generator reads model columns to seed the policy's `permitted_attributes_for_*`. Run `rails db:prepare` first.
 :::
 
 ### What gets generated

data/docs/reference/auth/profile.md

@@ -24,7 +24,7 @@ Meta-generator: runs `pu:profile:install` + `pu:profile:conn` in one shot.
 rails generate pu:profile:install bio:text avatar:attachment 'timezone:string?' \
   --dest=customer
 
-rails db:migrate
+rails db:prepare
 
 rails generate pu:profile:conn --dest=customer_portal
 ```

data/docs/reference/resource/actions.md

@@ -61,6 +61,9 @@ action :name,
   collection_record_action: true,
   bulk_action:              true,
 
+  # Conditional visibility — display-only proc, NOT authorization (see below)
+  condition: -> { params[:beta] == "1" },
+
   # Grouping
   category: :primary,                    # :primary, :secondary, :danger
   position: 50,                          # display order (lower = first)
@@ -84,6 +87,58 @@ def customize_actions
 end
 ```
 
+## Conditional visibility — `condition:`
+
+Like the `condition:` proc on [inputs/displays/columns](/reference/resource/definition), an action can be **defined but only rendered when a runtime proc is truthy**. It's purely a toggle on whether the **button is shown** — the action (and its route) stays fully live either way.
+
+The headline use case: **expose an action's endpoint without surfacing it in the UI** — e.g. one you call from the API, a webhook, or another service. Hide the button with an always-falsy condition; the route still works:
+
+```ruby
+# Defined and callable (API / programmatic), but no button anywhere in the UI:
+action :sync_inventory, interaction: SyncInventoryInteraction, condition: -> { false }
+```
+
+It also works as a dynamic toggle driven by the **record** or the **view/request** context:
+
+```ruby
+# object → the row/shown record (record & collection-record actions):
+action :reopen,  interaction: ReopenInteraction,  condition: -> { object.closed? }
+# view/request state — feature flag, preview/beta mode:
+action :preview, interaction: PreviewInteraction, condition: -> { params[:beta] == "1" }
+```
+
+Inside the proc, `object`/`record` is the contextual record, and every other call delegates to the **view context**:
+
+| Available | Notes |
+|---|---|
+| `object` / `record` | The row/shown record for **record** and **collection-record** actions; **`nil`** for resource and bulk actions (no single record). Guard with `object&.…` if a condition is shared across action kinds. |
+| `params`, `request` | Current request. |
+| `current_user`, `current_parent` | The signed-in user and (nested) parent. |
+| `resource_record!` | The shown record on the show page; raises on index/table — prefer `object`. |
+| `allowed_to?`, `policy_for`, other helpers | The usual view helpers. |
+
+`object` is evaluated **per row** in tables and grids, so per-record show/hide works there too.
+
+::: danger `condition:` is NOT authorization — it only hides the button
+A hidden action still has a **live route**: anyone who knows the URL can still trigger it. `condition:` decides whether the *button renders*, never whether the *request is allowed*.
+
+```ruby
+# 🚫 WRONG — this does NOT stop non-admins. The route is live; they can POST to it.
+action :wipe, interaction: WipeInteraction, condition: -> { current_user.admin? }
+
+# ✅ RIGHT — authorization belongs in the policy. The action only runs if this returns true.
+class WidgetPolicy < ResourcePolicy
+  def wipe? = current_user.admin?
+end
+```
+
+**Rule of thumb:** "who may run this" → **policy** (`def action_name?`). "is this UI relevant right now" → `condition:`. Authorization is enforced regardless of `condition:`; the two compose — an action appears only when the policy permits **and** the condition is truthy.
+:::
+
+::: tip Per-record display vs. per-record authorization
+`condition: -> { object.draft? }` is fine for **showing/hiding** a per-record button. But if the rule is about **who may run it** ("only while draft *and* nobody else has it locked"), put it in the policy — `def publish? = record.draft?` is also evaluated per record (per row), and unlike `condition:` it actually gates execution.
+:::
+
 ## Simple actions (navigation)
 
 Link to an existing route. The target route MUST exist.

data/docs/reference/resource/index.md

@@ -14,7 +14,7 @@ A **resource** is the unit Plutonium gives you full CRUD for — list, show, cre
 
 ```bash
 rails g pu:res:scaffold Post user:belongs_to title:string 'content:text?' --dest=main_app
-rails db:migrate
+rails db:prepare
 rails g pu:res:conn Post --dest=admin_portal
 ```
 

data/docs/reference/tenancy/invites.md

@@ -56,7 +56,7 @@ rails g pu:invites:install \
 After install:
 
 ```bash
-rails db:migrate
+rails db:prepare
 ```
 
 ## What gets created

data/gemfiles/rails_7.gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: ..
   specs:
-    plutonium (0.55.0)
+    plutonium (0.56.0)
       action_policy (~> 0.7.0)
       listen (~> 3.8)
       pagy (~> 43.0)

data/gemfiles/rails_8.0.gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: ..
   specs:
-    plutonium (0.55.0)
+    plutonium (0.56.0)
       action_policy (~> 0.7.0)
       listen (~> 3.8)
       pagy (~> 43.0)

data/gemfiles/rails_8.1.gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: ..
   specs:
-    plutonium (0.55.0)
+    plutonium (0.56.0)
       action_policy (~> 0.7.0)
       listen (~> 3.8)
       pagy (~> 43.0)

data/lib/generators/pu/core/typespec/typespec_generator.rb

@@ -42,7 +42,7 @@ module Pu
           say_status :pending, "#{migration.version} - #{migration.name}", :yellow
         end
         say ""
-        say "Run `bin/rails db:migrate` before generating TypeSpec specifications.", :red
+        say "Run `bin/rails db:prepare` before generating TypeSpec specifications.", :red
         raise Thor::Error, "Cannot generate TypeSpec with pending migrations"
       end
 

data/lib/generators/pu/saas/welcome_generator.rb

@@ -135,7 +135,7 @@ module Pu
         say "Next steps:"
         say "\n"
         say "1. Run migrations (if you haven't already):"
-        say "   rails db:migrate"
+        say "   rails db:prepare"
         say "\n"
         say "2. Customize the onboarding view to match your app:"
         say "   app/views/welcome/onboarding.html.erb"

data/lib/plutonium/action/base.rb

@@ -6,7 +6,7 @@ module Plutonium
   module Action
     # Base class for all actions in the Plutonium framework.
     class Base
-      attr_reader :name, :label, :description, :icon, :route_options, :confirmation, :turbo, :color, :category, :position, :return_to
+      attr_reader :name, :label, :description, :icon, :route_options, :confirmation, :turbo, :color, :category, :position, :return_to, :condition
 
       def initialize(name, **options)
         @name = name.to_sym
@@ -27,6 +27,7 @@ module Plutonium
         @position = options[:position] || 50
         @modal_mode = options[:modal]
         @modal_size = options[:size]
+        @condition = options[:condition]
         validate_modal_mode!
         validate_modal_size!
 
@@ -62,6 +63,21 @@ module Plutonium
         policy.allowed_to?(:"#{name}?")
       end
 
+      # Display-only visibility gate, mirroring the `condition:` proc on
+      # inputs/displays/columns. Returns true when no condition is set.
+      #
+      # The proc is evaluated against a ConditionContext: `object`/`record` is
+      # the contextual record (nil for resource/bulk actions), and every other
+      # call delegates to the view context (current_user, params, request,
+      # allowed_to?, resource_record!, …).
+      #
+      # NOT an authorization boundary — a hidden action still has a live route;
+      # keep authorization in the policy.
+      def condition_met?(view_context, record: nil)
+        return true if @condition.nil?
+        ConditionContext.new(view_context, record).instance_exec(&@condition)
+      end
+
       # Returns a new Action with the given options merged over this one.
       def with(**overrides)
         self.class.new(name, **to_options.merge(overrides))
@@ -90,7 +106,8 @@ module Plutonium
           category: @category.to_sym,
           position: @position,
           modal: @modal_mode,
-          size: @modal_size
+          size: @modal_size,
+          condition: @condition
         }
       end
 

data/lib/plutonium/action/condition_context.rb

@@ -0,0 +1,33 @@
+# frozen_string_literal: true
+
+require "delegate"
+
+module Plutonium
+  module Action
+    # Evaluation scope for an action's `condition:` proc.
+    #
+    # Exposes the contextual record as both `object` and `record`, and delegates
+    # everything else to the request's **view context** — the object render
+    # components forward their helpers to — so a condition can use current_user,
+    # params, request, allowed_to?, resource_record!, etc. directly, exactly
+    # like the `condition:` procs on inputs/displays/columns.
+    #
+    # Delegating to the view context (not a render component) matters: the
+    # component exposes params/request only as PRIVATE methods, which a delegator
+    # can't forward; the view context exposes them publicly.
+    #
+    # `record`/`object` is the row/shown record for record and
+    # collection-record actions, and nil for resource/bulk actions (no single
+    # record in scope) — so guard with `object&.…` in conditions shared across
+    # action kinds.
+    class ConditionContext < SimpleDelegator
+      attr_reader :record
+      alias_method :object, :record
+
+      def initialize(view_context, record)
+        super(view_context)
+        @record = record
+      end
+    end
+  end
+end

data/lib/plutonium/ui/grid/card.rb

@@ -232,12 +232,13 @@ module Plutonium
 
         def row_actions
           @row_actions ||= resource_definition.defined_actions.values.select { |a|
-            a.collection_record_action? && a.permitted_by?(record_policy)
+            a.collection_record_action? && a.permitted_by?(record_policy) && a.condition_met?(view_context, record:)
           }
         end
 
         def can_show?
-          resource_definition.defined_actions[:show]&.permitted_by?(record_policy)
+          action = resource_definition.defined_actions[:show]
+          action&.permitted_by?(record_policy) && action.condition_met?(view_context, record:)
         end
 
         def record_policy

data/lib/plutonium/ui/page/index.rb

@@ -33,7 +33,7 @@ module Plutonium
         end
 
         def page_actions
-          super || current_definition.defined_actions.values.select { |a| a.resource_action? && a.permitted_by?(current_policy) }
+          super || current_definition.defined_actions.values.select { |a| a.resource_action? && a.permitted_by?(current_policy) && a.condition_met?(view_context) }
         end
 
         def render_default_content

data/lib/plutonium/ui/page/show.rb

@@ -15,7 +15,7 @@ module Plutonium
         end
 
         def page_actions
-          super || current_definition.defined_actions.values.select { |a| a.record_action? && a.permitted_by?(current_policy) }
+          super || current_definition.defined_actions.values.select { |a| a.record_action? && a.permitted_by?(current_policy) && a.condition_met?(view_context, record: resource_record!) }
         end
 
         def render_default_content

data/lib/plutonium/ui/table/resource.rb

@@ -134,7 +134,7 @@ module Plutonium
               policy = policy_for(record:)
 
               actions = resource_definition.defined_actions
-                .select { |k, a| a.collection_record_action? && policy.allowed_to?(:"#{k}?") }
+                .select { |k, a| a.collection_record_action? && policy.allowed_to?(:"#{k}?") && a.condition_met?(view_context, record:) }
                 .values
 
               primary_actions = actions.select { |a| a.category.primary? }.sort_by(&:position)
@@ -161,7 +161,7 @@ module Plutonium
 
         def bulk_actions
           @bulk_actions ||= resource_definition.defined_actions
-            .select { |k, a| a.bulk_action? }
+            .select { |k, a| a.bulk_action? && a.condition_met?(view_context) }
             .values
         end
 

data/lib/plutonium/version.rb

@@ -1,5 +1,5 @@
 module Plutonium
-  VERSION = "0.56.0"
+  VERSION = "0.56.1"
   NEXT_MAJOR_VERSION = VERSION.split(".").tap { |v|
     v[1] = v[1].to_i + 1
     v[2] = 0

data/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@radioactive-labs/plutonium",
-  "version": "0.56.0",
+  "version": "0.56.1",
   "description": "Build production-ready Rails apps in minutes, not days. Convention-driven, fully customizable, AI-ready.",
   "type": "module",
   "main": "src/js/core.js",

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: plutonium
 version: !ruby/object:Gem::Version
-  version: 0.56.0
+  version: 0.56.1
 platform: ruby
 authors:
 - Stefan Froelich
@@ -956,6 +956,7 @@ files:
 - lib/plutonium.rb
 - lib/plutonium/action/README.md
 - lib/plutonium/action/base.rb
+- lib/plutonium/action/condition_context.rb
 - lib/plutonium/action/interactive.rb
 - lib/plutonium/action/route_options.rb
 - lib/plutonium/action/simple.rb