diff --git a/warzone/docs/FUTURE_TASKS.md b/warzone/docs/FUTURE_TASKS.md
new file mode 100644
index 0000000..9b6f8ef
--- /dev/null
+++ b/warzone/docs/FUTURE_TASKS.md
@@ -0,0 +1,238 @@
+# Future Tasks & Improvement Suggestions
+
+These are optional improvements identified during development. Each includes context, effort estimate, and questions to answer before starting.
+
+---
+
+## Priority: High (Security/Reliability)
+
+### 1. Auth Enforcement Middleware
+**What:** Add axum middleware to enforce bearer tokens on protected endpoints.
+**Why:** Currently anyone can impersonate any fingerprint — the auth system issues tokens but doesn't require them.
+**Effort:** Half a day (~200 lines)
+**Blocked by:** Nothing — can be done now.
+
+**Questions before starting:**
+- [ ] Should we enforce auth on all `/v1/*` routes or only write operations (send, groups, aliases)?
+- [ ] Should the web client use cookie-based auth (simpler) or bearer tokens (consistent with CLI)?
+- [ ] What's the token refresh strategy — silent refresh or re-auth on expiry?
+
+---
+
+### 2. Session Auto-Recovery
+**What:** When ratchet decryption fails (corrupted state), auto-send a new X3DH KeyExchange to re-establish the session.
+**Why:** Currently a corrupted session = permanent inability to decrypt from that peer until manual intervention.
+**Effort:** 1 day
+
+**Questions before starting:**
+- [ ] Should we show a warning ("security session was reset") like Signal does?
+- [ ] Should we keep the old corrupted session state for debugging, or just delete it?
+- [ ] How many auto-recovery attempts before giving up (prevent infinite loops)?
+
+---
+
+### 3. Crypto Audit Plan
+**What:** Prepare the codebase for a professional cryptographic audit.
+**Why:** We implemented X3DH + Double Ratchet from scratch. Production use requires independent verification.
+**Effort:** 1 week (documentation + code cleanup), then $20-50K for audit firm
+
+**Questions before starting:**
+- [ ] Do we want to audit now (before federation) or after Phase 3?
+- [ ] Budget range? Trail of Bits (~$50K), Cure53 (~$30K), NCC Group (~$40K)?
+- [ ] Should we migrate to libsignal instead? (Avoids audit but loses WASM + static binary)
+
+---
+
+## Priority: Medium (Architecture/Quality)
+
+### 4. Extract Web Client from Monolith
+**What:** Split the ~1000-line JS embedded in `web.rs` into separate files (app.js, crypto.js, ws.js, ui.js, style.css).
+**Why:** Currently unmaintainable — one raw string in Rust containing all HTML/CSS/JS.
+**Effort:** 1-2 days, zero functionality change
+
+**Questions before starting:**
+- [ ] Serve as static files from disk, or embed multiple files at compile time?
+- [ ] Use ES modules (modern) or keep everything global (simpler)?
+- [ ] Add a minimal build step (esbuild for bundling) or keep it build-free?
+
+---
+
+### 5. Session State Versioning
+**What:** Add version byte to serialized ratchet/session state. Migrate old formats instead of failing.
+**Why:** Any change to `RatchetState` struct breaks all existing sessions silently.
+**Effort:** Half a day
+
+**Questions before starting:**
+- [ ] Just a version prefix byte, or a full envelope format (version + length + data)?
+- [ ] Should we support migrating from v1→v2, or just re-establish sessions on version mismatch?
+
+---
+
+### 6. Periodic Auto-Backup
+**What:** Automatically backup session state + contacts + history every N minutes to an encrypted local file.
+**Why:** Currently backup is manual (`warzone backup`). If the process crashes, unsaved sessions are lost.
+**Effort:** Half a day
+
+**Questions before starting:**
+- [ ] Backup interval? Every 5 minutes? Every new session? On quit?
+- [ ] Where to store? Same directory as DB? Configurable?
+- [ ] Keep N backups with rotation, or just latest?
+
+---
+
+### 7. WireMessage Versioning
+**What:** Add a version field or envelope around the bincode `WireMessage` so old clients don't crash on new message types.
+**Why:** Adding a new enum variant to `WireMessage` is a breaking change for all existing clients.
+**Effort:** 1 day (careful, touches everything)
+
+**Questions before starting:**
+- [ ] Prefix with version byte before bincode, or switch to a self-describing format (protobuf, msgpack)?
+- [ ] How do old clients handle unknown message types — ignore silently or show "update required"?
+- [ ] Is this the right time to consider protobuf migration for the wire format?
+
+---
+
+## Priority: Normal (Features)
+
+### 8. Mule Binary Implementation
+**What:** Build the `warzone-mule` binary for physical message delivery between disconnected networks.
+**Why:** Core warzone use case — the design is complete (DESIGN.md section 4) but no code exists.
+**Effort:** 3-5 days
+
+**Questions before starting:**
+- [ ] Start with USB/file transport only, or include Bluetooth from the start?
+- [ ] Do we need a mule GUI, or is CLI sufficient?
+- [ ] How do we test this? Two isolated Docker networks? Physical devices?
+- [ ] Should the mule have its own identity (keypair), or is it anonymous?
+
+---
+
+### 9. libsignal Migration Assessment
+**What:** Evaluate replacing our custom X3DH + Double Ratchet with libsignal-client.
+**Why:** Battle-tested, audited. But has trade-offs.
+**Effort:** 1-2 weeks if we decide to do it
+
+**Questions before starting:**
+- [ ] Can we accept the BoringSSL C dependency? (Breaks pure Rust, complicates cross-compilation)
+- [ ] libsignal doesn't support WASM — do we keep dual implementations (libsignal native + our ratchet for WASM)?
+- [ ] Is the storage trait adaptation worth it? Their `IdentityKeyStore`/`SessionStore` are different from ours.
+- [ ] Would an audit of our implementation be cheaper and better?
+
+---
+
+### 10. featherChat as OIDC Identity Provider
+**What:** Add OIDC provider endpoints so external services (Authentik, Keycloak, Grafana) can use featherChat for SSO.
+**Why:** Makes featherChat the identity backbone for an entire organization.
+**Effort:** 1-2 weeks (see IDP_SMART_CONTRACT.md)
+
+**Questions before starting:**
+- [ ] OIDC only, or also SAML for enterprise environments?
+- [ ] What claims to include in the JWT? (fingerprint, alias, eth_address, groups)
+- [ ] Should Authentik integration be a priority, or generic OIDC first?
+- [ ] Do we need a consent screen / authorization UI?
+
+---
+
+### 11. Smart Contract Access Control
+**What:** Deploy a Solidity contract for on-chain permission management (server/group/feature access).
+**Why:** Decentralized, auditable, censorship-resistant permissions.
+**Effort:** 3-4 weeks (see IDP_SMART_CONTRACT.md)
+
+**Questions before starting:**
+- [ ] Which L2? Arbitrum, Base, Polygon, or deploy our own?
+- [ ] Who pays gas? Admin only, or users too?
+- [ ] Is NFT-gated access a priority, or start with simple ACL?
+- [ ] How do we handle users who don't have a wallet? (featherChat-managed vs self-custody)
+
+---
+
+### 12. DNS Federation
+**What:** Server discovery via DNS TXT records, server-to-server message relay.
+**Why:** Multiple servers, no single point of failure.
+**Effort:** 2-3 weeks (Phase 3)
+
+**Questions before starting:**
+- [ ] Do we run our own DNS server, or use existing infrastructure?
+- [ ] DNSSEC required or optional?
+- [ ] How do we handle split-brain (two servers think they're authoritative for the same user)?
+- [ ] Is gossip discovery (no DNS) a sufficient fallback for warzone scenarios?
+
+---
+
+### 13. WarzonePhone Integration
+**What:** Shared identity + call signaling through featherChat (see WZP_INTEGRATION.md).
+**Why:** One seed, one identity, chat + calls.
+**Effort:** 4-8 weeks across 4 phases
+
+**Questions before starting:**
+- [ ] Fix the HKDF info string mismatch first (`"warzone-ed25519"` vs `"warzone-ed25519-identity"`)?
+- [ ] Who aligns — featherChat or WZP? (featherChat has more users/data to migrate)
+- [ ] Start with shared identity only (Phase A), or jump to signaling (Phase B)?
+- [ ] QUIC transport (WZP's choice) — should featherChat also adopt QUIC for messaging?
+
+---
+
+## Priority: Low (Polish/Nice-to-Have)
+
+### 14. Message Search
+**What:** Full-text search across local message history.
+**Why:** "What was that config someone shared last week?"
+**Effort:** 1 day (sled scan + substring match), 1 week (proper full-text index)
+
+**Questions before starting:**
+- [ ] Simple substring search, or proper full-text (tantivy crate)?
+- [ ] Search across all contacts, or per-peer?
+- [ ] Web client search too, or CLI only?
+
+---
+
+### 15. Read Receipts
+**What:** Currently we have Delivered receipts. Add Read receipts (when user scrolls to/sees the message).
+**Why:** Users want to know if their message was read, not just delivered.
+**Effort:** Half a day
+
+**Questions before starting:**
+- [ ] Should read receipts be opt-in (privacy sensitive)?
+- [ ] What constitutes "read"? Message visible in viewport for N seconds?
+- [ ] TUI: is "displayed on screen" equivalent to "read"?
+
+---
+
+### 16. Typing Indicators
+**What:** Show "User is typing..." when a peer is composing a message.
+**Why:** UX polish.
+**Effort:** Half a day
+
+**Questions before starting:**
+- [ ] Privacy concern — do we want to leak typing activity?
+- [ ] Should this be opt-in?
+- [ ] Encrypted or plaintext? (Plaintext is simpler, typing indicators aren't sensitive)
+
+---
+
+### 17. Message Reactions (Emoji)
+**What:** React to a message with an emoji instead of a full reply.
+**Why:** Quick acknowledgment without cluttering the chat.
+**Effort:** 1 day
+
+**Questions before starting:**
+- [ ] New WireMessage variant, or encode as a special text message?
+- [ ] Display inline (next to message) or as a separate line?
+- [ ] Multiple reactions per message?
+
+---
+
+### 18. Voice Messages as Attachments
+**What:** Record audio in the client, send as file attachment.
+**Why:** Voice messages are critical in field use. Uses existing file transfer — no new protocol needed.
+**Effort:** 1 day (CLI: pipe from mic, Web: MediaRecorder API)
+
+**Questions before starting:**
+- [ ] Codec? Opus at 16kbps is good. Or Codec2 for LoRa-compatible ultra-low bitrate?
+- [ ] Max duration? 60 seconds? 5 minutes?
+- [ ] Inline playback in web client, or download-only?
+
+---
+
+*Last updated: v0.0.20*
+*To work on a task: answer the questions first, then implement.*