# Pilot's Toolkit — Working Roadmap *Last updated: March 4, 2026* *For completed milestones, see COMPLETED.md* --- > **RC1 locked — February 28, 2026.** Seven modules, both platforms, data externalized. > **RC2 planning — March 2026.** FBO Contact and Passdown Audit Trail targeted for next release. --- ## Phase I — Web & Android Apps ### RC2 Targets - **FBO Contact** — New module: outbound communication tab for contacting FBOs ahead of arrival. FBO autocomplete (learned from usage, auto-populates email), request details field with placeholder prompts (purpose of visit, transportation, services, ETA/ETD, catering), saveable/editable signature block (pilot name, registration, contact info, FBO loyalty program numbers). Email compose on send. Rewards numbers excluded from bulk exports. - **Passdown Audit Trail** — Diffs stored as a `history` array inline in the passdown JSON object. Each save captures timestamp, changed fields, and previous values. Compresses naturally inside existing `.ptz` gzip. Accessible from the passdown detail view only, via a disclosure element — main form and history list show only the final version. Retention policy on snapshots to keep record size bounded. ### Future Revisions - **Crew Rest Calculator** — Simplified rest period calculator for augmented crews (3–4 pilots). Equal division of en route rest after 30-minute all-hands blocks at departure and arrival. Potential paid add-on. Timer/alarm deferred (Android foreground services, notification channels). Full Part 117 compliance may not be attainable — regulatory liability is a fundamentally different risk profile than the rest of the toolkit. - **Crosswind Limits Overlay** — Per-aircraft wind limitations. Placeholder field exists in aircraft JSON. Blocked by data sourcing complexity (OEM vs operator limits, angle-dependent calculations). - **Room/SQLite Migration (Android)** — Migrate passdown storage from SharedPreferences to Room for better query/filter scalability. ### Removed from Consideration - ~~Unit Converter~~ — Duplicates existing EFB tools and web searches. - ~~Pressure Conversion~~ — Marginal standalone value. - ~~Density Altitude Calculator~~ — Covered by existing fleet performance tools. --- ## Phase II — Docker Deployment Single Docker container hosting the full stack: nginx (static Vite frontend + API proxy) + Node/Express (thin REST API, session-based auth) + SQLite (single-file database). Designed for homelab or small-group hosting. Doubles as an iOS demonstrator — iOS users access the web app through a browser before native iOS is built. - **Multi-user requirement:** User accounts with data partitioning. Each user's passdowns, lookups, and settings are isolated — no cross-visibility. Initial auth model: email + provided password, user changes password at first login. Managed by a small trusted group; more sophisticated auth layered on later if the user base grows. - **Frontend migration:** Storage calls swap from IndexedDB/localStorage to `fetch('/api/...')`. Data model, UI, and module logic stay untouched. - **API routes:** Auth (login/logout/session), passdowns CRUD, lookups CRUD, settings, .ptz import/export. - **Deployment:** Single `docker-compose.yml`, one volume for the SQLite database file. Exposed on port 38911 (no registered IANA service, low bot visibility). Runs on homelab HPC server. - **Security posture (proof of concept):** - nginx rate limiting on login endpoint (e.g., 5 attempts/min/IP → 429). - fail2ban monitoring nginx logs for 429s/401s — auto-bans offending IPs via iptables (e.g., 5 failures in 10 min → 1 hour ban, escalating for repeat offenders). - Session-based auth: user logs in once, stays logged in until explicit logout or token expiry (controlled server-side). No per-login OTP friction. - High port number provides minor obscurity benefit (not a security measure, but reduces noise from common-port scanners). - **Security upgrades (post-approval):** Cloudflare Tunnel (no open ports, email OTP gatekeeper, free tier, nothing to install on user devices — runs on server only) or VPN (Tailscale/WireGuard) if users can install software on their devices. Both are future options, not proof-of-concept requirements. Cloudflare session windows are configurable (24h to 30 days) but still require periodic re-auth, which adds friction for frequent daily use. - **Data security (future — managed device deployment):** Current .ptz files are plain-text gzipped JSON — readable by anyone with `gunzip`. Acceptable for a hand-selected beta group, but operationally sensitive data (maintenance squawks, crew schedules, tail numbers) must be protected on managed devices. Planned approach: when the Docker backend is live, passdown sync goes through the authenticated API — no .ptz files over email as the primary flow. The server controls who sees what; unmanaged/unauthorized devices simply can't authenticate. For offline/disconnected scenarios where .ptz file transfer is still needed, options include symmetric encryption (AES with operator-level shared passphrase) or per-user keys issued by the server. Key management complexity scales with the auth model — keep it simple until the user base demands otherwise. The goal: make it difficult for an individual to exfiltrate company operational data from a managed device. - **Mobile apps:** Stay local-only unless API sync is added later. Manual .ptz import/export provides a sync path for small groups in the meantime. --- ## Phase III — iOS (SwiftUI) - **Status:** Planning only. Architecture mapped out (SwiftUI + UserDefaults for persistence). - **Prerequisite:** Apple Developer Program ($99/year). Docker deployment (Phase II) provides a web-based stopgap for iOS users in the meantime. - **Approach:** Incremental migration in small, manageable chunks mirroring the Android module structure. Each module ported and tested independently before moving to the next. Allows troubleshooting at each step without large-scale rework. - **Migration order (tentative):** 1. App shell — navigation, tab bar, hamburger menu, aircraft selector, dark mode, theme 2. Fuel Order Calculator — simplest module, validates the SwiftUI patterns and data flow 3. Crosswind Calculator — standalone, no data dependencies 4. Pavement Strength — aircraft-dependent, tests data model integration 5. Fuel Buckets — slider, interpolation, CSV import, named profiles 6. Flight Level ↔ Meters — static data tables, lookup search, FLAS direction filter 7. HF Frequencies — network fetch, HTML parsing 8. Passdown Module — most complex, all CRUD + storage + export - **Storage:** Core Data or SwiftData for structured records, UserDefaults for preferences. - **Notable differences:** iOS will need its own .ptz export mechanism (likely via share sheet using UIActivityViewController), and HF fetch should work natively (no CORS restriction). --- ## Phase IV — Future Enhancements ### Ride Report / Turbulence Sensing Use phone accelerometer hardware to detect and classify turbulence intensity in real time. - **v1 (near-term, once core stable):** Simple vertical g-meter with real-time display, min/max peak hold, color-coded intensity gauge (light/moderate/severe/extreme bands). - **v2 (requires research):** Filtered intensity classification with time history graph. Key challenge is signal processing — low-pass/high-pass filter design, possibly Kalman filter for orientation fusion (accelerometer + gyroscope), windowing functions to separate turbulence from handling noise. This is a signal processing problem, not just linear math. - **v3 (ambitious, far future):** Crowd-sourced ride reports with GPS location, altitude, and intensity. Essentially a mini Turbulence Aware / PIREP system. - **APIs:** Web — DeviceMotion API. Android — SensorManager. iOS — CoreMotion. - **Status:** Wish list. Filtering approach needs dedicated research before implementation. ### App Icon Ideas discussed: compass rose, PT monogram, stylized wing/chevron, wrench+propeller hybrid, flight instrument silhouette. Compass rose and PT monogram scale best to small sizes (favicon, 48px Android icon). --- ## Aircraft Data (Suspended) Resumed when source data becomes available. - **G650** — ESWL formula working, max ramp weight needs confirmation (100,000 vs 104,000 lbs). ACN/ACR formulas not yet started (charts need deciphering). - **G700 fuel buckets** — Data not available for an indefinite period. - **G500** — Placeholder only. No pavement, weight, or bucket data yet. - **G450** — Updated pavement calculations pending integration of corrected data. --- ## Known Issues - **BlueMail (Android):** Send button uses `ACTION_SEND` with `message/rfc822` (.ptz attachment + plain text body + TO/CC). BlueMail receives the attachment but may not populate recipient fields or body text. Works correctly with Gmail and other standard email clients. BlueMail not presently supported; investigating.