docs: FAPP integration next steps + definition of done

docs/status.md

@@ -19,11 +19,19 @@
 - Location hint is PLZ only (e.g. "80331") — never exact address
 - Anti-spam: Approbation hash binding, signature verification, sequence-based dedup, rate limiting, TTL enforcement
 
-### What's Next
+### FAPP integration — next steps
-- Integrate FAPP message handling into mesh_router.rs
+
-- SlotReserve/SlotConfirm E2E encryption (X25519 key exchange)
+**Current state:** Spec (`docs/specs/fapp-protocol.md`) and Rust module (`crates/quicprochat-p2p/src/fapp.rs`) with store, matching, and tests are in place. **FAPP is not integrated** — `mesh_router.rs` does not decode, route, or emit FAPP CBOR yet.
-- Return-path routing for anonymous SlotQuery responses
+
-- Rate limiting per therapist address in FappStore
+**Next steps**
+1. **Wire into `mesh_router`:** On incoming mesh traffic, recognize FAPP message types; verify signatures and hop rules per spec; update `FappStore`; forward SlotAnnounce/Query/Response where applicable; align with `announce.rs` capability bits (`CAP_FAPP_*`).
+2. **Test on stack:** Multi-node TCP/mesh demo first (two+ nodes, therapist/relay/patient roles); then LoRa hardware when available (airtime, fragmentation, duty cycle).
+3. **After wiring:** SlotReserve/SlotConfirm E2E (e.g. X25519), anonymous return-path for SlotQuery responses, per-therapist rate limits in `FappStore`.
+
+**Definition of done**
+- Router end-to-end path for FAPP matches spec (verify, dedup, TTL, forwarding semantics).
+- Integration proof: announce → query → response over at least one multi-hop path (automated test or documented manual run).
+- Hardware check: same scenario on LoRa, or a short note in status on what blocked it.
 
 ---