bluera-knowledge 0.14.0 → 0.14.1

package/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "bluera-knowledge",
-  "version": "0.14.0",
+  "version": "0.14.1",
   "description": "Clone repos, crawl docs, search locally. Fast, authoritative answers for AI coding agents."
 }

package/CHANGELOG.md

@@ -2,6 +2,13 @@
 
 All notable changes to this project will be documented in this file. See [commit-and-tag-version](https://github.com/absolute-version/commit-and-tag-version) for commit guidelines.
 
+## [0.14.1](https://github.com/blueraai/bluera-knowledge/compare/v0.14.0...v0.14.1) (2026-01-16)
+
+
+### Bug Fixes
+
+* **npm:** add files field to prevent 389MB package bloat ([fa55313](https://github.com/blueraai/bluera-knowledge/commit/fa55313050381b8f2c51cb89d42f66c30adfe58c))
+
 ## [0.14.0](https://github.com/blueraai/bluera-knowledge/compare/v0.13.3...v0.14.0) (2026-01-16)
 
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bluera-knowledge",
-  "version": "0.14.0",
+  "version": "0.14.1",
   "description": "CLI tool for managing knowledge stores with semantic search",
   "type": "module",
   "bin": {
@@ -64,6 +64,17 @@
   "publishConfig": {
     "access": "public"
   },
+  "files": [
+    "dist/",
+    "python/",
+    "hooks/",
+    "commands/",
+    "skills/",
+    ".claude-plugin/",
+    "README.md",
+    "CHANGELOG.md",
+    "LICENSE"
+  ],
   "devDependencies": {
     "@eslint/js": "^9.39.2",
     "@types/babel__core": "^7.20.5",

package/.claude/commands/code-review.md

@@ -1,15 +0,0 @@
-# Code Review
-
-Review the local codebase using multi-agent analysis. See @.claude/skills/code-review-repo/skill.md for process details.
-
-## Context
-
-!`echo "---PROJECT---" && ls -la && echo "---CLAUDE.md FILES---" && find . -name CLAUDE.md 2>/dev/null`
-
-## Workflow
-
-1. **Gather context**: Find all CLAUDE.md files and source files
-2. **Multi-agent review**: Launch 5 parallel agents (CLAUDE.md compliance, bug scan, git history, PR comments, code comments)
-3. **Score issues**: Haiku agents score each issue 0-100 for confidence
-4. **Filter**: Only report issues with confidence >= 80
-5. **Output**: Print formatted results to console

package/.claude/commands/commit.md

@@ -1,34 +0,0 @@
-# Commit
-
-Create atomic, well-organized commits. See @.claude/skills/atomic-commits/SKILL.md for documentation check criteria.
-
-## Context
-
-!`git status && echo "---STAGED---" && git diff --cached --stat && echo "---UNSTAGED---" && git diff --stat && echo "---UNTRACKED---" && git ls-files --others --exclude-standard && echo "---HISTORY---" && git log --oneline -10`
-
-## Workflow
-
-1. **Analyze**: Run `git diff HEAD` to see all changes
-2. **Documentation Check**: Check if README.md or CLAUDE.md need updates (see skill)
-3. **Group**: Identify logical features (see skill for grouping rules)
-4. **Commit each group**:
-   ```bash
-   git add <files>
-   git commit -m "<type>(<scope>): <description>"
-   ```
-5. **Handle untracked**: Categorize as commit/ignore/intentional
-6. **Report**: Show commits created and final `git status --short`
-
-## Validation
-
-Pre-commit hooks run automatically:
-- **Doc-only changes**: Skips all validation (instant)
-- **Code changes**: Runs lint + typecheck per language
-
-If hooks fail, fix issues and retry. Never use `--no-verify`.
-
-## Safety
-
-- Never force push
-- Never amend commits from other sessions
-- Ask if unsure about grouping

package/.claude/council-cache/1a43ed5977b8f29afc79a9bf5c4082ee5ad8338c42ab991a4241a48f80c1e46d.json

@@ -1,7 +0,0 @@
-{
-  "provider": "openai",
-  "model": "codex-mini-latest",
-  "prompt": "What are the best trigger keywords and patterns for a skill auto-activation system in a Claude Code plugin? Context: We're building a UserPromptSubmit hook for the bluera-knowledge plugin that detects when users would benefit from learning about specific skills. The 5 skills are: (1) knowledge-search - how to query indexed library sources, (2) when-to-query - deciding between BK vs Grep/Read, (3) search-optimization - optimizing search parameters, (4) advanced-workflows - multi-tool orchestration, (5) store-lifecycle - managing knowledge stores. Key insight: if a user already uses BK terminology, they don't need the skill suggested. We want to catch users who SHOULD be using BK but don't know it exists.",
-  "response": "Below is a bite‑sized “pattern cookbook” you can drop into your `UserPromptSubmit` hook in the bluera‑knowledge Claude Code plugin. The idea is simple:\n\n1. **Look for “natural” signals** that a user is trying to do something Blue‑Knowledge (BK) was built for, but  \n2. **Exclude** anyone already using BK lingo (e.g. “knowledge‑search,” “index,” “store,” “workflow”) so you don’t remind the experienced.\n\n---\n\n## 1. Skill → Trigger‑patterns matrix\n\n| Skill                | What it is                                                                                   | Trigger patterns (if user text _contains_)                                                                                                     | Exclude if user text _contains_                        |\n|:---------------------|:---------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------|:--------------------------------------------------------|\n| **knowledge‑search** | How to query an indexed library of docs/sources.                                             | `\\b(find|lookup|search|get me|show me|where can i find)\\b.*\\b(docs|documentation|references?|articles?)\\b`                                       | `\\bknowledge[- ]search\\b|\\bindex(ed)?\\b|\\bstore\\b`       |\n| **when‑to‑query**    | Deciding whether to use BK vs. grep/`read()` etc.                                             | `\\b(grep|read\\(\\)|scan files|open files manually|search local files)\\b|\\b(is there a better way)\\b`                                             | `\\bwhen[- ]to[- ]query\\b|\\bblue[- ]knowledge\\b`          |\n| **search‑optimization** | Tuning filters, relevance, context windows, metadata to get better hits.                   | `\\b(narrow|filter|refine|limit|boost|prioritize|sort)\\b.*\\b(results|hits|matches)\\b`                                                           | `\\bsearch[- ]optimization\\b|\\brelevance\\b|\\bcontext window\\b` |\n| **advanced‑workflows** | Chaining multiple tools/APIs, branching, retrieval‑then‑generation, tool orchestration.      | `\\b(chain|pipeline|orchestrate|automate|workflow|multi[- ]step|multi[- ]tool)\\b`                                                               | `\\badvanced[- ]workflows\\b|\\btool orchestration\\b`       |\n| **store‑lifecycle**   | Setting up/updating/archiving knowledge stores, versioning, pruning old info.               | `\\b(create|update|delete|archive|prune|version)\\b.*\\b(store|index|database|repository)\\b`                                                       | `\\bstore[- ]lifecycle\\b|\\bknowledge[- ]store\\b`          |\n\n---\n\n### 1.1. Example Regex snippets\n\n```js\n// snippet for knowledge-search\nconst KNOWLEDGE_SEARCH_RE = /\\b(?:find|lookup|search|get me|show me|where can i find)\\b.*\\b(?:docs|documentation|references?|articles?)\\b/i;\n\n// snippet for when-to-query\nconst WHEN_TO_QUERY_RE = /\\b(?:grep|read\\(\\)|scan files|open files manually|search local files)\\b|\\b(?:is there a better way)\\b/i;\n\n// snippet for store-lifecycle\nconst STORE_LIFECYCLE_RE = /\\b(?:create|update|delete|archive|prune|version)\\b.*\\b(?:store|index|database|repository)\\b/i;\n```\n\n---\n\n## 2. Putting it together in your hook\n\nBelow is a simplified example of how you might wire these patterns into a Claude Code `UserPromptSubmit` hook. You’ll want to adjust the messaging and localization to taste.\n\n```js\n/**\n * bluera-knowledge UserPromptSubmit hook\n * Detect users who could benefit from Blue‑Knowledge skills.\n */\nexport async function onUserPromptSubmit(event, ctx) {\n  const text = event.prompt.text;\n\n  // quick bailout: if they already speak BK\n  const hasBKTerm = /\\bknowledge[- ]search\\b|\\bwhen[- ]to[- ]query\\b|\\bsearch[- ]optimization\\b|\\badvanced[- ]workflows\\b|\\bstore[- ]lifecycle\\b|\\bblue[- ]knowledge\\b/i.test(text);\n  if (hasBKTerm) return;\n\n  // mapping skill → [pattern, user‐facing hint]\n  const SKILLS = [\n    {\n      name: \"knowledge-search\",\n      re: /\\b(?:find|lookup|search|get me|show me|where can i find)\\b.*\\b(?:docs|documentation|references?|articles?)\\b/i,\n      hint: \"🔍 You can try using our **knowledge‑search** feature to query indexed docs—no manual grepping needed!\"\n    },\n    {\n      name: \"when-to-query\",\n      re: /\\b(?:grep|read\\(\\)|scan files|open files manually|search local files)\\b|\\b(?:is there a better way)\\b/i,\n      hint: \"💡 Noticed you're grepping or opening files one by one. Our **when‑to‑query** guide helps decide BK vs. direct file search.\"\n    },\n    {\n      name: \"search-optimization\",\n      re: /\\b(?:narrow|filter|refine|limit|boost|prioritize|sort)\\b.*\\b(?:results|hits|matches)\\b/i,\n      hint: \"⚙️ Want more relevant hits? See our **search‑optimization** tips for tuning relevance and filters.\"\n    },\n    {\n      name: \"advanced-workflows\",\n      re: /\\b(?:chain|pipeline|orchestrate|automate|workflow|multi[- ]step|multi[- ]tool)\\b/i,\n      hint: \"🔗 Looking to chain tools or build pipelines? Check out **advanced‑workflows** for multi‑tool orchestration.\"\n    },\n    {\n      name: \"store-lifecycle\",\n      re: /\\b(?:create|update|delete|archive|prune|version)\\b.*\\b(?:store|index|database|repository)\\b/i,\n      hint: \"🗄️ Managing indexes or archiving old data? Our **store‑lifecycle** guide covers store setup, pruning, and versioning.\"\n    }\n  ];\n\n  // find the first match\n  for (const skill of SKILLS) {\n    if (skill.re.test(text)) {\n      await ctx.reply({\n        type: \"skill-suggestion\",\n        skill: skill.name,\n        message: skill.hint\n      });\n      break;\n    }\n  }\n}\n```\n\n---\n\n## 3. Tuning tips\n\n1. **Balance precision/recall**:  \n   - Start _wide_: shorter patterns catch more but risk noise.  \n   - Refine as you gather real prompts: update regex to avoid false positives.\n\n2. **Avoid overlap**:  \n   If two patterns both match, pick the one that feels _most_ immediately helpful. (Above example picks the first.)\n\n3. **User‑facing copy**:  \n   Keep hints crisp, emoji‑tagged, and link directly to your docs or `@help` commands.\n\n4. **Metrics & feedback loop**:  \n   Log suggestions shown vs. accepted. Tune patterns around low‑acceptance hits.\n\n---\n\n### Summary\n\nBy combining simple regex‑based detectors with an exclusion of existing BK terminology, you’ll catch “hidden” use cases where users are laboring manually and would love a BK shortcut. Tweak patterns over time against your live traffic, and you’ll have a reliable auto‑activation layer that boosts discoverability _without_ nagging your power users.",
-  "timestamp": 1768432278
-}

package/.claude/hooks/post-edit-check.sh

@@ -1,40 +0,0 @@
-#!/bin/bash
-# Smart post-edit auto-fix hook
-# Auto-fixes lint issues and validates types on modified files
-
-cd "$CLAUDE_PROJECT_DIR" || exit 0
-
-# Get modified TS/JS files (uncommitted changes)
-MODIFIED_TS_FILES=$(git diff --name-only HEAD 2>/dev/null | grep -E '\.(ts|tsx|js|jsx)$' || true)
-
-# If no TS/JS changes, skip
-if [ -z "$MODIFIED_TS_FILES" ]; then
-  exit 0
-fi
-
-# Auto-fix lint issues on modified files only (fast)
-echo "$MODIFIED_TS_FILES" | xargs npx eslint --fix --quiet 2>/dev/null || true
-
-# Check for remaining lint errors (exit 2 to block and show to Claude)
-LINT_OUTPUT=$(echo "$MODIFIED_TS_FILES" | xargs npx eslint --quiet 2>&1)
-if [ -n "$LINT_OUTPUT" ]; then
-  echo "$LINT_OUTPUT" >&2
-  exit 2
-fi
-
-# Run typecheck (exit 2 to block and show to Claude)
-TYPE_OUTPUT=$(npx tsc --noEmit --pretty false 2>&1)
-if [ -n "$TYPE_OUTPUT" ]; then
-  echo "$TYPE_OUTPUT" | head -20 >&2
-  exit 2
-fi
-
-# Check for anti-patterns in code files only (not docs/markdown)
-ANTI_PATTERN=$(git diff -- '*.ts' '*.tsx' '*.js' '*.jsx' ':!dist/' | grep -E '\b(fallback|deprecated|backward compatibility|legacy)\b' | grep -v '^-' | grep -E '^\+' || true)
-if [ -n "$ANTI_PATTERN" ]; then
-  echo 'Anti-pattern detected (fallback/deprecated/backward compatibility/legacy). Review CLAUDE.md.' >&2
-  echo "$ANTI_PATTERN" >&2
-  exit 2
-fi
-
-exit 0

package/.claude/rules/code-quality.md

@@ -1,12 +0,0 @@
-# Code Quality Rules
-
-## Fail Early and Fast
-
-Our code is expected to *work* as-designed:
-- Use `throw` when state is unexpected or for any error condition
-- Use 100% strict typing; no `any` no `as`, unless completely unavoidable and considered best practice
-
-## Never
-
-- Write "fallback code" or "graceful degradation" code or implement "defaults" *unless* it's part of the specification
-- Leave commented code, nor reference outdated/deprecated implementations

package/.claude/rules/git.md

@@ -1,5 +0,0 @@
-# Git Rules
-
-## Never
-
-- Use `--no-verify` on Git commits; this anti-pattern completely circumvents the code protections we have in place

package/.claude/rules/versioning.md

@@ -1,7 +0,0 @@
-# Versioning Rules
-
-## Always
-
-- Use the `bun run version:*` commands after changes
-  - Without this, the changes would not be detected by Claude Code
-- Push to main after version bump - releases happen automatically (no manual tagging needed)

package/.claude/settings.local.json.example

@@ -1,45 +0,0 @@
-{
-  "permissions": {
-    "allow": [
-      "Bash(osascript:*)",
-      "Bash(bun run lint:*)",
-      "Bash(bun run typecheck:*)",
-      "Bash(npm run lint:*)",
-      "Bash(npm run typecheck:*)",
-      "Bash(bun run precommit:*)"
-    ],
-    "deny": [
-      "Bash(*validate-npm-release*)",
-      "Bash(bun run validate:*)",
-      "Bash(npm run validate:*)"
-    ]
-  },
-  "hooks": {
-    "PostToolUse": [
-      {
-        "matcher": "Write|Edit",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "\"$CLAUDE_PROJECT_DIR/.claude/hooks/post-edit-check.sh\"",
-            "statusMessage": "Validating changes..."
-          }
-        ]
-      }
-    ],
-    "Notification": [
-      {
-        "matcher": "permission_prompt|idle_prompt|elicitation_dialog",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "osascript -e 'display notification \"Claude needs your input\" with title \"Claude Code\" sound name \"Glass\"' 2>/dev/null || true"
-          }
-        ]
-      }
-    ]
-  },
-  "enabledPlugins": {
-    "bluera-knowledge@bluera": true
-  }
-}

package/.claude/skills/atomic-commits/SKILL.md

@@ -1,61 +0,0 @@
----
-name: atomic-commits
-description: Create atomic commits grouped by logical features with README.md and CLAUDE.md awareness.
-version: 1.0.0
----
-
-# Atomic Commits with Documentation Awareness
-
-Guidelines for creating well-organized commits with README.md and CLAUDE.md awareness.
-
-## Documentation Check
-
-Before committing, evaluate if changes need documentation updates.
-
-### README.md (User-facing documentation)
-
-| Change Type | README Section to Update |
-|-------------|-------------------------|
-| MCP tools added/removed/renamed | MCP Tools table, MCP Integration section |
-| New commands or skills | Commands/Skills documentation |
-| CLI interface changes | Usage examples |
-| Configuration changes | Configuration/Environment sections |
-| Breaking API changes | Upgrade/migration notes |
-| New features | Feature documentation |
-| Installation changes | Installation section |
-
-**Trigger files → check README.md:**
-- `src/mcp/server.ts` - MCP tool surface
-- `.claude-plugin/plugin.json` - Plugin metadata
-- `commands/*.md` - Command documentation
-
-### CLAUDE.md (Claude Code memory - hierarchical)
-
-CLAUDE.md stores context that helps future sessions "do the right thing". Update when:
-- You struggled with something and the insight would prevent future mistakes
-- Important patterns or conventions that aren't obvious from code alone
-- Workflows or commands that are non-trivial to discover
-
-CLAUDE.md is hierarchical - use the directory level matching the changed files. Use `@path/to/file` includes to stay DRY.
-
-| Change Scope | Which CLAUDE.md |
-|--------------|-----------------|
-| Project-wide (scripts, CI/CD, build) | Root CLAUDE.md |
-| Directory-specific patterns | Subdirectory CLAUDE.md (create if needed) |
-
-## Grouping Rules
-
-Identify logical features by grouping related files:
-- Same feature = same commit
-- Infrastructure/config = separate commit
-- Tests = with their implementation OR separate if test-only
-
-## Commit Message Format
-
-```
-<type>(<scope>): <description>
-```
-
-Types: `feat`, `fix`, `docs`, `chore`, `refactor`, `test`, `style`, `build`, `ci`, `perf`
-
-**Note:** Commit messages are validated by commitlint (conventional commits format).

package/.claude/skills/code-review-repo/skill.md

@@ -1,62 +0,0 @@
----
-name: code-review-repo
-description: Review local codebase for bugs and CLAUDE.md compliance using multi-agent analysis
-version: 1.0.0
----
-
-# Local Code Review
-
-Review the entire local codebase for bugs, issues, and CLAUDE.md compliance.
-
-## Process
-
-1. **Gather CLAUDE.md files**: Use a Haiku agent to find all CLAUDE.md files in the repository (root and subdirectories)
-
-2. **Identify source files**: Determine which files to review:
-   - Include: `.ts`, `.tsx`, `.js`, `.jsx`, `.py`, `.rs`, `.go` and similar source files
-   - Exclude: `node_modules/`, `dist/`, `.git/`, vendor directories, generated files
-
-3. **Multi-agent review**: Launch 5 parallel Sonnet agents to independently review the codebase. Each agent returns a list of issues with reasons:
-   - **Agent #1**: Audit for CLAUDE.md compliance. Check that code follows guidelines in all relevant CLAUDE.md files.
-   - **Agent #2**: Shallow bug scan. Look for obvious bugs, error handling issues, and logic errors. Focus on significant bugs, not nitpicks.
-   - **Agent #3**: Git history context. Use git blame and history to identify patterns, recent changes, and potential issues in light of historical context.
-   - **Agent #4**: Previous PR comments. Check closed PRs that touched these files for any feedback that might apply.
-   - **Agent #5**: Code comment compliance. Ensure code follows any guidance in TODO, FIXME, NOTE, or other code comments.
-
-4. **Confidence scoring**: For each issue found, launch a parallel Haiku agent to score confidence (0-100):
-   - **0**: False positive, doesn't hold up to scrutiny
-   - **25**: Might be real, but unverified. Stylistic issues not in CLAUDE.md
-   - **50**: Real but minor, rarely hit in practice
-   - **75**: Verified real issue, important, directly impacts functionality or mentioned in CLAUDE.md
-   - **100**: Definitely real, frequently hit, evidence confirms
-
-5. **Filter**: Only report issues with score >= 80
-
-## False Positive Examples
-
-Avoid flagging:
-- Issues that linters/typecheckers catch (imports, types, formatting)
-- General quality issues unless in CLAUDE.md
-- Code with lint-ignore comments for that specific issue
-- Pre-existing issues unrelated to recent changes
-- Pedantic nitpicks a senior engineer wouldn't mention
-
-## Output Format
-
-### Code review
-
-Found N issues:
-
-1. Brief description (CLAUDE.md says "...")
-   `file/path.ts:42`
-
-2. Brief description (bug due to missing error handling)
-   `file/path.ts:88-95`
-
----
-
-Or if no issues:
-
-### Code review
-
-No issues found. Checked for bugs and CLAUDE.md compliance.

package/.editorconfig

@@ -1,15 +0,0 @@
-root = true
-
-[*]
-charset = utf-8
-end_of_line = lf
-insert_final_newline = true
-trim_trailing_whitespace = true
-indent_style = space
-indent_size = 2
-
-[*.md]
-trim_trailing_whitespace = false
-
-[*.ts]
-indent_size = 2

package/.env.example

@@ -1,21 +0,0 @@
-# Required Configuration
-# Copy this file to .env and set all values
-
-# Logging Configuration
-# Valid values: trace, debug, info, warn, error, fatal
-LOG_LEVEL=info
-
-# Search Quality Configuration
-# Test file boost multiplier (lower values penalize test files more)
-SEARCH_TEST_FILE_BOOST=0.5
-
-# Confidence thresholds for raw vector similarity scoring
-# Results with maxRawScore >= high threshold are "high" confidence
-# Results with maxRawScore >= medium threshold are "medium" confidence
-# Results below medium threshold are "low" confidence
-SEARCH_CONFIDENCE_HIGH=0.5
-SEARCH_CONFIDENCE_MEDIUM=0.3
-
-# MCP Server Configuration
-# Project root directory for MCP server
-PROJECT_ROOT=/path/to/project

package/.github/workflows/auto-release.yml

@@ -1,64 +0,0 @@
-name: Auto Release
-
-on:
-  push:
-    branches: [main]
-  workflow_dispatch:
-
-# Prevent parallel tag creation - queue instead of cancel
-concurrency:
-  group: auto-release
-  cancel-in-progress: false
-
-jobs:
-  auto-release:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write  # Required to push tags
-    # Only run after CI completes successfully
-    needs: []
-
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-          token: ${{ secrets.MARKETPLACE_PAT }}  # Use PAT to trigger Release workflow
-
-      - name: Get version from package.json
-        id: package_version
-        run: |
-          VERSION=$(node -p "require('./package.json').version")
-          echo "version=$VERSION" >> $GITHUB_OUTPUT
-          echo "tag=v$VERSION" >> $GITHUB_OUTPUT
-
-      - name: Check if tag exists
-        id: check_tag
-        run: |
-          if git rev-parse "v${{ steps.package_version.outputs.version }}" >/dev/null 2>&1; then
-            echo "exists=true" >> $GITHUB_OUTPUT
-          else
-            echo "exists=false" >> $GITHUB_OUTPUT
-          fi
-
-      # CRITICAL: This is the quality gate for releases.
-      # CI workflow does NOT run on tags (to avoid redundant ~3 min test runs).
-      # This step ensures all CI checks pass on main BEFORE creating a tag.
-      # The Release workflow trusts this guarantee and publishes immediately.
-      # See ci.yml header comment for the full quality guarantee chain.
-      - name: Wait for CI to complete
-        if: steps.check_tag.outputs.exists == 'false'
-        uses: lewagon/wait-on-check-action@v1.3.4
-        with:
-          ref: ${{ github.sha }}
-          check-regexp: '^(lint-and-typecheck|test|build)$'
-          repo-token: ${{ secrets.GITHUB_TOKEN }}
-          wait-interval: 10
-          allowed-conclusions: success
-
-      - name: Create and push tag
-        if: steps.check_tag.outputs.exists == 'false'
-        run: |
-          git config user.name "github-actions[bot]"
-          git config user.email "github-actions[bot]@users.noreply.github.com"
-          git tag ${{ steps.package_version.outputs.tag }}
-          git push origin ${{ steps.package_version.outputs.tag }}

package/.github/workflows/ci.yml

@@ -1,168 +0,0 @@
-name: CI
-
-# CI runs on branch pushes and PRs, but NOT on tags.
-#
-# Why no tag trigger?
-# - Auto Release workflow (auto-release.yml) waits for CI to pass on main
-#   before creating a tag (uses wait-on-check-action with lint-and-typecheck,
-#   test, build checks)
-# - The tag contains the exact same code that just passed CI on main
-# - Running CI again on the tag is redundant and wastes ~3 minutes per release
-# - Release workflow (release.yml) trusts this guarantee and publishes immediately
-#
-# Quality guarantee chain:
-#   push to main → CI passes → Auto Release creates tag → Release publishes
-#
-on:
-  push:
-    branches: ['**']
-    # Note: tags intentionally excluded - see comment above
-  pull_request:
-    branches: [main]
-
-# Prevent duplicate runs: cancel in-progress runs for same branch
-# When a PR is open, only run the pull_request event (skip the push)
-concurrency:
-  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
-  cancel-in-progress: true
-
-jobs:
-  # Fast checks that don't need Python/models (runs in ~30s)
-  lint-and-typecheck:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Setup Bun
-        uses: oven-sh/setup-bun@v2
-        with:
-          bun-version: latest
-
-      - name: Cache Bun dependencies
-        uses: actions/cache@v4
-        with:
-          path: ~/.bun/install/cache
-          key: bun-${{ runner.os }}-${{ hashFiles('**/bun.lock') }}
-          restore-keys: |
-            bun-${{ runner.os }}-
-
-      - name: Install dependencies
-        run: bun install
-
-      - name: Lint
-        run: bun run lint
-
-      - name: Type check
-        run: bun run typecheck
-
-  # Tests with Python dependencies (slower, runs in parallel)
-  test:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Setup Python
-        uses: actions/setup-python@v5
-        with:
-          python-version: '3.11'
-
-      - name: Cache pip dependencies
-        uses: actions/cache@v4
-        with:
-          path: ~/.cache/pip
-          key: pip-${{ runner.os }}-crawl4ai
-          restore-keys: |
-            pip-${{ runner.os }}-
-
-      - name: Cache Playwright browsers
-        uses: actions/cache@v4
-        with:
-          path: ~/.cache/ms-playwright
-          key: playwright-${{ runner.os }}-chromium
-          restore-keys: |
-            playwright-${{ runner.os }}-
-
-      - name: Install crawl4ai
-        run: |
-          pip install crawl4ai
-          # Only run setup if Playwright not cached (checks for chromium)
-          if [ ! -d ~/.cache/ms-playwright/chromium-* ]; then
-            crawl4ai-setup
-          else
-            echo "Playwright browsers already cached, skipping setup"
-          fi
-
-      - name: Setup Bun
-        uses: oven-sh/setup-bun@v2
-        with:
-          bun-version: latest
-
-      - name: Cache Bun dependencies
-        uses: actions/cache@v4
-        with:
-          path: ~/.bun/install/cache
-          key: bun-${{ runner.os }}-${{ hashFiles('**/bun.lock') }}
-          restore-keys: |
-            bun-${{ runner.os }}-
-
-      - name: Cache Hugging Face models
-        uses: actions/cache@v4
-        with:
-          path: ~/.cache/huggingface-transformers
-          key: huggingface-transformers-${{ runner.os }}-all-MiniLM-L6-v2
-          restore-keys: |
-            huggingface-transformers-${{ runner.os }}-
-
-      - name: Install dependencies
-        run: bun install
-
-      - name: Warm up embedding model
-        run: |
-          # Download embedding model before tests to prevent race conditions
-          # Multiple test files use embeddings - this ensures model is fully cached
-          node -e "
-            import('@huggingface/transformers').then(async ({ pipeline, env }) => {
-              const { homedir } = await import('node:os');
-              const { join } = await import('node:path');
-              env.cacheDir = join(homedir(), '.cache', 'huggingface-transformers');
-              console.log('Downloading embedding model to:', env.cacheDir);
-              await pipeline('feature-extraction', 'Xenova/all-MiniLM-L6-v2', { dtype: 'fp32' });
-              console.log('Model downloaded successfully');
-            });
-          "
-
-      - name: Run tests with coverage
-        run: bun run test:coverage
-
-  # Build (lightweight, runs in parallel)
-  build:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Setup Bun
-        uses: oven-sh/setup-bun@v2
-        with:
-          bun-version: latest
-
-      - name: Cache Bun dependencies
-        uses: actions/cache@v4
-        with:
-          path: ~/.bun/install/cache
-          key: bun-${{ runner.os }}-${{ hashFiles('**/bun.lock') }}
-          restore-keys: |
-            bun-${{ runner.os }}-
-
-      - name: Install dependencies
-        run: bun install
-
-      - name: Build
-        run: bun run build
-
-  # Success job - only runs if all parallel jobs pass
-  ci-success:
-    runs-on: ubuntu-latest
-    needs: [lint-and-typecheck, test, build]
-    steps:
-      - name: CI passed
-        run: echo "All CI checks passed!"