feat: add configurable auth schemes and request history features

- Add configurable auth schemes (Bearer, Raw, Basic) for flexible header injection
- Implement pattern specificity-based rule precedence (more specific patterns win)
- Add multiple rules warning when 2+ rules are active on a page
- Add expandable request history with domain-level breakdown in ContextBar
- Add per-rule request count badges in RuleCard
- Extract stateless components (PageInfo, ActivityStatus, MultipleRulesWarning)
- Extract shared utility functions for domain pattern matching
- Remove unused SettingsDialog component
- Add comprehensive tests for new utilities and components
- Add CLAUDE.md with development guidelines

Author: prosdev

.github/workflows/release.yml

@@ -42,20 +42,13 @@ jobs:
       - name: Build
         run: pnpm build
 
-      - name: Get version from package.json
-        id: package_version
-        run: echo "version=$(node -p "require('./package.json').version")" >> $GITHUB_OUTPUT
-      
       - name: Create extension zip
-        run: |
-          cd dist
-          zip -r ../auth-header-injector-${{ steps.package_version.outputs.version }}.zip .
-          cd ..
+        run: pnpm package
 
       - name: Create GitHub Release
         uses: softprops/action-gh-release@v2
         with:
-          files: auth-header-injector-${{ steps.package_version.outputs.version }}.zip
+          files: auth-hi-*.zip
           generate_release_notes: true
           draft: false
           prerelease: false

CLAUDE.md

@@ -0,0 +1,70 @@
+# Claude AI Assistant Rules
+
+Guidelines for AI-assisted development in this codebase.
+
+## Code Style & Formatting
+
+- **Biome** for linting and formatting
+  - Single quotes
+  - 2 space indentation
+  - 100 character line width
+  - Auto-format on save
+- **TypeScript** strict mode
+- **Pure functions** preferred for testability (extract to `utils/`)
+
+## UI Component Guidelines
+
+- **Use shadcn UI components** (Alert, Button, Dialog, Select, Switch, etc.)
+- **Use Lucide icons** for all iconography
+- **Extract stateless components** for reusability
+- Consistent Tailwind CSS styling
+
+## Architecture Patterns
+
+- **SDK Kit plugin architecture** for background service worker
+- **Pure functions** in `utils/` for testability
+- **React hooks** for state management (no external state library)
+- **Separation of concerns:**
+  - `background/` - Service worker with SDK Kit plugins
+  - `panel/` - Side panel UI
+  - `popup/` - Popup UI
+  - `options/` - Options page UI
+  - `shared/` - Shared types and utilities
+
+## Chrome Extension Specifics
+
+- **Manifest V3** patterns
+- **`declarativeNetRequest`** API for header injection
+- **Priority-based rule ordering** using pattern specificity
+- **Storage:**
+  - `chrome.storage.sync` for rules (synced across devices)
+  - `chrome.storage.local` for stats (device-specific)
+- **⚠️ CRITICAL: New changes must NOT affect permissions**
+  - Adding new permissions requires Chrome Web Store review
+  - Check `manifest.json` before making changes that might require new permissions
+  - If permissions are needed, discuss first before implementing
+
+## Testing Guidelines
+
+- **Vitest** for unit tests
+- **Test pure functions** - extract to `utils/` for testability
+- **Mock Chrome APIs** in `tests/setup.ts`
+- **Colocate tests** with source files (`.test.ts`)
+
+## Git & Versioning
+
+- **Conventional commits** (feat, fix, docs, refactor, test, chore)
+- **Manual versioning** (no changesets yet - will add when auto-deploying to Chrome Web Store)
+- **Ask before performing git actions** (user preference)
+
+## Code Review Checklist
+
+Before submitting code, ensure:
+- ✅ Pure functions extracted for testability
+- ✅ Uses shadcn UI components
+- ✅ Uses Lucide icons (not emojis)
+- ✅ Tests added for new functionality
+- ✅ No new permissions required (check `manifest.json`)
+- ✅ TypeScript types are correct
+- ✅ Follows existing patterns and conventions
+

docs/content/getting-started.mdx

