docs: clarify GitHub App permissions & events in DEPLOY.md#3
Conversation
The GitHub App walkthrough in DEPLOY.md §2b described permissions as a single prose line and told readers to subscribe to the "Issue comment" event without explaining that it is gated behind the Issues permission — so the checkbox never appears until Issues: Read-only is granted. It also specified Contents: Read-only, which silently breaks the /remember and /feedback memory commits (those need Contents: write). - Add a Repository permissions table (Metadata, Pull requests, Contents, Issues) with access level, rationale, and when each is needed. - Add a Subscribe to events table (Pull request, Issue comment). - Call out that the events list is filtered by the selected permissions, and that "Issue comment" specifically requires the Issues permission. - Note the permissions-before-events ordering and the per-installation re-approval prompt triggered by editing permissions. - Add a minimal-vs-full summary and point section 2c at the new tables.
Mimir review — 🟢 No blocking issuesSolid documentation improvement. The new tables make the GitHub App permissions/events setup concrete and the "Minimal vs full" breakdown is helpful. The explanation of the GitHub quirk (Issue comment event gated by Issues permission, not Pull requests) saves future deployers from the common frustration. All env references (ALLOWED_OWNERS, POST_NITS, etc.) are consistent with the codebase and Findings: 0 critical · 0 major · 0 minor · 0 nit 💰 Review cost: $0.0048 — primary |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the deployment documentation in DEPLOY.md to provide detailed tables and instructions for configuring GitHub App repository permissions and event subscriptions. The review feedback suggests using the official GitHub permission terms ("Read-only" and "Read and write") instead of "read" and "write" in the "Minimal vs full" summary section to maintain consistency with the GitHub UI and the preceding tables.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
2 participants
What
Rework the GitHub App setup in
DEPLOY.md§2b so the App can be configured correctly on the first try, with explicit Repository permissions and Subscribe to events tables.Why
The previous walkthrough had two traps that are easy to hit and hard to diagnose:
/review,/remember,/feedbackPR commands) but that event does not appear in the list until the Issues permission is granted — GitHub filters the events by the permissions you selected. Without knowing this, the checkbox simply isn't there.Contents: Read-onlysilently breaks memory. §2b specified Contents read-only, but/rememberand/feedbackcommit memory files to.mimir/memory/*.md, which requires Contents: Read and write. With read-only the commands fail quietly with a 403.Changes
Docs-only; no code changes.