update main

.beads/.gitignore

@@ -0,0 +1,44 @@
+# SQLite databases
+*.db
+*.db?*
+*.db-journal
+*.db-wal
+*.db-shm
+
+# Daemon runtime files
+daemon.lock
+daemon.log
+daemon.pid
+bd.sock
+sync-state.json
+last-touched
+
+# Local version tracking (prevents upgrade notification spam after git ops)
+.local_version
+
+# Legacy database files
+db.sqlite
+bd.db
+
+# Worktree redirect file (contains relative path to main repo's .beads/)
+# Must not be committed as paths would be wrong in other clones
+redirect
+
+# Merge artifacts (temporary files from 3-way merge)
+beads.base.jsonl
+beads.base.meta.json
+beads.left.jsonl
+beads.left.meta.json
+beads.right.jsonl
+beads.right.meta.json
+
+# Sync state (local-only, per-machine)
+# These files are machine-specific and should not be shared across clones
+.sync.lock
+sync_base.jsonl
+
+# NOTE: Do NOT add negation patterns (e.g., !issues.jsonl) here.
+# They would override fork protection in .git/info/exclude, allowing
+# contributors to accidentally commit upstream issue databases.
+# The JSONL files (issues.jsonl, interactions.jsonl) and config files
+# are tracked by git by default since no pattern above ignores them.

.beads/README.md