@@ -47,17 +47,24 @@ Toggle the "Enable extension" switch at the top of the panel.
 Click "Add Rule" and fill in:
 
 - **Pattern**: URL pattern to match (e.g., `*.api.example.com`)
-- **Token**: Your Bearer token (just the token, not "Bearer ...")
+- **Token**: Your authentication token
+- **Scheme**: Choose Bearer (default), Raw, or Basic
 - **Label**: Optional friendly name (e.g., "Staging API")
 
 Click "Save" and you're done!
 
+**Auth Schemes:**
+- **Bearer**: Adds `Authorization: Bearer {token}` header (most common)
+- **Raw**: Adds `Authorization: {token}` header (for APIs expecting raw tokens)
+- **Basic**: Adds `Authorization: Basic {token}` header (token should be base64-encoded)
+
 ### 4. Verify It's Working
 
 1. Navigate to a page that makes API calls matching your pattern
-2. Check the "Context Bar" at the top - it shows matched rules
+2. Check the "Context Bar" at the top - it shows matched rules and request counts
 3. See request counts increase as API calls are intercepted
-4. Open DevTools → Network tab → Check request headers
+4. Click the request count to expand and see domain-level breakdown
+5. Open DevTools → Network tab → Check request headers
 
 ## Example: GitHub API
 

docs/content/guide/_meta.js

@@ -1,5 +1,6 @@
 export default {
   patterns: 'URL Patterns',
   examples: 'Examples',
+  'auth-schemes': 'Auth Schemes',
   troubleshooting: 'Troubleshooting',
 };

docs/content/guide/auth-schemes.mdx

@@ -0,0 +1,89 @@
+# Auth Schemes
+
+Auth HI! supports multiple authentication header formats to work with different APIs.
+
+## Available Schemes
+
+### Bearer (Default)
+
+The most common authentication format. Adds `Authorization: Bearer {token}` header.
+
+**Use when:**
+- Working with REST APIs (GitHub, GitLab, most modern APIs)
+- Token is a JWT or API key
+- API expects standard Bearer token format
+
+**Example:**
+```
+Pattern: *.api.example.com
+Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
+Scheme: Bearer
+```
+
+**Result:** `Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...`
+
+### Raw
+
+Adds the token directly without any prefix. Adds `Authorization: {token}` header.
+
+**Use when:**
+- API expects raw token without "Bearer" prefix
+- Working with APIs that use custom token formats
+- Token format is non-standard
+
+**Example:**
+```
+Pattern: *.lytics.io
+Token: abc123xyz789
+Scheme: Raw
+```
+
+**Result:** `Authorization: abc123xyz789`
+
+### Basic
+
+Adds Basic authentication header. Adds `Authorization: Basic {token}` header.
+
+**Use when:**
+- Working with HTTP Basic Auth
+- Token is already base64-encoded (format: `base64(username:password)`)
+- API uses Basic authentication
+
+**Example:**
+```
+Pattern: api.example.com
+Token: dXNlcm5hbWU6cGFzc3dvcmQ=  (base64-encoded credentials)
+Scheme: Basic
+```
+
+**Result:** `Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=`
+
+**Note:** The token should already be base64-encoded. If you have `username:password`, encode it first:
+```javascript
+btoa('username:password') // Returns base64 string
+```
+
+## Choosing the Right Scheme
+
+| API Type | Recommended Scheme | Example |
+|----------|-------------------|---------|
+| GitHub/GitLab | Bearer | `ghp_...` or `glpat-...` |
+| JWT APIs | Bearer | `eyJhbGci...` |
+| Custom APIs | Raw | Check API docs |
+| HTTP Basic Auth | Basic | Base64-encoded credentials |
+| Lytics API | Raw | Raw token format |
+
+## Migration
+
+Existing rules created before scheme support default to **Bearer** for backward compatibility. You can edit any rule to change its scheme.
+
+## Troubleshooting
+
+**Problem:** API returns 401 even with correct token
+
+**Solutions:**
+1. Check if the API expects a different scheme (try Raw instead of Bearer)
+2. Verify token format matches API requirements
+3. For Basic auth, ensure token is base64-encoded
+4. Check API documentation for exact header format expected
+

