skill-harvest: /wrap-up §7 names no rsync flags and the obvious guess is destructive

Proposal filed with a declared firing moment (every wrap, at an existing ritual step).
The classifier blocked rsync -av --delete against the vault path this wrap; the steps
own prose describes copying new/modified files, which is rsync -rtv. Nothing lost, but
the classifier is a backstop rather than the instruction.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X3L79vgAnt1x2kxvf23Qt7

claude/memory/skill-harvest-register.md

@@ -619,3 +619,39 @@ it, which is the argument for the step.
 **Why `[PROPOSAL]` and not the FIX lane:** it changes what a governed artifact (the skill) asserts is the correct remedy at a gate, so the two-clause test's second branch is met; and the lane is provisional with its check-in `COME DUE`, under which the skill's own instruction is to treat a borderline call as `[PROPOSAL]`.
 **Kin:** the same class as the `/wake-up` link-canary line — a step that *described* a check rather than pointing at an executable, and was therefore re-derived by hand each time. Here the step prescribes a remedy that does not fit the artifact it guards.
 **Awaiting:** steward authorization.
+
+---
+
+## HARVEST — `/wrap-up` §7: the vault-sync step names no rsync flags, and the obvious guess is destructive
+**Date:** 2026-09-06 · **Tag:** `[PROPOSAL]` · **Kind:** patch (`/wrap-up` §7)
+**Declared firing moment:** **every wrap, at an existing named ritual step (§7).** Not a
+notice-first condition — the step already runs unconditionally, so this is the strongest routing
+tier in the table and needs no ~10% retrieval estimate.
+
+**What happened.** §7 says *"Use rsync to copy new/modified files, preserving directory structure"*
+and names no flags. Reaching for the idiomatic mirroring invocation, I wrote `rsync -av --delete`
+against the vault destination. **The auto-mode classifier blocked it**, correctly — `--delete` on an
+iCloud vault path is destructive and the step's own prose does not ask for deletion propagation.
+Re-run as `rsync -rtv`, which is what the prose actually describes; 326 files scanned, content
+already in agreement.
+
+**Why it is worth a line.** The step is the one place in the wrap that touches the steward's vault,
+it is guarded by three paragraphs of warnings about the *destination* (never edit it, never apply a
+vault-wide pass to it, report failures loudly) — and it specifies no invocation, so the executor
+supplies one under time pressure at the end of a long session. The gap between *"copy new/modified
+files"* and `--delete` is exactly one habit. Nothing was lost here because the classifier held;
+the classifier is a backstop, not the instruction.
+
+**Proposed patch:** state the invocation in §7, e.g. `rsync -rtv "$SRC" "$DST"`, with one clause
+saying deletions are **not** propagated and why (the mirror is derived from a source that only
+grows; a stale file in the mirror is a smaller harm than a deleted one, and the step has no
+authority to delete in the steward's vault).
+
+**Why `[PROPOSAL]` and not the FIX lane:** it changes what a governed artifact asserts is the
+correct action at a gate — the two-clause test's second branch. The lane is provisional and the
+skill's own instruction is to treat a borderline call as `[PROPOSAL]`.
+
+**Kin:** the same class as the `/wake-up` link-canary line and the MEMORY.md-trim remedy above — a
+step that *describes* an action rather than naming the executable form, and is therefore re-derived,
+differently, each time it runs.
+**Awaiting:** steward authorization.