+ Start from GitHub App setup, then keep the first rollout + narrow until the repo owner has verified permissions, webhook delivery, and public copy. +
+Metadata: read, Pull requests: read, and{" "}
+ Issues: write. Add Checks: write only when Context or Gate check
+ runs are enabled for the repository.
+ issues, issue_comment,{" "}
+ pull_request, and repository.
+ + Treat launch as a controlled trust review. Do not enable public comments or required checks + until every step below has a maintainer-visible result. +
++ Maintainer commands should be treated like privileged review actions. Use them to fetch + context on demand, not to create always-on public scoring. +
++ If a command would include private reviewability, private scoreability, duplicate-risk, or + contributor-history context, the result must stay in maintainer-visible surfaces. Public + replies should only contain sanitized actions a contributor can safely use. +
+ ++ Preview every public output path before enabling it. The same public-safety boundary applies + to GitHub comments, issue bodies, PR bodies, extension-visible public panels, and copied + snippets. +
++ For the full boundary, keep Privacy & security as + the source of truth. For AI-written text, use the{" "} + AI summaries policy before posting generated copy. +
+ ++ The extension is a maintainer review aid. It should make state and scope obvious instead of + implying that a contributor or public viewer can see private packets. +
++ UI, frontend, browser-extension, or GitHub-overlay pull requests need maintainer-reviewable + screenshots or a short recording that shows the relevant states. A checked template box is + not enough evidence. +
+ ++ A healthy installation should leave an audit trail that maintainers can reason about without + exposing repository source or contributor secrets. +
++ Keep GitHub CI/check state separate from reviewer and mergeability state. A green CI run or + advisory Context check can prove automation completed, but it does not prove the PR is + acceptable, non-duplicative, or safe to merge. Human maintainers still decide whether the + contribution fits the repo, issue, and subnet goals. +
++ If the repo enables Gittensory Gate, document which blockers are enforced + and why. Otherwise, treat Gittensory output as reviewer context only. +
+ ++ Maintainers should request changes or close PRs that misuse Gittensory output. The tool is a + contribution operating layer, not a guarantee that work deserves merge. +
++ Continue with Maintainer workflow for daily PR + review, Troubleshooting for install diagnostics, and{" "} + Browser extension for overlay behavior. +
+Ya(v0RhH+(TcT6nT`r 4Q?iR}u
zkb$)Wn9wX07`?~~s!dheAd0id>`j-mxRvn?UZCV4ts}ek5V9Q`7fS%eXgl!(0f&qK
zc?*a;4Hpfs-d@eI=@lnNN!8)0(=b0>XukekcMLT0BeA#LZii;`ASLLouV-gxRjD<<
zAB!?mqm%lL1~;L7kRqp`@M)BeQ9E&Yo{1>>QYE_FUO&lZfM34k{bMy@fN
z5$-3d80k?D&71k;+C^0rl@-e0OAnI$V)MOqug!=lzYmu%j-h-onEzbDe3i;AjRBA}
zgCcHjZWBZTB`k9S
di+l6Ay9TBm?d>cUS7PZG9QB=jrHJra-MCNM+Jt_a#=L1-N0FA)
zn|F)3R|*a+n51#3z7uZm3=NHX3;5=fdp-=)F*Cp)%E0*&W%5(4|Djxa