heartbeat-edge-backfill

name	heartbeat-edge-backfill
description	Process pre-batched vadimgest edge/local intake slices into compact sourced Inbox notes, deduping grouped channel/thread evidence and committing only the exact checkpointed source lines; references/2026-07-01-heartbeat-edge-backfill.md and references/2026-07-03-heartbeat-edge-backfill-batch.md

Heartbeat Edge Backfill

Use this skill when a pre-run batch of vadimgest edge/local records arrives and you need to drain it into durable notes without double-processing or one-note-per-row spam.

Core intent

Take one batch snapshot, compact each emitted channel/thread group first, then write a small number of sourced Inbox notes with clear provenance. Treat the batch as a grouped conversation window, not a raw table dump.

When to use

• The intake payload is already batched by source/channel/thread.
• The prompt explicitly says to backfill an edge/local batch.
• You need to preserve source line ranges or representative URIs.
• The batch mixes actionable business/relationship/process items with noise.

Procedure

1. Read the batch instructions and trust the batch payload as the only source for this run.
2. Group records by channel/thread before writing anything.
3. Deduplicate repeated facts/messages inside each group.
4. For each group, answer the four intake questions:
   • What needs to be done?
   • How can I help now?
   • What facts changed?
   • What patterns/signals changed?
5. Route durable facts to the smallest correct home:
   • Clear people/org/deal/project facts → entity note with provenance.
   • Unclear or cross-entity historical evidence → sourced Inbox note.
   • Pure noise / empty headers / synthetic pings → count as skipped.
6. In Inbox notes, include either source line ranges or representative vadimgest://... URIs for every meaningful group.
7. Write back only after triage is complete.
8. Run the exact checkpoint snippet provided by the batch, and commit only the listed source lines.
9. Verify the checkpoint file changed as expected.

What good output looks like

• A concise sourced Inbox note per batch, not a row-per-record transcript.
• Group headings by channel/thread.
• Clear Q1–Q4 answers per group.
• Representative source ranges / URIs.
• A short batch note or delta summary with writeback + checkpoint status.

Pitfalls

• Do not over-fragment a batch into many tiny notes when the thread is one conversation.

• Do not commit source lines not named by the batch.

• Do not treat empty headers, forwarded boilerplate, or one-word pings as durable facts.

• Do not treat empty headers, forwarded boilerplate, or one-word pings as durable facts.

• Do not split a request-only diagnostics ping and a bare media-generation stub just because their surface task type differs; if neither has a stable entity target, keep them together in one compact sourced Inbox section.

• If the same request-only diagnostics ask reappears in the same batch or same channel window (for example, a repeated W&B/SoTA/VAL forensics ping), dedupe it into one refreshed Inbox section instead of creating a second sibling note.

• Do not promote one-off promotional broadcasts or partner pitches into entity notes just because they mention product features, payments, or business language; if there is no active owner/thread, keep the batch in Inbox with provenance.

• Do not over-route filename-only inventory bursts (media names, README/manifest/test stubs) into durable notes; summarize them once as skipped/no-durable-update noise unless the content itself reveals a stable fact.

• If the only substantive item in a batch is a calendar event, capture the exact event URI/title/time in Inbox and stop there unless the agenda or attendees changed.

• If the batch contains only a healthy system-status ping or other routine telemetry, keep it as a skipped/no-durable-update item instead of forcing a note.

• If the batch is centered on one live project thread and the new fact is primarily about copy, framing, or demo positioning, patch the project note directly instead of minting a fresh Inbox sibling.

• If a mixed batch contains one clear reusable named-contact fact, update the existing person note directly and keep the batch Inbox summary compact; do not leave the durable contact fact only in the batch note.

• If a live short-call request changes a person's durable state (last_contact, follow_up), refresh the person note directly with a minimal dated log entry and keep the batch note compact.

• After writeback, run the exact checkpoint snippet from the batch and verify the checkpoint file actually reflects the committed source lines.

