title: Auth tokens expire too quickly

description:
## Summary

[Brief description of the bug]

## Steps to Reproduce

1. Step 1
2. Step 2
3. Step 3

## Expected Behavior

[What should happen]

## Actual Behavior

[What actually happens]

## Environment

- OS: [e.g., macOS 15.7.1]
- Version: [e.g., bd 0.20.1]
- Additional context: [any relevant details]

## Additional Context

[Screenshots, logs, or other relevant information]

design:
## Root Cause Analysis

[Describe the underlying cause once identified]

## Proposed Fix

[Outline the solution approach]

## Impact Assessment

- Affected features: [list]
- Breaking changes: [yes/no and details]
- Migration needed: [yes/no and details]

acceptance_criteria:
- [ ] Bug no longer reproduces with original steps
- [ ] Regression tests added
- [ ] Related edge cases tested
- [ ] Documentation updated if behavior changed

status: open

issue_type: bug


title: Add template support for issue creation

description:
Support creating issues from predefined templates to streamline common workflows like epics, bug reports, or feature proposals.

Example usage:
  bd create --from-template epic "Phase 3 Features"
  bd create --from-template bug "Login failure"
  bd template list
  bd template create epic

Templates should include:
- Pre-filled description structure
- Suggested priority and type
- Common labels
- Design/acceptance criteria sections

Implementation notes:
- Store templates in .beads/templates/ directory
- Support YAML or JSON format
- Ship with built-in templates (epic, bug, feature)
- Allow custom project-specific templates

status: closed

issue_type: feature


title: Override test

description:
## Overview

[Describe the high-level goal and scope of this epic]

## Success Criteria

- [ ] Criteria 1
- [ ] Criteria 2
- [ ] Criteria 3

## Background

[Provide context and motivation]

## Scope

**In Scope:**
- Item 1
- Item 2

**Out of Scope:**
- Item 1
- Item 2

design:
## Architecture

[Describe the overall architecture and approach]

## Components

- Component 1: [description]
- Component 2: [description]

## Dependencies

[List external dependencies or constraints]

acceptance_criteria:
- [ ] All child issues are completed
- [ ] Integration tests pass
- [ ] Documentation is updated
- [ ] Code review completed


title: Add WebSocket support

description:
## Feature Request

[Describe the desired feature]

## Motivation

[Why is this feature needed? What problem does it solve?]

## Use Cases

1. **Use Case 1**: [description]
2. **Use Case 2**: [description]

## Proposed Solution

[High-level approach to implementing this feature]

## Alternatives Considered

- **Alternative 1**: [description and why not chosen]
- **Alternative 2**: [description and why not chosen]

design:
## Technical Design

[Detailed technical approach]

## API Changes

[New commands, flags, or APIs]

## Data Model Changes

[Database schema changes if any]

## Implementation Notes

- Note 1
- Note 2

## Testing Strategy

- Unit tests: [scope]
- Integration tests: [scope]
- Manual testing: [steps]

acceptance_criteria:
- [ ] Feature implements all described use cases
- [ ] All tests pass
- [ ] Documentation updated (README, commands)
- [ ] Examples added if applicable
- [ ] No performance regressions


title: Add label-based filtering to bd ready command

description:
Allow filtering ready work by labels to help organize work by sprint, week, or category.

Example usage:
  bd ready --label week1-2
  bd ready --label frontend,high-priority

This helps teams organize work into batches and makes it easier for agents to focus on specific categories of work.

Implementation notes:
- Add --label flag to ready command
- Support comma-separated labels (AND logic)
- Should work with existing ready work logic (unblocked issues)


title: Clarify JSONL size bounds with multi-repo

description:
The contributor-workflow-analysis.md states (line 226): 'Keep beads.jsonl small enough for agents to read (<25k)'

With multi-repo hydration, it's unclear whether this bound applies to:
- Each individual JSONL file (likely intention)
- The total hydrated size across all repos (unclear)
- Both (most conservative)

Clarification needed because:
- VC monitors .beads/issues.jsonl size to stay under limit
- With multi-repo, VC needs to know if each additional repo also has 25k limit
- Agents reading hydrated data need to know total size bounds
- Performance characteristics depend on total vs per-repo limits

Example scenario:
- Primary repo: 20k JSONL
- Planning repo: 15k JSONL
- Total hydrated: 35k
Is this acceptable or does it violate the <25k principle?

acceptance_criteria:
- Documentation explicitly states size bound applies per-repo or total
- Rationale explained (why that bound matters)
- Guidance for monitoring size with multi-repo
- If total bound exists, formula provided (e.g., sum of all repos <25k)

issue_type: task


title: Test Epic

issue_type: epic


title: Q4 Platform Improvements


title: Frontend task


title: Test Epic 2


title: Add migration guide for library consumers

