Fix: argType detail popover overflows viewport when content is tall

.claude/skills/builder-bug-workflow/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: builder-bug-workflow
+description: Complete workflows for verifying builder bug fixes in code/builders/**. Includes Flow 2 (frontend output) and Flow 3 (terminal output) with sandbox requirements, hash normalization, and snapshot management.
+---
+
+# Builder Bug Verification Workflow
+
+When fixing bugs in `code/builders/**`, determine whether the change affects browser-visible output (Flow 2) or Node.js stdout/stderr output (Flow 3), and follow the appropriate workflow.
+
+## Decision: Is this a Browser Output Bug or Terminal Output Bug?
+
+- **Browser output bug** (Flow 2): The fix affects how Storybook renders in the browser (CSS, layout, UI elements, story preview content).
+- **Terminal output bug** (Flow 3): The fix affects what is logged to the console during the build or dev process (progress messages, timestamps, paths, diagnostics).
+
+---
+
+# Flow 2 — Builder Bug Verification (Frontend Output)
+
+Follow this workflow if your builder change affects browser-visible output.
+
+## Step 1: Create or Update a Template Story
+
+Create or update a story in the sandbox that demonstrates the affected behaviour and confirms the fix.
+
+For `builder-vite` verification, place the template story in `code/renderers/react/template/stories/` (it will be automatically symlinked into `react-vite-default-ts` at sandbox generation time).
+
+## Step 2: Select the Appropriate Sandbox Template
+
+- **`builder-vite` changes**: Use `react-vite/default-ts`
+- **`builder-webpack5` changes**: Use `react-webpack/18-ts`
+
+## Step 3: Generate and Start the Sandbox
+
+Generate the sandbox environment:
+
+```bash
+yarn nx sandbox <template> -c production
+```
+
+Start the dev server as a background task:
+
+```bash
+cd ../storybook-sandboxes/<sandbox-dir> && yarn storybook --ci
+```
+
+- **Startup time**: The sandbox dev server typically takes **30–90 seconds** on first cold start; wait for the console to emit `"Storybook X.Y started"` before opening the browser.
+- **Known failure — port in use**: If port 6006 is occupied, kill the incumbent process:
+  ```bash
+  lsof -ti :6006 | xargs kill -9
+  ```
+  Then retry the dev server start.
+
+Wait for the port to be ready (check console for "Storybook started").
+
+## Step 4: Capture Visual Evidence
+
+Use the Browser MCP to:
+
+1. Open the Storybook instance
+2. Navigate to your template story
+3. Take a screenshot showing the fix works correctly
+
+Save the screenshot locally. It will be uploaded directly into the PR description — do **not** commit it to the repository.
+
+## Step 5: Fallback Path (if bug persists)
+
+If the browser output still shows the bug:
+
+1. Kill the dev server
+2. Recompile: `yarn nx compile <package-name> -c production`
+3. Copy fresh `dist/` into the sandbox:
+   - Source: `code/<package-path>/dist/`
+   - Destination: `../storybook-sandboxes/<sandbox-dir>/node_modules/@storybook/<package-name>/dist/`
+4. Restart the dev server: `cd ../storybook-sandboxes/<sandbox-dir> && yarn storybook --ci`
+5. Re-verify with a new screenshot
+
+---
+
+✅ **Flow 2 COMPLETE** — Before/after screenshots captured locally. Return to `/implement-and-verify-fix` Step 6 to commit the template story file and prepare screenshots for the PR body.
+
+---
+
+# Flow 3 — Builder Bug Verification (Terminal Output)
+
+Follow this workflow if your builder change affects Node.js stdout/stderr output (console logs, build progress, error messages, etc.).
+
+## Step 1: Verify Sandbox Availability
+
+The terminal output capture requires the sandbox directory to exist for your builder:
+
+- **`builder-vite`**: Requires `../storybook-sandboxes/react-vite-default-ts`
+- **`builder-webpack5`**: Requires `../storybook-sandboxes/react-webpack-18-ts`
+
+If either directory is missing, generate it:
+
+```bash
+yarn nx sandbox <template> -c production
+```
+
+## Step 2: Run the Capture Script
+
+Run the terminal output capture and comparison:
+
+```bash
+jiti scripts/capture-terminal-output.ts --builder <builder-name>
+```
+
+The output is compared against `scripts/terminal-output-snapshots/<builder-name>-build.snap.txt`.
+
+## Step 3: Review and Commit the Baseline
+
+**Decision: Create or Update?**
+
+- **No baseline exists** (you have never run this before for this builder): You must **create** a baseline by running `--update`
+- **Baseline exists** but needs updating due to your fix: You **update** the baseline
+- **Baseline exists** but output doesn't match your fix: Your fix may be incomplete—re-run Step 1-2
+
+**If no baseline exists** (all snapshots start as placeholders):
+
+- Run: `jiti scripts/capture-terminal-output.ts --builder <builder-name> --update`
+- This creates a "PROVISIONAL BASELINE" snapshot requiring reviewer approval
+- Add a note to your PR description: `<!-- PROVISIONAL BASELINE — requires reviewer approval before merge -->`
+
+**If the diff is consistent with your fix**:
+
+- Review the diff output carefully to confirm it shows only expected changes:
+  - Build structure changes (new assets, removed files, reorganized chunks)
+  - Performance metrics (durations, file sizes)
+  - Build messages or progress indicators
+  - **NOT** due to asset filename hashes (these are auto-normalized to `<HASH>`)
+- Run: `jiti scripts/capture-terminal-output.ts --builder <builder-name> --update` to commit the new baseline
+- Summarize the changes in your PR description
+
+## Step 4: Understand Hash Normalization
+
+Build tools generate content hashes in filenames to enable long-term caching. These hashes change whenever file content changes. To keep snapshots stable and focused on structural changes, the capture script automatically normalizes hashes:
+
+- **Original output**: `context-C0qIqeS4.png`, `formatter-ABCDEF-GHIJKL.js`, `ts-argtypes-BOocmtEy.css`
+- **Normalized snapshot**: `context-<HASH>.png`, `formatter-<HASH>.js`, `ts-argtypes-<HASH>.css`
+
+**Validation checklist**:
+
+- ✓ All asset filenames (`/assets/*.ext`) show `<HASH>` placeholders, not real hashes
+- ✓ Version numbers like `v10.3.0-alpha.12` are preserved (not normalized)
+- ✓ Build messages and paths are normalized where present
+
+## Step 5: Handle Noisy or Unexpected Diffs
+
+If the diff is large or unexpected:
+
+1. Diagnose what output changed and why
+2. Verify the changes are a direct result of your builder modification
+3. Iterate on your fix until the diff is clean and focused
+4. Run the capture script again: `jiti scripts/capture-terminal-output.ts --builder <builder-name>`
+
+---
+
+✅ **Flow 3 COMPLETE** — Snapshot updated in `scripts/terminal-output-snapshots/`. Return to `/implement-and-verify-fix` Step 6 to commit artifacts.

.claude/skills/fix-bug/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: fix-bug
+description: Complete end-to-end workflow to fetch a GitHub issue, understand the bug, plan the fix, implement it, test it, verify it works, and prepare a PR—all in one linear process.
+---
+
+## Workflow Overview
+
+```
+Step 1: /plan-bug-fix [issue-number]
+         ↓ [MUST PASS: Plan complete, branch created]
+Step 2: /implement-and-verify-fix
+         ↓ [MUST PASS: Tests pass, evidence gathered]
+Step 3: /verification-checklist
+         ↓ [MUST PASS: Root cause confirmed, no regressions]
+Step 4: Documentation Self-Improvement (if needed)
+         ↓
+Step 5: /open-pull-request [issue-number]
+         ↓ [DONE: PR created and ready for review]
+```
+
+---
+
+## Step 1: Understand & Plan the Fix
+
+**Action**: Read and follow `.claude/skills/plan-bug-fix/SKILL.md` with the issue number.
+
+That skill will:
+- Fetch the GitHub issue
+- Determine the verification flow (0–4)
+- Create a detailed fix plan
+- Create the feature branch `agent/fix-issue-[number]`
+
+**Expected Output**:
+
+- ✅ Issue clearly understood with full context
+- ✅ Verification flow determined (0 = Pure Logic, 1 = Renderer, 2 = Builder Frontend, 3 = Builder Terminal, 4 = Manager UI)
+- ✅ Feature branch created (e.g., `agent/fix-issue-12345`)
+- ✅ Fix plan documented and ready to follow
+
+**Success Criteria**:
+
+- [ ] Issue understanding is complete and verified
+- [ ] Verification flow (0–4) is clearly identified
+- [ ] Feature branch created and checked out
+- [ ] Fix plan is documented and ready to follow
+- [ ] No blockers or unclear items remain
+
+⚠️ **CRITICAL**: Do NOT proceed to Step 2 until all success criteria above are met.
+
+---
+
+## Step 2: Implement, Test, and Verify
+
+**Action**: Read and follow `.claude/skills/implement-and-verify-fix/SKILL.md`.
+
+That skill will:
+- Implement the code fix
+- Run tests and lint
+- Commit the changes
+- Run the flow-specific verification skill (reading its SKILL.md file)
+
+**Expected Output**:
+
+- ✅ Code implemented following plan
+- ✅ All tests pass
+- ✅ Code formatted and linted
+- ✅ Changes committed to feature branch
+- ✅ Verification evidence gathered (flow-specific)
+
+**Success Criteria**:
+
+- [ ] All tests pass (`cd code && yarn test`)
+- [ ] No linting errors
+- [ ] Changes committed
+- [ ] Verification artifacts saved
+
+⚠️ **CRITICAL**: Do NOT proceed to Step 3 until all success criteria above are met.
+
+---
+
+## Step 3: Run Verification Checklist
+
+**Action**: Read and follow `.claude/skills/verification-checklist/SKILL.md`.
+
+That skill confirms the fix addresses root cause, all tests pass, and no regressions were introduced.
+
+**Expected Output**:
+
+- ✅ All checklist items pass
+- ✅ Fix addresses root cause (not just symptoms)
+- ✅ No regressions
+
+⚠️ **CRITICAL**: Do NOT proceed to Step 4 until the checklist passes.
+
+---
+
+## Step 4: Documentation Self-Improvement
+
+**IMPORTANT**: Reflect on your workflow execution before opening the PR.
+
+**Did you encounter any of these issues?**
+
+- [ ] Instructions in CLAUDE.md were unclear, incomplete, or incorrect
+- [ ] Instructions in any skill file were ambiguous or wrong
+- [ ] You struggled to follow certain steps due to missing information
+- [ ] You discovered better practices or approaches during implementation
+- [ ] Command examples failed or needed adjustments
+- [ ] Prerequisites were missing or incorrect
+
+**If YES to any**: FIX THE DOCUMENTATION NOW before opening the PR.
+
+**Action Steps**:
+
+1. Identify which file needs updating (CLAUDE.md or specific skill in `.claude/skills/`)
+2. Make the fix directly in that file using edit tools
+3. Include in PR description: What was wrong? What did you fix? Why will this help next time?
+
+**Rationale**: Each bug fix workflow is an opportunity to improve the skills themselves. By fixing documentation issues immediately, the next agent run will perform better and avoid the same pitfalls.
+
+**Success Criteria**:
+
+- [ ] All documentation issues identified during workflow execution are fixed (or none found)
+- [ ] Documentation improvements committed to feature branch (if any)
+- [ ] Ready to proceed with PR preparation
+
+---
+
+## Step 5: Open Pull Request
+
+**Action**: Read and follow `.claude/skills/open-pull-request/SKILL.md` with the issue number.
+
+That skill will prepare the PR title and body (following `.github/PULL_REQUEST_TEMPLATE.md`) and open the PR.
+
+**Expected Output**:
+
+- ✅ PR title prepared (`Fix: [description]`)
+- ✅ PR body complete with root cause, solution, tests, and flow-specific evidence
+- ✅ AI disclaimer included
+- ✅ PR created on GitHub with correct labels and issue linked