nitro_kit 2.0.0.alpha.4 → 2.0.0.alpha.6

data/lib/nitro_kit/installation.rb

@@ -23,6 +23,14 @@ module NitroKit
       Each skill resolves the installed gem with `bundle show nitro_kit` and reads
       its version-matched documentation.
 
+      For greenfield planning or broad product work, check whether Nitro Kit
+      catalog or MCP tools are available. When they are, inventory and search the
+      catalog by product workflow, retrieve the relevant patterns, and state what
+      will be used, adapted, or deferred before implementation. When they are not,
+      continue with the bundled skills, documentation, and component contracts;
+      catalog access is optional and must never block the work. Nitro Kit Doctor
+      verifies integration health, not product completeness.
+
       In a greenfield application, run `bin/rails generate phlex:install` and use
       Phlex for the application layout, route views, and reusable UI. In an
       established application, preserve its existing view architecture and

data/lib/nitro_kit/version.rb

@@ -1,3 +1,3 @@
 module NitroKit
-  VERSION = "2.0.0.alpha.4"
+  VERSION = "2.0.0.alpha.6"
 end

data/plugins/nitro-kit/.codex-plugin/plugin.json

@@ -14,15 +14,15 @@
   "interface": {
     "displayName": "Nitro Kit",
     "shortDescription": "Build Rails UI with Nitro Kit and Hotwire",
-    "longDescription": "Model conventional Rails resources, compose Nitro Kit components, and implement Hotwire interactions from the installed gem version.",
+    "longDescription": "Model conventional Rails resources, compose Nitro Kit components, implement Hotwire interactions from the installed gem version, and use optional catalog guidance when available.",
     "developerName": "Mikkel Malmberg",
     "category": "Developer",
     "capabilities": ["Read", "Write"],
     "websiteURL": "https://nitrokit.dev",
     "defaultPrompt": [
-      "Build this Rails feature on the Nitro Kit Rails path.",
-      "Build this Rails interface with Nitro Kit components.",
-      "Implement this interaction with Nitro Kit and conventional Hotwire."
+      "Build this Rails feature on the Nitro Kit Rails path, using relevant catalog guidance when available.",
+      "Build this Rails interface with Nitro Kit components and any relevant catalog guidance available.",
+      "Implement this interaction with Nitro Kit, conventional Hotwire, and relevant catalog guidance when available."
     ]
   }
 }

data/plugins/nitro-kit/skills/nitro-kit-hotwire/SKILL.md

@@ -25,6 +25,18 @@ Make the server response and stable DOM boundary the interaction API. Add Stimul
 7. Read `NITRO_KIT_ROOT/docs/browser_support.md` for the canonical
    full/reduced/unavailable no-JavaScript classification.
 
+## Discover optional catalog guidance
+
+For a broad product workflow, check whether Nitro Kit catalog or MCP tools are
+available. When they are, inventory and search by workflow, retrieve relevant
+patterns, and state what will be used, adapted, or deferred before
+implementation. When they are not, continue with the installed Hotwire recipes,
+component contracts, and source. Catalog access is optional and must never
+block the work or be implied in the result.
+
+For a focused interaction, use the catalog only when it is already available
+and a higher-level pattern would materially help.
+
 Do not proceed with a remembered Nitro Kit 1.x API. Do not copy or recreate
 the installed gem's `nk--*` controllers under `app/javascript/controllers/nk`.
 
@@ -46,7 +58,7 @@ Keep frames around complete resource or collection regions, not individual butto
 - Do not describe that HTML branch as a JavaScript-free interaction when its
   control still depends on Turbo or a closed overlay.
 - Let GET query parameters be the source of truth for filtering, sorting, and pagination.
-- Use native Nitro Dialog behavior for reviewed destructive actions. Use `data: { turbo_confirm: ... }` for compact confirmations that do not need a dialog.
+- Use Nitro Dialog for destructive confirmations, including short delete, remove, and revoke flows. Put the real Rails form inside the dialog; do not add `turbo_confirm`. Follow `docs/patterns/destructive_action.md`.
 - Render flash through `NitroKit::Toast::FlashMessages`; the application owns setting the flash.
 
 ## Preserve ownership
@@ -69,3 +81,8 @@ before changing application code. Disable Chrome's background throttling or
 use a test-only `requestAnimationFrame` shim when necessary. Never ship that
 workaround in the application or replace a conventional Turbo flow to satisfy
 one browser driver.
+
+For a full-page CRUD index, default to ordinary GET forms and links with Turbo
+Drive and normal caching. Use Frames for independently navigable regions.
+History tests must check restored rows and controls, not just the URL, and
+wait past `html[data-turbo-preview]` before interacting with a new page.

data/plugins/nitro-kit/skills/nitro-kit-hotwire/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Nitro Kit Hotwire"
   short_description: "Build conventional Nitro Kit Hotwire flows"
