diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4a4d845e..c8db339a 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,20 +1,8 @@
 # Changelog
 
-## [1.6.4.0] - 2026-04-22 (in-progress on `garrytan/injection-tuning`)
+## [1.6.4.0] - 2026-04-22
 
-## **Branch resynced with main. Injection-tuning plan approved. No user-facing runtime changes yet.**
-
-Placeholder entry so VERSION 1.6.4.0 has a home. The actual v1.6.4.0 shipping content (real detection recovery from 56.2% → ≥67% via canonicalization, chunking, Haiku prompt sharpening, DeBERTa consent, boundary escalation to Sonnet, Phase 10 tool-result intercept, and full 3,680-case BrowseSafe-Bench) lands when the approved plan at `~/.claude/plans/system-instruction-you-are-working-golden-crystal.md` is implemented. Until then, this entry is a bookmark.
-
-### What's on the branch today
-
-- Two merges bringing the branch up to main's v1.6.3.0 (v1.6.0.0 security wave, v1.6.1.0 Opus 4.7 migration, v1.6.2.0 plan-review RECOMMENDATION fix, v1.6.3.0 Codex ELI10).
-- Prior branch work v1.5.2.0 (Haiku FP cut 44% → 23%, detection 67.3% → 56.2% — the regression that motivated this branch) is retained in its own CHANGELOG entry below.
-- Approved 10-phase plan for injection-tuning v1.5.3.0 scope: Phase -1 bisect the v1.5.2.0 regression, Phase 0 error analysis, Phases 1-8 canonicalization + chunking + Haiku sharpening + split consent (local DeBERTa + remote Sonnet, both default OFF) + threshold calibration + boundary escalation + architectural audit + full 3,680-case measurement, Phase 10 PostToolUse hook intercept (real prevention, not late-kill), Phase 9 CHANGELOG rewrite at ship time.
-
-### What this means for anyone on this branch
-
-Run `bun test browse/test/security*.test.ts` — passes. Detection and FP baseline unchanged at 56.2% / 22.9% on the 500-case smoke. The branch is a stable base to start Phase -1 on. This entry will be replaced by a real release-summary entry at /ship time per the branch-scoped CHANGELOG discipline in `CLAUDE.md`.
+Version bump for branch-ahead discipline. No user-facing changes yet.
 
 ## [1.6.3.0] - 2026-04-23
 
diff --git a/CLAUDE.md b/CLAUDE.md
index d683b907..27cd8fec 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -452,6 +452,22 @@ CHANGELOG.md is **for users**, not contributors. Write it like product release n
 - No jargon: say "every question now tells you which project and branch you're in" not
   "AskUserQuestion format standardized across skill templates via preamble resolver."
 
+**Only document what shipped between main and this change.** Readers do not care how
+we got here. Keep out of the CHANGELOG, always:
+
+- Branch resyncs, merge commits with main, rebase activity.
+- Plan approvals, review outcomes (CEO / eng / design / outside-voice / codex findings),
+  AskUserQuestion decisions, scope negotiations.
+- "Work queued," "plan approved," "in-progress," "will ship later" — the CHANGELOG
+  documents what DID ship, not what MIGHT ship.
+- Version-bump housekeeping when no user-facing work actually landed.
+
+If the diff between the base branch version and this version has no user-facing change
+(only merges, only CHANGELOG edits, only placeholder work), the honest entry is one
+sentence: "Version bump for branch-ahead discipline. No user-facing changes yet." Stop
+there. Do not pad. Do not explain the plan that will ship eventually. Do not narrate
+the branch's history. When real work lands, the entry will replace this at /ship time.
+
 ### Release-summary format (every `## [X.Y.Z]` entry)
 
 Every version entry in `CHANGELOG.md` MUST start with a release-summary section in