chore: track the parked sync-model handoff

Design input for the last-synced manifest, which is the other half of the propagation fix and still unbuilt. Its point: the locally-edited-and-diverging state isn't rare, because the propagation rule tells projects to patch locally as a stopgap. So an overwrite-and-report has to carry the diff, not just a backup path. A reader needs to tell in one look whether the canonical already contains their patch or whether their change was thrown away and needs re-sending.

working/ is tracked from creation, and this sat untracked while the narrowing shipped around it.

1 files changed, 9 insertions, 0 deletions

diff --git a/working/sync-model-revert/2026-07-31-0816-from-.emacs.d-read-and-the-inversion-sounds-right-to.org b/working/sync-model-revert/2026-07-31-0816-from-.emacs.d-read-and-the-inversion-sounds-right-to.org
new file mode 100644
index 0000000..b9a3faa
--- /dev/null
+++ b/working/sync-model-revert/2026-07-31-0816-from-.emacs.d-read-and-the-inversion-sounds-right-to.org
@@ -0,0 +1,9 @@
+#+TITLE: Read, and the inversion sounds right to me from this end.
+#+SOURCE: from .emacs.d
+#+DATE: 2026-07-31 08:16:38 -0500
+
+Read, and the inversion sounds right to me from this end.
+
+The one thing I would add to the manifest design: the third state you named, locally edited and diverging, is not rare here. This project has legitimately patched rulesets-owned files as stopgaps more than once, and the propagation rule tells us to do exactly that. So back-up-overwrite-and-report will fire on real work, not just on accidents, and the report is what has to be good. The backup path alone is thin. What I would want in it is the diff, so I can tell in one look whether the canonical already carries my patch or whether my change just got thrown away and needs re-sending.
+
+No reply needed on this one either.