helder test and helder.test (src/helder/test/README.md): the *.test.hx files under src/, tests/ and the class paths, linked into bin/test/src (Haxe takes no dot in a module's name), one generated main, built once, run on the host or wasm32-wasi (--target all; Eval only for the files that opt in, @:test.interp: compile-time code), paths written back as the real files'; -t, --watch, -u for text snapshots. The library has no macros: describe, test (.skip(), .only(), .timeout()), hooks, async(coroutine) bodies, assert, equals (deep, both values shown), notEquals, approx, throws, require, fail, snapshot.

One message format on the dev connection (src/helder/devtools/README.md): JSON-RPC 2.0, versioned by a Runtime.hello exchange, methods in domains enabled per tool:

• Runtime (hello, reload as a request answered once saved, ready, state: the keys Hot keeps and dropped; the CLI's built, buildError, reloaded, connected, exited), Log (traces with their positions, the program's output and the builds' errors, the last 500 kept by the CLI for a tool that comes late), Frame (time, work, GC bytes, collections and pauses per frame, 10 batches a second, no garbage per frame: 60 ns enabled, 0.4 ns disabled), Ui.getTree (a hook helder.ui registers);
• the agent in dev builds only (27 KB; a release build unchanged, byte for byte), helder dev as the relay (a WebSocket at /__helder/devtools on its HTTP port, natively too, named by bin/dev/devtools.json), helder inspect --tree --log --frames --state;
• @hxmc/cli's {"type"} lines still spoken to a program its dev.mjs runs; the devtools lane, headless.

hxmc's fixes in a nightly (@hxmc/cli 0.1.0-nightly.20261027.a4195c7), their workarounds removed: processes' cwd, env and signals and nanosecond mtimes (#81), sockets' connect and poll (#79, the native backend), allocation-free IntMap, resize and short sorts (#84, where as fast), GcStats (#85), Blocking and IoBuffer (#86), a --wait server kept by an empty connection; WasmGC's lanes removed (hxmc drops it, #90); haxe.Timer.stamp without the event loop, hxmc's std overrides trimmed by DCE (#89: the devtools agent and helder.test on Timer.stamp again; native builds 100 to 210 KB smaller: Todo 2042 to 1849 KB, Planets 2438 to 2234, Counter 1663 to 1499, Walker 708 to 607, a one-test helder test 297 to 262; wasm32 4 KB smaller); the platform package's compiler finding its runtime objects beside itself (#93: the CLI no longer gives HXMC_RT_DIR).

TypeScript for apps (optional, after the boundary tags): end users write their app in TS/TSX; helder itself stays Haxe, and the output is hxmc's, native or wasm, with no JavaScript in it.

• A helder ts frontend (started: helder.typescript) the CLI runs when a project's entry is src/main.ts(x): the program checked by the app's TypeScript 7.1+ (tsgo, driven over its API's pipes from Haxe: no node at build time), its AST lowered straight to hxmc's IR inside helder's compiler (hxmc's, with this frontend), JavaScript's semantics from a runtime in Haxe; helder dev keeps tsgo up in the compilation server and feeds it the watcher's changes; errors and stack traces mapped back to the .ts lines, as .test.hx paths are. Still to come: the CLI's entries, helder's API from TS, TSX.
• TSX as helder.view's markup, typed against helder's elements and compiled by its macros to direct calls on signals, no virtual DOM; <Scene> in TSX once scenes take markup.
• helder's API as .d.ts files in the npm package, generated from the Haxe API when helder is published (a .hx content mapper, TypeScript 7.1's plugin point, only if apps mix their own .hx files in).
• A generous subset, since app code is GC code: classes, functions, interfaces as anonymous structures, unions as generated enums, async/await on helder.async, number as Float (an i32 alias for Int); refused: any spread through code, mapped and conditional types beyond what Haxe can express, prototypes changed at run time. Shaders in TS (to Haxe shader classes) later, for games.
• A proof first: the .d.ts for view and ui, the emitter, the counter and todo examples in TSX built and live-reloaded by helder dev; started once TypeScript 7.1's API is out of beta.

• Between frames, the decode is one frame of 224 ms natively, 443 ms on wasm32.
• As a GC job, it made the main thread's collections wait 35 ms (up to 55): the 1 ms bar fails, so the engine uses GC-free jobs.
• As a GC-free job in a safe region, on scoped or off-heap memory, the longest pause is 0.3-0.6 ms, as with no job; without the region, 176-235 ms.
• On wasm32, a worker instance leaves the frames alone; the pixels cost the main thread one 15 ms copy into its memory, avoidable by uploading from the transferred buffer.
• Done since: the main loop with the frames, workers on the web, helder.jobs (above). (Upstream's hxcoro or a runtime of our own: our own, helder.async, which hxcoro's tasks run on.)

• Commands and tasks: dev, build, test, the target; build errors in the problems panel; helder test's files and results in the test explorer, a failure's line a click away.
• Language support on the Haxe extension (vshaxe): view's markup highlighted in .hx, .test.hx and .story.hx mapped for the display server (today they have no diagnostics, hover or completion), jumping to source from inspector nodes and profiler spans.
• Custom editors per kind of file, wherever it is in the tree: an image's preview, its settings per target and the code using it (bundled or not); a glTF's viewport and node tree; a font's specimen; audio's waveform; a story file's stories with their controls; edits to settings in a sidecar (.meta), reloaded live.
• The program: its own window natively (kept by the dev host across reloads), a web build in a webview, a phone attached through the CLI (which holds every build's connection, and outlives a crash with its logs).
• An agent in dev builds only (-D hxmc.dev, as Hot; a few tens of KB): counters and spans that do not allocate, GC bytes and pauses per frame, tree snapshots on request, commands, pick and highlight. Its protocol is there (phase 2: src/helder/devtools/README.md, frame stats, the log and the ui tree), and helder inspect a small client of it.
• Stories, as Storybook's: Foo.story.hx files anywhere (linked as .test.hx files are) whose stories() registers story("Inventory/full", c -> ...), built into dev builds only; controls are signals (c.number, c.bool, a choice, a colour), so an edit updates only what is bound; the story and its controls kept across a reload; a story is a test too, rendered headlessly by helder test against a snapshot (an image, or the tree as text), with a scripted interaction and assertions.
• Panels: the inspector (the ui tree with layout, styles and accessibility, signals and view's graph, each node traced to its markup line; the state a reload kept and dropped); the profiler (frame time, spans, GC bytes per frame split into the engine's and the program's); the console; pause and step.
• Literals edited without a recompile, as Makepad's live design: in dev builds markup literals (styles, numbers, colours, strings) read from a table keyed by their source position, which the CLI patches when an edit changes only literals; an inspector's or a control's edit applied as an edit in VS Code (its undo works).
• An MCP server in the CLI over the same protocol (inspect, set, stories, a screenshot), so an agent sees and checks a running program, its edits ordinary diffs.
• Chrome-trace or Tracy files exported until the timeline is drawn in a panel.
• First slice: the extension with the commands and the test explorer; the .test.hx/.story.hx mapping and markup highlighting; the image editor (once assets are referenced by path); the console and frame stats over the protocol. Then the stories editor, the inspector with jumping to source, the glTF and font editors.

Landed: <Surface> on phones: the safe area on both (Window.safeTop... in pixels: iOS's safeAreaInsets, Android's window insets through JNI, API 30's getInsets(systemBars | displayCutout) or API 29's system window and cutout insets; a Resize when they change), in ui as CSS's env(safe-area-inset-*) in markup's literal attributes (with calc(), max(), min(); bound to SafeArea.insets, laid out again when they change), Ui.safeArea, and SceneBox.safeArea() for a scene's HUD; Window.scale (Android's density, iOS's nativeScale, a ScaleChange when the configuration changes it); Window.immersive (Android's immersive mode, iOS's status bar and home indicator hidden); package.json's "orientation" (portrait, landscape, any: the manifest's screenOrientation, the plist's UISupportedInterfaceOrientations and UIRequiresFullScreen) and "fullscreen" (-D helder.fullscreen, UIStatusBarHidden); a rotation resizes the surface through the existing Resize. Tested: the options' manifest and plist (App.test.hx, Apk.test.hx, Bundle.test.hx; the pack lane's PackCheck on the built APK and app: screenOrientation, the orientations, the define reaching the program), env() and its binding (SafeArea.test.hx, natively and as wasm32-wasi); on CI's emulator (a Pixel 6, API 34) and simulator tests/pack/Screen.hx (tests/pack/screen.mjs): the window's size and scale (the Pixel 6's 2.625, the iPhone 17's 3), the insets (Android: the navigation bar's 126 px at the bottom; iOS: the island's 186 at the top, the home indicator's 102 at the bottom), immersive on Android (the bars' inset gone, the window into the camera's cutout: its 128 px at the top), a rotation on Android (wider than high, the cutout at the side). Not checked anywhere yet: the simulator's rotation (simctl has no command for it), immersive's effect on iOS's safe area (none on the island's iPhone), a ui drawn on a phone with the insets applied. Later: env() in runtime-set attributes and in sheets' rules, the keyboard's inset kept apart from the bars'.

Landed: the frame loop from the display: Choreographer (AChoreographer_postFrameCallback64, NDK only, on the program's own looper: helder.os.android.Vsync) on Android, a CADisplayLink on iOS (its callback stops the run loop's wait); App.run asks for the next vsync only while a frame may be drawn, sleeps until it comes, and draws with App.frame (a FrameClock: the vsync's time in haxe.Timer.stamp()'s seconds, the delta, the display's period); an idle frame (App.wait) asks for none until it has slept; the background, a lost window and an inactive app (onPause, the window destroyed; willResignActive, didEnterBackground) ask for none, the first frame after them a period's delta. Tested: FrameClock.test.hx (natively and as wasm32-wasi: 60 and 120 Hz, a missed frame, a pause, nothing allocated); on CI's emulator and simulator the fixture's first frames vsyncs, 120 of them at the display's pace (16.67 ms on both) with nothing allocated, Suspend and Resume and the first frame after (the delta a period); desktop and web keep their loops (App.frame from the turn's start: the gfx, ui-draw, app and browser lanes). Later: ProMotion's 120 Hz (preferredFrameRateRange, CADisableMinimumFrameDurationOnPhone), Android's frame rate API.

Multi-touch and gestures, after a study of the platforms' and engines' models (web Pointer Events, Android MotionEvent, UIKit's touches and gesture recognizers, Flutter's gesture arena, Unity's Input System, Godot), in four steps:

1. Landed: one pointer stream in os (Pointers: mouse, touch, pen; dense ids, phases, cancellation, coalesced samples; per event and per frame, allocating nothing; emulate keeps a touch's old click and scrolls). Tested natively (no allocation) and in Chromium (fingers, a pen, the mouse); Android's and iOS's back ends are written and compile, not run on a phone yet (CI's emulator and simulator jobs come first).
2. Landed: ui's pointers (fingers and pens with ids, capture and releaseCapture, onPointerCancel, onLostPointerCapture; a tap clicks, the first finger's drag scrolls in ui itself; a press on ui's own nodes marks the pointer the ui's), a <Scene> picking at each pointer's press only (the node hit owns it), one SceneEvent per box. Tested natively and as wasm32-wasi (src/helder/ui/Pointers.test.hx), the todo's touch drag, flick and tap in Chromium (ui-web).
3. Landed: touch in scene's input actions (Touch(zone), TouchDelta look zones, VirtualStick floating or fixed, VirtualButton, a press owned by its control until it lifts, ui's presses left alone, cancels letting go; <Stick> drawn in ui), read once a step from Pointers with nothing allocated. Tested natively and as wasm32-wasi (TouchActions.test.hx), <Stick> under Xvfb.
4. Landed: gestures in ui competing for each pointer (an arena: Tap, Pan, Scale; onTap, onPan, onPinch, onScale in markup; a recogniser that wins takes the click), onTap on scene nodes and <OrbitControls> for a <Scene>'s camera (one finger turns it, two pinch about their centre, move and twist it; the mouse and the wheel too; a glide). Tested natively and as wasm32-wasi (Gestures.test.hx, OrbitControls.test.hx), a tap and an orbit over a GPU's <Scene> under Xvfb.

Tested where: the desktop (Linux, natively, and its GPU under Xvfb) and the browser (wasm32-wasi in headless Chromium, touches and pens through the DevTools protocol); Android's and iOS's back ends are written and compile, not run on a phone yet. Later: long press, double tap and waitFor, rotate alone, touch-action on nodes, pen tilt and pressure in use, prediction, Windows' and X11's touch screens, macOS's trackpad gestures (magnify, rotate).

Landed: assets by path, bundled into the APK and the app (phase 2's "assets anywhere, bundled by use"; helder.asset, src/helder/asset/README.md): Asset.image, font, model, sound, bytes (and embed) by a path anywhere in the project, checked when compiling (the file there, in that case; a path's rules: AssetPath), a handle loaded on the main loop (load() a coroutine, ready, peek(), the handle a node of helder.view's graph, an async memo, its read() tracked; under helder.view's <Loading>, Solid 2's model, the content waits on its first load only: its fallback, then the content, kept through a reload; isPending); Model.of(path, Lazy) is Asset.model, Model.of reads its file through the same one way. Bundled by use: each call's marker is in the output only while its code is (hxmc emits the literals of the code it keeps), so helder build takes exactly those: desktop's executable has them as resources (read where they are mapped, no file beside it; a build whose built-in files differ is made again), the APK's assets/ (stored, read through AAssetManager), the app's assets/ (sealed by CodeResources before the link), the page's assets/ (fetched; Model.of's before main). helder dev reads them from disk (an Android app from helder dev: asset <key>), watches them and sends a change without a build (Assets.changed): an Image, a FontFile or a Model's meshes swapped in place, the handle's readers run again. Tested: AssetPath.test.hx, tests/asset/Assets.test.hx (natively and as wasm32-wasi: the bundle without a file named only in dead code; <Loading> over an image in ui's markup), tests/view's ViewTest (<Loading>: the fallback on a first load only, nested, a memo's and a component's reads, a failure the Errored's, none above: nothing rendered; on Eval, natively and as JavaScript), the asset lane (rejections; tests/asset/Checksum.hx alone in an empty directory, its files' CRC-32s; the web's files exactly), the pack lane (PackCheck: the APK's, the app's and the .ipa's assets/, CodeResources' hashes), the cli lane (an image swapped in the same Image with the dev host and without, a text's reader; the page told), tests/os/dev/dev-asset.mjs (the page's reload in Chromium), tests/pack/dev.mjs (the dev APK without assets, asset <key>); on CI's emulator and simulator Checksum's lines (tests/pack/android.sh, ios.sh; codesign --verify with assets) and an asset reloaded in the running app (tests/os/dev/dev-android.mjs), passing there (Pixel 6, API 34; iPhone 17, iOS 26.2). Later: .meta sidecars, compressed textures, sounds decoded.

Landed, a first slice: the game, Floating Greens (examples/golf/README.md): mini golf on floating islands, nine holes built from kit pieces in code (flats, ramps, rails, blocks, bumper posts, moving blocks, the cup) with a par each; the shot one gesture (a drag back from the ball: a recogniser of ui's arena winning the press at once, so <OrbitControls> on the same <Scene> turn and pinch the camera from anywhere else), the camera following behind the ball and facing the cup when it stops; helder.physics at 120 Hz, deterministic (six recorded rounds holed natively and as wasm32-wasi: the examples lane), a frame of play allocating nothing (GcStats); a trail, a squash, a shake, slow motion, confetti; the HUD and the holes' menu (stars, best strokes) in ui on helder.view's graph, clear of the safe areas; the save in helder.os's Store, procedural sounds through Sfx. Built for the web (on the examples site, full screen or expanded over the page, its APK on its card), natively, for Android and the iOS simulator (CI's emulator and simulator: built, started, its first frames, a screenshot). On the way: multisampled render targets in helder.gfx on every back end (<Surface> and <Scene> antialiased by default), WebGPU's bind groups no longer reusing a recycled handle's destroyed texture. Still to come: tweens for gameplay, live reload on a phone tried with it, its gaps (the report's list: an example's app options, a kinematic body, rolling resistance, struct values in Arrays boxed).

Landed: save data, helder.os.Store (src/helder/os/Store.hx): a small key-value store of strings, written through to a JSON file in the app's data directory (Linux's XDG data home, macOS's Application Support, Windows' APPDATA, Android's files directory, iOS's Library), localStorage on the web. Tested natively and as wasm32-wasi (Store.test.hx), the web's through golf's save in Chromium.

Landed: CI on an Android emulator and the iOS simulator: the android job (a Pixel 6's emulator, API 34: hello through helder run and adb, the screen fixture, Android's dev loop) and the ios-simulator job (the newest iPhone's simulator: hello through helder run, the screen fixture), green, not required.

Later in this phase: audio (decoders: WAV, Ogg Vorbis; a mixer above every back end, running as a kernel; AAudio on Android, RemoteIO on iOS; a simple Sound.play; a first slice landed: helder.os.audio.Sfx, a few voices mixing one-shot effects made up front on the existing outputs, desktop and the web, nothing allocated on the audio thread, Sfx.test.hx; silent on phones until their back ends), a compositor thread for scrolling and animations, so a busy main thread does not show (as Ladybird's compositor, Core Animation, Flutter's raster thread): the main thread hands ui's renderer a retained layer tree (layers, transforms, clips, scroll offsets) in flat, off-heap buffers; a render thread, a GC-free job in a safe region, scrolls, runs transform and opacity animations and presents at the display's rate; input routed to compositor-scrolled layers. Layout itself stays on the main thread (10k nodes laid out in 4.2 ms, allocating next to nothing): moved off it only if a measurement shows layout holding frames back. On the web, workers share no heap: the layer tree transferred, or a SharedArrayBuffer behind cross-origin isolation. And devices in the extension: their logs, a screenshot or a recording, a story picked on the phone.