chore(beads): migrate issue tracking from bd to br

Agents were told to run bd commands that beads_rust does not have (bd prime,
bd remember, bd dolt push, bd tag, bd note, bd children), and bd's git hooks
were still active, so bd could re-export its stale dolt state over br's
JSONL on commit.

- Rewrite AGENTS.md, docs/agents/issue-tracker.md, docs/agents/triage-labels.md
  and the .serena memories around br's real CLI surface
- Replace bd's generated AGENTS.md block with br's (br agents --add)
- Point the .claude session hooks at `br robot-docs guide`
- Remove bd git hooks and unset core.hooksPath; br installs no hooks
- Ignore br runtime files (local SQLite DB, recovery and merge artifacts)
- Rewrite .beads/README.md, config.yaml and metadata.json for br

Issue: nix-overlay-6pp

docs/agents/issue-tracker.md

@@ -1,55 +1,58 @@
-# Issue tracker: bd (beads)
+# Issue tracker: br (beads_rust)
 
-Issues and specs for this repo live in the beads database at `.beads/`. The source of truth is `.beads/issues.jsonl`, managed through the `bd` CLI (v1.3.0). beads state is versioned in the repo and synced with `git push`; there is no separate Dolt remote.
+Issues and specs for this repo live in the beads database at `.beads/`. The source of truth is `.beads/issues.jsonl`, managed through the `br` CLI (v0.7.6). beads state is versioned in the repo and synced with `git push`; there is no separate Dolt remote.
+
+**Note:** `br` is non-invasive and never executes git commands. After `br sync --flush-only`, you must manually run `git add .beads/ && git commit`.
 
 The forge remote (`git.millerson.name`, self-hosted Gitea) is not the issue tracker. Do not open Gitea, GitHub, or GitLab issues for work in this repo.
 
 ## Core commands
 
 ```bash
-bd ready                 # open issues with no active blockers
-bd show <id>             # full issue detail
-bd list                  # list issues
-bd search "<text>"       # text search
-bd create "title" -d "description" -p 2 -l label1,label2
-bd q "quick capture"     # create and print only the id
-bd update <id> --claim   # claim before starting work
-bd close <id> --reason "..."
-bd reopen <id>
-bd comment <id> "..."    # conversation history
-bd note <id> "..."       # append a note
-bd tag <id> <label>      # shorthand for: bd update <id> --add-label <label>
-bd label add <id> <label>
-bd label remove <id> <label>
-bd status                # database overview
+br robot-docs guide    # session context and command reference (run first)
+br ready               # open issues with no active blockers
+br show <id>           # full issue detail
+br list                # list issues
+br search "<text>"     # text search
+br create "title" -d "description" -p 2 -l label1,label2
+br q "quick capture"   # create and print only the id
+br update <id> --claim # claim before starting work
+br close <id> --reason "..."
+br reopen <id>
+br comments add <id> "..."          # conversation history
+br update <id> --append-notes "..." # append to the issue notes field
+br label add <id> <label>
+br label remove <id> <label>
+br label list <id>
+br status              # database overview
 ```
 
-Issue ids look like `nix-overlay-4g1`. New work must be claimed with `bd update <id> --claim` before it starts.
+Issue ids look like `nix-overlay-4g1`. New work must be claimed with `br update <id> --claim` before it starts.
 
 ## When a skill says "publish to the issue tracker"
 
-Run `bd create`. Use one issue per ticket. Put the full body in `--description` (markdown is fine). Add labels per `triage-labels.md`. For a multi-part spec, create a parent issue and link children with `--deps`.
+Run `br create`. Use one issue per ticket. Put the full body in `--description` (markdown is fine). Add labels per `triage-labels.md`. For a multi-part spec, create a parent issue and link children with `--deps`.
 
 ## When a skill says "fetch the relevant ticket"
 
-Run `bd show <id>` and read the description plus comments (`bd show <id> --include-comments --json` when full comment bodies are needed). The user normally passes the issue id directly.
+Run `br show <id>` and read the description. Use `br show <id> --json` for machine-readable output, and `br comments list <id>` for the comment thread. The user normally passes the issue id directly.
 
 ## Dependencies
 
