| 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
- When the user does not explicitly name the target, start with
./forge status so device reachability is visible.
- If the user explicitly asks for
u64, run ./forge run u64.
- If the user explicitly asks for
c64u or c64u.ue2, run ./forge run c64u.ue2.
- Otherwise, prefer
./forge run u64 when u64 is reachable or available.
- Fall back to
./forge run c64u.ue2 only when u64 is not available and c64u is reachable or available.
- 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.
- Remember that
c64u.ue2 uses a FAST_LAUNCH helper by default for unattended Telnet launch.
- Use
--launcher-confirmation only when the user explicitly wants the stock confirmed launcher for manual testing.
Validation
- Report which target was chosen and why.
- Report the launcher profile used for
c64u.ue2.
- 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.