-  default_prompt: "Use $nitro-kit-hotwire to build this interaction with Nitro Kit and conventional Hotwire."
+  default_prompt: "Use $nitro-kit-hotwire to build this interaction with Nitro Kit, conventional Hotwire, and relevant catalog guidance when available."

data/plugins/nitro-kit/skills/nitro-kit-rails/SKILL.md

@@ -24,6 +24,18 @@ established application outside the requested scope.
 9. Read `NITRO_KIT_ROOT/docs/browser_support.md` before claiming an
    interaction works without JavaScript.
 
+## Discover optional catalog guidance
+
+For greenfield planning or broad product work, check whether Nitro Kit catalog
+or MCP tools are available. When they are, inventory and search by product
+workflow, retrieve the relevant patterns, and state what will be used, adapted,
+or deferred before implementation. When they are not, continue with the
+installed skills, documentation, component contracts, and source. Catalog
+access is optional and must never block the work or be implied in the result.
+
+For a focused Rails change, use the catalog only when it is already available
+and the task could benefit from a higher-level product pattern.
+
 Never use a Nitro Kit 1.x helper, copied component, controller, or Tailwind
 contract as a substitute for the installed API.
 
@@ -53,7 +65,7 @@ contract as a substitute for the installed API.
 - Render HTML on the server and add Hotwire progressively.
 - Set the document language on the root `html` element.
 - Test with Minitest and fixtures, including tenancy and unhappy paths.
-- In authenticated admin areas, default to a hybrid `AppShell` with the route's
+- In authenticated admin areas, default to a sidebar `AppShell` with the route's
   one `h1` and basic actions in its `Toolbar`. Keep one page gutter and avoid
   repeated headings or automatic Card wrappers. At narrow widths, let trailing
   actions stack below a Back affordance and title instead of clipping the title
@@ -70,3 +82,6 @@ Nitro Kit owns component contracts and focused progressive behavior.
 Run focused model and request tests first. Add a system test only where browser
 behavior is part of the contract. Assert status, visibility, authorization,
 and stable DOM boundaries rather than implementation trivia.
+
+Nitro Kit Doctor verifies integration and runtime contracts, not product
+completeness. For broad work, verify the agreed workflow coverage separately.

data/plugins/nitro-kit/skills/nitro-kit-rails/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Nitro Kit Rails"
   short_description: "Build conventional Rails applications with Nitro Kit"
-  default_prompt: "Use $nitro-kit-rails to build this feature on the Nitro Kit Rails path."
+  default_prompt: "Use $nitro-kit-rails to build this feature on the Nitro Kit Rails path, using relevant catalog guidance when available."

data/plugins/nitro-kit/skills/nitro-kit-ui/SKILL.md

@@ -18,14 +18,25 @@ Use the documentation shipped with the application's installed gem as the source
    classifications in `NITRO_KIT_ROOT/docs/browser_support.md`.
 7. Inspect the installed component source when constructor or compound-slot details remain unclear. Never guess a component API from memory.
 
+## Discover optional catalog guidance
+
+For greenfield planning or broad product UI work, check whether Nitro Kit
+catalog or MCP tools are available. When they are, inventory and search by
+product workflow, retrieve the relevant patterns, and state what will be used,
+adapted, or deferred before implementation. When they are not, continue with
+the installed skills, documentation, component contracts, and source. Catalog
+access is optional and must never block the work or be implied in the result.
+
+For a focused component change, use the catalog only when it is already
+available and a higher-level composition would materially help.
+
 For a Nitro Kit 1.x migration, read
 `NITRO_KIT_ROOT/docs/migration_1_to_2.md` before editing. Inventory product
 flows, behavior, application-owned button classes and Rails button helpers,
 joined controls, and the existing semantic color, focus, radius, density, and
 typography tokens first. Capture representative wide and narrow screenshots.
-If the Nitro Kit MCP catalog is available, search it by workflow rather than
-old component name, then select high-level compositions before replacing
-atoms.
+Apply the optional catalog process above, searching by workflow rather than old
+component name and selecting high-level compositions before replacing atoms.
 
 If the gem is not installed, say that the skill requires Nitro Kit and follow the application's requested installation scope. Do not substitute APIs from an older Nitro Kit release.
 
@@ -44,9 +55,13 @@ If the gem is not installed, say that the skill requires Nitro Kit and follow th
 5. Keep routes, authorization, records, query policy, DOM IDs, Turbo boundaries, and response semantics in the application.
 6. Translate the application's semantic theme into documented `--nk-*` properties instead of choosing similar raw palette values. Use `--nk-button-radius` when Button shape intentionally differs from inputs and surfaces.
 7. Verify closed options and required compound declarations before rendering.
-8. For authenticated CRUD, prefer a hybrid `AppShell` with a `Toolbar` that
+8. For authenticated CRUD, prefer a sidebar `AppShell` with a `Toolbar` that
    owns the route's single `h1` and basic actions. The shell main region owns
