put.io Device Harness

Use this skill when designing or reviewing a device/platform harness for put.io work. The harness should wrap platform tools, expose a typed command surface, drive runtime behavior, assert meaningful state, and leave proof artifacts.

Workflow

1. Read references/harness-pattern.md before shaping the harness architecture.
2. Read references/examples.md when you need concrete patterns from taizn or putio-roku.
3. Read references/platform-notes.md for platform-specific constraints before picking tools or proof surfaces.
4. Keep the generic harness core platform-focused. Put app-specific journeys, content IDs, credentials, and expectations in the app repo or scenario files.
5. Prefer deterministic commands and typed outputs over prose-only manual steps.
6. Design verification around hardware-backed or emulator-backed proof when static checks cannot prove behavior.
7. Before implementation, check the design covers all seven layers from harness-pattern.md: adapter, CLI/API, runtime driver, assertions, proof artifacts, repo integration, and boundaries.
8. If any layer is missing, revise the design before writing code; if platform state cannot be queried, require stronger screenshot, log, or transcript proof.

Mini-example command surface:

harness package --profile <profile-name>
harness install --device <device-alias>
harness launch --app <app-id>
harness press --key play-pause
harness assert-screen --name player --artifact artifacts/live/player.png

The exact command names should follow the target repo, but the shape should stay narrow, typed, and proof-producing.

Minimal TypeScript shape:

type HarnessArtifact = {
  kind: "screenshot" | "log" | "state" | "review-html";
  path: string;
};

type HarnessResult = {
  status: "ok" | "failed";
  device: string;
  artifacts: HarnessArtifact[];
  message?: string;
};

interface PlatformAdapter {
  package(profile: string): Promise<HarnessResult>;
  install(device: string): Promise<HarnessResult>;
  launch(appId: string): Promise<HarnessResult>;
  press(key: string): Promise<HarnessResult>;
  screenshot(path: string): Promise<HarnessResult>;
}

Output Shape

For a harness design or implementation plan, report:

• Platform adapter and wrapped tools
• CLI/API command surface
• Runtime driver capabilities
• Assertion model
• Proof artifacts
• Repo integration and verify/smoke entrypoints
• Secrets, local state, and app-logic boundaries

Guardrails

• Keep device IPs, passwords, certs, signing keys, tokens, content IDs, and personal local facts out of git.
• Checked-in examples use placeholders.
• Do not bake app business logic into generic platform commands.
• Wait for meaningful runtime conditions instead of arbitrary sleeps.
• If the platform cannot expose state directly, make the limitation explicit and compensate with screenshots, logs, or review artifacts.