fix(registry): activity-graph API swap, tooltips, and logo-cloud fixes

.pi/skills/jalco-ui-registry/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: jalco-ui-registry
+description: Create, review, and document jalco ui registry items with shadcn-style ergonomics, strong variants, and docs-to-registry alignment. Use for adding jalco ui components or blocks, updating registry.json, writing component docs, reviewing API and composition quality, or navigating the jalco-ui docs and registry structure. Use proactively when working in /Users/justin/Documents/Github/jalco-ui or when the user asks to create a component, improve variants, write docs, or audit registry readiness.
+---
+
+# jal-co/ui Registry
+
+Repo-aware guidance for building polished jalco ui registry items and documentation.
+
+## When to Use
+
+Use this skill when working in:
+- `/Users/justin/Documents/Github/jalco-ui`
+
+Use it for:
+- creating a new jalco ui component or block
+- reviewing a registry item for readiness
+- updating `registry.json`
+- writing or revising docs pages under `app/docs/components/*`
+- deciding whether a component needs variants
+- aligning implementation, docs copy, exports, and registry metadata
+- navigating the repo's docs and registry structure
+
+## Read First
+
+Start with these repository files:
+1. `/Users/justin/Documents/Github/jalco-ui/AGENTS.md`
+2. `/Users/justin/Documents/Github/jalco-ui/registry.json`
+3. `/Users/justin/Documents/Github/jalco-ui/README.md`
+4. `/Users/justin/Documents/Github/jalco-ui/app/docs/page.mdx`
+5. `/Users/justin/Documents/Github/jalco-ui/app/docs/installation/page.mdx`
+
+Then route by task:
+- Need repo orientation or example files → `references/repo-map.md`
+- Creating a new component or block → `references/component-workflow.md`
+- Designing variants and public API → `references/variants-and-api.md`
+- Writing or revising docs → `references/docs-patterns.md`
+- Editing registry metadata → `references/registry-patterns.md`
+- Auditing existing work → `references/review-checklist.md`
+
+## Core Rules
+
+- Follow jalco ui's repo conventions before introducing new patterns.
+- Reuse existing registry and docs patterns before inventing new structure.
+- Keep components installable, readable, and easy to adapt.
+- Prefer composability over boolean-prop-heavy APIs.
+- Add variants when they represent real reusable visual states, not speculative flexibility.
+- Treat docs as part of the feature, not a follow-up.
+- Keep naming aligned across folder names, exports, docs titles, slugs, and `registry.json` entries.
+- Use `"use client"` only when interactivity actually requires it.
+- Prefer realistic examples over placeholder content.
+- Follow jalco ui's compact comment style for Jalco-authored public files: useful file headers when appropriate, minimal inline comments, and no decorative AI-style section banners.
+- For public component entry files, headers should usually include the component name, a one-sentence description, and key props when helpful.
+- Do not mass-retrofit copied, upstream, generated, or template-derived files unless they are being meaningfully rewritten.
+
+## Best Existing Anchors
+
+Use these as primary examples unless a closer match exists:
+- Registry implementation:
+  - `/Users/justin/Documents/Github/jalco-ui/registry/github-stars-button/github-stars-button.tsx`
+  - `/Users/justin/Documents/Github/jalco-ui/registry/github-stars-button/github-button-group.tsx`
+  - `/Users/justin/Documents/Github/jalco-ui/registry/waitlist-card/waitlist-card.tsx`
+  - `/Users/justin/Documents/Github/jalco-ui/registry/code-line/code-line.tsx`
+- Docs pages:
+  - `/Users/justin/Documents/Github/jalco-ui/app/docs/components/github-stars-button/page.tsx`
+  - `/Users/justin/Documents/Github/jalco-ui/app/docs/components/github-button-group/page.tsx`
+  - `/Users/justin/Documents/Github/jalco-ui/app/docs/components/waitlist-card/page.tsx`
+  - `/Users/justin/Documents/Github/jalco-ui/app/docs/components/code-line/page.tsx`
+
+## Expected Output
+
+When creating or updating jalco ui work, usually produce or update:
+- one or more files under `registry/<item-name>/`
+- a matching `registry.json` entry
+- a docs page under `app/docs/components/<slug>/page.tsx` when the item is public-facing
+- a catalog card preview at `components/docs/previews/<registry-name>.tsx`
+- a sidebar nav entry in `lib/docs.ts`
+- installation and usage copy aligned with the registry payload URL
+- notes about accessibility, API quality, and any tradeoffs
+
+After creating or modifying a card preview file, run `pnpm previews:generate` to update the auto-generated import map.
+
+## Validation
+
+Before considering work done:
+- confirm work is on a feature branch (`feat/<name>`), not main
+- confirm the item type and file paths are correct
+- confirm metadata and docs descriptions align
+- confirm dependencies and registryDependencies are justified
+- confirm variants are intentional and documented when exposed
+- confirm docs include realistic preview, install, and usage guidance
+- confirm a catalog card preview exists at `components/docs/previews/<registry-name>.tsx` with key variants
+- confirm the sidebar nav entry exists in `lib/docs.ts` with `badge: "New"` and `badgeAdded` date
+- confirm screenshots exist at `public/previews/<name>-dark.png` and `<name>-light.png`
+- confirm `pnpm registry:build` and `pnpm build` pass
+- confirm the component feels shadcn-style: composable, accessible, and easy to own
+- open a PR using the component template (`.github/PULL_REQUEST_TEMPLATE/component.md`)