-   one content gutter. Do not repeat that heading in `PageHeader`, or wrap each
+   one content gutter, not a universal maximum width. Tables fill the canvas;
+   form and reading pages may use a centered Container inside that gutter.
+   Simple resource forms use a single-column Fieldset in Container lg so fields
+   use the available width; reserve split SettingsSections for roomy settings pages.
+   Do not repeat that heading in `PageHeader`, or wrap each
    table, form, and detail region in another Card. At narrow widths, preserve
    the full title and persistent actions by stacking the trailing actions below
    the title rather than clipping either region.
@@ -76,4 +91,12 @@ If the gem is not installed, say that the skill requires Nitro Kit and follow th
 
 Run the smallest relevant application tests. For component rendering, assert semantic elements and owned `data-nk` or slot attributes rather than private implementation helpers. Exercise invalid and empty states when the UI accepts user input or collections.
 
+Nitro Kit Doctor verifies integration and runtime contracts, not product
+completeness. Do not use a green Doctor result as proof that every relevant
+screen, state, or catalog workflow has been implemented.
+
 For a migration, Doctor is an inventory, not visual proof. Run representative form and component rendering with `ActiveModel::Translation.raise_on_missing_translations` enabled when the application uses strict i18n. Compare the same representative flows in a browser at wide and narrow widths, exercise keyboard focus, and inspect computed styles for missing application classes, stacked Button content, broken compound corners, double focus rings, clipping, and theme drift. Re-audit rendered native buttons, Rails button helpers, and application-owned button classes before declaring the conversion complete. Search the whole application for `desperately_need_a_class:` and review every result, aiming for zero. Move layout and visual treatment to application-owned wrappers, remove generic class forwarding, accept incidental Nitro defaults, and keep unmatched product UI application-owned; retain only documented external-integration hooks.
+
+Use Nitro Dialog for destructive confirmations, including simple deletion,
+member removal, and invitation revocation. Read `docs/patterns/destructive_action.md`;
+do not substitute native browser confirmation for short messages.

data/plugins/nitro-kit/skills/nitro-kit-ui/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Nitro Kit UI"
   short_description: "Build Rails interfaces with Nitro Kit components"
-  default_prompt: "Use $nitro-kit-ui to build this Rails interface with the installed Nitro Kit components."
+  default_prompt: "Use $nitro-kit-ui to build this Rails interface with the installed Nitro Kit components and any relevant catalog guidance available."

data/src/stylesheets/nitro_kit/components/app_shell.css

@@ -179,25 +179,7 @@
 
 @layer nitro-kit.variant {
   :where(
-      [data-nk="app-shell"][data-layout="sidebar"]
-        > [data-slot="app-shell-header"]
-        > [data-slot="app-shell-topbar"]
-    ) {
-    display: none;
-  }
-
-  :where(
-      [data-nk="app-shell"][data-layout="sidebar"]
-        > [data-slot="app-shell-main"]
-    ) {
-    grid-row: 1 / 3;
-  }
-
-  :where(
-      [data-nk="app-shell"]:is(
-          [data-layout="sidebar"],
-          [data-layout="hybrid"]
-        ):not(
+      [data-nk="app-shell"][data-layout="sidebar"]:not(
           :has(> [data-slot="app-shell-header"] > [data-slot="app-shell-brand"])
         )
         > [data-slot="app-shell-sidebar"]

data/src/stylesheets/nitro_kit/components/dialog.css

@@ -10,6 +10,7 @@
     margin: auto;
     padding: calc(var(--nk-space) * 6);
     overflow: auto;
+    text-align: start;
     color: var(--nk-color-foreground);
     background: var(--nk-color-surface);
     border: var(--nk-border-width) solid var(--nk-color-border);
@@ -27,6 +28,23 @@
     position: static;
   }
 
+  :where(
+      [data-nk="dialog"]
+        > [data-slot="dialog-panel"]
+        > [data-slot="dialog-header"]
+    ) {
+    display: flow-root;
+    margin-block-end: calc(var(--nk-space) * 4);
+  }
+
+  :where(
+      [data-nk="dialog"]
+        > [data-slot="dialog-panel"]
+        > [data-slot="dialog-body"]
+    ) {
+    clear: both;
+  }
+
   :where([data-nk="dialog"] [data-slot="dialog-title"]) {
     font-size: var(--nk-title-surface-size);
     font-weight: var(--nk-title-surface-weight);
@@ -36,7 +54,6 @@
 
   :where([data-nk="dialog"] [data-slot="dialog-description"]) {
     margin-block-start: calc(var(--nk-space) * 2);
-    margin-block-end: calc(var(--nk-space) * 4);
     color: var(--nk-color-muted-foreground);
     font-size: var(--nk-text-sm);
     line-height: var(--nk-leading-relaxed);