• If a person-note patch fails because the note was only read in chunks, re-read the target span before retrying and prefer a fresh dated log entry over a broad replace.

• If another agent or process modified the same note after your last read, re-read the target span before any retry; do not reuse stale replace anchors.

• If a batch is only a continuation of an already-covered project thread, patch the existing project note directly rather than minting a fresh Inbox continuation note.

• If a batch only refreshes a live workstream title (for example, a demo-tab fix or ultrasound-probe-detection refresh) and the canonical Inbox note for that day already exists, extend that note instead of minting a sibling note.

• If a note has a repeated state key or adjacent dated entries, re-read the full contiguous block before editing and keep one canonical state line; move the rest into the dated log.

• If read_file output is being re-used as write input, strip line-number prefixes first; a raw round-trip can corrupt the note with duplicated numbering.

Session lessons

• references/2026-07-08-mixed-telegram-signal-project-note-routing.md captures the newest mixed launch-routing lesson: when Telegram + Signal + Dayflow all point at one launch, patch the canonical project note directly, refresh person notes only for real contact deltas, and always re-read the edited span before checkpointing.

• references/2026-07-08-heartbeat-edge-backfill-batch-2.md captures the follow-on lesson from this batch: repetitive bot/status noise can stay skipped while a real person-state change and a separate infra blip still get routed to their own durable homes.

• references/2026-07-07-heartbeat-edge-backfill-batch.md captures the newest mixed-source lesson: a lone calendar marker stays compact in Inbox, while a LinkedIn follow-up with concrete account signals should update both Inbox and the new person/contact note before checkpointing.

• references/2026-07-05-heartbeat-edge-backfill-batch-12823.md captures the newest batch lesson: a one-line Silent Speech launch-copy repeat should stay grouped with the broader launch stream, not split into a sibling note, and the exact checkpoint snippet must still be run and verified after writeback.

• references/2026-07-05-codex-batch-12845-12846.md captures the sibling lesson from the same day: even two near-identical launch-prep records in one channel/window should compact into one dated batch section, with exact checkpointing after writeback verification.

• references/2026-07-04-heartbeat-edge-backfill-batch-12789.md captures the preceding batch lesson: repeated title-only Codex markers should be compacted into one active workstream, launch-copy churn should stay grouped until a real artifact changes, health research prompts should not be over-interpreted, and the exact checkpoint snippet must still be run and verified after writeback.

• references/2026-07-04-silent-speech-multi-source-routing.md captures the cross-source launch lesson from this run: when Telegram, Signal, Dayflow, and entity notes all point at the same launch, keep the project note updated in place, refresh the person note directly for real relationship deltas, and leave only the cross-entity remainder in one compact Inbox note.

• references/2026-07-04-mixed-signal-telegram-intake.md captures the mixed-source lesson from this run: keep launch-critical Signal threads separate from routine Telegram telemetry, dedupe each group, and still finish with one compact sourced Inbox note when there is no single stable entity target.

• references/2026-07-04-mixed-entity-plus-inbox-routing.md captures the same-run mixed-routing lesson: when one batch spans launch friction, inbound bizdev, and account-admin friction, update the obvious entity notes directly, keep only the cross-entity remainder in Inbox, and skip sender-only noise.

• references/2026-07-04-gmail-noise-and-billing-recurrence.md captures the Gmail backfill lesson from this run: promo/newsletter noise should stay skipped, but a notification-only Vercel billing block still belongs in the existing billing hygiene note when it repeats a live problem.

• references/2026-07-02-heartbeat-edge-backfill-batch.md captures this run's batch lesson: compact by thread, keep low-signal pings as skipped/no-durable-update items, preserve thin Gmail facts with explicit limitations, and verify the exact checkpoint snippet after writeback.

• references/2026-07-02-mixed-person-project-checkpoint.md captures the mixed entity lesson from this run: write the clear person/contact delta directly, keep the project delta in its existing entity note, and leave only the surrounding context in Inbox.