.pi/skills/jalco-ui-registry/references/component-workflow.md

@@ -0,0 +1,113 @@
+# Component Workflow
+
+Use this workflow when creating or substantially revising a Jalco UI registry item.
+
+## Step 1: Understand the request
+
+Clarify:
+- is this a component, block, docs utility, or multi-file registry item?
+- what problem does it solve?
+- who installs it and customizes it?
+- does it need to be interactive?
+- does it belong in Jalco UI at all?
+
+If the request is vague, identify the smallest useful artifact that feels publishable.
+
+## Step 2: Read the repo before building
+
+Read:
+- `/Users/justin/Documents/Github/jalco-ui/AGENTS.md`
+- `/Users/justin/Documents/Github/jalco-ui/registry.json`
+- `/Users/justin/Documents/Github/jalco-ui/package.json`
+
+Then inspect:
+- the closest matching file in `registry/`
+- the closest matching docs page in `app/docs/components/`
+
+## Step 3: Choose the correct registry shape
+
+Common Jalco UI patterns:
+- simple single-file item → `registry/<name>/<name>.tsx`
+- multi-file item → colocate `components/`, `lib/`, or `hooks/` under `registry/<name>/`
+- primitive dependency reuse → import from `@/registry/ui/*` when appropriate
+
+Prefer the smallest structure that still feels clean and installable.
+
+## Step 4: Design the API
+
+Before coding, decide:
+- whether the component should be server or client
+- what props are truly public API
+- whether variants are justified
+- whether customization is best expressed as composition, children, slots, className, or CVA variants
+
+Do not add props just because they might be useful someday.
+
+## Step 5: Implement like a public registry item
+
+Target quality bar:
+- readable source
+- minimal dependencies
+- strong defaults
+- easy to own after installation
+- accessibility considered by default
+- realistic markup and copy
+- consistent Jalco UI comment and header style
+
+Use `"use client"` only when required by state, effects, browser APIs, event-heavy interactivity, or client-only dependencies.
+
+Comment rules during implementation:
+- use a compact top-of-file header for Jalco-authored public-facing source files when attribution or dependency context is useful
+- for public component entry files, include the component name, a one-sentence description, and key props when helpful
+- prefer the Jalco UI header shape: `jalco-ui`, component name, `by Justin Levine`, `ui.justinlevine.me`, then optional description, props, dependencies, inspiration, and runtime notes
+- keep inline comments minimal and useful
+- do not add decorative separator banners or AI-style section headings
+- do not mass-retrofit copied, upstream, generated, or template-derived files unless they are being meaningfully rewritten
+
+## Step 6: Add or update `registry.json`
+
+For each public item, ensure:
+- `name` matches the folder and install URL
+- `type` is correct
+- `title` is human-readable
+- `description` is concise and docs-aligned
+- `dependencies` lists package dependencies only when required
+- `registryDependencies` lists upstream shadcn registry items when required
+- `files` paths and types are correct
+- `categories` are used when they improve organization
+
+## Step 7: Write the docs page
+
+For a public-facing component, create or update:
+- `/Users/justin/Documents/Github/jalco-ui/app/docs/components/<slug>/page.tsx`
+
+Typical docs flow:
+1. metadata
+2. title + concise description
+3. dependency badges
+4. preview
+5. installation command
+6. usage import + basic example
+7. examples / features / customization / API / notes as justified
+
+Only include sections that improve adoption.
+
+## Step 8: Review before calling it done
+
+Check:
+- Does this feel installable and useful?
+- Is the API smaller and clearer than the first draft?
+- Are variants justified and shown in docs?
+- Is the docs copy polished and aligned with metadata?
+- Is the implementation consistent with existing Jalco UI work?
+
+## Common anti-patterns
+
+Avoid:
+- boolean-prop-heavy APIs
+- variants without real visual meaning
+- generic placeholder examples
+- unnecessary client components
+- docs that repeat obvious implementation details
+- registry metadata that drifts from actual behavior
+- over-abstracting before multiple real use cases exist

