[Feature] RubyUI 2.0 — Phase 2.0b: the other 173 ERB fixtures

[cirdes]

What

Stacked on #548. Every one of the 188 golden scenarios now has an ERB
fixture under gem/test/golden/views/, rendered through the harness
(ReActionView → Herb) and compared against the canonical and strict
snapshots Phase 2.0a froze from Phlex — with every component still Phlex,
through phlex-rails. Button's 15 were in #548; the other 173 are here, in
seven batches, each green before the next.

• A coverage test, every scenario has a fixture, red from the first commit
  (173 missing) to the last (0). Its message was the inventory.

• Every fixture is one line, plus a trailing newline. Decision 10 records why:
  measured through Herb 0.10.4, the end closing a <%= … do %> block
  ignores its own trim markers and the indentation before an output tag is
  emitted, so an indented one-render-per-line template is not
  whitespace-tight — and the strict lane would see every such character.
  The plan's Appendix A has each probe's source and output.

• The shapes the catalog uses — a block parameter writing raw HTML,
  yield(self) with group.ToggleGroupItem, DataTableForm reaching for
  the view context, a block yielding nothing, a Ruby loop, a heredoc — were
  each measured strict-identical before the plan was written; the plan's
  evidence table has the list.

• One harness fix the lane exposed (Task 7b). ActionView instruments every
  render, and the first instrumentation on a thread creates ActiveSupport's
  Instrumenter, whose id is SecureRandom.hex(10) — inside the harness pin,
  on the first ERB render of a process, that call took the counter's first
  value and shifted every generated id in that render by one, so
  tooltip/default, select/default or date_picker/generated_id failed
  their own determinism check when one of them ran first (about 3 runs in
  190). render_erb now creates the instrumenter before the pin; a test
  renders twice on a fresh thread and asserts identical output. This amended
  the plan's "harness does not change" boundary by a ruling taken during
  execution — please ratify or revert it explicitly in review.

No component changes, no snapshot changes. Nothing under gem/lib/, docs/
or mcp/ moves; the harness changes by that one line.

Why

Decision 7: with every fixture written before any component migrates, a
migration from 2.1 on changes only an implementation, never the ruler — "did I
write the fixture right" and "did I port the component right" stop being one
failure. Plan: design/plans/2026-09-20-phase-2-0b-fixtures-implementation.md.

Test steps

cd gem
bundle exec rake            # 776 runs, 0 failures, 0 skips; 423 files, no offenses
bundle exec rake golden     # 410 runs: 188 Phlex-lane + 188 ERB-lane + 7 coverage + 27 of the ruler's own

To see a fixture fail, add a space before <% end %> in
test/golden/views/shortcut_key/default.html.erb and re-run rake golden:
the canonical form passes, the strict form fails — whitespace only, exactly
what the strict lane exists for.

🤖 Generated with Claude Code

---

Summary by cubic

Adds the remaining 173 ERB fixtures so all 188 golden scenarios render through the harness and compare against the snapshots Phase 2.0a froze from Phlex. Components stay on Phlex this phase, so a later migration changes only an implementation, never the test baseline.

A coverage test enforces that every scenario has a fixture; it was red at 173 missing and is green now.

Harness fix

• The first ERB render on a thread could shift every generated id by one: ActionView's first instrumentation creates an Instrumenter whose SecureRandom.hex(10) id landed inside the harness pin. render_erb now creates the instrumenter before the pin, with a regression test rendering twice on a fresh thread.

All fixtures are one line because measured Herb 0.10.4 trim behavior keeps the newline after a block-closing end and emits indentation before output tags; recorded as decision 10.

^{Written for commit 8ac23ac. Summary will update on new commits.}

[cubic-dev-ai]

3 issues found across 180 files

Not reviewed (too large): design/plans/2026-09-20-phase-2-0b-fixtures-implementation.md (~1,788 lines) - if these are generated or fixture files, add them to ignored paths to exclude them from future reviews.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="gem/test/golden/views/clipboard/popover_success.html.erb">

<violation number="1" location="gem/test/golden/views/clipboard/popover_success.html.erb:1">
P2: This fixture renders a ClipboardPopover whose panel is hidden at initial render (parent div has class="hidden"), but the recorded snapshot freezes the panel in data-state="open". ContextMenu, HoverCard, and Popover all rest hidden panels in data-state="closed" (see context_menu_content.rb, hover_card_content.rb, popover_content.rb), and starting "open" leaves the animate-in classes active at rest when the panel is not visible. Since this PR records the golden snapshot for this scenario, set ClipboardPopover#default_attrs state to :closed so hidden popovers start closed, then re-record the snapshot.</violation>
</file>

<file name="gem/test/golden/views/switch/checked_without_hidden_input.html.erb">

<violation number="1" location="gem/test/golden/views/switch/checked_without_hidden_input.html.erb:1">
P2: This new fixture's golden snapshot locks in an inaccessible switch: the label carries role="switch" but no aria-checked, and the actual control (checkbox class="hidden peer") is display:none, so it is not keyboard-focusable. The fixture faithfully records the component's current behavior, so the fix belongs in lib/ruby_ui/switch/switch.rb: mirror the checked state onto aria-checked on the label and make the checkbox visually hidden but focusable (e.g. replace the "hidden" class with "sr-only peer") instead of display:none. Re-record this snapshot (and the switch default snapshot) once the component is updated.</violation>
</file>

<file name="gem/test/golden/harness.rb">

