Ways to contribute
You don't have to write a single line of C to make this project stronger. Pick the lane that fits.
| Lane | What it looks like |
|---|
| Code | New modules, bug fixes, hardening the engagement gate, tests. Python (FastAPI) backend, Ink/React TUI, React/Vite web UI. |
| Documentation | Setup guides, the build-your-own BOM, module how-tos, fixing anything that's wrong or unclear. |
| Hardware | Build the deck from the BOM, report what worked and what didn't, test new SDR / GPS / mesh peripherals, photograph your build. |
| Field reports | You ran it on a real authorized engagement — tell us what held up, what was missing, what you wish it did. |
| Triage | Reproduce issues, confirm bugs, review pull requests, help newcomers get a deck booting. |
| Responsible disclosure | Found a security flaw in the tooling itself? Report it privately first — see below. |
The Code of Ethics
Every serious security tool is dual-use — the Charter says so plainly. The capability is the capability; what separates a profession from a crime is the posture of the person at the keyboard. Contributing here means committing to that posture. By opening a pull request you affirm the following.
- Authorization before action. I use these tools only against systems I own or am explicitly authorized — in writing — to test.
- Honest scope. I keep my engagement scope truthful and narrow. I do not expand it to reach targets I was not authorized to touch.
- Accountability over deniability. I keep records. I will not strip, disable, or circumvent the audit trail, the engagement gate, or the kill switch — not in my own use, and not in code I contribute.
- Capability, not weaponry. I will not contribute features whose primary purpose is to evade detection, attack non-consenting third parties, or cause indiscriminate harm.
- Responsible disclosure. When I find a vulnerability — in these tools or in a system I'm authorized to test — I disclose it responsibly and give the owner reasonable time to fix it before going public.
- Respect for privacy. Captured data — handshakes, traffic, locations, signals — is sensitive. I minimize what I collect and never retain or publish other people's data without cause and consent.
- Teach, don't enable. I share knowledge to make defenders better, not to lower the bar for people who intend harm.
- Own the outcome. If I wouldn't want the signed audit trail of what I did read back to me in a room with the client and their lawyer, I don't do it.
This is published verbatim in the repository as CODE_OF_ETHICS.md so it travels with the code.
What we won't merge
- Anything whose only purpose is to defeat the engagement gate, the scope check, the kill switch, or the audit / attestation trail.
- Stealth / anti-forensics features dressed up as "operational security" but really built to hide unauthorized activity.
- Targeting, mass-exploitation, or credential-harvesting tooling aimed at non-consenting third parties.
- Anything that ships secrets, real client data, or another person's captured traffic in the diff.
How to submit
- Fork the repo and create a branch — feat/<thing> or fix/<thing>.
- Keep changes additive and backward-compatible where you can; the gate and audit paths are load-bearing — don't route around them.
- Add tests for new behavior, and run the existing suite before you push.
- Open a pull request describing what changed and why. Opening it affirms the Code of Ethics above.
- For security issues, do not open a public issue — see disclosure below.
Full mechanics live in CONTRIBUTING.md.
Reporting a security issue
Found a flaw in the tooling itself — a way to bypass the gate, forge an attestation, or escalate beyond an authorized scope? Report it privately by opening a GitHub security advisory rather than a public issue. We'll work the fix with you and credit you when it ships.
Build wisely.
