using-topic-brancheslisted

# Using Topic Branches Branch on the **shape of the work**, not on a permanent partition of the codebase. The goal is one logical change per branch (clean diff for review) without the standing cost of long-lived branches (drift, resync ceremony, stale tracking remotes). This replaces the older "one permanent branch per domain" convention. Permanent domain branches (`dev-safety`, `dev-ui`, `dev-perception`, …) force constant resyncing against `main` for **no review benefit**: the audit gate happens at merge time regardless of how long the branch has existed. Short-lived topic branches keep the isolation and drop the permanence. ## The Two Shapes **1. Lead-only doc / ADR / small-refactor work → land directly on `main`.** No branch overhead for changes that have no audit gate and no parallel contributors: session docs, ADRs, changelog/roadmap updates, comment fixes, config-only tweaks, small single-file refactors you are reviewing yourself. The branch would add ceremony and buy nothing. **2. Team-deployed or multi-agent code work with an audit gate → use a topic branch.** When the work has an explicit review/test gate before it can land (a code-reviewer pass, a safety audit, a test-runner gate) or multiple contributors are involved, isolate it: - **Name it** `topic/<scope>-<slug>`: e.g. `topic/vram-coordinator`, `topic/c2-identity-evidence`, `topic/dashboard-wiring`. Scope is the wave/feature; slug is the one logical change. - **Create it at the start of the work**, bran