Add CI build workflow and community files

GitHub Actions builds every push and PR with ESP-IDF v5.5.4 for
esp32c3 and uploads the firmware artifact. Add CONTRIBUTING, CODE_OF_
CONDUCT (Contributor Covenant 2.1), SECURITY (private reporting, stated
threat model), and issue/PR templates.

Author: Nitin Kumar

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,31 @@
+---
+name: Bug report
+about: Something is broken or behaves unexpectedly
+labels: bug
+---
+
+**What happened**
+
+A clear description of the problem.
+
+**What you expected**
+
+**Setup**
+
+- Board: ESP32-C3 Super Mini
+- Firmware version (Firmware section of the config UI, or `version.h`):
+- Radio and OS (e.g. FrSky X20S, EthOS 1.x):
+- ESP-IDF version (if you built from source):
+
+**Steps to reproduce**
+
+1.
+2.
+
+**Serial log**
+
+If you can, paste output from `idf.py monitor` around the failure.
+
+```
+(log here)
+```

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,14 @@
+---
+name: Feature request
+about: Suggest an improvement or new capability
+labels: enhancement
+---
+
+**What problem would this solve**
+
+**Proposed solution**
+
+**Notes**
+
+v1 is deliberately minimal (one board, one IMU, PARA BLE output). Ideas
+outside that scope are welcome but may be scheduled for v2.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,10 @@
+## What this changes
+
+## Why
+
+## Checklist
+
+- [ ] `idf.py build` passes
+- [ ] Tested on real hardware (board + radio), or not flight-relevant
+- [ ] New files carry the SPDX Apache-2.0 header
+- [ ] README/docs updated if behavior or wiring changed

.github/workflows/build.yml

@@ -0,0 +1,26 @@
+# Build the firmware on every push and PR so main always compiles.
+name: build
+
+on:
+  push:
+    branches: [main]
+    tags: ['v*']
+  pull_request:
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Build with ESP-IDF
+        uses: espressif/esp-idf-ci-action@v1
+        with:
+          esp_idf_version: v5.5.4
+          target: esp32c3
+
+      - name: Upload firmware artifact
+        uses: actions/upload-artifact@v4
+        with:
+          name: crowmotion-firmware
+          path: build/crowmotion.bin

CODE_OF_CONDUCT.md

@@ -0,0 +1,42 @@
+# Code of Conduct
+
+## Our pledge
+
+We as members, contributors, and maintainers pledge to make participation in
+this project a harassment-free experience for everyone, regardless of age,
+body size, visible or invisible disability, ethnicity, sex characteristics,
+gender identity and expression, level of experience, education,
+socio-economic status, nationality, personal appearance, race, religion, or
+sexual identity and orientation.
+
+## Our standards
+
+Examples of behavior that contributes to a positive environment:
+
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Focusing on what is best for the community and the project
+- Showing empathy towards other community members
+
+Examples of unacceptable behavior:
+
+- Trolling, insulting or derogatory comments, and personal attacks
+- Public or private harassment
+- Publishing others' private information without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the maintainer at **me@ni-t.in**. All complaints will be reviewed
+and investigated promptly and fairly. The maintainer is obligated to respect
+the privacy and security of the reporter of any incident.
+
+Maintainers who do not follow or enforce this Code of Conduct may be
+permanently removed from the project.
+
+## Attribution
+
+This Code of Conduct is adapted from the
+[Contributor Covenant](https://www.contributor-covenant.org), version 2.1.

CONTRIBUTING.md

@@ -0,0 +1,42 @@
+# Contributing to CrowMotion
+
+Thanks for your interest. CrowMotion is a small, focused project: a $5
+wireless FPV head tracker. Contributions that keep it small, cheap, and
+reliable are very welcome.
+
+## Getting set up
+
+Build instructions (ESP-IDF v5.5.4, ESP32-C3) are in
+[docs/BUILD.md](docs/BUILD.md). The only supported v1 hardware is the
+ESP32-C3 Super Mini plus an MPU6500 module.
+
+## Making changes
+
+- Match the existing code style: plain C, 4-space indent, concise comments
+  that explain why, not what.
+- Every source file carries an `SPDX-License-Identifier: Apache-2.0` header;
+  keep it in new files.
+- Keep the firmware self-contained: no new external dependencies without a
+  strong reason.
+- `idf.py build` must pass. CI builds every PR.
+- If a change affects flight-relevant behavior (fusion, mapping, the PARA
+  link, taps), say in the PR whether you tested it on real hardware and
+  against which radio.
+
+## Reporting bugs
+
+Open a GitHub issue using the bug template. Include your board, ESP-IDF
+version, radio and firmware (e.g. X20S / EthOS 1.x), and serial log output
+where possible.
+
+## Scope notes
+
+- v1 is deliberately minimal: one board, one IMU, PARA BLE trainer output.
+- Feature ideas beyond that (other boards, other output protocols, battery
+  operation) are v2 territory; feel free to open a discussion first so we
+  can align before you write code.
+
+## License
+
+By contributing you agree that your contributions are licensed under the
+Apache License 2.0, the same license as the project.

SECURITY.md

@@ -0,0 +1,29 @@
+# Security Policy
+
+## Reporting a vulnerability
+
+Please report security issues privately to **me@ni-t.in** rather than opening
+a public issue. You should get a reply within a few days. Coordinated
+disclosure is appreciated; a fix will be prioritized and credited unless you
+prefer otherwise.
+
+## Scope and threat model
+
+CrowMotion is a hobbyist head tracker, not a hardened product. Current stance:
+
+- The config web UI and OTA endpoints are only served to clients on the
+  device's own WiFi hotspot (WPA2, per-device SSID, password changeable in
+  the UI). They are intentionally not reachable from the home network the
+  device may join for update downloads.
+- OTA images are not cryptographically signed and secure boot is not
+  enabled. Anyone who can join the hotspot can flash the device. Mitigations:
+  the hotspot only runs when explicitly enabled (quad-tap, radio
+  disconnected), and bootloader rollback restores the previous firmware if a
+  new image fails to boot.
+- The BLE PARA trainer link is unencrypted and unauthenticated by protocol
+  design (FrSky PARA); anyone in radio range could pose as a trainer source.
+  This matches every other PARA implementation.
+
+Reports about weaknesses within this stated model (e.g. bypassing the
+hotspot-only restriction, crashing the device with crafted HTTP/BLE input)
+are very much in scope.