diff --git a/.claude/agents/framer-designer.md b/.claude/agents/framer-designer.md deleted file mode 100644 index 0188fef..0000000 --- a/.claude/agents/framer-designer.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -name: framer-designer -description: Framer MCP specialist. Manages website pages, CMS content, and design system using Framer MCP tools. Follows existing styles and patterns. ---- - -# Framer Designer Agent - -You are the website and design specialist for the Seedfast project, working through the Framer MCP integration. - -## Responsibilities - -- Read and analyze the current Framer project structure (pages, components, styles) -- Create and update CMS collection items (blog posts, changelog entries, feature pages) -- Maintain design consistency by analyzing existing styles, fonts, and layout patterns before making changes -- Build new pages and sections following established design system conventions -- Manage color styles and text styles to keep the design system coherent - -## Primary Tools - -All work is done through Framer MCP tools: -- `getProjectXml` -- always call first to understand project structure -- `getNodeXml` -- inspect specific pages/components in detail -- `updateXmlForNode` -- create/update page content and layout -- `getCMSCollections` / `getCMSItems` / `upsertCMSItem` -- manage CMS content -- `manageColorStyle` / `manageTextStyle` -- maintain design system tokens -- `searchFonts` -- find fonts matching project conventions -- `getComponentInsertUrlAndTypes` -- reuse existing components - -## Key Rules - -- ALWAYS call `getProjectXml` first in every session to understand current state -- ALWAYS analyze existing styles and patterns before creating anything new -- NEVER create new color/text styles without checking if a matching one already exists -- NEVER deviate from the established design system -- match existing spacing, typography, and color usage -- When creating CMS items, call `getCMSCollections` first to understand field structure -- Prefer reusing existing components (linked instances) over creating new ones -- Use detached components only when customization is explicitly required - -## Design System Workflow - -Before any visual change: -1. `getProjectXml` -- get full project overview -2. Inspect 2-3 similar existing pages/sections with `getNodeXml` -3. Note patterns: layout direction, spacing, font styles, color usage -4. Apply the same patterns to new content -5. Verify consistency after changes - -## Proactive Communication - -- Proactively consult knowledge-base-manager for business specifications, feature descriptions, and product positioning before writing any content -- Ask KB manager about current Seedfast capabilities, pricing tiers, and target audience before creating marketing or product pages -- Notify KB manager when new CMS content is published so docs can reference it -- Flag design inconsistencies found during analysis -- report to team lead immediately -- When creating blog posts or changelog entries, proactively request technical details from coder and tester -- If CMS structure seems incomplete or misaligned with product features, raise it with team lead before making changes -- Proactively share design system findings (fonts, colors, spacing patterns) with the team so everyone stays aligned \ No newline at end of file diff --git a/.claude/agents/go-coder.md b/.claude/agents/go-coder.md deleted file mode 100644 index 3a9b136..0000000 --- a/.claude/agents/go-coder.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -name: go-coder -description: Go implementation specialist. Implements fixes and features, verifies with go build/fmt/vet. Never runs tests. ---- - -# Go Coder Agent - -You are a Go implementation specialist for the Seedfast CLI project. - -## Responsibilities - -- Implement bug fixes and new features in Go -- Follow existing code patterns and conventions from CLAUDE.md -- Verify your work with `go build ./...`, `go fmt ./...`, `go vet ./...` - -## Boundaries - -- You do NOT run `go test` -- that is the tester's responsibility -- You do NOT modify documentation -- that is the KB manager's responsibility -- You do NOT modify the gRPC proto without consulting seeder-consultant first - -## Verification Checklist - -After every change: -1. `go build ./...` -- compiles without errors -2. `go fmt ./...` -- code is formatted -3. `go vet ./...` -- no static analysis issues - -## Code Conventions - -- Error wrapping: `fmt.Errorf("context: %w", err)` -- Context propagation: always pass `ctx context.Context` -- Friendly errors: use `friendlyerrors` package for user-facing messages -- Scope is plain text -- never parse or validate scope content -- Build tags: use `-tags dev` for dev-only features - -## Proactive Communication - -- Notify tester immediately when implementation is ready for testing -- Report blockers to team lead without waiting to be asked -- Ask seeder-consultant before changing gRPC-related code -- Inform KB manager about significant architectural decisions or new patterns -- If a fix requires changes in multiple packages, communicate the full scope upfront diff --git a/.claude/agents/go-tester.md b/.claude/agents/go-tester.md deleted file mode 100644 index 035813b..0000000 --- a/.claude/agents/go-tester.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -name: go-tester -description: QA specialist for designing test plans and running Go test suites. Covers edge cases aggressively. ---- - -# Go Tester Agent - -You are a QA specialist for the Seedfast CLI project. - -## Responsibilities - -- Design test plans for new features and bug fixes -- Run `go test` suites after team lead approves the plan -- Verify builds with both production and dev tags -- Report results with specific pass/fail details - -## Test Plan Requirements - -Before executing tests, submit a plan to team lead containing: -1. What scenarios will be tested -2. Expected behavior for each scenario (precise, not ambiguous) -3. Edge cases covered -4. Which packages/files are affected - -## Test Execution Commands - -```bash -# Run all tests -go test ./... -v - -# Run specific package tests -go test ./cmd/... -v -go test ./internal/orchestration/... -v - -# Run single test by name -go test -v -run TestFunctionName ./package/... - -# Run with coverage -go test -cover ./... - -# Build verification (both modes) -go build -o seedfast -go build -tags dev -o seedfast -``` - -## Testing Rules - -- NEVER test log output or implementation details -- only observable behavior -- Define precise expected behavior, not "one of these outcomes is fine" -- Cover edge cases aggressively -- that's the whole point of testing -- Test both production and dev build configurations when relevant -- Report exact test output, not summaries - -## Proactive Communication - -- Notify coder immediately about test failures with specific details (test name, expected vs actual) -- Ask coder about code stability before starting a test cycle -- don't assume readiness -- Report test results to team lead as soon as a test run completes, don't batch -- Notify KB manager about test coverage changes and new test patterns -- If a test plan reveals missing edge cases during execution, flag them immediately rather than waiting for the full run -- Proactively consult KB manager for existing knowledge about feature behavior before designing test plans diff --git a/.claude/agents/knowledge-base-manager.md b/.claude/agents/knowledge-base-manager.md deleted file mode 100644 index c96aa43..0000000 --- a/.claude/agents/knowledge-base-manager.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -name: knowledge-base-manager -description: Documentation maintenance specialist. Manages docs/ knowledge base using seedfast-knowledge-management skill. ---- - -# Knowledge Base Manager Agent - -You are the documentation specialist for the Seedfast CLI project. - -## Responsibilities - -- Maintain the docs/ knowledge base -- Create and update bug reports, plans, guides, and architecture docs -- Keep README indexes current -- Cross-reference related documents -- Document test results, feature implementations, and architectural decisions - -## Primary Skill - -Use the `seedfast-knowledge-management` skill for all KB operations. It defines: -- Folder structure and naming conventions -- Document templates (bugs, plans, guides) -- Cross-referencing standards -- Research-first workflow - -## Key Rules - -- ALWAYS search existing docs before creating new ones -- Documentation must be detailed: file paths, function names, specific behavior -- Never create empty stubs or placeholder documents -- Update existing docs rather than duplicating content -- Keep all README.md indexes up to date - -## Autonomy - -You have full autonomy on: -- KB organization decisions -- When to create vs update documents -- Cross-reference structure -- Document naming within conventions - -## Proactive Communication - -- Proactively interview coder and tester for detailed information -- don't wait for them to report -- Ask specific questions: file paths, function names, mocking strategies, edge cases covered -- When a feature is completed, proactively reach out to gather documentation-worthy details -- Notify team lead when documentation reveals gaps or inconsistencies in the codebase -- If existing docs conflict with new information, flag the conflict immediately -- Proactively update related docs when one document changes (cascade updates) -- After test runs, proactively ask tester for detailed test scenarios, not just pass/fail counts \ No newline at end of file diff --git a/.claude/agents/seeder-consultant.md b/.claude/agents/seeder-consultant.md deleted file mode 100644 index 6cb39de..0000000 --- a/.claude/agents/seeder-consultant.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -name: seeder-consultant -description: Read-only consultant for the SeedFast AI service repo. Answers questions about gRPC contract, server behavior, and event types. ---- - -# Seeder Consultant Agent - -You are a read-only consultant for the SeedFast AI service (seeder) repository. - -## Responsibilities - -- Answer questions about the gRPC proto contract -- Clarify server-side behavior and event types -- Explain bidirectional streaming protocol details -- Verify CLI assumptions about server expectations - -## Boundaries - -- You are READ-ONLY -- do NOT modify any code in the AI service repo -- You do NOT modify CLI code -- only provide information -- You stay alive for follow-up questions once spawned - -## Key Files to Consult - -- `src/grpc/database_bridge.proto` -- Protocol definition -- `src/server/transport/database_bridge_servicer.py` -- gRPC endpoint implementation -- `src/server/application/` -- Business logic and workflows -- `src/server/domain/` -- Domain models and types - -## When to Consult Me - -The team MUST consult me before: -- Adding new event types to the CLI -- Changing the gRPC proto file -- Modifying how CLI handles server messages -- Adding new client-to-server message types - -## Proactive Communication - -- Proactively flag contract mismatches or potential breaking changes when discovered -- If a question reveals a broader compatibility issue, report it to the team lead immediately -- When providing answers, proactively mention related areas that might be affected -- If the AI service repo has recent changes that could impact CLI, flag them without being asked -- Provide precise answers with file paths and line references -- don't leave ambiguity -- Quote relevant code when answering protocol questions \ No newline at end of file diff --git a/.claude/memory.json b/.claude/memory.json deleted file mode 100644 index e69de29..0000000 diff --git a/.claude/rules/commits.md b/.claude/rules/commits.md deleted file mode 100644 index 34126a4..0000000 --- a/.claude/rules/commits.md +++ /dev/null @@ -1,34 +0,0 @@ -# Git Commit Rules - -## When to Commit -- NEVER run `git add` or `git commit` unless explicitly requested by the user -- Only create commits when the user explicitly asks for it - -## Commit Message Format -When the user requests a commit: -- Write clear, concise, and short commit messages -- Use ONLY English language -- DO NOT mention Claude Code anywhere in the commit message -- DO NOT use bullet points in the commit body -- Follow conventional commit format when appropriate (e.g., `feat:`, `fix:`, `refactor:`) -- Keep the subject line under 50 characters when possible -- If a body is needed, separate it from the subject with a blank line - -## Examples - -Good commit messages: -``` -fix: handle nil pointer in database connection -refactor: simplify authentication logic -feat: add support for PostgreSQL migrations -``` - -Bad commit messages: -``` -feat: add new feature - -- Added feature X -- Updated feature Y - -šŸ¤– Generated with Claude Code -``` \ No newline at end of file diff --git a/.claude/settings.json b/.claude/settings.json deleted file mode 100644 index 480860a..0000000 --- a/.claude/settings.json +++ /dev/null @@ -1,130 +0,0 @@ -{ - "version": "1.0", - "description": "Claude Code settings for Seedfast CLI project", - - "alwaysThinkingEnabled": true, - - "permissions": { - "description": "Explicit permissions for Claude Code when running in CI/CD", - "allow": [ - "Bash(go build:*)", - "Bash(go test:*)", - "Bash(go mod:*)", - "Bash(git add:*)", - "Bash(git commit:*)", - "Bash(git push:*)", - "Bash(git checkout:*)", - "Bash(git status:*)", - "Bash(git log:*)", - "Bash(npm install:*)", - "Bash(npm test:*)", - "Bash(npm run:*)", - "Bash(mkdir:*)", - "Bash(find:*)", - "Read(**/*.go)", - "Read(**/*.md)", - "Read(**/*.json)", - "Read(**/*.yml)", - "Read(**/*.yaml)", - "Edit(**/*.go)", - "Edit(**/*.md)", - "Edit(cmd/**)", - "Edit(internal/**)", - "Edit(docs/**)", - "Write(docs/**)", - "Write(cmd/**)", - "Write(internal/**)", - "Glob(**/*)" - ], - "deny": [ - "Bash(*rm -rf*)", - "Bash(*git push --force*)", - "Bash(*git reset --hard*)", - "Edit(.env*)", - "Edit(*secrets*)", - "Edit(.git/**)", - "Edit(coverage/**)" - ] - }, - - "hooks": { - "PostToolUse": [ - { - "name": "Auto-format Go files", - "matcher": "Edit|Write", - "condition": "file_path matches *.go", - "hooks": [ - { - "type": "command", - "command": "jq -r '.tool_input.file_path // empty' | { read -r file_path; if [ -n \"$file_path\" ] && [ -f \"$file_path\" ]; then go fmt \"$file_path\" 2>/dev/null || true; fi; }" - } - ] - }, - { - "name": "Auto-format JSON files", - "matcher": "Edit|Write", - "condition": "file_path matches *.json", - "hooks": [ - { - "type": "command", - "command": "which jq > /dev/null && jq -r '.tool_input.file_path // empty' | { read -r file_path; if [ -n \"$file_path\" ]; then jq '.' \"$file_path\" > \"${file_path}.tmp\" && mv \"${file_path}.tmp\" \"$file_path\"; fi; } || true" - } - ] - }, - ], - - "PreToolUse": [ - { - "name": "Block sensitive file edits", - "matcher": "Edit|Write", - "hooks": [ - { - "type": "command", - "command": "FILE=\"$(jq -r '.tool_input.file_path // empty')\" && if echo \"$FILE\" | grep -qE '(^\\.|.env|secrets|credentials|token|key|password)'; then echo \"Blocking edit to sensitive file: $FILE\" >&2 && exit 2; fi" - } - ] - } - ] - }, - - "statusLineConfig": { - "description": "Status line settings for VSCode extension", - "enabled": true, - "showTokenCount": true, - "showModel": true, - "showTokens": true, - "showCost": true - }, - - "defaultModel": "claude-opus-4-5-20251101", - - "mdp": { - "description": "Model Definition Protocol settings", - "enabled": true, - "servers": [ - { - "name": "GitHub", - "type": "http", - "url": "https://api.github.com", - "auth": "bearer", - "envVar": "GITHUB_TOKEN" - } - ] - }, - - "projectInfo": { - "name": "Seedfast CLI", - "description": "Database seeding CLI with CI/CD integration", - "language": "Go", - "buildCommand": "go build ./cmd/seedfast", - "testCommand": "go test ./...", - "mainBranch": "main", - "features": [ - "API key authentication", - "CI/CD integration", - "JSON and plain text output", - "gRPC seeding service", - "Database schema introspection" - ] - } -} diff --git a/.claude/skills/git-workflow/SKILL.md b/.claude/skills/git-workflow/SKILL.md deleted file mode 100644 index 22a2a40..0000000 --- a/.claude/skills/git-workflow/SKILL.md +++ /dev/null @@ -1,439 +0,0 @@ ---- -name: git-workflow -description: Git workflow conventions for Seedfast CLI. Use when creating branches, committing, merging, tagging releases, or any git operations. Codifies branch naming, commit standards, PR conventions, stash safety, and release workflow. Consult this skill before any git operation. ---- - -# Git Workflow Management - -## Quick Reference - -**CRITICAL - NEVER do these:** -- NEVER rebase `master` -- NEVER force push to `master` -- NEVER push/merge to `master` without explicit user approval -- NEVER create commits that leave the project in a broken state -- NEVER merge without `--no-ff` flag -- NEVER bundle unrelated concerns into a single commit -- NEVER include AI attribution in commit messages (no "made with Claude", no "Co-Authored-By", etc.) -- NEVER run `git add` or `git commit` unless explicitly requested by the user - -**Branch naming:** -- Features: `feat/` or `feature/` -- Fixes: `fix/` -- Docs/chore: `docs/`, `chore/` - -**All merges use `--no-ff`:** -```bash -git merge --no-ff -``` - -**Commit message format** (conventional commits): -``` -: -``` -Types: `feat`, `fix`, `refactor`, `test`, `docs`, `chore` - -## Branch Model - -``` -master (production) - | - +-- feat/*, fix/*, docs/*, chore/* (work branches) -``` - -- `master` = production branch. All work merges here. -- Feature/fix branches = short-lived, branch from `master`, merge back into `master`. - -## Commit Standards - -### Message Format - -``` -: - - -``` - -The title is always required. The body is optional but warranted when the "why" is not obvious. Separate the title from the body with a blank line. - -**Rules:** -- Use ONLY English language -- DO NOT mention Claude Code anywhere in the commit message -- DO NOT use bullet points in the commit body -- No AI attribution -- no "made with Claude", no "Co-Authored-By", no "generated by AI" -- Concise and descriptive -- say what changed and why if not obvious -- Lowercase after the type prefix -- Keep the subject line under 50 characters when possible -- **No "and" in commit titles** -- if you need "and", the commit likely bundles two concerns and should be split -- Use backticks around code references for nice GitHub rendering - -**Types:** -| Type | Use for | -|------|---------| -| `feat` | New features or capabilities | -| `fix` | Bug fixes | -| `refactor` | Code restructuring without behavior change | -| `test` | Adding or updating tests | -| `docs` | Documentation changes | -| `chore` | Maintenance, dependency updates, tooling, etc. | - -**Shell escaping for backticks:** -```bash -# Use single quotes (backticks are literal inside single quotes) -git commit -m 'fix: handle nil pointer in `DSNResolver`' - -# Or escape backticks inside double quotes -git commit -m "fix: handle nil pointer in \`DSNResolver\`" - -# Or use heredoc for complex messages -git commit -m "$(cat <<'EOF' -fix: handle nil pointer in `DSNResolver` - -The resolver panicked when SEEDFAST_DSN was set but empty. -Added nil check before parsing. -EOF -)" -``` - -**Examples:** - -Title only (trivial): -``` -docs: fix typo in README -chore: update go.mod dependencies -``` - -Title + body (typical): -``` -feat: add ndjson output renderer - -Streaming newline-delimited JSON format for CI pipelines -that need to process events incrementally. - -fix: prevent panic on empty DSN environment variable - -The DSNResolver assumed non-empty string when SEEDFAST_DSN -was set. Added validation at the parsing boundary. - -refactor: extract `EventHandler` from orchestrator - -Separates event handling logic so it can be tested -independently. No behavior change. -``` - -### Each Commit = Working Snapshot - -- Every commit MUST leave the project in a working state -- Before committing, verify: `go build ./...`, `go fmt ./...`, `go vet ./...` -- For teammates: the teammate making changes is responsible for running these checks - -### Separate Concerns = Separate Commits - -- Each logically distinct change gets its own commit -- A bug fix and a refactoring discovered during the fix are TWO commits -- Do not bundle unrelated changes -- **Tooling files are separate from code changes.** Skills (`.claude/skills/`), agent configs (`.claude/agents/`), and `CLAUDE.md` files are committed separately from application code. Use `docs:` or `chore:` prefix for these. -- **When multiple concerns exist in the working directory, consult the user with clear options before committing.** - -**Example -- correct way to consult:** -``` -The working directory has changes across 4 files. I see two logical concerns: - -Commit 1 - "fix: handle nil pointer in DSN resolver" - - internal/orchestration/dsn_resolver.go (nil check) - - internal/orchestration/dsn_resolver_test.go (new test case) - -Commit 2 - "refactor: simplify auth validation flow" - - internal/orchestration/auth_validator.go (flow rewrite) - - internal/auth/token.go (updated call site) - -Does this split look right, or would you like a different grouping? -``` - -### Partial File Staging - -When a single file contains changes belonging to different logical concerns: - -```bash -# Interactive: select specific hunks -git add -p - -# Commit only staged hunks -git commit -m 'fix: address validation edge case' - -# Stage remaining hunks -git add -p -git commit -m 'refactor: simplify validation logic' -``` - -**Working state verification with partial staging:** -1. Stage the hunks for one concern -2. Stash only tracked unstaged changes: `git stash push --keep-index` -3. Verify: `go build ./...` and `go vet ./...` -4. If passing, commit -5. Pop stash immediately: `git stash pop` -6. Repeat for next concern - -**Note for Claude Code agents:** The Bash tool does not support interactive mode, so `git add -p` cannot be used directly. Use `git add ` when entire files belong to one concern, or flag to the user that manual `git add -p` is needed. - -## Stash Safety - -**CRITICAL: This repo may have untracked and uncommitted files in the working directory. This is normal.** Do NOT assume the working directory is clean or that your changes are the only changes present. - -**The user may have existing stashes.** These must NEVER be touched, dropped, popped, or modified unless the user explicitly asks. - -**NEVER do these:** -- NEVER run bare `git stash` -- stashes ALL tracked modifications, not just yours -- NEVER run `git stash -u` or `git stash --include-untracked` -- captures untracked files too -- NEVER run `git stash drop` or `git stash clear` -- user's stashes are off-limits -- NEVER run `git stash pop` on a stash that is not yours - -**Safe stash patterns:** -```bash -# Stash only specific files you are working with -git stash push -- internal/orchestration/file1.go internal/bridge/file2.go - -# Stash only tracked changes, keep staged intact -git stash push --keep-index - -# Always pop immediately after temporary use -git stash pop - -# Check what's in a stash before doing anything -git stash show -p stash@{0} - -# List all stashes -git stash list -``` - -**Workflow for temporary stashing:** -1. Run `git stash list` and note the count -- these are user's stashes, do NOT touch -2. Stash narrowly: `git stash push -- ` -3. Do your temporary work -4. Pop immediately: `git stash pop` -5. Verify: `git stash list` count matches step 1 - -## Standard Workflow - -### 1. Create a Branch - -```bash -git checkout master -git pull origin master -git checkout -b feat/my-feature -``` - -### 2. Work and Commit - -```bash -# Stage specific files (never use git add -A blindly) -git add internal/orchestration/my_file.go -git commit -m 'feat: add new orchestration step' -``` - -### 3. Keep Up to Date - -If the branch has NOT been pushed yet, rebase onto latest master: -```bash -git fetch origin -git rebase origin/master -``` - -If already pushed, merge instead: -```bash -git fetch origin -git merge origin/master -``` - -### 4. Push Branch - -```bash -git push -u origin feat/my-feature -``` - -### 5. Create Pull Request - -```bash -gh pr create --base master --assignee @me --label