Tactical Pirate — Roadmap

The Roadmap records the current direction of Project Destroyer and The Tactical Pirate. It is not a release-date promise. Hardware results, licensing, safety requirements and physical testing remain capable of changing course.

Established Foundation

• Project Destroyer: the engineering programme responsible for development, testing, architecture and commissioning.
• The Tactical Pirate: the product and operator-facing identity.
• LILYGO T-Embed CC1101 Plus established as the current development and physical-test platform.
• 320×170 Tactical Pirate Hull architecture established with the display divided into Hull-owned header, viewport and footer regions.
• Boot → Landing / Ready → Main Deck established as the primary operating hierarchy.
• Semantic navigation established around PREVIOUS, NEXT, SELECT, BACK, contextual ACTION and MAIN commands.
• Hull-owned BACK and MAIN behaviour established so operational screens do not invent independent navigation rules.
• Main Deck established with six departments: Weapons, Wireless, Reconnaissance, Engineering, Ship’s Hold and Ember’s Mischief.
• Initial microSD storage validated using the TACTICAL FAT32 volume.
• IR Broadside v2 replay/storage architecture completed and software-verified.

Current Commissioning Work

• Capability Registry: establish one authoritative model for READY, PRESENT_NOT_COMMISSIONED, ABSENT and FAILED hardware-backed capabilities.
• Connect operational departments to actual detected and commissioned hardware rather than hard-coded menu assumptions.
• Complete physical verification of SELECT, BACK and MAIN behaviour on the exact Tactical Pirate hardware.
• Continue physical acceptance testing after each bounded Project Destroyer work package.
• Commission the first department-level menus only after the capability model is proven.

Next Priorities

• Hardware-aware departments: expose functions only when the required capability exists and is usable.
• Engineering: provide operator-visible hardware and capability status without exposing unnecessary diagnostic clutter.
• Ship’s Hold: establish unified storage for captures, evidence, exports, logs and other retained material.
• Reconnaissance: build the Stormy Awareness Portal as the primary situation-awareness and reporting destination.
• Documentation: create simple operator instructions with screenshots and images where they improve understanding.
• Firmware distribution: establish stormysailors.com as the official Tactical Pirate update channel.
• Offline recovery: provide an SD-card update and recovery path independent of network availability.

Conditional Hardware Capabilities

The Tactical Pirate is intended to adapt to the hardware actually fitted. A capability may therefore exist on one build and be absent on another without creating ghost menus or false status.

• IR: transmit, receive, capture, replay and database functions where supported by installed hardware.
• PN532 / NFC: commissioned only when compatible hardware is physically present and accepted.
• nRF24: commissioned only when compatible radio hardware is fitted and verified.
• CC1101: continue commissioning around the radio hardware supplied by the current LILYGO platform.

Planned Hardware Expansion

• GPS/BDS: add reliable position and navigation data using suitable external GNSS hardware.
• Ethernet Deck: develop a wired-diagnostics expansion, preferably with PoE support.
• Field power: validate dependable operation from practical external USB battery packs.
• IR expansion: improve transmitter range and receiver performance where the enclosure and final PCB permit it.

Authorization and Safety

The Tactical Pirate remains an authorized-assessment and defensive-diagnostics platform. Passive observation and clear evidence are preferred wherever possible.

• Potentially disruptive active capabilities remain governed by the Letter of Marque authorization model.
• Operational tools must be bounded, attributable and suitable for use only against owned equipment or explicitly authorized targets.
• Safety, legality and operator awareness outrank feature count.

Longer-Term Development

• Expand offline IR databases and protocol assistance without sacrificing reliability.
• Develop additional reconnaissance and diagnostic modules only when they have a clear operator purpose.
• Explore USB-accessible Ship’s Hold storage where the ESP32-S3 hardware and firmware safely permit it.
• Continue enclosure and PCB development based on manufacturing feedback and final antenna, display, connector and expansion requirements.
• Conduct Operation Ember reliability hardening before irreversible production-security measures are considered.

Commissioning Standard

The Tactical Pirate is not considered complete because it compiles, flashes successfully or looks finished. Commissioning requires the supported functions to work on the exact hardware, fitted capabilities to report honestly, controls and recovery paths to behave predictably, protected functions to remain bounded, and the operator to be able to navigate the system without being trapped or misled.

Recent Commissioning Status

• Missions Department: mission creation, lifecycle tracking, SNTP time-synchronization gating, evidence export and verification are commissioned.
• Quarterdeck Web Companion: the read-only bridge now exposes device status, Ship’s Hold files and mission records from a laptop-hosted web interface.
• The Watch: the department shell and Wireless Threat Watch core are established, including an explicit bridge handoff for supported monitoring functions.
• Network refit: AP plus STA operation, static local addressing and mDNS have been commissioned, with the Tactical Pirate access point retained as fallback.
• Evidence and storage: OUI-SPY, Dockyard Link transfers, packet capture and verified mission archives are now part of the working evidence chain.
• Current hardware work: CC1101 diagnostics and remaining physical acceptance tests continue to be treated as commissioning work, not assumed capability.

Tactical Pirate Dockyard

The Dockyard is planned as a Linux-only, distro-agnostic companion workflow. Its first role will be USB-first import, verification, metadata cataloguing and preservation of original captures and mission material, with working copies routed to appropriate Linux analysis tools. Network workflows may follow later.