Four automated loops drive every SiftPulse decision: continuous PR review, new-issue triage, a daily stale-PR nudge cron, and a weekly digest email. Here is what each one does and how it shows up in your dashboard.
Every time a pull request opens, reopens, or pushes a new commit, your code-hosting platform (GitHub, GitLab, or Bitbucket) sends a signed webhook to SiftPulse. We verify the HMAC signature, fetch the unified diff and PR metadata, and strip content matching known secret patterns — private keys, .env assignments, credential regexes — before assembling the review prompt.
routes/github.js (or the GitLab / Bitbucket equivalent). Signature verified, installation resolved.repo_custom_prompts merged into the review prompt.POLSIA_AI_BASE_URL (zero-retention model terms; see /security).suggestion blocks for mechanical findings (style, null checks, typos, unused vars) when .siftpulse.yml has suggestions: true.pr_review_events with verdict, blocker/suggestion/nit counts, summary excerpt, and the comment ID for re-review reconciliation.Every consecutive push triggers an incremental re-review that diffs against the last reviewed SHA via pr_review_state so the agent only reports new blockers rather than re-spamming earlier findings.
When a new issue opens on a watched repo, routes/triage.js dispatches the title, body, and a recent-issue embedding lookup to the triage agent. The agent returns a structured verdict that the webhook handler writes back to GitHub / GitLab / Bitbucket.
issues / issue-open events.priority/p1, type/bug — opt-outs in .siftpulse.yml triage_labels_disabled).services/issue-pr-routing.js and estimates which open PRs are most likely to resolve the issue — logged to issue_pr_routing_events.Every triage run is logged in triage_events with repo, issue number, priority, labels, duplicate verdict, and the comment ID so the dashboard "Issues" tab can replay the exact reasoning.
SiftPulse keeps PRs alive. A daily cron job (declared under polsia.toml [[crons]] and running as an isolated node process in jobs/) scans every watched repo for open PRs that have been idle past their configured threshold, drafts a short nudge summary, and stages it for human sign-off.
jobs/nudge-stale-prs.js — single node invocation, fresh checkout, must exit cleanly.pr_nudge_events with idle hours, draft summary, and target PR.pending_nudge_signoffs with a 72-hour TTL token; a one-tap email is dropped to the installer.routes/signoff.js (token-based, no auth) — outcomes are logged to nudge_signoff_events for later ROI tracking.> unstuck commit and, if found, logs a pr_unstuck_events row so the dashboard can plot "% of nudged PRs that moved within 7 days."Installations can opt out per-installation via the digest_unsubscribed column — but nudge cron control lives on the dashboard "Cron settings" page, not in the digest flag.
Once a week, a cron emits a digest to every installation. The mailer reads the previous seven days of pr_review_events and suggestion_events, computes the headline numbers (PRs reviewed, suggestion-block accept rate, merge-to-deploy median when Render is connected), groups by repo, and sends one transactional email via the POLSIA_EMAIL_PROXY_URL.
polsia.toml [[crons]]; per-installation iteration.digest_sends on the (installation_id, week_start) unique key — prevents accidental double-sends on a cron retry.digest_sends for aggregate ROI tracking./activity mirrors the same data publicly so anonymous visitors can compare against their own weekly totals.Installations can opt out via the digest_unsubscribed column on github_installations (the same flag governs the in-app digest panel). Sign-off and digest emails both support /unsubscribe one-tap links.