diff --git a/.agent-instructions.toml b/.agent-instructions.toml
index af35aa47..9470834a 100644
--- a/.agent-instructions.toml
+++ b/.agent-instructions.toml
@@ -2,5 +2,5 @@
 # it is on, and the shared blocks it has. Its drift check reads this file,
 # and its apply job rewrites it. Which blocks a repository should carry is
 # decided upstream in repos.json, not here.
-ref = "0.3.0"
+ref = "0.3.1"
 blocks = ["workflow", "agentcoop", "rust", "changelog"]
diff --git a/AGENTS.md b/AGENTS.md
index 405a3347..ad60e3cd 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -18,6 +18,9 @@ before generating code.
 - Do NOT put issue or PR numbers in the title.
 - Body: wrap at 72 characters, free-form, explain *why* not *what*.
 - Separate title and body with a blank line.
+- Do NOT rely on literal `\n` escapes for a commit body — they land in
+  the subject line as characters, and git reports success. Use a real
+  multiline string, or `git commit -F` with a file or heredoc.
 - Reference issues in the body, not the title: `Closes #N` to close an
   issue, or `Part of #N` when the commit addresses part of one.
 
@@ -45,6 +48,12 @@ before generating code.
   number,title,state,url`, and check `/pull/` vs `/issues/` in the URL.
 - Never act on failed or garbled command output. Re-verify every create
   and edit with a structured `--json` re-query before reporting success.
+- A body that was overwritten is recoverable: GitHub keeps every prior
+  version, and `gh api graphql` reads them out of
+  `userContentEdits(first: N) { nodes { editedAt editor { login } diff } }`
+  on the issue or pull request. Restore the one you want with
+  `--body-file`. Do NOT retype it from memory — a body that reads like
+  the original and is not is worse than the empty one it replaced.
 
 ## Markdown lint configuration
 
@@ -441,16 +450,23 @@ Where the crate handles key material or secrets:
   running the last released version could observe it. Work that builds,
   reworks, or removes something they never had is invisible to them and
   does not belong.
-- Entries carry NO issue or PR references. `Closes #N` and `Part of #N`
-  are GitHub automation keywords: they close an issue when they appear
-  in a commit message or a pull request body, and do nothing whatever
-  inside `CHANGELOG.md`. All that is left there is a command addressed
-  to a bot, stranded in a record of what already shipped — it cannot
-  act, and the reader has no use for it. Git and the issue tracker
-  already hold that history.
+- Entries carry NO issue or PR references. A reader of the release notes
+  cannot act on one: the number names something in a tracker they may
+  not be able to open, and git and that tracker already hold the history
+  it points at. `Closes #N` and `Part of #N` are worse still. They are
+  GitHub automation keywords, closing an issue when they appear in a
+  commit message or a pull request body and doing nothing whatever
+  here, so what is left is a command addressed to a bot, stranded in a
+  record of what already shipped.
 - Announce a feature once, under `### Added`, describing what it does.
   If it was reworked or renamed before the release shipped, that is not
   a separate `### Changed` entry — no user saw the earlier form.
+- A released file carries no `[Unreleased]` section. Cutting a release
+  turns that heading into the version being released and its link
+  reference into a compare range, and the next change to land opens a
+  new one. An empty section left behind is not cosmetic where a release
+  job builds the notes by finding the heading that matches the tag: it
+  finds nothing, and fails after the tag has already been pushed.
 <!-- END shared:changelog -->
 
 ## CI Requirements