Artemis II launched on April 1, 2026. Four astronauts aboard Orion, heading for a lunar flyby — the first crewed mission beyond low Earth orbit since Apollo 17.
NASA publishes spacecraft telemetry, but it’s scattered across OEM ephemeris files, XML feeds, and on-demand APIs. There’s no single interactive tracker. So we built one.
Live app: artemis-tracker-murex.vercel.app Source code: github.com/fluxforgeai/ARTEMIS
The entire project — 47 files, ~8,000 lines of TypeScript, deployed on Vercel — was built in a single session using the Wrought pipeline. This post walks through each stage and what it produced.
The App
ARTEMIS is a real-time 3D visualization of the Artemis II mission. It combines three NASA data sources:
- OEM Ephemeris Files — spacecraft state vectors at 4-minute intervals, interpolated to 60fps using degree-8 Lagrange polynomials
- Deep Space Network XML — live antenna status from Goldstone, Canberra, and Madrid
- JPL Horizons — Moon position in the J2000 reference frame
The tech stack: Vite, React 19, React Three Fiber, Zustand, Framer Motion, Tailwind CSS 4, and Gemini 2.5 Flash for the AI chatbot. Five Vercel serverless functions proxy the NASA APIs to handle CORS and caching.
The Pipeline in Practice
Every Wrought project follows the same sequence. Here’s how it played out for ARTEMIS.
Finding
The project started with a Findings Tracker — Wrought’s structured document for capturing what you’re building, why, and tracking it through every stage.
Finding: Interactive Artemis II Live Visualization
Type: Gap (High)
Rationale: No unified interactive tracker exists.
NASA data scattered across OEM, XML, and API endpoints.
Mission window ~10 days — time-sensitive.Research
Before building the AI chatbot, we evaluated three approaches: FAQ pattern matching, system prompt stuffing with an LLM, and RAG with vector search. The entire Artemis II knowledge base is ~3,000 tokens — smaller than most blog posts. RAG would have been absurd. System prompt stuffing with Gemini 2.5 Flash (genuinely free tier) was the pragmatic choice.
Design
Four architecture options evaluated with weighted scoring. Vite + React Three Fiber scored 8.6/10. Next.js was actively wrong — no content to server-render, no SEO to optimize, just a WebGL canvas that talks to APIs. Vite gives sub-second HMR and a smaller bundle without the hydration tax.
Blueprint
The design was translated into an implementation spec: 48 files across 8 phases, with interfaces for the OEM parser, Lagrange interpolator, Zustand store shape, and serverless proxy signatures. By the time implementation starts, the AI agent has a clear architecture, specific interfaces, and an explicit scope boundary.
Implementation
One iteration. All 15 tests passing. Build succeeds. Deployed to Vercel.
That’s not magic — that’s upstream work paying off. When the design specifies “Zustand store with scalar selectors to avoid re-render storms” and the blueprint defines the exact store interface, implementation becomes execution, not design.
Code Review — Where It Gets Interesting
After implementation, Wrought’s multi-agent /forge-review ran four specialized agents in parallel:
- Complexity Analyst — algorithmic time/space complexity
- Paradigm Enforcer — FP/OOP consistency
- Efficiency Sentinel — performance anti-patterns
- Data Structure Reviewer — access patterns vs. structure selection
The first review found 5 critical issues:
| # | Issue | Impact |
|---|---|---|
| C1 | 60fps Zustand re-render storm | Full React reconciliation every frame |
| C2 | O(n) linear scan in interpolator | ~194,000 wasted comparisons/sec |
| C3 | Per-frame array allocations | 120+ GC’d arrays/sec at 60fps |
| C4 | Stale closure in useChat | Multi-turn chat silently broken |
| C5 | StrictMode cleanup bug | Orphaned intervals and timeouts |
All five were genuine bugs that would have shipped silently. The linear scan and re-render storm would have made the app janky on mobile. The stale closure would have broken multi-turn chat.
After a root cause analysis and fix cycle, the re-review came back clean: 0 critical, 2 warnings (both benign edge cases), 2 suggestions.
The Audit Trail
Every decision made during this build is documented in the docs/ directory of the ARTEMIS repo:
- Finding — why we built it, what gap it fills
- Research — why system prompt over RAG, why Gemini over Claude
- Design — why Vite over Next.js, why R3F over vanilla Three.js
- Blueprint — the full implementation spec
- Reviews — both the initial review (5 criticals) and re-review (clean)
- RCAs — root cause analysis for each critical finding
Six months from now, when someone asks “why did you build it this way?”, the answer exists in those artifacts, not in someone’s memory.
Open for Contributions
ARTEMIS is a public repo with automated CI:
- Every PR triggers a Wrought-powered code review via GitHub Actions
- Claude reviews for bugs, security issues, render loop performance, and data pipeline correctness
- Branch protection requires the review to pass before merge
Fork it, improve it, open a PR. The pipeline will review your code the same way it reviewed ours.
What This Demonstrates
The Wrought pipeline isn’t about making AI code faster. It’s about making AI-written code trustworthy.
The 5 critical bugs caught by /forge-review are exactly the kind of issues that vibe-coded projects ship with. They work in the demo. They break in production. And nobody knows until users complain.
Structured engineering with AI produces software you can reason about, audit, and defend. That’s what Wrought is for.
Read the full technical walkthrough on Dev.to — includes code snippets, architecture details, and the complete forge-review findings.