@loupfeed/demo-native

The mobile half of the loupfeed demo engine (#6): compile the same scenario schema the web player executes into a Maestro flow and run it on a simulator/emulator, recording on-device.

import { compileToMaestro, runScenarioOnDevice } from '@loupfeed/demo-native';

const flow = compileToMaestro(scenario, {
  appId: 'com.example.app',
  deepLinkBase: 'example://', // lets `goto` steps navigate
});
// or in one call (Maestro CLI must be installed, device connected):
const result = await runScenarioOnDevice(scenario, { appId: 'com.example.app' });

Why Maestro (the v1 driver decision)

On a phone there is no visible cursor — "human-like" reduces to pacing, flick-style scroll physics, and settle beats, all expressible with Maestro's declarative commands (swipe with duration, scrollUntilVisible, waitForAnimationToEnd) at a fraction of Appium's setup cost. Appium's fine-grained W3C pointer paths would buy curved multi-touch gestures; revisit if those ever earn their keep on camera.

Mapping

| Scenario step | Maestro | | --- | --- | | goto | openLink via deepLinkBase (first goto may be launchApp) | | click | tapOn (id or text — see selector rules) | | type | tapOn + inputText | | scroll | a burst of decaying percentage swipes — flick, coast | | scrollTo | scrollUntilVisible | | expectVisible | extendedWaitUntil + timeout | | read / pause | waitForAnimationToEnd + a held beat (Maestro has no sleep) | | recording | startRecording / stopRecording (on-device, default on) |

Selectors: fb:<id> targets the loupfeed element id the RN SDK exposes as the view's testID; id=…, text=…, :has-text("…"), and plain labels also map. Structural CSS (input[name=…], combinators) has no native equivalent and is refused with a clear error — write mobile scenarios against ids and labels.

Status

Compiler + runner are unit-tested against Maestro's documented command set; an end-to-end device proof (RN example app + simulator) is the natural next step and tracked in #6.