← RFC
Status: Standing direction from the operator, shaping Stage 5+ design. Date: 2026-06-11.
The vision
Once Loomwave is released and fielded:
- GitHub is the community surface. Feature requests, bugs, enhancements, and field reports
arrive as issues; an AI maintainer semi-automatically parses, triages, and acts on them —
triage → reproduce/evaluate → propose → human approval. Not fully autonomous; the human gate
stays.
- Simulate-before-implement is a standing gate. Fielded nodes feed back enough operational
telemetry that any proposed change can be evaluated in simulation against real measured
conditions — effectiveness, performance, impact — before a line of firmware changes.
This generalizes the discipline that built the project: every Stage-2 decision was sim-backed;
every Stage-4 milestone was hardware-measured; v8 calibrated the sim against live networks. The
vision makes that loop continuous and community-fed rather than a one-time development practice.
What it requires of the system (design rules, effective now)
- The simulator is a permanent first-class artifact. Every protocol change MUST land in the
SimPy model in the same change-set as spec/firmware (sim–spec–firmware versioned together).
Model drift silently breaks the evaluate-before-implement loop. The existing pattern —
real-topology seeding + calibrated propagation (v8) — is the prototype: simulation scenarios
are generated from operational telemetry, not hand-authored.
- Telemetry is designed-in, not bolted on. INFRA daemons emit structured operational logs
(the drive-test CSV is the seed): slot utilization, delivery ratios, per-link SNR distributions,
churn/fallback episodes, replay rejects, desense events. A versioned telemetry schema +
export bundle gives field reports a machine-readable attachment format.
- Privacy hooks in the export path. Positions and identities are sensitive; the export tool
anonymizes by default (same sensibility as
operator-access-options.md).
- GitHub plumbing at release time: issue templates (bug / feature / field report with
telemetry bundle); CI that runs the sim regression suite on every PR and posts the scenario
numbers (delivery/latency/util deltas) as the PR's evidence; labels/automation the AI maintainer
drives.
Refinement: UI is a different change class
Protocol changes make falsifiable claims — a sim gate fits. UI/UX changes (Android app, client
device screens) are preference-driven: there is no objective function to simulate, and one
design cannot satisfy the opinion space. Strategy direction (open, under consideration): make the
UI easily customizable by end users rather than evidence-gating a single design. A spectrum of
mechanisms exists — theming/layout preferences → user-selectable mode profiles (e.g. drive-test /
emergency / casual messaging) → declarative or community-variant UIs users opt into.
The architectural enabler is already mandated (CLAUDE.md Stages 6–7): protocol/business logic
behind a stable protobuf API with MVVM/clean separation — the UI must remain a thin, swappable
layer for any of those mechanisms to work. Any UI usage telemetry would be opt-in and
privacy-reviewed, unlike node operational telemetry.
- Stage-5/6 firmware and the INFRA daemon get telemetry emission as a requirement, not a debug
afterthought (the C6 drive logging continues and generalizes).
- The Stage-2 sim stops being "done" — it gains a maintenance obligation and, post-tower-deploy, a
scenario importer that consumes the real drive/tower logs.
- The RFC paper gains a section: the operational feedback loop as part of the system's design.