Atomic Bead Filing

Overview

File beads that future agents can execute with zero shared context. You receive an observation, ground it in the codebase, and create a bead that stands alone.

When to Use

• Main agent noticed something off while working
• Need to capture it without derailing current task
• Want a proper bead, not a vague note

Core Principle

A bead is good if a stranger-agent can execute it knowing ONLY:

1. The bead's description
2. The codebase (via search/read)

They should NOT need: conversation history, the observer's context, or clarification.

Workflow

1. Receive observation from main agent (you have conversation context)
2. Explore codebase to ground it - find specific files, line numbers, patterns
3. Ask questions via AskUserQuestion if genuinely unclear
4. Determine actionability:
   • Clear path → actionable bead
   • Multiple valid approaches → add

     human-needed

     label, describe options
5. File bead with

   bd create

6. Sync with

   bd sync

   (just git commit isn't enough - beads live on beads-sync branch)
7. Return bead ID + full bead details so main agent sees what was filed

Bead Structure

Title: Concise, grounded summary (not vague)

• Bad: "Fix type issues"
• Good: "RuleViolation missing priority field - Rust hardcodes HIGH"

Description: The concrete issue

## What's Wrong
[Specific problem - what IS off, grounded in files]

## Where
[Exact file paths, line numbers]

## Why It Matters
[What could go wrong, why this is tech debt]

## Files to Study
- path/to/file.rs (the problematic code)
- path/to/related.py (the other side of the mismatch)

Fields to set (run

bd create --help

--type task

bug

feature

--priority

--labels human-needed

--deps discovered-from:<id>

--acceptance

--design

Fold context into description footer:

---
*Discovered while: [what triggered this observation]*

human-needed Label

Use when there are forks requiring human decision:

• Multiple valid architectural approaches
• Trade-offs that depend on priorities you don't know
• Breaking changes vs. compatibility concerns

When using human-needed, add to description:

## Decision Needed
[Specific question]

## Options
1. **Option A**: [approach] - [pros/cons]
2. **Option B**: [approach] - [pros/cons]

What NOT to Do

• Don't file vague beads ("look into this")
• Don't propose fixes unless obvious (focus on WHAT is off)
• Don't skip grounding (always find specific files)
• Don't ask unnecessary questions (use conversation context + codebase)

Example

Input from main agent: "The severity is hardcoded in transform.rs. Noticed while adding analyzer endpoint."

Your process:

1. Search for severity in transform.rs
2. Find line 250:

   parse_severity("HIGH")

3. Trace back - where should severity come from?
4. Find RuleViolation struct doesn't have severity field
5. Find Python RuleViolationDto DOES have priority field
6. Ground the full issue

Output bead:

bd create "RuleViolation drops priority - Rust hardcodes HIGH severity" \
  --type task \
  --priority 1 \
  --acceptance "Rust RuleViolation receives and uses Python's computed priority" \
  --description "## What's Wrong
Rust transform hardcodes severity to HIGH, ignoring Python's computed priority.

Line 250 in transform.rs:
\`\`\`rust
let priority = parse_severity(\"HIGH\").unwrap_or(RuleSeverity::Medium);
\`\`\`

## Where
- oxide/server/src/eval/transform.rs:250 (hardcoded value)
- oxide/server/src/eval_client.rs:165-173 (RuleViolation missing priority field)
- src/app/features/evaluation/contracts/rules_contracts.py:62-75 (RuleViolationDto HAS priority)

## Why It Matters
Python evaluator computes actual priority per-violation, but Rust discards it. All violations appear HIGH priority regardless of actual severity. Silent data loss.

## Files to Study
- oxide/server/src/eval/transform.rs (the transform)
- oxide/server/src/eval_client.rs (HTTP receive types)
- src/app/features/evaluation/contracts/rules_contracts.py (Python source types)

---
*Discovered while: adding analyzer endpoint*"