PR review feedback silently drops maintainer reviews (OWNER/MEMBER authorAssociation filtered)

[mindfn]

Problem

PR review feedback notifications (F140 ReviewFeedbackTaskSpec) silently drop all reviews from users with authorAssociation = OWNER or MEMBER. This means maintainer reviews are never delivered — only bot/external reviews trigger notifications.

Observed behavior

• Thread thread_mqomaaf0htcblmut (PR fix: batch fix #991 + #966 + #992 + #995 + #1002 + Skill tab UI consistency #993): chatgpt-codex-connector[bot] reviews delivered ✅, maintainer reviews silently dropped ❌
• Co-creator had to manually trigger notifications for every maintainer review

Root cause

ReviewFeedbackTaskSpec.ts:508-534 applies F168 Repo Inbox's decideDelivery() policy to PR review feedback:

// F168 Phase B: apply delivery policy — OWNER/MEMBER activity is silent-log
const decision = decideDelivery({
  state: 'in_progress',
  eventKind: 'pr.review_submitted',
  authorAssociation: c.authorAssociation,
});
if (decision === 'silent-log') return false;  // ← maintainer review silently dropped

community-delivery-policy.ts:25,59:

const MAINTAINER_ASSOCIATIONS = new Set(['OWNER', 'MEMBER']);
// Rule 2: maintainer-authored activity is silent regardless of case state
if (MAINTAINER_ASSOCIATIONS.has(input.authorAssociation)) {
  return 'silent-log';
}

Why this is wrong

Two contexts use decideDelivery() with opposite requirements:

Context	Purpose	Maintainer activity should?
Repo Inbox (F168)	Monitor community contributions; own team's activity = noise	silent-log ✅
PR Review Feedback (F140)	Cat waiting for PR review; maintainer review = exactly what's awaited	wake-owner ❌ wrong

Existing correct filter

ReviewFeedbackTaskSpec already has isEchoComment / isEchoReview — these correctly filter self-authored echoes (the cat's own comments posted via GitHub API). This is the right granularity: only filter yourself.

Proposed fix

Remove the decideDelivery() call from ReviewFeedbackTaskSpec.ts (lines 508-534, both comment and review filtering). PR review tracking is opt-in (cat explicitly registered) — all reviewer feedback should be delivered, regardless of reviewer's repo association. The existing isEchoComment / isEchoReview + isNoiseComment filters are sufficient.

Alternatively, add a context: 'repo-inbox' | 'pr-tracking' parameter to decideDelivery() and only apply OWNER/MEMBER silencing in repo-inbox context.

Files

• packages/api/src/infrastructure/email/ReviewFeedbackTaskSpec.ts — lines 508-534 (remove decideDelivery calls)
• packages/api/src/domains/community/community-delivery-policy.ts — reference only (policy itself is correct for Repo Inbox)

[zts212653]

Confirmed as a valid bug and accepted. The local source matches the report: ReviewFeedbackTaskSpec applies the F168 decideDelivery() maintainer-silence policy before delivering F140 PR review feedback, while F140 is the opt-in PR tracking channel where maintainer review decisions are exactly the signal the owner is waiting for.

Maintainer triage:

• Useful to us: yes. Dropping OWNER/MEMBER reviews breaks merge-gate and review routing reliability.
• Existing anchor: this belongs to F140 PR Signals / Review Feedback; the conflict is with F168 Repo Inbox delivery semantics being reused in the wrong context.
• Preferred architecture: keep OWNER/MEMBER silence in Repo Inbox/community activity, but do not apply that policy to PR tracking. PR review feedback should only filter self-authored echoes/noise.
• Merge/intake worthiness: yes, if covered by regression tests for OWNER/MEMBER review decisions and comments still being delivered in PR tracking.
• Debt/risk: low-to-medium implementation risk, high operational impact if left unfixed.

Since you are a collaborator and the issue already includes a concrete fix direction: do you plan to send a PR, or should we route an internal fix thread?

[砚砚/gpt-5.5🐾]

[zts212653]

Maintainer clarification: the acceptance here is narrower than "remove decideDelivery() from ReviewFeedbackTaskSpec".

The fix must also preserve precise self-echo filtering for shared-owner GitHub accounts. In our deployment, Cat Café automation may post through the same maintainer GitHub login that a human maintainer uses. So PR tracking must distinguish:

• manual maintainer feedback from the shared OWNER/MEMBER login => deliver to the tracking thread
• Cat Café self-authored trigger/comment/review posted through that same login => suppress as echo

selfGitHubLogin / gh api /user is still useful, but login-level filtering is not sufficient for this deployment model. The preferred shape is provenance-backed filtering: when Cat Café posts outbound GitHub feedback, record the returned comment/review id plus repo/pr, body hash, catId/threadId/invocationId, then have F140 polling skip only those recorded outbound items. A context parameter on decideDelivery() would separate Repo Inbox from PR tracking, but by itself it does not solve the shared-owner self-echo problem.

Regression coverage should include at least:

• OWNER manual review decision delivered
• MEMBER manual review decision delivered
• OWNER/MEMBER manual PR comment delivered
• Cat Café self-authored trigger/comment/review under the same login suppressed
• chatgpt-codex-connector[bot] real review delivered
• setup-only bot conversation noise still suppressed
• F168 Repo Inbox OWNER/MEMBER activity still silent

[砚砚/gpt-5.5🐾]