feat(home-feed): instrument scheduler + sequence with emitFeedEvent [JARVIS-512]

[alex-nork]

Summary

Third step of JARVIS-512, stacked on #25584 and #25586 (both merged). Wires emitFeedEvent into the first batch of background-job completion points so real assistant activity starts showing up in the home feed's activity log.

What lands

scheduler.ts — 4 emit points

Branch	When	dedupKey
notify mode, one-shot	After notifyScheduleOneShot + completeOneShot	schedule-notify-oneshot:<jobId>
notify mode, recurring	After completeScheduleRun(ok)	schedule-run:<runId>
execute mode, task	After completeScheduleRun(ok) in the run_task: branch (gated on !job.quiet)	schedule-run:<runId>
execute mode, message	After completeScheduleRun(ok) in the plain-message branch (gated on !job.quiet)	schedule-run:<runId>

Execute-mode emits mirror the existing notifySchedule gating on !job.quiet — users who opted out of push notifications also opt out of activity log entries. Notify-mode emits always fire because notify-mode IS notification by design.

A small emitScheduleFeedEvent helper at the bottom of the file wraps emitFeedEvent with fire-and-forget .catch handling so a schema error or writer hiccup can never interrupt the 15s scheduler tick.

sequence/engine.ts — 1 emit point

After recordSend in processEnrollment, keyed on sequence-step:<enrollmentId>:<stepIndex>. Placed after the step.requireApproval gate so draft-only steps (which pause without sending) don't show up in the log — only actual sends produce a real signal.

Loop / runaway-cost audit (per the concern raised in-thread)

• No feedback loop: no daemon-side subscriber to home_feed_updated was found in the audit (only the macOS client consumes it). Emits can't trigger more background work.
• No unguarded high-frequency emit: scheduler ticks every 15s but only emits when a schedule actually fires (bounded by user-defined RRULE/cron cadence). Sequences are capped at 10 enrollments/tick.
• No LLM cost multiplier: the reflection/gmail-digest producers were deliberately not instrumented — they're the activity log's consumers, not sources. Double-emitting there would spam SSE and inflate the per-source action cap without adding signal.
• Bounded volume: per-source action cap (MAX_ACTIONS_PER_SOURCE = 20, from feat(home-feed): action append semantics + per-source cap [JARVIS-512] #25584) keeps total source: "assistant" actions at ≤20 most-recent. Older emits fall off deterministically.

Deferred to follow-ups (with specific reasons)

• Gmail watcher event processing (watcher/engine.ts:222) — loop-risk: the LLM event-processing path could itself re-trigger watcher polling if we're not careful. Needs its own audit.
• Manual task-runner completion (task-runner.ts:102) — needs a dedup story with the scheduler layer so schedule-triggered tasks don't double-emit (scheduler AND task-runner both firing).
• Skill runner completion — no single well-defined "skill done" hook in the codebase yet; instrumentation would be sprinkled and hard to reason about.

Testing

• bun run typecheck — clean
• bun run lint — clean
• bun test src/home/ — 144/144 pass (regression check; no new tests in this PR — see below)
• Manual smoke test on the branch: trigger a schedule and observe a feed entry land

No new unit tests in this PR. The scheduler and sequence modules don't have existing test harnesses (no src/schedule/__tests__, no src/sequence/__tests__) — standing one up just for these pass-through emits is significant scope creep. The emitFeedEvent helper itself has thorough unit coverage in #25586. Manual smoke after merge will verify end-to-end wiring.

🤖 Generated with Claude Code

---

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 3 additional findings.