feat: bulk edit metadata across folders and selected notes

[chhoumann]

Summary

Adds a coherent bulk metadata edit capability: add or update a single YAML
frontmatter property across many notes at once, safely and idempotently.

Reachable two ways:

• Folder context menu -> "Bulk edit metadata in this folder (and subfolders)" (replaces the old blind per-file writer).
• File-explorer multi-selection -> "Bulk edit metadata in selected notes" (new files-menu entry - the literal ask of Add feature to add a property to multiple notes. #64).

The flow: prompt for a property name and value, then - only when some notes
already define the property - choose a conflict policy once:

Policy	Behavior
Skip (default)	Add only where missing; never touch existing values (no duplicates).
Merge	Add the value into a list, without duplicating; every note ends up list-shaped.
Overwrite	Replace existing values. Gated behind a blast-radius confirmation.

A single summary Notice reports the outcome (added / merged / overwritten / skipped / unchanged / failed). Per-note failures are isolated and logged; one
bad note never aborts the batch.

Closes #64. Closes #20.

Why these issues, and what about #32?

• Add feature to add a property to multiple notes. #64 ("add a property to multiple notes") and don't duplicate properties inside folders #20 ("don't duplicate a
  property when bulk-applying in folders; merge into arrays; confirm before
  overwriting") are the same capability from two angles, delivered together here.
  On today's master don't duplicate properties inside folders #20's literal duplicate is already prevented by the
  controller's hasOwnProperty guard; what was missing - and is added here - is
  the actual bulk capability: a multi-select entry point, a conflict policy
  (merge into lists / confirmed overwrite), idempotency, and a single summary.
• Search for line with keyword, and add to property #32 ("search for a line with a keyword and add it to a property") is
  intentionally scoped out. It is a content-harvest operation (scan note
  body lines, collect matches into a property) - a fundamentally different
  mental model from "apply property = value across a set of notes," and
  single-note-oriented in the issue. Folding it in would muddy a clean
  capability. The bulk engine is operation-shaped so Search for line with keyword, and add to property #32 can be added later as
  its own feature. Recommend keeping Search for line with keyword, and add to property #32 open as a separate follow-up.

Design

• Idempotent by construction. Each note's decision is a pure function
  (src/bulk/bulkMetadata.ts): re-running any policy is a no-op (proven by unit
  tests and live re-run E2E). Merge dedupes by stable serialization and every
  policy converges.
• Atomic, safe writes. Each note's read -> decide -> write happens inside a
  single app.fileManager.processFrontMatter callback - the same frontmatter
  primitive the controller write path is built on - not hand-rolled YAML text
  edits. Decisions use the note's live frontmatter, never the lazy metadata
  cache.
• Parity with single-note adds. Bulk adds honor EditMode multi-value
  wrapping, so YAML shape is consistent whether you add one note or many.
• Cancel-safe UI. An owned BulkOptionModal resolves null on Escape; text
  prompts catch the prompt's cancel rejection and abort cleanly.

Adversarial review

Design and implementation each went through opposing-model adversarial review
(refute-first, multiple lenses). Findings folded in: cancel-safe modal; atomic
read-decide-write against live frontmatter; EditMode parity; recursive menu
reachability (items now appear when markdown lives only in subfolders);
overwrite confirmation framed against the authoritative selection size (never a
cache count that could understate the blast radius); empty value aborts; failures
reported once via console.warn (not per-note error Notices). Verified live that
processFrontMatter performs no write on a no-op, so skip/unchanged re-runs
don't churn files or fire automators.

Collision boundary

Touches only src/main.ts, src/Modals/LinkMenu.ts, new files under
src/bulk/, src/Types/obsidian-augmentations.d.ts, and styles.css. It edits
none of: metaController.ts, parser.ts, Settings/, the suggester modals, or
MetaEditApi.ts.

Validation

Obsidian 1.12.7, isolated worktree E2E vault. Branch rebased on current
master (integrates #120 / #122).

• pnpm run lint -> 0 errors (only pre-existing warnings; 2 adjacent ones fixed).
• pnpm run build -> clean.
• pnpm run test -> 96 unit tests pass (22 new for the decision engine).
• pnpm run test:e2e -> 16 live tests pass (11 pre-existing + 5 new), each asserting zero runtime errors.
• Live multi-note proof: seeded a nested folder with mixed states (no
  frontmatter, scalar conflict, array, empty, subfolder note, non-md file) and
  verified collection (recursion + md filter + dedup), every policy, idempotent
  re-runs, EditMode wrapping, recursive menu reachability, the multi-select menu
  wiring, the full interactive flow (prompts -> option modal -> summary), and
  cancel-safety (Escape aborts with no writes, no hang). Final frontmatter
  verified clean (correct fences, list formatting, merged [x, y, z] with no
  duplicates).

Known limitations / deliberate choices

• Not undoable. Bulk edits write programmatically and aren't reversible with
  Ctrl+Z (same as the previous folder command); that's why Overwrite is confirmed.
• Merge dedupes by string form, so 5 and "5" are treated as the same
  value (prevents visually-identical duplicates). Pre-existing duplicates inside
  a list are left as-is rather than silently rewritten.
• Conflict count in the policy prompt is read from Obsidian's metadata cache
  (the same source as the existing getFilesWithProperty); the apply uses live
  frontmatter and the summary reports the true counts. The destructive overwrite
  confirmation is framed against the authoritative selection size, so it can
  never understate the blast radius.
• Write serialization. Bulk writes use processFrontMatter (atomic,
  key-scoped) sequentially; they are not cross-serialized with the controller's
  private per-file queue, which lives in a file outside this change's boundary.
  Risk is low because writes are sequential and merge into existing frontmatter
  by key.
• Large folders are processed sequentially (correct; no mid-run progress beyond
  the final summary).

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1aebe430c1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Detect conflicts from live frontmatter

When the selected notes were just created or externally modified and Obsidian's metadata cache has not caught up, countExisting() can return 0 even though applyToFile() later sees the key via processFrontMatter; in that case the interactive flow never offers Merge or Overwrite and silently applies the default skip policy, leaving those existing values unchanged. The conflict scan should use the same live frontmatter source as the write path, or otherwise wait for/cache-validate metadata before deciding whether to show the policy modal.

Useful? React with 👍 / 👎.

[github-actions]

🎉 This PR is included in version 1.9.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