<violation number="1" location="gem/test/golden/harness.rb:39">
P3: The fix makes the Instrumenter deterministic on a single thread, but the pin state it relies on is not thread-local: `@active`, `@hex_calls`, and `@rand_calls` are instance variables on the `Golden::Harness` module, shared by every thread and reset by each render. If two threads render concurrently (the fresh-thread test in `gem/test/golden/harness_test.rb` is the first code path that exercises threads), the second thread's `ActiveSupport::Notifications.instrumenter` call can run while another thread has `@active == true`; its `SecureRandom.hex(10)` then calls `next_hex` and consumes a shared counter slot, shifting the ids of the in-flight render and of the new render. Each render also rewrites the shared counters and toggles `@active`, so one thread's `ensure` turns the pin off while another thread is still rendering — letting real randomness leak into a pinned render. The claimed "identical output on a fresh thread" property therefore holds only when renders across threads never overlap. Make the counters and `@active` thread-local (Thread.current) or serialize renders with a Mutex, or document that the harness is single-threaded-only.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: This fixture renders a ClipboardPopover whose panel is hidden at initial render (parent div has class="hidden"), but the recorded snapshot freezes the panel in data-state="open". ContextMenu, HoverCard, and Popover all rest hidden panels in data-state="closed" (see context_menu_content.rb, hover_card_content.rb, popover_content.rb), and starting "open" leaves the animate-in classes active at rest when the panel is not visible. Since this PR records the golden snapshot for this scenario, set ClipboardPopover#default_attrs state to :closed so hidden popovers start closed, then re-record the snapshot.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At gem/test/golden/views/clipboard/popover_success.html.erb, line 1:

<comment>This fixture renders a ClipboardPopover whose panel is hidden at initial render (parent div has class="hidden"), but the recorded snapshot freezes the panel in data-state="open". ContextMenu, HoverCard, and Popover all rest hidden panels in data-state="closed" (see context_menu_content.rb, hover_card_content.rb, popover_content.rb), and starting "open" leaves the animate-in classes active at rest when the panel is not visible. Since this PR records the golden snapshot for this scenario, set ClipboardPopover#default_attrs state to :closed so hidden popovers start closed, then re-record the snapshot.</comment>

<file context>
@@ -0,0 +1 @@
+<%= render RubyUI::ClipboardPopover.new(type: :success) do %>success<% end %>
</file context>

[cubic-dev-ai]

P2: This new fixture's golden snapshot locks in an inaccessible switch: the label carries role="switch" but no aria-checked, and the actual control (checkbox class="hidden peer") is display:none, so it is not keyboard-focusable. The fixture faithfully records the component's current behavior, so the fix belongs in lib/ruby_ui/switch/switch.rb: mirror the checked state onto aria-checked on the label and make the checkbox visually hidden but focusable (e.g. replace the "hidden" class with "sr-only peer") instead of display:none. Re-record this snapshot (and the switch default snapshot) once the component is updated.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At gem/test/golden/views/switch/checked_without_hidden_input.html.erb, line 1:

<comment>This new fixture's golden snapshot locks in an inaccessible switch: the label carries role="switch" but no aria-checked, and the actual control (checkbox class="hidden peer") is display:none, so it is not keyboard-focusable. The fixture faithfully records the component's current behavior, so the fix belongs in lib/ruby_ui/switch/switch.rb: mirror the checked state onto aria-checked on the label and make the checkbox visually hidden but focusable (e.g. replace the "hidden" class with "sr-only peer") instead of display:none. Re-record this snapshot (and the switch default snapshot) once the component is updated.</comment>

<file context>
@@ -0,0 +1 @@
+<%= render RubyUI::Switch.new(name: "notifications", include_hidden: false, checked: true, checked_value: "yes", unchecked_value: "no") %>
</file context>

[cubic-dev-ai]

P3: The fix makes the Instrumenter deterministic on a single thread, but the pin state it relies on is not thread-local: @active, @hex_calls, and @rand_calls are instance variables on the Golden::Harness module, shared by every thread and reset by each render. If two threads render concurrently (the fresh-thread test in gem/test/golden/harness_test.rb is the first code path that exercises threads), the second thread's ActiveSupport::Notifications.instrumenter call can run while another thread has @active == true; its SecureRandom.hex(10) then calls next_hex and consumes a shared counter slot, shifting the ids of the in-flight render and of the new render. Each render also rewrites the shared counters and toggles @active, so one thread's ensure turns the pin off while another thread is still rendering — letting real randomness leak into a pinned render. The claimed "identical output on a fresh thread" property therefore holds only when renders across threads never overlap. Make the counters and @active thread-local (Thread.current) or serialize renders with a Mutex, or document that the harness is single-threaded-only.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At gem/test/golden/harness.rb, line 39:

<comment>The fix makes the Instrumenter deterministic on a single thread, but the pin state it relies on is not thread-local: `@active`, `@hex_calls`, and `@rand_calls` are instance variables on the `Golden::Harness` module, shared by every thread and reset by each render. If two threads render concurrently (the fresh-thread test in `gem/test/golden/harness_test.rb` is the first code path that exercises threads), the second thread's `ActiveSupport::Notifications.instrumenter` call can run while another thread has `@active == true`; its `SecureRandom.hex(10)` then calls `next_hex` and consumes a shared counter slot, shifting the ids of the in-flight render and of the new render. Each render also rewrites the shared counters and toggles `@active`, so one thread's `ensure` turns the pin off while another thread is still rendering — letting real randomness leak into a pinned render. The claimed "identical output on a fresh thread" property therefore holds only when renders across threads never overlap. Make the counters and `@active` thread-local (Thread.current) or serialize renders with a Mutex, or document that the harness is single-threaded-only.</comment>

<file context>
@@ -32,6 +32,11 @@ def render(&block)
+        # thread creates the Instrumenter, whose id is SecureRandom.hex(10).
+        # Inside the pin that call would take the counter's first value and
+        # shift every generated id in that one render by one. Create it first.
+        ActiveSupport::Notifications.instrumenter
         @active = true
         @hex_calls = 0
</file context>