SESSION 02 / AI CODING · LUNAR DELIVERY
The last mile on the Moon
Start with a playable lander. Use Codex to understand the model, add a reproducible crosswind mission, and verify how the change affects flight. Fuel, inertia, position, and touchdown limits create decisions worth investigating. Allow 75 minutes plus 15 for discussion.
Download coding starter Fly calm starter Fly full reference
The starter already implements calm flight, fuel, collision, and debrief. You build the crosswind extension; the reference solution is excluded from the starter ZIP. The simulation is a game, not flight training.
From conversation to project work
Use conversation to explore the experience. Use Codex with actual project files to inspect, edit, run, test, and review it. ChatGPT with tools can also act; the useful comparison is what context, tools, and evidence are involved, not an absolute product boundary.
I'd like to extend this lunar delivery game: https://moon-tea-session-2.winl.ai/en/ Get the starter and help me run my own calm-flight copy. I want to add crosswinds myself, not copy the completed reference. Tell me if I need to choose a folder or grant access. Don't edit yet.
Source: https://moon-tea-session-2.winl.ai/starter.zip . Let Codex start the preview; no manual terminal steps. If browser control is unavailable, you can fly the page and report what you observe.
Fly first and understand the tradeoffs
Your decision
What would you improve: difficulty, fairness, or feedback?
What to do
Try one calm flight with no thrust, then an approach with early braking. Use ↑/W for thrust, ←→/A D for tilt, Space to start/pause, and R to reset. Touch controls can be held. The reference adds wind, fuel constraints, and trajectory projection.
Send to Codex
Help me understand this ship. Why does it keep moving after I release thrust? What does tilting affect? Explain using this project without changing it yet.
Expected result
Distinguish position, velocity, acceleration, and fuel, and read the debrief.
Check: Touchdown requires both feet on the pad, vertical speed ≤9m/s, lateral speed ≤7m/s, and tilt ≤12°. Failure identifies position, speed, tilt, or corridor issues.
Trace input, dynamics, and rendering
Your decision
Choose one input and trace how it changes the system.
What to do
Ask Codex to read demo and AGENTS.md. Find initial conditions, wind, fuel burn, contact rules, fixed time steps, and keyboard/touch input. Save a recovery point. These are simplified game parameters, not a flight-training model.
Send to Codex
Trace what happens while I hold thrust: how do fuel, velocity, position, and rendering update? Why shouldn't altitude change while paused? Explain first, then save a recoverable version.
Expected result
flight-engine.mjs contains rules; flight.js handles input, stepping, and drawing; flight.css handles layout; media supplies the setting.
Check: Locate the responsibilities in real files. Calm flight, retry, pause, and debrief still work.
Define crosswind delivery and review a plan
Your decision
How should wind change while remaining understandable and reproducible?
What to do
Preserve calm flight. Add a task with fixed initial conditions and wind varying by simulation time, not fresh randomness every frame. Apply wind as lateral acceleration and display the same value in the instrument. Pause freezes simulation time; retry restores conditions.
Send to Codex
Keep calm mode. Add crosswind delivery: the wind should vary, but retrying identical conditions should be reproducible. Show its direction and strength. Pausing must not let it keep moving the ship. Explain what you'd change and how you'd check it before editing.
Expected result
The plan covers configuration, wind function, dynamics, mission selection, instruments, and checks. No backend, AI API, or new framework is required.
Check: Define identical input, wind units, and the boundary between the new task and calm flight.
Implement one system change
Your decision
Does the plan preserve the existing flight? Agree before implementation.
What to do
Let Codex edit your copy and run a preview with available tools. Fly calm and crosswind modes, then inspect the key diff. A code suggestion or completion claim alone is insufficient.
Send to Codex
Go ahead with that plan. Open my local preview so I can compare calm and crosswind flight. Then show me where the wind calculation and instrument changed. Handle running it and tell me if you need my input.
Expected result
Actual file changes, a running preview, a selectable mission, and an explainable instrument.
Check: Calm remains wind-free. Identical input changes lateral motion in wind. Retry, pause, and mode changes clear stale input and time.
Verify fairness with reproducible experiments
Your decision
Which failures are pilot decisions, and which might be implementation defects?
What to do
Use the checklist, then add a few rule tests. Fixed steps and scripted input can replay a flight, but a scripted controller landing is not proof of good human playtesting. Check keyboard, touch, blur-to-pause, instruments, and debrief in a browser.
Send to Codex
Help me verify wind and fuel. Replay the same flight with fixed input and compare calm versus crosswind. Check exact landing limits and values just beyond them. Separate actual test results from checks that still need manual playtesting.
Expected result
Rule-test output, replay comparisons, manual flight notes, and explicit gaps.
Check: Nonnegative fuel; no thrust when empty; independent boundary rules; deterministic replay; correct pause/reset; no silently relaxed landing thresholds.
| Scenario | Expected |
|---|---|
| No engine / tilt / empty tank | Gravity acts; tilt redirects force; empty tank cannot thrust |
| Landing limits | Test exact vertical, lateral, tilt, and pad-edge boundaries |
| Same replay | Same scenario, time steps, and input produce identical state |
| Pause / resume | Position and fuel unchanged while paused; no time jump |
| Retry / mission switch | Restore initial state and clear held controls |
| Human interface | Keyboard, touch holds/cancel, blur pause, trace, and debrief |
When something feels wrong
Report mission, inputs, and debrief. First decide whether the issue is the piloting decision, a stated rule, or a defect. Do not silently relax the limits. If no defect is observed, keep it as game-feel feedback and test a deliberate parameter change separately.
Review the diff and extend it independently
Your decision
Choose fuel limits, trajectory projection, or scoring.
What to do
Review the crosswind diff and map files to behavior. Use available Git review features or /review where supported; otherwise compare files. Define a new rule: can half fuel still complete a mission, is projection explicitly engine-off, or can a crash earn points?
Send to Codex
I'd like a low-fuel mission, but not one made impossible by arbitrary numbers. First review the current changes, then compare initial conditions and explain how we could establish that a landing is feasible. I'll choose the settings.
Expected result
A change you defined and verified, with the prior version retained. Separate rule verification from game-feel assessment.
Check: Record feasibility evidence, failure behavior, mode switching, and baseline regression checks.
Optional: strengthen the mission with media
Your decision
What should media communicate? Do not generate just to replace an asset.
What to do
The real clip remains in story material. For a new image, ask Codex to assist Jimeng, confirm settings and cost, then submit. Video can follow later. Save approved files into media and check after refresh. Queues should not block coding.
Send to Codex
I'd like an arrival image for the Moon Tea delivery. Keep the robot design and make the landing pad and shop easy to understand. Refine the description, check Jimeng settings and cost, and wait for confirmation. Keep flight rules unchanged.
Expected result
Media serving the mission, or a decision to keep the original. Jimeng access is not required for coding.
Check: Media changes preserve physics, controls, mode switching, and debrief. The site makes no Jimeng API requests.
Optional Jimeng account and plan preparation
Prepare Jimeng with Codex as your main app
Describe ideas and evaluate results in the Codex App. When your environment supports browser control, Codex can assist with Jimeng’s website. Jimeng supplies the media; you do not need a separate prompting workflow.
1. Register or sign in
Ask Codex to open the official Jimeng website and locate sign-in. Complete the login methods available on the page yourself; first-time users follow its account setup prompts. Handle phone numbers, SMS codes, QR scans, CAPTCHA challenges, and terms yourself rather than posting them in chat. Existing users can sign in without creating another account.
I haven't set up Jimeng yet. Open the official site and help me find where to sign in. When I need to receive a code, scan something, or accept terms, hand the page over to me. I'll tell you when I'm done.
2. Choose a personal plan for this experiment
First check your free credits and access to the selected model. Available free credits may be enough to try keyframes. If the video model requires a paid plan, check whether Basic covers one short clip and a few revisions. Compare Standard if you expect repeated creative work. If you already have Standard, use it; this lab does not require an upgrade. For a one-off experiment, compare one-month purchase with recurring monthly billing before choosing quarterly or annual billing for its discount.
The official membership page observed on November 12, 2026 offered Basic, Standard, Advanced, and Super tiers with one-month and recurring options. Offers and prices change. Check the initial price, renewal price, credit reset, model access, and automatic renewal on your own checkout page.
I only want to make a few images and one short video to start with. Can you look at the current personal plans? Are my free credits enough? If not, would Basic or Standard make more sense? Explain what I'd pay now and whether it renews automatically. I'll decide and pay myself.
3. Check that Codex can see your signed-in page
Signing in to an arbitrary browser does not guarantee Codex can access it. Ask Codex to open a page it can actually control, and sign in there. Follow any connection instructions for your current environment. Check access without submitting a generation task.
I'm signed in now. Can you see my Jimeng page? Check whether image and video generation are available, and look at my remaining credits. Don't generate or buy anything yet. If you can't see it, tell me where I should sign in or what's missing.
Ready when: Codex can describe the visible generation controls, and you know your credits and costs. Confirm the settings and credit use again before generating.
What if this Codex environment cannot control a browser?
Ask it to explain the limitation. Use the included real sample for the coding lab and return to generation when browser support is available, or watch the presenter demonstrate. Do not claim a connection exists or assume personal membership includes API access. API integration is not required for this lab.
Hand off a change you can explain
Your decision
What rules and evidence will you need next time?
What to do
Ask Codex to write HANDOFF.md with initial conditions, wind, limits, changes, actual tests, manual flights, issues, and next task. Retain a few stable AGENTS.md rules. Reuse Session 1 for Vercel.
Send to Codex
Save this iteration: how wind changes, which files changed, what input was used for verification, whether we playtested manually, and what is unconfirmed. Keep a recoverable version so I can continue. Reuse Session 1 if updating online.
Expected result
Recoverable code and an honest handoff, without copying reference results as your own completion.
Check: Explain how rules shape the experience, and distinguish automated tests, scripted feasibility checks, and human playtesting.
Connect both sessions to your domain and HTTPS
Complete Session 1’s Vercel publishing flow first. The example uses the already purchased winl.ai domain and retains each Vercel project name as its subdomain prefix. Both example hostnames passed DNS and HTTPS checks on November 12, 2026. The preparation and verification workflow below remains available to follow. Use your own domain and projects for your exercise.
| Session | Vercel project | Verified example hostname |
|---|---|---|
| 1 | moss-codex-session-1 | moss-codex-session-1.winl.ai |
| 2 | moon-tea-session-2 | moon-tea-session-2.winl.ai |
1. Check access to your signed-in pages
Open Cloudflare and Vercel. Handle sign-in and verification yourself. Check that Codex can access the actual controlled pages; a login in another browser does not establish a connection. If browser control is unavailable, follow the page steps yourself while discussing them in Codex.
I'm signed in to Cloudflare and Vercel. I own winl.ai and want one address for each session, keeping the existing Vercel project names as the prefixes. Check whether you can see both dashboards and confirm the projects and domain first. Don't change settings yet. Tell me if I need to sign in or authorize access.
2. Confirm DNS hosting and preserve existing records
Select winl.ai in Cloudflare. Check Active status and authoritative nameservers. Retain a working setup. If Pending, compare the registrar’s nameservers with Cloudflare’s assigned values before changing anything. Record existing web, email and verification entries and check whether either target hostname is already used. Cloudflare setup
Check whether Cloudflare is already serving DNS for winl.ai. Are moss-codex-session-1 and moon-tea-session-2 already used? Show the current records and proposed changes. Leave email and other websites alone.
3. Add each hostname to its matching Vercel project
In each project, open Settings → Domains → Add Existing, or its current equivalent. Add the matching full hostname from the table to Production. Read that project’s displayed DNS requirements and any ownership TXT verification. Subdomains generally use CNAME; use the current dashboard values rather than a memorized target. Do not include /demo/ in DNS. Vercel domain setup
Match moss-codex-session-1.winl.ai to the Session 1 project and moon-tea-session-2.winl.ai to Session 2. Verify the mapping, add each domain, and show the actual record type, name, target and any ownership TXT Vercel requests. Let me review that table before changing Cloudflare.
4. Apply the requested DNS records in Cloudflare
Open winl.ai → DNS → Records. The names will normally be moss-codex-session-1 and moon-tea-session-2. Use each matching project’s displayed target. Start with DNS only (gray cloud) and Auto TTL: Cloudflare resolves DNS while Vercel serves the site and TLS. Preserve existing values and resolve conflicts explicitly. Cloudflare proxy status
Show exactly how the two records should look using the table we checked. If there are no conflicts, configure them as DNS only with Auto TTL. Explain existing-record conflicts before replacing anything. Keep root, email and other websites unchanged, then check both Vercel projects.
5. Verify HTTPS separately for both hostnames
After DNS validation, Vercel attempts automatic certificate issuance and renewal. A separately purchased SSL certificate is usually unnecessary. Check both domain and certificate statuses, then visit each HTTPS address. DNS-only traffic does not require changing Cloudflare’s zone-wide SSL mode. If adding orange-cloud proxy later, first check its edge certificate, then use Full (strict) with a valid Vercel origin certificate. Do not use Flexible as a workaround or casually change zone-wide settings. Vercel certificates · Cloudflare Full (strict)
Both DNS records are saved. Check that each hostname opens the right session, the HTTPS certificate matches, and HTTP redirects to HTTPS. Try both languages, slides, manuals and demo videos. If anything is pending, tell me whether it's DNS, ownership verification or certificate issuance rather than calling it finished.
6. Update course links after both sites pass
Retain the vercel.app addresses for checking. Once both new hosts work, inspect both course headers, cross-session links, manual entry URLs and source archives. Replace relevant absolute URLs while preserving relative paths and language switching. Republish both projects and verify navigation in both directions. Keep winl.ai itself unchanged unless you separately choose a landing page or redirect.
Once both domains pass, update course links and manual entry URLs to the new addresses across both sites. Show the affected files, publish the agreed changes to both projects, and verify cross-session navigation, languages, downloads and HTTPS. Save the original DNS values and recovery steps.
Done when: Each hostname serves the correct session, HTTPS is valid, HTTP redirects, languages and assets work, course links are correct, and both projects, DNS before/after, certificate status and unfinished items are recorded.
If setup stalls
Check target-host DNS, conflicting records, ownership verification and Vercel’s current message. For certificates, inspect CAA and validation paths. Do not substitute a fixed wait for checks. A Vercel sign-in gate is a separate sharing setting. Track each site independently if only one is ready.
Completion record
Goal; rule changes; files; reproducible input; actual tests; human playtesting; known issues; recovery version; next task.