.pi/skills/jalco-ui-registry/references/docs-patterns.md

@@ -0,0 +1,105 @@
+# Docs Patterns
+
+Use this file when creating or revising Jalco UI docs pages.
+
+## Canonical spec
+
+The canonical docs format guide lives at:
+- `/Users/justin/Documents/Github/jalco-ui/docs-component-format-spec.md`
+
+Read that file when making docs structure decisions.
+
+## Primary goal
+
+A Jalco UI docs page should help someone:
+- understand what the component is
+- install it quickly
+- see what it looks like
+- copy a working usage example
+- understand meaningful customization points
+
+## Required framework
+
+Public component docs should follow the shared page framework:
+1. Metadata
+2. Header
+3. Preview
+4. Installation
+5. Usage
+
+After that, only include justified optional sections such as:
+- Requirements
+- When to use
+- Examples
+- Features
+- API Reference
+- Customization
+- Notes
+
+## Key structural rules
+
+- Use the standard section order from `docs-component-format-spec.md`.
+- Keep docs consistent across the site without forcing every page to have identical sections.
+- Treat setup blockers as Requirements or Usage guidance, not buried Notes.
+- Do not call every example a variant.
+- Keep examples labeled by meaning: Variants, Sizes, Examples, Configurations, or bundled exports.
+
+## Copy rules
+
+Follow repo guidance from `AGENTS.md` and the docs format spec:
+- start descriptions with a concise sentence
+- do not start with "A", "An", or "A React component for..."
+- avoid implementation-detail-first descriptions
+- avoid fluff and subjective marketing copy in technical summaries
+- keep docs description aligned with `registry.json`
+
+## Installation and requirements
+
+For public items, include the shadcn CLI command using the Jalco registry URL pattern:
+
+```bash
+npx shadcn@latest add https://ui.justinlevine.me/r/<item-name>.json
+```
+
+If a secondary exported component is bundled inside another item, say so clearly instead of pretending it has its own payload.
+
+If supporting setup materially affects adoption, explain it before Examples.
+
+## Usage and examples
+
+Usage should usually include:
+- import example
+- simplest meaningful render example
+- an important runtime note if relevant
+
+Examples should be:
+- realistic
+- labeled clearly
+- grouped by meaning rather than by arbitrary prop existence
+
+## API and notes
+
+Use an API section when the public props are meaningful enough to deserve a formal reference.
+
+Use Notes for secondary behavior details like cache behavior, fallback behavior, or implementation nuance.
+Do not use Notes as a dumping ground for setup blockers or primary usage constraints.
+
+## Alignment rules
+
+Ensure these agree:
+- page metadata description
+- header description
+- `registry.json` description
+- actual implementation behavior
+
+If those drift, fix them together.
+
+## Good docs heuristics
+
+A good Jalco UI docs page is:
+- skimmable
+- honest about constraints
+- visually polished
+- technically precise
+- built from realistic examples
+- minimal without feeling incomplete