docs(contributing): ask security and integration PRs for practical scenarios (#224)

Adds a 'Before a security or integration PR' section to CONTRIBUTING.md, a
security question block to the PR template, and a trust-model bullet to
SECURITY.md's scope notes. Additive only; existing scope text is unchanged.

Co-authored-by: v-openrig-build <[email protected]>

.github/PULL_REQUEST_TEMPLATE.md

@@ -12,6 +12,10 @@
 
 <!-- Design choices, edge cases you did not cover, places a reviewer should look hardest. Empty is a fine answer. -->
 
+## If this is security-related
+
+<!-- Exploitable? Report it privately first (SECURITY.md). Otherwise: how does this go wrong for someone using OpenRig as designed (your own machine or a trusted private network), with evidence? Who causes it, and how do they reach the install? What does the change cost everyone else? See CONTRIBUTING.md. -->
+
 - [ ] One concern per PR; no version bump; no `CHANGELOG.md` edit
 - [ ] Tests added or updated where the change is testable
 - [ ] I listed the checks I ran, their results, and any checks I could not run

CONTRIBUTING.md

@@ -17,6 +17,27 @@ change in with the least friction on both sides.
 - **Questions:** use [Discussions › Q&A](https://github.com/mvschwarz/openrig/discussions/categories/q-a),
   not an issue.
 
+## Before a security or integration PR
+
+OpenRig connects your coding agents to each other: shared context, messaging, coordination and long-running seats.
+It's designed for your own machine or a trusted private network, for you and people you trust, not for the open
+internet. It doesn't try to act for you in the outside world; your agents already have tools for that.
+
+**Security-related PRs.** If you've found something exploitable, report it privately first (see
+[SECURITY.md](SECURITY.md)) rather than in a public PR. For hardening changes, tell us in the PR description:
+
+- the scenario: how this goes wrong for someone using OpenRig as it's designed to be used, and the evidence you have
+- who or what causes it, and how they reach the install
+- what the change costs everyone else: a refusal, an extra step, a new setting
+
+We look at the finding and the fix separately. We may agree with a finding and fix it differently, or decide the fix
+costs more than it protects. If the answers are missing we'll ask once, and close the PR with thanks if they don't
+come.
+
+**Integrations with other tools or projects.** Open an issue or an Ideas Discussion and wait for a maintainer's yes on
+scope before you build it; an issue on its own isn't a yes. Often the best home for an integration is your own
+repository, and we're happy to link to it.
+
 ## Setting up
 
 Node `^22 || ^24` and a working `tmux` are required. Then:

SECURITY.md

@@ -39,6 +39,10 @@ could do. A proof of concept is welcome; a working exploit against a third party
 
 ## Scope notes
 
+- OpenRig is designed for your own machine or a trusted private network, for you and people you trust, not for the
+  open internet. We assess reports by their practical impact on a user in that setup. Exposing an install to the open
+  internet isn't a supported deployment. OpenRig's own gateway integrations with outside services, such as Slack, and
+  anything that lets an untrusted party reach the daemon or an agent are in scope.
 - OpenRig assumes the machine and the accounts it runs under are trusted by their owner. Reports
   that require a hostile local user with the same account are still welcome but are unlikely to be
   treated as high severity.