description:
The contributor-workflow-analysis.md has excellent migration examples for CLI users (lines 508-549) but lacks examples for library consumers like VC that use beadsLib in Go/TypeScript code.

Library consumers need to know:
- Whether their existing code continues to work unchanged (backward compatibility)
- How config.toml is automatically read (transparent hydration)
- When and how to use explicit multi-repo configuration
- What happens if config.toml doesn't exist (defaults)

Example needed:
```go
// Before (v0.17.3)
store, err := beadsLib.NewSQLiteStorage(".beads/vc.db")

// After (v0.18.0 with multi-repo) - still works!
store, err := beadsLib.NewSQLiteStorage(".beads/vc.db")
// Automatically reads .beads/config.toml if present

// Explicit multi-repo (if needed)
cfg := beadsLib.Config{
    Primary: ".beads/vc.db",
    Additional: []string{"~/.beads-planning"},
}
store, err := beadsLib.NewStorageWithConfig(cfg)
```

acceptance_criteria:
- Section added to contributor-workflow-analysis.md for library consumers
- Code examples showing backward compatibility
- Code examples showing explicit multi-repo configuration
- Guidance on when library consumers should use multi-repo vs single-repo


title: Backend task


title: Week 1 task


title: Add mermaid output format for bd dep tree

description:
Add visual dependency graph output using Mermaid format for better visualization of issue relationships.

Example usage:
  bd dep tree --format mermaid <issue-id>
  bd dep tree --format mermaid bd-42 > graph.md

This would output Mermaid syntax that can be rendered in GitHub, documentation sites, or Mermaid live editor.

Implementation notes:
- Add --format flag to dep tree command
- Support 'text' (default) and 'mermaid' formats
- Mermaid graph should show issue IDs, titles, and dependency types
- Consider using flowchart LR or graph TD syntax


title: Manual task


title: Clarify exclusive lock protocol compatibility with multi-repo

description:
The contributor-workflow-analysis.md proposes per-repo file locking (Decision #7) using flock on JSONL files. However, VC (a downstream library consumer) uses an exclusive lock protocol (vc-195, requires Beads v0.17.3+) that allows bd daemon and VC executor to coexist.

Need to clarify:
- Does the proposed per-repo file locking work with VC's existing exclusive lock protocol?
- Do library consumers like VC need to adapt their locking logic?
- Can multiple repos be locked atomically for cross-repo operations?

Context: contributor-workflow-analysis.md lines 662-681

acceptance_criteria:
- Documentation explicitly states compatibility or incompatibility with existing lock protocols
- If incompatible, migration path is documented for library consumers
- If compatible, example showing coexistence is provided


title: Add performance benchmarks for multi-repo hydration

description:
The contributor-workflow-analysis.md asserts sub-second queries (line 702) and describes smart caching via file mtime tracking (Decision #4, lines 584-618), but doesn't provide concrete performance benchmarks.

VC's requirement (from VC feedback section):
- Executor polls GetReadyWork() every 5-10 seconds
- Queries must be sub-second (ideally <100ms)
- Smart caching must avoid re-parsing JSONLs on every query

Suggested performance targets to validate:
- File stat overhead: <1ms per repo
- Hydration (when needed): <500ms for typical JSONL (<25k)
- Query (from cache): <10ms
- Total GetReadyWork(): <100ms (VC's requirement)

Also test at scale:
- N=1 repo (baseline)
- N=3 repos (typical)
- N=10 repos (edge case)

These benchmarks are critical for library consumers like VC that run automated polling loops.

acceptance_criteria:
- Performance benchmark suite created for multi-repo hydration
- Benchmarks cover file stat, hydration, and query times
- Tests at N=1, N=3, N=10 repo scales
- Results documented in contributor-workflow-analysis.md
- Performance targets met or issues filed for optimization


title: Add guidance for self-hosting projects

description:
The contributor-workflow-analysis.md is optimized for OSS contributors making PRs to upstream projects. However, it doesn't address projects like VC that use beads for their own development (self-hosting).

Self-hosting projects differ from OSS contributors:
- No upstream/downstream distinction (they ARE the project)
- May run automated executors (not just humans)
- In bootstrap/early phase (stability matters)
- Single team/owner (not multiple contributors with permissions)

Guidance needed on:
- When self-hosting projects should stay single-repo (default, recommended)
- When they should adopt multi-repo (team planning, multi-phase dev)
- How automated executors should handle multi-repo (if at all)
- Special considerations for projects in bootstrap phase

Examples of self-hosting projects: VC (building itself with beads), internal tools, pet projects

acceptance_criteria:
- Section added: 'For Projects Using Beads for Self-Hosting'
- Clear guidance on when to stay single-repo vs adopt multi-repo
- Recommendations for automated executor behavior with multi-repo
- Bootstrap phase considerations documented