105 lines
9 KiB
Markdown
105 lines
9 KiB
Markdown
# 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 in progress — March 2026.** Crew Rest Calculator (basic) completed. 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 (Advanced)** — The basic equal-division calculator is implemented. Future enhancements under consideration: 14 CFR Part 117 rest facility classes (bunk vs recliner vs none), acclimated time zones, theater changes, split-duty provisions, timer/alarm capability (requires 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. Potential paid add-on.
|
|
- **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.
|