fix: show every mobile test status in --wait output

[austin-autify]

Problem

autify mobile test run --wait prints a status line per poll:

TestPlan: 🚗 Running, TestCases: 👍 Passed  / 🚨 Failed

emojiStatus in src/autify/mobile/waitTestResult.ts covers six statuses. The mobile API returns eleven. The other five fall through to the ❔ None default, so a run that hits any of them tells you nothing:

status	before	after
canceled	❔ None	⏹ Canceled
internal_error	❔ None	🚫 Internal error
wait_device	❔ None	⌛ Waiting device
wait_device_timeout	❔ None	⏱ Device timeout
skip_passed	❔ None	✅⏩ Already passed

skip_passed is new, added by MOB-3570 for cells a rerun carries over instead of running again. The other four predate it, so this is not only about that feature.

What this does not change

Nothing about exit codes or polling. The loop terminates on data.finished_at, not on a status allowlist, and isPassed reads the plan status, which never takes any of these values. An unrecognised status was already safe, just illegible. This is a display fix.

Why the shape changed

The old chain hand-padded every label to seven characters so the progress line keeps a stable width. That made adding a status a matter of counting spaces, which is a plausible reason five of them were missing. A lookup table plus padEnd holds the same seven-column minimum without the counting.

Seven is kept deliberately rather than derived from the longest label. Every status that already rendered has a label of seven characters or fewer, so its output is byte-for-byte unchanged. The five new labels run longer and pad to nothing, so the only lines that move are ones that used to read "None".

camelcase rejects the API status values as property names, and quoting them does not help because prettier's default quoteProps strips the quotes straight back off. The table carries a scoped eslint-disable rather than being contorted into a different data structure to satisfy the linter.

Labels match the wording the Autify for Mobile UI already uses, so skip_passed reads "Already passed" in both places.

Snapshot changes

Sixty-one lines across two golden snapshots recorded the bug. Those runs had a test case sitting in wait_device, and the snapshots captured it as ❔ None:

- [HH:MM:SS] → TestPlan: 🚗 Running, TestCases: ❔ None
+ [HH:MM:SS] → TestPlan: 🚗 Running, TestCases: ⌛ Waiting device

They were edited rather than regenerated with -u. Running the suite locally adds a util._extend DeprecationWarning to stderr that CI does not produce, and -u would have baked that into every snapshot it touched. The two *Wait snapshots with no status change are untouched, which is also what confirms the warning is local: they differ only by that line.

Checks

npm run build, eslint, and prettier --check all pass locally. Rendered every status to confirm the emoji names resolve in node-emoji and that the column still lines up:

emoji	status	shown as
⏹	canceled	Canceled
❌	failed	Failed
🚫	internal_error	Internal error
👍	passed	Passed
🚦	queuing	Queuing
🚗	running	Running
✅⏩	skip_passed	Already passed
⏩	skipped	Skipped
⌛	wait_device	Waiting device
⏱	wait_device_timeout	Device timeout
⏳	waiting	Waiting
❔	anything unrecognised	None

⏩ and ✅⏩ are a pair: the fast-forward means skipped, and the check in front of it means skipped because it had already passed. That only reads if skipped owns the fast-forward on its own, which is why it moved off the sleep glyph.

🚫 for internal_error matches the ban icon the Mobile UI already uses for it. ⏹ for canceled and ⏩ for skipped read as media controls: stopping a run, skipping past a cell.

failed, queuing and skipped also exist in src/autify/web/waitTestResult.ts, which keeps its own copy of this function, so all three changed there too. Leaving them out of step would mean autify web and autify mobile disagreeing about what a failed test looks like. Seven recorded lines in the web snapshots carried the old queuing glyph; failed and skipped appear in no snapshot on either side.

skipped, failed and queuing also exist in src/autify/web/waitTestResult.ts, which keeps its own copy of this function. Only skipped changed here, so web still shows 💤 for it. Worth reconciling, but in its own change rather than this one.

[xiankai]

Nice improvement, some emoji alternatives from me:

Emoji suggestions
❌ for failed
⏩ for skipped
✅⏩ for skip_passed (if 2 emojis is fine)
⏱️ for wait_device_timeout
🚦for queued

[austin-autify]

Took all five. Pushed in 6e047bf.

	before	after
failed	🚨	❌
queuing	🌀	🚦
skipped	💤	⏩
wait_device_timeout	⏰	⏱
skip_passed	❔ None	✅⏩

⏩ and ✅⏩ are the pair that made the rest worth doing. No single glyph says "skipped, and it passed", and the composition only reads if the fast-forward means skipped on its own, so skipped had to move off 💤 for skip_passed to mean anything. Your suggestions were a system rather than five independent picks, which I did not see until I tried to take half of them.

⏱ over ⏰ is right for the reason you would expect: a stopwatch reads as elapsed time, an alarm clock as something scheduled.

Applied to web as well as mobile. failed, queuing and skipped also live in src/autify/web/waitTestResult.ts, which keeps its own copy of this function. Changing them in mobile alone would have left autify web and autify mobile disagreeing about what a failed test looks like, which is a worse outcome than either set of emoji. Cost was seven recorded lines in the web snapshots carrying the old queuing glyph; failed and skipped appear in no snapshot on either side.

That duplication is the thing worth fixing next. Two copies of one function is why the divergence was even possible, and why mobile has eleven statuses while web still has six. Out of scope here, but someone should collapse them.

On the snapshots, worth flagging as evidence rather than housekeeping: 61 recorded lines had captured a wait_device cell as ❔ None. That is the bug sitting in golden output, not a hypothetical.

I edited those by hand rather than running jest -u. Running the suite locally adds a util._extend DeprecationWarning to stderr that CI does not emit, and -u would have baked it into all 17 snapshots. The files with no status change are the control: they differ only by that warning.