43 lines
3.9 KiB
Markdown
43 lines
3.9 KiB
Markdown
# Ordered sprints and implementation prompts
|
||
|
||
Status: **Sprints 1–3 complete with local/remote MQTT 5 checks; Sprint 4 complete with a live browser check; Sprint 5 implemented with restart verification blocked; Sprints 6–7 awaiting authorization**.
|
||
|
||
Read [PLAN.md](PLAN.md) for the design and [../README.md](../README.md) for boundaries. Sprints 1–5 are implemented; Sprint 5 has an unresolved verification gate. Each remaining prompt is a future handoff and requires authorization for that sprint.
|
||
|
||
## Execution rules
|
||
|
||
- Work only in `/home/ryan/Media/Code/Code/robot-market/test-mqtt-5`. Existing projects are read-only references.
|
||
- Read applicable AGENTS.md files and `/home/ryan/.codex/RTK.md`; prefix shell commands with `rtk`.
|
||
- Implement only the authorized sprint. Report acceptance criteria, actual checks/results, limitations, and remaining work, then wait unless continuing across sprints was explicitly authorized.
|
||
- Do not modify production brokers, credentials, listeners, device repositories, or data. No dangerous device commands.
|
||
- Record verification environment accurately. A skipped check is not a pass. Local simulator evidence is not hardware evidence.
|
||
- Keep documentation practical: update the existing plan/README and targeted contract/runbook/checklist files; do not add repetitive status reports.
|
||
- Proposed file paths are guidance. Keep packages small; do not create abstractions merely to match a directory list.
|
||
- Recheck dependency pins before first installation. Explain material deviations. Do not download SDKs or install tools unnecessarily.
|
||
|
||
## Sprint files
|
||
|
||
Each sprint is stored in its own file with tasks, deliverables, dependencies, acceptance criteria, automated checks, manual verification, risks, a copy-ready prompt, and a mandatory end-of-sprint test/check gate.
|
||
|
||
| Sprint | Document | Status |
|
||
| --- | --- | --- |
|
||
| 1 | [Go foundation, configuration, contracts and event model](sprints/01-foundation.md) | Complete; local checks PASS |
|
||
| 2 | [Server broker deployment package](sprints/02-local-broker.md) | Complete; artifacts, server runtime and external connectivity verified |
|
||
| 3 | [MQTT 5 backend, simulator and visible message flow](sprints/03-backend-simulator.md) | Complete; unit/race, real CLI and remote TLS/plaintext checks PASS |
|
||
| 4 | [Small Go-served browser viewer](sprints/04-browser-viewer.md) | Complete; local/race checks and live browser verification PASS; ESP32 hardware remains untested |
|
||
| 5 | [Reliability scenarios and compatibility evidence](sprints/05-reliability.md) | Implemented; ACK/reliability checks PASS, restart verification BLOCKED |
|
||
| 6 | [Remote test-broker deployment and connectivity](sprints/06-remote-broker.md) | Not started |
|
||
| 7 | [Conditional real-device compatibility](sprints/07-device-compatibility.md) | Not started |
|
||
|
||
## Mandatory completion policy
|
||
|
||
After every sprint, execute its tests and manual checks, review final changes, fix failures, rerun affected checks, and report acceptance criteria with actual evidence. Missing required verification is BLOCKED, not passed. Do not mark an unverified sprint complete or bypass this gate when authorized to continue across sprints.
|
||
|
||
## ESP32 connection reference
|
||
|
||
The supplied `Esp32MqttConfig` configures connectivity, not payloads. Go backend/simulator work can proceed without a C serializer. Device integration must check the C library/version, TLS/protocol selection and whether its single publish_topic setting can support the proposed telemetry/status/ACK topics. See [PLAN.md section 6.1](PLAN.md#61-esp32-connection-configuration-supplied-by-user).
|
||
|
||
## Approval checkpoint
|
||
|
||
Current order: Sprint 2 server package, user deployment and broker details, Sprint 3 local backend/simulator against that broker, Sprint 4 viewer, Sprint 5 reliability, Sprint 6 operational review and conditional Sprint 7 hardware. The user may authorize a subset. Documentation edits do not authorize application implementation, deployment, or hardware changes.
|