+ 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. +
+