Shape a helper for applying resolved encrypted-note conflicts

[k7r2-ricon]

Shape

This is not implementation-ready. It is a shaping issue for a possible conflict-resolution helper after the newer notes conflicts / notes merge --dry-run artifact flow.

Today the tool can already help inspect encrypted note content conflicts:

notes merge --dry-run --out /tmp/note-merge
notes conflicts --out /tmp/note-merge

That maps obfuscated paths to readable note names and writes readable base.md, ours.md, and theirs.md artifacts. This is a big improvement over the old manual git checkout-index --stage=N --temp flow.

The remaining footgun is the final apply step. After manually creating a resolved plaintext file, the user/agent still has to know how to:

1. map readable note name back to notes/<hash>;
2. copy plaintext into the obfuscated path;
3. stage the obfuscated path so git-crypt re-encrypts it;
4. refresh/check the readable copy;
5. verify git ls-files -u no longer lists that note.

Possible command shape

Maybe something like:

notes resolve adhered-patterns.md \
  --from /tmp/note-merge/conflicts/adhered-patterns.md/resolved.md

Or perhaps this belongs under notes merge:

notes merge --apply adhered-patterns.md \
  --from /tmp/note-merge/conflicts/adhered-patterns.md/resolved.md

Expected behavior if we build it

A resolution helper should probably:

• accept a readable note name/path and a resolved plaintext file;
• map that readable note to the conflicted obfuscated path;
• reject unresolved conflict markers (<<<<<<<, =======, >>>>>>>);
• write the plaintext to the obfuscated path;
• stage that path through the correct encrypted clean filter;
• refresh the readable working-tree copy if needed;
• confirm the note no longer appears in git ls-files -u;
• print a short next-step receipt.

Design questions

• Name: notes resolve, notes merge --apply, or something else?
• Should it only operate while the target note has unmerged stages?
• Should it require an explicit --from file, or also support stdin?
• Should it support resolving all conflicts from a directory layout if every conflict has a resolved.md?
• Should it call git add notes/<hash> directly, or reuse notes stage internals?
• How should it behave if the readable copy is dirty or stale?
• Is a separate notes patch command useful later, or is applying arbitrary patches too subtle for the first version?

Related

• notes status: surface help pointer when encrypted-note content has unmerged stages #70 handled surfacing conflict pointers / unmerged encrypted-note stages.
• The current fold docs now point agents at notes merge --dry-run / notes conflicts first, with the manual checkout-index flow as fallback.

Why this matters

notes conflicts makes the inspection step easy, but resolution still requires knowing the obfuscated-path/git-crypt staging mechanics. A small apply helper could keep agents from re-learning that machinery while still leaving the semantic merge decision to the human/agent.