-`bd create --deps 'blocked-by:nix-overlay-4g1,discovered-from:nix-overlay-2a3'`
+`br create --deps 'blocked-by:nix-overlay-4g1,discovered-from:nix-overlay-2a3'`
 
-Bare ids, `depends-on:` and `blocked-by:` all make the new issue depend on the target. `blocks:` reverses the direction. `bd link`, `bd dep`, and `bd children` manage the graph after creation. `bd ready` already excludes anything with an unresolved blocker, so a ticket is unblocked when every issue that blocks it is closed.
+Bare ids, `blocked-by:` and `discovered-from:` all make the new issue depend on the target. `depends-on:` is not a valid br dependency type and is rejected. `br dep add <issue> <depends-on>` adds a dependency after creation, `br dep list <issue>` shows the graph, and `br dep tree <issue>` shows it as a tree. `br ready` already excludes anything with an unresolved blocker, so a ticket is unblocked when every issue that blocks it is closed.
 
 ## Wayfinding operations
 
 Used by `/wayfinder`. The map is a parent bead; the children are its sub-issues.
 
 - **Map**: a bead created for the effort. Its description holds the Notes / Decisions-so-far / Fog body.
-- **Child ticket**: a bead linked to the map with `--deps depends-on:<map-id>`. The question goes in the description. Record the ticket type as a label (`research`, `prototype`, `grilling`, `task`).
+- **Child ticket**: a bead created with `--parent <map-id>`, which links it to the map as a parent-child dependency (br ids the child `<map-id>.1`). The question goes in the description. Record the ticket type as a label (`research`, `prototype`, `grilling`, `task`).
 - **Blocking**: a `blocked-by:<id>` dependency on the blocking bead.
-- **Frontier**: `bd ready` output, restricted to children of the map (`bd children <map-id> --ready` or filter `bd ready` by parent). Lowest priority number, then oldest, wins.
-- **Claim**: `bd update <id> --claim` before any work starts.
-- **Resolve**: append the answer with `bd note <id> "..."` or `bd comment`, then `bd close <id> --reason "<answer gist>"`, then add a context pointer (gist plus issue id) to the map's Decisions-so-far with `bd note <map-id> "..."`.
+- **Frontier**: `br ready` output, restricted to children of the map (`br list --tree` groups children under their parent, or filter `br ready` by label). Lowest priority number, then oldest, wins.
+- **Claim**: `br update <id> --claim` before any work starts.
+- **Resolve**: append the answer with `br update <id> --append-notes "..."` or `br comments add <id> "..."`, then `br close <id> --reason "<answer gist>"`, then add a context pointer (gist plus issue id) to the map's Decisions-so-far with `br comments add <map-id> "..."`.
 
 ## Session end
 
@@ -57,7 +60,9 @@ Work is not complete until pushed. The project workflow requires:
 
 ```bash
 git pull --rebase
-bd dolt push    # prints "No remote is configured - skipping." here; expected, not a failure
+br sync --flush-only    # export issue state to .beads/issues.jsonl
+git add .beads/
+git commit -m "sync beads"
 git push
-git status      # must show up to date with origin
+git status              # must show up to date with origin
 ```

docs/agents/triage-labels.md

@@ -14,17 +14,16 @@ When a skill mentions a role (for example "apply the AFK-ready triage label"), u
 
 Edit the right-hand column to match whatever vocabulary you actually use.
 
-## Applying labels with bd
+## Applying labels with br
 
-Labels are bd labels, not forge labels:
+Labels are br labels, not forge labels:
 
 ```bash
-bd tag <issue-id> ready-for-agent
-bd label add <issue-id> needs-triage
-bd label remove <issue-id> needs-triage
-bd label list <issue-id>
+br label add <issue-id> ready-for-agent
+br label remove <issue-id> needs-triage
+br label list <issue-id>
 ```
 
-On creation: `bd create "title" -l ready-for-agent`.
+On creation: `br create "title" -l ready-for-agent`.
 
 A ticket has at most one triage role label. When a ticket moves to a new role, remove the old label and add the new one in the same step rather than stacking role labels.