inbox-backfill-maintenance

name	inbox-backfill-maintenance
description	Class-level workflow for draining batched edge/intake records into Obsidian inbox notes, deduping repeated signals, and safely committing checkpoints.

Inbox Backfill Maintenance

Use this skill when a batch of source-backed intake records needs to be compacted into durable notes, especially when the batch contains repeated refreshes, repeated titles, or long notes that must be appended to rather than rewritten.

Goals

• Compact each channel/thread group before writing.
• Preserve source provenance with line ranges or representative URIs.
• Deduplicate repeated facts/messages inside a group.
• Write to the smallest correct durable home.
• Commit checkpoints only after triage/writeback is complete for the exact batch.

Workflow

1. Group records by channel/thread first.
2. For each group, answer:
   • What needs to be done?
   • How can I help now?
   • What facts changed?
   • What patterns/signals changed?
3. Dedupe repeated asks within the group before writing any note.
4. If entity routing is unclear, write one sourced Inbox backfill note for the whole batch rather than scattering one note per row.
5. Include source line ranges or representative vadimgest://... URIs in the note.
6. Only after writeback, run the exact checkpoint commit step for the listed source lines.

When to prefer an Inbox note

• The target entity is uncertain.
• The same ask appears across multiple rows or channels.
• The batch is historical/backfill-oriented rather than immediately executable.
• The note will later be groomed into a better home by reflection or a follow-up pass.

When to route elsewhere

• Clear facts about a person, org, project, or deal belong in the relevant State + Log note.
• Tasks or follow-ups belong in the task system only when actually actionable.
• Drafts for external people stay as drafts.

Pitfalls

• Do not create one note entry per raw row when rows clearly belong to the same conversation.
• Do not commit checkpoint positions for sources that were not fully processed.
• Do not rewrite a long repeated note with a fuzzy patch if the heading is duplicated many times; append at a unique insertion point instead.
• If a patch fails because the target text repeats, re-read around the insertion point and switch to a deterministic append/update method.
• Do not treat refresh/repost batches as new claims unless the content actually changed.

Verification

• Re-read the written note to confirm the new section is present.
• Confirm the checkpoint file was updated with only the intended source line.
• If the batch was partially processed, leave the checkpoint untouched for those lines.

Reference

• See references/long-note-patching.md for the repeated-heading / append strategy and a compact checklist.