docs(claude): codify how rulesets-owned changes propagate

A bug or enhancement in a rulesets-owned synced file (a workflow, skill, rule, or script) is handled by editing the local copy, sending rulesets a copy plus an explanatory note, and letting it update the canonical and re-sync. A local edit alone is overwritten on the next template sync. Captured after running it twice this session.

1 files changed, 2 insertions, 0 deletions

diff --git a/CLAUDE.md b/CLAUDE.md
index 79e68ada..b6383975 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -85,3 +85,5 @@ Prefer Write over cumulative Edits for nontrivial new code. Small functions (und
 - **Warn at module load when an external tool path is configured but missing.** Calling `cj/executable-find-or-warn` (from `system-lib.el`) at `:config` time emits a `display-warning` if `prettier` / `pyright` / `pandoc` / etc. isn't on PATH, instead of letting the first format-on-save or LSP-attach fail with a confusing mid-edit error. Pattern in use: `modules/prog-webdev.el` (prettier), `modules/prog-python.el` (pyright). (`pattern` — 2026-05-16)
 
 - **ghostel F-key / prefix bindings need `ghostel-keymap-exceptions` + a rebuild, not just `ghostel-mode-map`.** In semi-char mode ghostel forwards every key not in `ghostel-keymap-exceptions` to the pty, and `ghostel-semi-char-mode-map` (rebuilt from that list, and outranking the major-mode map) wins. So binding F9 / F12 / C-; in `ghostel-mode-map` alone is silently dead inside agent/terminal buffers — the key reaches the shell, not Emacs. Fix: add the key to `ghostel-keymap-exceptions` AND call `ghostel--rebuild-semi-char-keymap` (`add-to-list` updates the list but not the already-built map). `term-config.el` (C-;, F12) and `ai-term.el` (F9 family) do this in their `with-eval-after-load 'ghostel`. This is the opposite of vterm, where binding in `vterm-mode-map` sufficed. (`gotcha` — 2026-06-05)
+
+- **Rulesets-owned changes propagate by edit-local + send-copy + explanatory note.** A bug or enhancement that belongs to a rulesets-owned synced file (a workflow under `.ai/workflows/`, a skill, a rule under `.claude/rules/`, a script under `.ai/scripts/`) is handled by editing the local copy so it's usable now, then sending rulesets a copy of the edited file plus an explanatory note — a local edit alone is overwritten on the next template sync, so the canonical update is what makes it durable. The note covers: how the problem was hit, what outcomes the change should alter, any implementation recommendations, and any follow-up instructions (e.g. send a note back with more info). Send notes with the inbox-send script (`inbox-send rulesets --file <path>`). Offer the change proactively when it would help. (`pattern` — 2026-06-12)