Document contributor checks and private security reporting

.github/pull_request_template.md

@@ -0,0 +1,15 @@
+## Change
+
+Describe the problem and the resulting behavior.
+
+## Validation
+
+List checks run and remaining limits.
+
+- [ ] Relevant automated checks passed.
+- [ ] Public examples and synthetic fixtures used; no private data included.
+- [ ] Phone and desktop behavior checked for dashboard changes, including favorites where relevant.
+- [ ] Control, installation, and rollback risks described where relevant.
+- [ ] Documentation and validation claims match the evidence.
+
+Deployment or live RF/audio validation performed (if any):

CONTRIBUTING.md

@@ -0,0 +1,27 @@
+# Contributing to BlueNode
+
+BlueNode is alpha software for AllStarLink v3. Keep changes small and describe
+the operator-visible problem, the resulting behavior, and any remaining limits.
+
+1. Start a branch from the latest `main` and make one focused change.
+2. Use public example configuration and disposable fixtures. Never commit live
+   configuration, credentials, reports, recordings, or private station data.
+3. Follow [Testing](docs/TESTING.md). Run the checks relevant to the change and
+   include their results in the pull request. GitHub also requires the core,
+   dashboard, and repository checks to pass on an up-to-date branch.
+4. For dashboard changes, check phone and desktop layouts. Verify saved favorites
+   and labels across independent browsers when changing preference behavior;
+   document whether data is local to a browser or shared by the node.
+5. For controls or installation changes, include failure and rollback behavior.
+   Tests must not connect to an operating radio or change its configuration.
+
+Open a pull request with a clear description and validation evidence. Passing
+fixture tests does not establish real RF/audio behavior, hardware compatibility,
+or endurance. Keep those claims tied to actual evidence and the
+[validation status](docs/VALIDATION_STATUS.md).
+
+Report ordinary bugs using the repository's issue templates. For vulnerabilities,
+follow [Security](SECURITY.md) before sharing technical details publicly.
+
+Publishing source or merging a pull request does not authorize deployment to
+an operating node. Deployment and supervised radio acceptance are separate steps.

SECURITY.md

@@ -0,0 +1,18 @@
+# Security reporting
+
+BlueNode is alpha software. Security fixes target the current development branch;
+older alpha builds have no guaranteed backport or response-time commitment.
+
+Use GitHub's private [Report a vulnerability](https://github.com/BlueKF0OZX/BlueNode/security/advisories/new)
+form for suspected vulnerabilities. Include the affected revision, a minimal
+reproduction using synthetic data, expected and actual behavior, and likely impact.
+Do not attach passwords, tokens, complete live configuration, or unfiltered logs.
+
+If private reporting is unavailable, open an issue asking for a private contact
+channel without disclosing the vulnerability or sensitive data. Do not publish
+exploitation details in a normal issue before coordinated review.
+
+Keep the dashboard on a trusted interface or use the documented authenticated
+access setup. See [Remote access](docs/REMOTE_ACCESS.md) and
+[Remote Admin](docs/REMOTE_ADMIN.md). Test reports against an isolated fixture;
+do not probe someone else's node or trigger radio controls without permission.