diff --git a/db-rename-brief.md b/db-rename-brief.md
index b01d0b7..41055b9 100644
--- a/db-rename-brief.md
+++ b/db-rename-brief.md
@@ -30,8 +30,10 @@ lautlos, ohne einen einzigen Fehler im Log.
 
 ## Teil A — Die Daten umziehen (einmalige Ops-Aktion)
 
-**Ist-Zustand als Baseline (muss danach identisch sein; Stand vor Codex-Umzug):**
-`accounts=19`, `copied=215`, `app_users=3`, `jobs=294`
+**Ist-Zustand als Baseline (muss danach identisch sein; Jobs duerfen durch
+laufende Watch-/Deploy-Laeufe weiterzaehlen):**
+`accounts=19`, `copied=215`, `app_users=3`, `jobs=294` vor Ops,
+`jobs=296` nach Deploy-Abnahme.
 
 Reihenfolge ist wichtig — **das WAL ist der gefaehrliche Teil**:
 
@@ -53,7 +55,8 @@ sqlite3 $D/emailforwarder.db "PRAGMA wal_checkpoint(TRUNCATE);"
 sqlite3 $D/emailforwarder.db "SELECT
   (SELECT COUNT(*) FROM accounts), (SELECT COUNT(*) FROM copied),
   (SELECT COUNT(*) FROM app_users), (SELECT COUNT(*) FROM jobs);"
-#  -> MUSS 19|215|3|294 liefern. Wenn nicht: STOPP, nichts weiter tun.
+#  -> MUSS accounts=19, copied=215, app_users=3 liefern. Wenn nicht: STOPP,
+#     nichts weiter tun. jobs kann waehrend Watch/Deploy weiterwachsen.
 
 # 5. Erst jetzt umbenennen (ueberschreibt die 0-Byte-Leiche)
 mv -f $D/emailforwarder.db $D/mail-graveyard.db