diff --git a/AGENTS.md b/AGENTS.md
index 3959c82e..1711bab7 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -240,6 +240,32 @@ Centralized logging uses a three-layer stack:
 
 These rules apply to every change. No exceptions.
 
+### Work from `dev`, always
+
+`dev` is the baseline for day-to-day work. Cut branches from it, open pull
+requests against it, and read it whenever you need current truth:
+
+```bash
+git fetch origin dev && git checkout -b <branch> origin/dev
+```
+
+`main` is the release branch and trails `dev` by an entire release cycle -
+routinely hundreds of commits. Anything read from `main` may therefore be
+stale: file paths and line anchors, where a function lives, which subsystems
+exist at all, and whether an architectural claim still holds. This is a
+recorded failure mode, not a theoretical one - a planning pass was once
+researched entirely against `main` and had to be redone when `dev` turned out
+to be 305 commits and a minor version ahead, with a whole subsystem the
+research never saw.
+
+So: when a claim about this codebase matters, verify it on `dev`, and say which
+branch you checked.
+
+The one exception is the release cut itself: promotion pull requests from `dev`
+to `main` are opened by maintainers. This rule restates, for agents, the
+branching model already documented in
+[`CONTRIBUTING.md`](CONTRIBUTING.md) - keep the two in step if either changes.
+
 ### Experimental code stays out of dev
 
 Unproven, demo-bound, or design-in-motion work never merges to dev. It lives
diff --git a/CLAUDE.md b/CLAUDE.md
index aa64b7c4..39016478 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -587,6 +587,32 @@ peer APIs rather than through a central authoritative trace store.
 
 These rules apply to every change. No exceptions.
 
+### Work from `dev`, always
+
+`dev` is the baseline for day-to-day work. Cut branches from it, open pull
+requests against it, and read it whenever you need current truth:
+
+```bash
+git fetch origin dev && git checkout -b <branch> origin/dev
+```
+
+`main` is the release branch and trails `dev` by an entire release cycle -
+routinely hundreds of commits. Anything read from `main` may therefore be
+stale: file paths and line anchors, where a function lives, which subsystems
+exist at all, and whether an architectural claim still holds. This is a
+recorded failure mode, not a theoretical one - a planning pass was once
+researched entirely against `main` and had to be redone when `dev` turned out
+to be 305 commits and a minor version ahead, with a whole subsystem the
+research never saw.
+
+So: when a claim about this codebase matters, verify it on `dev`, and say which
+branch you checked.
+
+The one exception is the release cut itself: promotion pull requests from `dev`
+to `main` are opened by maintainers. This rule restates, for agents, the
+branching model already documented in
+[`CONTRIBUTING.md`](CONTRIBUTING.md) - keep the two in step if either changes.
+
 ### Experimental code stays out of dev
 
 Unproven, demo-bound, or design-in-motion work never merges to dev. It lives