Clarify CMS back-sync boundary

README.md

@@ -33,8 +33,9 @@ branch; it never writes to `main`.
 4. Merge only after the required CMS validation, both site builds, and SloanOps
    review pass.
 5. Relevant `main` changes deploy the production primary and/or blog Worker.
-6. Synchronize the resulting `main` merge commit back into `cms` through a
-   protected-branch pull request before the next editing cycle.
+6. If `main` contains file changes that are not already in `cms`, synchronize
+   them back through a protected-branch pull request before the next editing
+   cycle. A merge commit whose tree already matches `cms` needs no no-op sync.
 
 Operator-authored CMS application or configuration work also starts from the
 current `cms` state. Use a short branch and a pull request into protected

docs/decap-cms-gitea-setup.md

@@ -214,8 +214,9 @@ altered by choosing another branch name.
    SloanOps approval.
 4. Merge deliberately, then confirm each affected production Worker workflow
    succeeds and smoke-test the public routes.
-5. Merge the resulting `main` commit back into `cms` through another
-   protected-branch pull request if the histories diverge.
+5. Merge `main` back into `cms` through another protected-branch pull request
+   only when its tree contains file changes missing from `cms`. Do not create a
+   history-only sync when the trees already match.
 6. Confirm previews remain no-index and never expand OAuth/CORS for a temporary
    branch alias.
 

docs/decap-cms-pilot.md

@@ -267,9 +267,10 @@ Because Decap writes to a fixed `cms` branch, SloanOps creates the pull request
 from `cms` to `main` in Gitea. Internal CMS application/configuration changes
 start from the current `cms` state, enter protected `cms` through an
 operator-reviewed pull request, and are then promoted with the staged content.
-After an approved `main` merge, synchronize its merge commit back into `cms`
-through a protected-branch pull request before the next editing cycle. Do not
-automate production merge.
+After an approved `main` merge, synchronize only file changes that are missing
+from `cms` through a protected-branch pull request. When the `main` merge commit
+has the same tree as `cms`, no no-op sync is required. Do not automate
+production merge.
 
 The accepted pilot is promoted by replacing the disposable branch with the
 permanent, slash-free `cms` branch. It remains a preview/staging branch and
@@ -285,8 +286,8 @@ retains the same pull-request, validation, and approval path into `main`.
 4. Review the complete staged diff and open `cms` to `main`.
 5. Require the stable secret-free validation status and SloanOps approval.
 6. Merge deliberately and confirm the affected production Worker jobs pass.
-7. Synchronize the resulting `main` merge commit back into protected `cms`
-   before another editing cycle.
+7. Synchronize `main` back into protected `cms` only when it contains file
+   changes absent from `cms`; skip a no-op history-only merge.
 
 ## Test matrix