• references/2026-07-02-gimran-launch-video-handoff.md captures the handoff lesson from this run: when a thread moves from status chatter to a reusable handoff fact, update the person note directly with a dated log entry and keep the batch Inbox context compact.

• references/2026-07-02-codex-eval-media-only-routing.md captures the newest lesson from this run: request-only eval pings and media-task titles can share one compact sourced Inbox note when there is no stable entity target, and the exact checkpoint snippet must still be run and verified afterward.

• references/2026-07-02-codex-request-only-and-video-stub.md captures the current run's compact-routing lesson: request-only W&B/SoTA/VAL analysis pings plus a bare speaking-video task stub belong in one sourced Inbox note when there is no stable entity target.

• references/2026-07-02-codex-request-only-wandb-backfill.md captures the latest lesson from this run: two near-duplicate request-only W&B diagnostics rows compact into one refreshed Inbox section, with provenance preserved and the exact checkpoint snippet run afterward.

• references/2026-07-02-codex-request-only-wandb-12669.md captures the same-class lesson from the 12669 batch: keep request-only W&B/SoTA/VAL diagnostics in one compact Inbox section when there is no stable entity target, and dedupe repeat asks in the same window.

• references/2026-07-02-codex-title-only-refreshes.md captures the title-only codex lesson from this run: keep live workstream refreshes like "Fix demo tab and git pull" / "Fix ultrasound probe detection" inside the canonical Inbox note unless the scope or target changes.

• references/2026-07-02-codex-silent-speech-launch-refresh.md captures this run's Silent Speech launch-refresh lesson: when a batch mixes a blog/video-demo ask with repeated "find ultrasound" refreshes, patch the existing Silent Speech project note directly rather than minting a duplicate Inbox continuation note.

• references/2026-07-02-codex-title-refresh-12660.md captures the single-line refresh lesson from this run: when a codex item only restates an active workstream title, append it to the canonical daily Inbox note instead of minting a sibling note.

• references/2026-07-02-paginated-writeback-retry-and-roundtrip.md captures this run's pagination lesson: strip read_file line prefixes before writeback, and re-read the full target span if a patch fails against a partially read note.

• references/2026-07-02-heartbeat-edge-backfill-batch.md captures this run's batch-specific lesson: dedupe against an existing Inbox or meeting note, strip any accidental read_file line-number prefixes before final writeback, and verify the exact checkpoint snippet against the intake checkpoint file.

• references/2026-07-02-exact-checkpoint-verification.md captures the checkpointing lesson from this run: after writeback, run the exact snippet and re-read the checkpoint file to confirm the persisted positions changed.

• references/2026-07-02-codex-wandb-and-video-stub-routing.md captures the combined lesson from this run: request-only W&B diagnostics plus a bare speaking-video stub can share one compact Inbox note when no stable entity target is clear.

• references/2026-07-01-codex-requests-wandb-val-beamform.md captures the newest lesson from this run: repeated request-only eval pings should be deduped by semantic intent into one sourced Inbox note, with no entity writeback until metrics or a durable target appear.

• references/2026-07-01-heartbeat-edge-backfill-batch.md captures the mixed-batch lesson from this run: compact by thread, keep one sourced Inbox note, create person notes for reusable named-contact facts, and verify the exact checkpoint snippet after writeback.

• references/2026-07-01-heartbeat-edge-backfill-batch-2.md captures the same run’s mixed-routing pattern: one compact Inbox note plus a direct person-note update, with empty-header groups left as skipped noise.

• references/2026-07-01-heartbeat-edge-backfill-batch-3.md captures the newest lesson from this run: a batch can include both compact Inbox routing and direct person/org writebacks; keep the batch note small and promote reusable named-contact facts into the entity note.

• references/2026-07-01-mixed-entity-writeback.md captures the key pattern from this run: one batch can contain both a compact Inbox note and a direct person-note update; keep the Inbox summary compact and move durable contact facts into the right entity note.

