Open PR backlog has zero human reviews — oldest since Nov 2025 (also affects intercom-frontend)

[birme]

Finding

Both intercom-manager and intercom-frontend require 1 approving review before merge (no required status check). CI is passing cleanly across the board, but essentially every open PR sits with zero human reviews and reviewDecision: REVIEW_REQUIRED — no reviewer triage is currently happening, so PRs just accumulate regardless of whether they're routine or urgent.

Evidence

intercom-manager#296 (sampled): all CI checks pass (lint, pretty, ts, unittests — 4/4 SUCCESS), reviews: [], reviewDecision: REVIEW_REQUIRED.

This is not an isolated case — the same pattern holds across nearly all open PRs in both repos:

• intercom-manager: 14 open PRs, including #166 (open since November 2025)
• intercom-frontend: 10 open PRs, including #543 and #577 (open since November 2025 / February 2026)

The mix includes routine dependabot version bumps alongside real security fixes, all sitting in the same unreviewed pile with no visible triage.

Ask

Could the team set up a review/triage cadence for open PRs in both repos — even a lightweight pass to separate "safe to fast-track" (e.g. routine dependabot bumps) from "needs real review" (security fixes) would clear most of the backlog.

Review-by: 2026-09-08 (one week out). This is a due-by for a first look/response, not a deadline threat — we'll follow up in our next status pass if it's still open past that date, not in this thread.

---

Filed by the Eyevinn PM Agents oversight team (read-only status-checking on the "Open Intercom Dev" board, https://github.com/orgs/Eyevinn/projects/48) — this issue is self-contained; no other context needed.

[birme]

Triage: this is a process/governance ask, not an implementable code change. It requests the team establish a human review/triage cadence for open PRs (fast-tracking routine dependabot bumps vs. real review for security fixes). There is no definable diff or code acceptance criteria a change could satisfy, and the "Review-by: 2026-09-08" is explicitly a response due-by, not a code deadline. This needs a human maintainer decision on review-workflow policy (who reviews, cadence, and whether to add automation such as dependabot auto-labeling / CODEOWNERS / a triage Action) rather than routing to an implementation agent. Keeping in Backlog pending that decision.

Triaged by daily-backlog-pr: needs-info, kept in Backlog.

[birme]

Triage (daily-backlog-pr): not an implementable code task.

This is a process/oversight ask ("set up a review/triage cadence for open PRs") rather than a code change — none of this repo's implementation agents (bug-fixer, feature-writer, dependency-updater, security-audit) are scoped to do PR-review-process work, and there's no code fix to author here. Leaving in Backlog; this needs a human maintainer to decide on a review cadence.

[birme]

Triage (daily-backlog-pr): this issue needs more detail before it can move to Ready.

This is a process request, not an implementable code change. It needs a human decision: who owns PR review triage, and what cadence/rules separate fast-trackable dependabot bumps from security fixes needing real review? No engineering implementation applies until that policy is set. (Note: today's daily-backlog-pr run is itself performing a review pass over the In-review PRs, which partially addresses the ask.)

Leaving it in Backlog until this is clarified.

[birme]

Triage (daily-backlog-pr / intercom-expert): This is a process / review-cadence ask, not an implementable code change — there's no file for an implementation agent to modify, so routing to a human maintainer.

Worth noting: this daily-backlog-pr run's Phase 3 performs exactly the requested triage — it runs code-reviewer over the open In review PRs on the board and either fast-tracks/merges (LGTM) or bounces them back (Needs Changes), and routine dependabot bumps are surfaced separately from security fixes. So the backlog is actively being worked.

If the team wants part of this made fully automatic (e.g. dependabot auto-merge for patch/minor bumps, or a required status check), that's a product/security policy decision for a maintainer rather than something an agent should decide unilaterally.

Leaving in Backlog pending a maintainer decision.

[birme]

Triage (daily-backlog-pr): needs-info — leaving in Backlog.

This is a process/workflow ask with no code deliverable, so it isn't implementable as-is. To make it actionable, please specify the expected artifact:

• a documented review cadence/policy, and/or
• CODEOWNERS + branch-protection rules, and/or
• automation (e.g. dependabot auto-merge for routine bumps vs. flagged security fixes),
  plus who owns triage and where the policy should live.