transient-device-run

name	transient-device-run
description	Perform the safest normal hardware validation path through forge run.

Intent

Use this skill for transient hardware validation and as the default interpretation of ambiguous deploy requests.

Inputs

• Target: u64, c64u.ue2, or no explicit target.
• Optional --dry-run or --build-tools-dir.

Execution

1. When the user does not explicitly name the target, start with ./forge status so device reachability is visible.
2. If the user explicitly asks for u64, run ./forge run u64.
3. If the user explicitly asks for c64u or c64u.ue2, run ./forge run c64u.ue2.
4. Otherwise, prefer ./forge run u64 when u64 is reachable or available.
5. Fall back to ./forge run c64u.ue2 only when u64 is not available and c64u is reachable or available.
6. Interpret generic wording such as "run firmware", "run this", "deploy firmware", "deploy this", "flash firmware", plain "run ", plain "deploy ", or plain "flash " as this transient path unless the user explicitly asks for hard, permanent, or persistent flash.
7. Remember that c64u.ue2 uses a FAST_LAUNCH helper by default for unattended Telnet launch.
8. Use --launcher-confirmation only when the user explicitly wants the stock confirmed launcher for manual testing.

Validation

1. Report which target was chosen and why.
2. Report the launcher profile used for c64u.ue2.
3. When reachable, confirm REST health after deployment.

Safety

• Prefer run over install or flash when the user asks for the safest validation path.
• Do not fall back to install or hard flash just because the transient target preference failed.
• Do not treat the bare verbs "run", "deploy", or "flash" plus a device name as permission to take the persistent flash path.