• references/2026-07-01-heartbeat-edge-backfill-mixed-entity.md captures the same-run lesson with a direct example of refreshing an existing person note (last_contact + dated log) while leaving the rest of the batch in one Inbox summary.

• references/2026-07-01-vox-harbor-homepage-refresh.md captures the new mixed-routing lesson from this run: a short Signal request can justify both an Inbox backfill note and a durable org log entry when a public-facing asset clearly changed.

• references/2026-07-01-mixed-batch-whatsapp-entity-routing.md captures the latest lesson from this run: when a WhatsApp batch yields one reusable contact fact plus a separate small durable life note, write both directly and leave the noisy remainder in one Inbox note.

• references/2026-07-01-numbered-read_file-pitfall.md captures a writeback pitfall from this run: read_file output includes visible line-number prefixes, so strip them before round-tripping into write_file and verify the cleaned file after write.

• references/2026-07-01-system-status-ping-routing.md captures this run’s tiny-batch lesson: a one-row system-status ping still deserves a compact sourced Inbox note, but not a forced entity update.

• references/2026-06-30-heartbeat-edge-backfill-batch-98.md captures the mixed-WhatsApp lesson from this batch: compact by thread, keep one sourced Inbox note, and add concise person-note logs only for stable durable facts.

• references/2026-06-30-whatsapp-batch78-lessons.md captures a compact example of mixed WhatsApp backfill routing: several unrelated subthreads in one batch, thin business/equity chatter best kept in Inbox, and checkpoint verification after writeback.

Support files

• references/2026-07-05-heartbeat-edge-backfill-batch-12823.md — one-row Silent Speech launch-copy repeat; keep it grouped with the broader launch stream and still verify the exact checkpoint snippet.
• references/2026-07-04-heartbeat-edge-backfill-batch-12789.md — this run's concise lesson bank for repeated title-only Codex records, launch-copy churn, health research prompts, and exact checkpoint verification.
• references/2026-07-04-filename-only-inventory-and-calendar.md — this run's tiny-batch lesson: filename-only inventory stays skipped/no-durable-update, while a lone calendar row should still be captured compactly with exact URI/title/time.
• references/2026-07-02-codex-eval-media-only-routing.md — request-only eval and media-task routing lesson from the current run; keep it in one compact Inbox note when no durable target exists.
• references/2026-07-02-codex-title-only-refreshes.md — title-only codex refreshes from this run; keep live workstream updates in the canonical Inbox note until the scope changes.
• references/2026-07-02-codex-request-only-and-video-stub.md — current run lesson: request-only W&B/SoTA/VAL analysis pings plus a bare speaking-video stub stay in one compact Inbox note unless a stable entity target appears.
• references/2026-07-02-toms-short-chat-and-checkpoint.md — short-call routing lesson from this run; refresh the person note directly when a named-contact ping changes durable state.
• references/2026-07-04-filename-only-inventory-and-calendar.md — this run's lesson: filename-only inventory bursts should stay skipped/no-durable-update, while a lone calendar event should still be captured minimally in Inbox.
• references/2026-07-04-mixed-entity-plus-inbox-routing.md — this run's routing example for a batch that spans launch friction, bizdev, and account-admin cleanup across multiple entity notes plus one Inbox remainder.
• references/batch-note-template.md — compact note structure and delta checklist for batch backfills.
• references/2026-07-01-heartbeat-edge-backfill-batch.md — session lessons from the 2026-07-01 batch; use as the freshest routing example.
• references/2026-07-01-heartbeat-edge-backfill-batch-2.md — mixed-routing notes from the same run; shows compact Inbox + direct entity-note update in one batch.
• references/2026-07-01-heartbeat-edge-backfill-batch-4.md — continuation-batch lesson: repeat silent-speech launch/realtime rows should stay in one compact Inbox continuation note unless they add a genuinely new durable fact.
• references/2026-07-02-silent-speech-continuation-routing.md — this run's lesson: when the thread is already covered in the project note, patch that note directly instead of creating a duplicate Inbox continuation note.
• references/2026-07-02-project-note-over-inbox-routing.md — general rule from this run: if the grouped slice clearly belongs in an existing project/entity note, update that durable note in place rather than creating a duplicate Inbox continuation note.
• references/2026-07-02-silent-speech-continuation-routing.md — continuation-routing example: Silent Speech launch/realtime rows were better merged into the project note than copied into a new Inbox continuation note.
• references/2026-07-01-mixed-entity-writeback.md — mixed-batch lesson: compact Inbox plus direct entity-note update when a reusable contact fact appears.
• references/2026-07-01-numbered-read_file-pitfall.md — writeback pitfall: normalize read_file output before round-tripping into write_file.
• references/2026-07-01-partial-read-writeback.md — verification checklist for re-reading the full target span after paginated inspection.
• references/2026-07-01-telegram-promo-broadcast.md — Telegram promo-broadcast routing example: keep one-off Any.Cash / Kolo pitches in Inbox unless they map to an active owner.
• references/2026-07-01-no-duplicate-entity-writeback.md — batch lesson from 2026-07-01: if the meeting note already exists and the contact note already tracks the same thread, keep the batch writeback compact and avoid forcing a duplicate entity-note edit.
• references/2026-07-01-person-note-refresh.md — mixed-entity lesson: when a batch yields one reusable named-contact fact, patch the existing person note directly and keep the Inbox summary compact.
• references/2026-07-02-sibling-modification-writeback.md — sibling-modification lesson: re-read the target span before retrying any write after another agent/process touched the note.

