Deploy MQTT test backend with private viewer and Gitea CI/CD

docs/sprints/06-remote-broker.md

@@ -0,0 +1,68 @@
+# Sprint 6 — Remote test-broker deployment and connectivity
+
+Status: proposed; not implemented. Read [the plan](../PLAN.md), [sprint index and shared rules](../SPRINTS.md), and [README](../../README.md).
+
+
+### Goal and scope
+
+Deploy the locally validated broker as a separate remote test instance and verify outbound-only local clients against it.
+
+### Deliverables and likely files
+
+- Environment-specific deployment examples with placeholders and final pinned digest.
+- `docs/DEPLOYMENT.md` complete remote certificate/firewall/operations runbook.
+- Remote entries in `docs/VERIFICATION.md`; no secrets committed.
+
+### Tasks
+
+1. Obtain OS/CPU, Docker/Compose support, available resources/port, DNS/SANs, access method and certificate renewal constraints without requesting secret values in chat.
+2. Inspect current listeners/services read-only; choose an isolated instance/port and validate artifacts locally before remote mutation.
+3. Prepare test-only credentials/ACLs, certificate provisioning/renewal, data/config mounts, health check, ownership, bounded logs and firewall requirements.
+4. Present exact remote operations and obtain any required authorization. Then deploy only the authorized test instance.
+5. Verify hostname/certificate/auth/ACL behavior from the development computer, simulator exchange, restart/session recovery and health.
+6. Document backup/update/rollback with compatible persistence snapshot and renewal verification. Browser viewer remains local.
+
+### Dependencies and required inputs
+
+Sprint 5 local verification; remote details/access and explicit authorization for remote changes. If unavailable, finish locally reviewable artifacts and report remote tests blocked.
+
+### Acceptance criteria
+
+- Separate remote TLS instance works without changing production listeners/configuration or requiring inbound development-computer access.
+- Local backend/simulator exchange messages and show them in logs/viewer through outbound connections.
+- Remote security and restart checks have actual evidence; runbook is complete.
+- If access is unavailable, the sprint is explicitly incomplete for deployment, not marked verified.
+
+### Automated checks
+
+Local artifact validation before deployment; remote health and focused MQTT integration scenarios after authorization. Repeat checks only where remote environment changes behavior.
+
+### Manual verification
+
+Inspect remote listening ports, certificate chain/SAN, log bounds, access controls and persistence. Walk through documented update/rollback steps using the test instance where authorized.
+
+### Risks and unresolved decisions
+
+Unknown remote environment, existing port conflicts, certificate renewal method and network restrictions. Native deployment is an explicit alternative if Compose is unsuitable.
+
+### Mandatory end-of-sprint testing and completion gate
+
+After implementing this sprint, run its automated checks and manual verification above. Inspect the final changes for correctness, scope, secret exposure, and compatibility with completed sprints. Fix failures and rerun affected checks before declaring completion.
+
+Record the exact commands/checks, actual outcomes, verification environment, and each acceptance criterion as PASS, FAIL, or BLOCKED. Include applicable regression checks for previously completed behavior. A skipped/unavailable required check is BLOCKED, never PASS; do not claim full sprint completion while required checks fail or remain blocked. Do not run unrelated or production-project tests.
+
+Report the results and remaining limitations to the user. Wait for authorization before the next sprint unless continued execution was explicitly authorized. Even with permission to continue, do not bypass this verification gate.
+
+### Copy-ready implementation prompt
+
+```text
+Implement Sprint 6 only in /home/ryan/Media/Code/Code/robot-market/test-mqtt-5 after authorization. Read applicable AGENTS.md, /home/ryan/.codex/RTK.md, README.md, docs/PLAN.md and docs/sprints/06-remote-broker.md. Use rtk. Existing projects, production listeners and credentials must remain untouched.
+
+First obtain/inspect remote OS, CPU, Docker/Compose support, free test port, DNS/certificate constraints and access method without exposing secrets. Prepare and locally validate the dedicated TLS Mosquitto deployment from prior sprints, pinned by compatible digest, with separate test credentials, per-device ACLs, persistence, restrictive secret permissions, bounded logs and authenticated health check. Complete certificate issuance/renewal, firewall, backup/update/rollback procedures. Present concrete remote operations before requesting any still-required authorization. Do not treat documentation authorization as deployment authorization.
+
+Only after required authorization, deploy the isolated remote test instance and verify outbound-only local backend/simulator connectivity, hostname validation, bad credentials/ACL behavior, restart and health. Keep the browser viewer on local loopback. If access/details are missing, preserve complete local artifacts and report remote work blocked/unverified. Update deployment/verification docs, report evidence by environment and wait.
+
+ESP32 reference: read docs/PLAN.md section 6.1 for the supplied Esp32MqttConfig. It is connection configuration, not a payload schema or a blocker for Go implementation. Preserve the proposed Go test contracts. Device-specific MQTT 5 selection depends on the actual C library/build/init; inspect TLS/CA handling, role-specific credentials and single publish_topic limitations during device integration. Do not modify existing C projects. Separate MQTT 3.1.1 payload interoperability from native MQTT 5 feature evidence.
+
+Mandatory completion gate: after implementing this sprint, run its listed automated and manual checks plus relevant regression checks, inspect the final changes for correctness/scope/secrets/compatibility, fix failures and rerun affected checks. Report exact checks, real outcomes, environment, and every acceptance criterion as PASS/FAIL/BLOCKED. Missing required checks are BLOCKED, never a pass. Do not mark the sprint complete with unresolved failures/blockers or bypass verification when continuing to another sprint.
+```