Why
Every persona posts its OWN top-level comment, so one PR produces several. Measured on macchina#2115:
03:38 <!-- grug-teller:walkthrough -->
03:43 <!-- grug-elder-stack -->
11:58 <!-- grug-sentinel:abandoned-review -->
Three GitHub comments, three emails, hours apart, for a single review. The author has to reassemble one picture out of an inbox, and the two most useful signals (what changed, what Elder thinks) arrive as separate notifications five minutes apart.
The content is also flat. Every section renders fully expanded, so a walkthrough with a six-row file table and a mermaid diagram pushes the actual verdict below the fold - in the reported case the Elder verdict was "clear, 3 weak findings held back", which is one line buried under a diagram.
The lever is that GitHub notifies on comment CREATION, not on EDIT. One comment that every persona edits costs exactly ONE email regardless of how many personas contribute, and every later pass refreshes it silently. That is how the SaaS reviewers get one tidy thread per PR, and it needs no new infrastructure here - the upsert-by-marker pattern already exists in walkthrough/dispatch.py, it is just pointed at a per-persona marker instead of a shared one.
Two presentation defects found while measuring, both cheap:
- The inline Elder portrait is
grug_elder.png at 1.7 MB / 1024px, scaled to 46px in every comment. It is the only portrait referenced anywhere despite twelve existing.
- The GitHub App's own avatar - the round icon on every comment and every email - is a pixel-art rock, not a grug.
Acceptance criteria
- A PR with walkthrough + review + safety-net output produces ONE grug comment, and therefore ONE email, instead of three
- Each persona writes only its own section; a persona rewriting its section never alters another persona's content
- Sections render in a fixed order regardless of which persona finished first
- Long sections (walkthrough file table, diagram, evidence) are collapsible so the verdict is visible without scrolling
- A section written by an unknown persona key is preserved, not dropped
- The inline portrait is served at a size appropriate to its render box
- The App avatar is a grug rather than a rock
Out of scope
- Sentinel's "merged with a blocking check failing" notice arguably SHOULD stay a separate notification - it is an alert about something that already shipped, not review content. Decide per-persona which ones join the board rather than assuming all of them do.
- Inline review-thread comments (the per-line markings). Those are a different surface with different semantics and are not part of the notification problem.
- Any change to what the personas SAY. This is purely how it is delivered.
Size: M
Part of #707
Why
Every persona posts its OWN top-level comment, so one PR produces several. Measured on macchina#2115:
Three GitHub comments, three emails, hours apart, for a single review. The author has to reassemble one picture out of an inbox, and the two most useful signals (what changed, what Elder thinks) arrive as separate notifications five minutes apart.
The content is also flat. Every section renders fully expanded, so a walkthrough with a six-row file table and a mermaid diagram pushes the actual verdict below the fold - in the reported case the Elder verdict was "clear, 3 weak findings held back", which is one line buried under a diagram.
The lever is that GitHub notifies on comment CREATION, not on EDIT. One comment that every persona edits costs exactly ONE email regardless of how many personas contribute, and every later pass refreshes it silently. That is how the SaaS reviewers get one tidy thread per PR, and it needs no new infrastructure here - the upsert-by-marker pattern already exists in
walkthrough/dispatch.py, it is just pointed at a per-persona marker instead of a shared one.Two presentation defects found while measuring, both cheap:
grug_elder.pngat 1.7 MB / 1024px, scaled to 46px in every comment. It is the only portrait referenced anywhere despite twelve existing.Acceptance criteria
Out of scope
Size: M
Part of #707