Feature Build-Out

Modules 1-4 got you a real, working dashboard, built the AI-native way: live positions, a default watch region, free-pan, trails, history playback, all of it prompted, reviewed, and steered into existence rather than typed by hand. This module is where that workflow gets tested against something harder than any single lesson so far, six genuinely independent features, each one asking an AI assistant to extend architecture it didn’t just build a minute ago. Airports and live weather for context. The emergency-squawk and overflight detection that’s been running silently since Module 2 finally getting a UI. A place to browse the full overflight history. Two watch regions rendered side by side. Quick map-view bookmarks. A shareable snapshot. A real mobile layout.

Why This Matters

None of these six features need each other, but every single one of them needs something you already directed an AI assistant to build two or three modules ago. That’s exactly the situation where an AI assistant’s confidence and its correctness come apart the most. Ask it to add a viewport-scoped airport query and it might just as easily hand you one that fetches every row in the table. Ask it to add a saved-locations bookmark feature and it might quietly wire a save action into the same list the background poller reads from, because on the surface a “saved point on a map” and a “watch region” look like the same shape. The code runs. It looks plausible in a demo. It’s still wrong, and the only way to catch it is knowing what the existing architecture actually promises and checking that the new feature honors it instead of duplicating or bypassing it.

What You’ll Learn

• Directing an AI assistant to seed and query a real airport dataset by map viewport, and add a live METAR weather overlay with the caching a “check the weather” feature actually needs
• Prompting the frontend to finally consume the WebSocket’s remaining message types, turning two years of silently-discarded server pushes into a live alert feed with sound and browser notifications
• Directing a three-state home-location config flow and a full persisted overflight log, and catching the difference between “not configured” and “configured but cleared” before it becomes a UI bug
• Prompting two watch regions onto the screen side by side for free, because the store already keyed positions by region, and building a saved-locations feature deliberately kept separate from what the poller watches
• Directing a shareable snapshot capture, including a one-line CORS fix an AI assistant will almost certainly skip, and filling in the real mobile layout

Outcome

By the end of this module, SKYWATCH has every feature the real, finished app has, same as the original course, except you got there by writing six detailed prompts and reviewing six pieces of AI output against the architecture you already know it’s supposed to respect. Module 6 closes the course out with directing an AI assistant through testing and a real verification pass.

Let’s get started.