Support files

• references/batch-note-template.md — compact note structure and delta checklist for batch backfills.
• references/2026-07-01-heartbeat-edge-backfill-batch.md — session lessons from the 2026-07-01 batch; use as the freshest routing example.
• references/2026-07-01-heartbeat-edge-backfill-batch-2.md — mixed-routing notes from the same run; shows compact Inbox + direct entity-note update in one batch.
• references/2026-07-01-heartbeat-edge-backfill-batch-4.md — continuation-batch lesson: repeat silent-speech launch/realtime rows should stay in one compact Inbox continuation note unless they add a genuinely new durable fact.
• references/2026-07-02-silent-speech-continuation-routing.md — this run's lesson: when the thread is already covered in the project note, patch that note directly instead of creating a duplicate Inbox continuation note.
• references/2026-07-02-project-note-over-inbox-routing.md — general rule from this run: if the grouped slice clearly belongs in an existing project/entity note, update that durable note in place rather than creating a duplicate Inbox continuation note.
• references/2026-07-02-silent-speech-continuation-routing.md — continuation-routing example: Silent Speech launch/realtime rows were better merged into the project note than copied into a new Inbox continuation note.
• references/2026-07-01-mixed-entity-writeback.md — mixed-batch lesson: compact Inbox plus direct entity-note update when a reusable contact fact appears.
• references/2026-07-01-numbered-read_file-pitfall.md — writeback pitfall: normalize read_file output before round-tripping into write_file.
• references/2026-07-01-partial-read-writeback.md — verification checklist for re-reading the full target span after paginated inspection.
• references/2026-07-01-telegram-promo-broadcast.md — Telegram promo-broadcast routing example: keep one-off Any.Cash / Kolo pitches in Inbox unless they map to an active owner.
• references/2026-07-01-no-duplicate-entity-writeback.md — batch lesson from 2026-07-01: if the meeting note already exists and the contact note already tracks the same thread, keep the batch writeback compact and avoid forcing a duplicate entity-note edit.
• references/2026-07-01-person-note-refresh.md — mixed-entity lesson: when a batch yields one reusable named-contact fact, patch the existing person note directly and keep the Inbox summary compact.
• references/2026-07-02-sibling-modification-writeback.md — sibling-modification lesson: re-read the target span before retrying any write after another agent/process touched the note.

Verification

Before finishing, confirm:

• The note path exists and contains the batch metadata.
• The source ranges / URIs are present.
• The exact checkpoint snippet was run.
• Only the listed source lines were committed.