@@ -0,0 +1,81 @@
+# Beads - AI-Native Issue Tracking
+
+Welcome to Beads! This repository uses **Beads** for issue tracking - a modern, AI-native tool designed to live directly in your codebase alongside your code.
+
+## What is Beads?
+
+Beads is issue tracking that lives in your repo, making it perfect for AI coding agents and developers who want their issues close to their code. No web UI required - everything works through the CLI and integrates seamlessly with git.
+
+**Learn more:** [github.com/steveyegge/beads](https://github.com/steveyegge/beads)
+
+## Quick Start
+
+### Essential Commands
+
+```bash
+# Create new issues
+bd create "Add user authentication"
+
+# View all issues
+bd list
+
+# View issue details
+bd show <issue-id>
+
+# Update issue status
+bd update <issue-id> --status in_progress
+bd update <issue-id> --status done
+
+# Sync with git remote
+bd sync
+```
+
+### Working with Issues
+
+Issues in Beads are:
+- **Git-native**: Stored in `.beads/issues.jsonl` and synced like code
+- **AI-friendly**: CLI-first design works perfectly with AI coding agents
+- **Branch-aware**: Issues can follow your branch workflow
+- **Always in sync**: Auto-syncs with your commits
+
+## Why Beads?
+
+✨ **AI-Native Design**
+- Built specifically for AI-assisted development workflows
+- CLI-first interface works seamlessly with AI coding agents
+- No context switching to web UIs
+
+🚀 **Developer Focused**
+- Issues live in your repo, right next to your code
+- Works offline, syncs when you push
+- Fast, lightweight, and stays out of your way
+
+🔧 **Git Integration**
+- Automatic sync with git commits
+- Branch-aware issue tracking
+- Intelligent JSONL merge resolution
+
+## Get Started with Beads
+
+Try Beads in your own projects:
+
+```bash
+# Install Beads
+curl -sSL https://raw.githubusercontent.com/steveyegge/beads/main/scripts/install.sh | bash
+
+# Initialize in your repo
+bd init
+
+# Create your first issue
+bd create "Try out Beads"
+```
+
+## Learn More
+
+- **Documentation**: [github.com/steveyegge/beads/docs](https://github.com/steveyegge/beads/tree/main/docs)
+- **Quick Start Guide**: Run `bd quickstart`
+- **Examples**: [github.com/steveyegge/beads/examples](https://github.com/steveyegge/beads/tree/main/examples)
+
+---
+
+*Beads: Issue tracking that moves at the speed of thought* ⚡

.beads/config.yaml

@@ -0,0 +1,62 @@
+# Beads Configuration File
+# This file configures default behavior for all bd commands in this repository
+# All settings can also be set via environment variables (BD_* prefix)
+# or overridden with command-line flags
+
+# Issue prefix for this repository (used by bd init)
+# If not set, bd init will auto-detect from directory name
+# Example: issue-prefix: "myproject" creates issues like "myproject-1", "myproject-2", etc.
+# issue-prefix: ""
+
+# Use no-db mode: load from JSONL, no SQLite, write back after each command
+# When true, bd will use .beads/issues.jsonl as the source of truth
+# instead of SQLite database
+# no-db: false
+
+# Disable daemon for RPC communication (forces direct database access)
+# no-daemon: false
+
+# Disable auto-flush of database to JSONL after mutations
+# no-auto-flush: false
+
+# Disable auto-import from JSONL when it's newer than database
+# no-auto-import: false
+
+# Enable JSON output by default
+# json: false
+
+# Default actor for audit trails (overridden by BD_ACTOR or --actor)
+# actor: ""
+
+# Path to database (overridden by BEADS_DB or --db)
+# db: ""
+
+# Auto-start daemon if not running (can also use BEADS_AUTO_START_DAEMON)
+# auto-start-daemon: true
+
+# Debounce interval for auto-flush (can also use BEADS_FLUSH_DEBOUNCE)
+# flush-debounce: "5s"
+
+# Git branch for beads commits (bd sync will commit to this branch)
+# IMPORTANT: Set this for team projects so all clones use the same sync branch.
+# This setting persists across clones (unlike database config which is gitignored).
+# Can also use BEADS_SYNC_BRANCH env var for local override.
+# If not set, bd sync will require you to run 'bd config set sync.branch <branch>'.
+sync-branch: "beads-sync"
+
+# Multi-repo configuration (experimental - bd-307)
+# Allows hydrating from multiple repositories and routing writes to the correct JSONL
+# repos:
+#   primary: "."  # Primary repo (where this database lives)
+#   additional:   # Additional repos to hydrate from (read-only)
+#     - ~/beads-planning  # Personal planning repo
+#     - ~/work-planning   # Work planning repo
+
+# Integration settings (access with 'bd config get/set')
+# These are stored in the database, not in this file:
+# - jira.url
+# - jira.project
+# - linear.url
+# - linear.api-key
+# - github.org
+# - github.repo

.beads/issues.jsonl

@@ -0,0 +1 @@
+{"id":"proofkit-137","title":"Fix CLI scaffold missing component files","description":"## CLI Scaffold Missing Component Files\n\n**Test:** `@proofkit/cli` \u003e `browser-apps.test.ts` \u003e 'should create a project with FileMaker integration in CI mode'\n\n**Reproduced locally:** Yes (after deleting stale `packages/tmp/cli-tests/test-fm-project`)\n\n### Missing 3 components:\n1. `src/components/mode-toggle.tsx` - imported by `slot-header-right.tsx:4`\n2. `src/components/ui/sonner.tsx` - imported by `providers.tsx:4`\n3. `src/components/ui/button.tsx` - imported by `page.tsx:11`\n\n### Root cause:\nCLI scaffolding generates code that imports these shadcn/ui-style components but doesn't include the actual component files in the generated project.\n\n### Why it appeared to pass locally before:\nStale `test-fm-project` dir existed from previous runs. Turbo may have cached 'passed' result based on old inputs. Fresh scaffold exposes the missing files.\n\n### Fix needed:\nEnsure CLI registry/templates include all required UI components that generated code imports. Check:\n- `packages/registry/` for component definitions\n- CLI scaffold logic that copies/generates components\n\n### Additional warnings (non-blocking):\n```\nWarning: Invalid input options - For the \"define\". Invalid key: Expected never but received \"define\".\n```\nThis vitest config warning appears twice but doesn't cause failure.","status":"in_progress","priority":2,"issue_type":"bug","created_at":"2026-01-10T13:34:47.060701-06:00","created_by":"ericluce","updated_at":"2026-01-10T13:41:51.749548-06:00"}

.beads/metadata.json

@@ -0,0 +1,4 @@
+{
+  "database": "beads.db",
+  "jsonl_export": "issues.jsonl"
+}

.changeset/better-auth-type-errors.md

@@ -0,0 +1,6 @@
+---
+"@proofkit/better-auth": patch
+---
+
+Fix TypeScript build errors by making adapter/migration types resilient to upstream Better Auth changes.
+

.changeset/fix-typegen-auth-detection.md

@@ -0,0 +1,5 @@
+---
+"@proofkit/typegen": patch
+---
+
+Fix generated client authentication type detection to use OttoAdapter when OTTO_API_KEY environment variable is set with default names

.changeset/pre.json

@@ -18,9 +18,12 @@
   },
   "changesets": [
     "add-format-command",
+    "bright-dogs-teach",
     "brown-keys-float",
+    "fix-typegen-auth-detection",
     "get-query-string-entity-ids-override",
     "happy-rocks-watch",
+    "lucky-zebras-beam",
     "olive-coins-trade",
     "quick-ends-drop",
     "real-ideas-sort",

.claude/CLAUDE.md

@@ -2,6 +2,8 @@
 
 This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
 
+@AGENTS.md
+
 ## Project Overview
 
 ProofKit is a monorepo of TypeScript tools and libraries for building web applications integrated with Claris FileMaker. Documentation: https://proofkit.dev

.claude/ai-builder.lock.json

@@ -0,0 +1,13 @@
+{
+  "version": 1,
+  "artifacts": {
+    "skill:openameba/create-changeset": {
+      "type": "skill",
+      "slug": "create-changeset",
+      "author": "openameba",
+      "name": "create-changeset",
+      "installedAt": "2026-01-07T14:50:43.613Z",
+      "files": [".claude/skills/create-changeset/SKILL.md"]
+    }
+  }
+}

.claude/settings.json

@@ -0,0 +1,5 @@
+{
+  "enabledPlugins": {
+    "typescript-lsp@claude-plugins-official": true
+  }
+}

.claude/skills/create-changeset/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: create-changeset
+description: Analyze git changes and create changesets for package releases. Use when preparing pull requests, creating PRs, when branch has commits ready for review, or when user mentions changeset or version bump.
+---
+# Create Changeset Skill
+
+## Purpose
+
+This skill automatically analyzes branch changes and creates appropriate changesets for package releases in this monorepo. It examines git history, determines version bump types based on Conventional Commits, and generates properly formatted changeset files.
+
+## When to Invoke
+
+Automatically invoke this skill when:
+- User is preparing to create a pull request
+- User mentions "PR", "pull request", or "ready for review"
+- Branch has commits ready for review
+- User explicitly mentions "changeset" or "version bump"
+
+Do NOT invoke when:
+- User is only pushing changes without creating a PR
+- Only documentation files have changed (README, .md files)
+- Only CI/CD configuration has changed (.github/workflows/)
+- Only development tool configuration has changed (eslint, prettier, etc.)
+- Commits are only `docs:`, `chore:`, `ci:`, or `test:` types that don't affect packages
+
+## Pre-execution Validation
+
+Before creating a changeset, check if a changeset file already exists for the current changes:
+- Look for `.changeset/*.md` files (excluding README.md)
+- If exists, ask user: "A changeset already exists. Create another one?"
+
+## Implementation Steps
+
+### 1. Check Current State
+
+Execute `git log main..HEAD` (or `origin/main..HEAD`) to check for committed changes on the branch. If no commits exist, exit early without creating a changeset.
+
+### 2. Analyze Changes
+
+Use `git diff main...HEAD` (or `origin/main...HEAD`) to analyze **committed changes only**.
+
+Identify which packages are affected by checking files under `packages/*/`. Review commit messages using `git log main..HEAD --oneline` (or `origin/main..HEAD`).
+
+### 3. Determine Version Bump Type
+
+Analyze commit messages following Conventional Commits 1.0.0 format:
+
+- **major**: Contains `BREAKING CHANGE` in commit body, or breaking changes detected in code
+  - API signature changes
+  - Removed exports or features
+  - Incompatible behavior changes
+- **minor**: Starts with `feat:` or `feat(scope):` - new features (backward compatible)
+  - New components or functionality
+  - New props or options (with defaults)
+  - New exports
+- **patch**: Starts with `fix:` or `fix(scope):` - bug fixes and minor improvements
+  - Bug fixes
+  - Performance improvements
+  - Minor style updates
+- **skip**: Other types (`chore:`, `docs:`, `ci:`, `test:`) typically don't require changesets unless they affect package functionality
+
+Review actual code changes to confirm the appropriate version bump. **When in doubt between minor and patch, prefer patch for safety.**
+
+If the version bump is ambiguous or unclear:
+- Ask user for clarification
+- Explain the reasoning behind the suggested bump type
+- Allow user to override the suggestion
+
+If all commits are types that don't require changesets (`docs:`, `chore:`, `ci:`, `test:`), exit early without creating a changeset.
+
+### 4. Generate Changeset
+
+Create a changeset file with a descriptive filename in `.changeset/` directory.
+
+**Filename format:**
+- Use kebab-case with `.md` extension
+- Examples: `.changeset/add-new-button.md`, `.changeset/fix-layout-bug.md`, `.changeset/update-icon-props.md`
+
+**File content format:**
+```markdown
+---
+"@openameba/package-name": major|minor|patch
+---
+
+Clear description of the change
+```
+
+**Example for single package:**
+```markdown
+---
+"@openameba/spindle-ui": minor
+---
+
+Add new Button variant for secondary actions
+```
+
+**Example for multiple packages:**
+```markdown
+---
+"@openameba/spindle-ui": minor
+"@openameba/spindle-tokens": patch
+---
+
+- spindle-ui: Add new Button variant for secondary actions
+- spindle-tokens: Fix color token contrast ratio
+```
+
+**Important guidelines:**
+- The description should be user-friendly as it will appear in CHANGELOG
+- **Use the same language as the commit messages** (Japanese or English). If commit messages are mixed, prefer Japanese.
+- Split changesets into separate files when the same package has changes with different purposes (e.g., new feature + bug fix, breaking change + internal refactoring)
+- This creates individual top-level items in release notes, making it easier for readers to understand the intent of each change
+- Example: Create `.changeset/add-secondary-button.md` for a new feature and `.changeset/fix-button-layout.md` for a bug fix, even if both target the same package
+
+### 5. Lint Changeset
+
+Execute `pnpm textlint .changeset/<filename>.md` to validate the changeset file.
+
+**Error handling:**
+- If linting errors occur, attempt to auto-fix common issues:
+  - Spacing and punctuation
+  - Common grammar mistakes
+- Re-run textlint after auto-fix
+- If errors persist:
+  - Display error details to user
+  - Ask user for guidance on how to fix
+  - Do NOT proceed to commit until lint passes
+
+### 6. Verify and Commit
+
+Display the generated changeset for review:
+- Show the file path
+- Show the file content
+- Confirm it accurately reflects the changes
+
+Once verified, commit the changeset file:
+```bash
+git add .changeset/<filename>.md
+git commit -m "chore: add changeset"
+```