Merge branch 'beads-sync' of https://github.com/Jan-Reimes_HEAD/tdoc-crawler into beads-sync

# 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 - 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 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: "tdc"

# 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

 No newline at end of file

---

name: code-auditor

description: Performs comprehensive codebase analysis covering architecture, code quality, security, performance, testing, and maintainability. Use when user wants to audit code quality, identify technical debt, find security issues, assess test coverage, or get a codebase health check.

---

# Code Auditor

Comprehensive codebase analysis covering architecture, code quality, security, performance, testing, and maintainability.

## When to Use

- "audit the code"

- "analyze code quality"

- "check for issues"

- "review the codebase"

- "find technical debt"

- "security audit"

- "performance review"

## What It Analyzes

### 1. Architecture & Design

- Overall structure and organization

- Design patterns in use

- Module boundaries and separation of concerns

- Dependency management

- Architectural decisions and trade-offs

### 2. Code Quality

- Complexity hotspots (cyclomatic complexity)

- Code duplication (DRY violations)

- Naming conventions and consistency

- Documentation coverage

- Code smells and anti-patterns

### 3. Security

- Common vulnerabilities (OWASP Top 10)

- Input validation and sanitization

- Authentication and authorization

- Secrets management

- Dependency vulnerabilities

### 4. Performance

- Algorithmic complexity issues

- Database query optimization

- Memory usage patterns

- Caching opportunities

- Resource leaks

### 5. Testing

- Test coverage assessment

- Test quality and effectiveness

- Missing test scenarios

- Testing patterns and practices

- Integration vs unit test balance

### 6. Maintainability

- Technical debt assessment

- Coupling and cohesion

- Ease of future changes

- Onboarding friendliness

- Documentation quality

## Approach

1. **Explore** using Explore agent (thorough mode)

2. **Identify patterns** with Grep and Glob

3. **Read critical files** for detailed analysis

4. **Run static analysis tools** if available

5. **Synthesize findings** into actionable report

## Thoroughness Levels

- **Quick** (15-30 min): High-level, critical issues only

- **Standard** (30-60 min): Comprehensive across all dimensions

- **Deep** (60+ min): Exhaustive with detailed examples

## Output Format

```markdown

# Code Audit Report

## Executive Summary

- Overall health score

- Critical issues count

- Top 3 priorities

## Findings by Category

### Architecture & Design

#### 🔴 High Priority

- [Finding with file:line reference]

  - Impact: [description]

  - Recommendation: [action]

#### 🟡 Medium Priority

...

### [Other categories]

## Prioritized Action Plan

1. Quick wins (< 1 day)

2. Medium-term improvements (1-5 days)

3. Long-term initiatives (> 5 days)

## Metrics

- Files analyzed: X

- Lines of code: Y

- Test coverage: Z%

- Complexity hotspots: N

```

## Tools Used

- **Task (Explore agent)**: Thorough codebase exploration

- **Grep**: Pattern matching for issues

- **Glob**: Find files by type/pattern

- **Read**: Detailed file analysis

- **Bash**: Run linters, coverage tools

## Success Criteria

- Comprehensive coverage of all six dimensions

- Specific file:line references for all findings

- Severity/priority ratings (Critical/High/Medium/Low)

- Actionable recommendations (not just observations)

- Estimated effort for fixes

- Both quick wins and long-term improvements

## Integration

- **feature-planning**: Plan technical debt reduction

- **test-fixing**: Address test gaps identified

- **project-bootstrapper**: Set up quality tooling

## Configuration

Can focus on specific areas:

- Security-only audit

- Performance-only audit

- Testing-only assessment

- Quick architecture review