docs/content/guide/examples.mdx

@@ -72,21 +72,28 @@ Perfect for local development against your own API.
 
 ## Multiple Rules for Same Domain
 
-You can have multiple rules that match the same domain. They'll all be applied:
+You can have multiple rules that match the same domain. When multiple rules match, **the most specific pattern wins**:
 
 ```
-# Rule 1: General API access
-Pattern: *api.example.com
+# Rule 1: General API access (less specific)
+Pattern: *.api.example.com
 Token: general_token
+Scheme: Bearer
 Label: Example API
 
-# Rule 2: Specific service
+# Rule 2: Specific service (more specific - wins!)
 Pattern: auth.api.example.com  
 Token: auth_service_token
+Scheme: Bearer
 Label: Auth Service
 ```
 
-Both rules will inject their tokens when matching requests occur.
+When a request matches both patterns, Rule 2 wins because `auth.api.example.com` is more specific than `*.api.example.com`. The extension will show a warning when 2+ rules are active on the same page.
+
+**Pattern Specificity:**
+- More specific parts = higher priority
+- Fewer wildcards = higher priority
+- Example: `api.staging.example.com` > `*.example.com` > `*.com`
 
 ## Pro Tips
 

docs/content/guide/patterns.mdx

@@ -102,6 +102,24 @@ OR
 Pattern: *://api.example.com/*
 ```
 
+## Rule Precedence
+
+When multiple rules match the same URL, the **most specific pattern wins**. Specificity is calculated based on:
+
+- **Number of specific parts** (more = more specific)
+- **Number of wildcards** (fewer = more specific)
+
+**Example:**
+```
+Pattern: api.staging.example.com  (specificity: 30)
+Pattern: *.example.com            (specificity: 19)
+Pattern: *.com                    (specificity: -1)
+```
+
+If all three match a request to `api.staging.example.com`, the first rule wins.
+
+The extension shows a warning in the Context Bar when 2+ rules are active on the same page, so you know which rule is being used.
+
 ## Testing Your Patterns
 
 1. Add your rule in the extension

docs/content/index.mdx

@@ -19,10 +19,10 @@ Say hi to hassle-free auth headers. A Chrome extension that automatically inject
 | Feature | Description |
 |---------|-------------|
 | 🎯 **Pattern Matching** | Target specific domains or subdomains with flexible URL patterns |
-| 🔐 **Bearer Token Injection** | Automatically inject Authorization headers into matching requests |
-| 📊 **Real-time Tracking** | See which requests are being intercepted as you browse |
+| 🔐 **Flexible Auth Schemes** | Support Bearer, Raw, and Basic authentication header formats |
+| 📊 **Request History** | Track intercepted requests with expandable domain-level breakdown |
 | 🎨 **Side Panel UI** | Context-aware interface that stays open while browsing |
-| ⚡ **Event-driven Architecture** | Minimal performance impact with smart caching |
+| ⚡ **Smart Rule Precedence** | More specific patterns automatically win when multiple rules match |
 | 🌓 **Dark Mode** | Chrome DevTools-inspired aesthetic |
 
 ## Quick Start

package.json

@@ -1,6 +1,6 @@
 {
   "name": "auth-header-injector",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Auth HI! - Chrome extension for injecting auth headers. Built with SDK Kit.",
   "type": "module",
   "scripts": {
@@ -14,6 +14,7 @@
     "test": "vitest run",
     "test:watch": "vitest",
     "test:ui": "vitest --ui",
+    "package": "node scripts/create-zip.js",
     "prepare": "husky"
   },
   "keywords": ["chrome-extension", "auth", "headers", "sdk-kit", "developer-tools"],
@@ -28,6 +29,7 @@
     "@lytics/sdk-kit": "^0.1.1",
     "@radix-ui/react-dialog": "^1.1.15",
     "@radix-ui/react-label": "^2.1.8",
+    "@radix-ui/react-select": "^2.2.6",
     "@radix-ui/react-slot": "^1.2.4",
     "@radix-ui/react-switch": "^1.2.6",
     "class-variance-authority": "^0.7.1",