← ModRetro Chromatic PluginCONTENT HISTORY

Update to ModRetro Chromatic Plugin

Snapshot Sep 30, 2026 · 23:18 UTC · version 1.0.33+codex.distribution.66e8961d3ce30093ea3c9ee4

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "name": "chromatic-deployment",
  "description": "Find or set up a physical ModRetro Chromatic, capture its USB video feed, stream a live ROM demo to it, or flash a homebrew cartridge.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 290
    }
  ],
  "skill_md_contents": "---\nname: chromatic-deployment\ndescription: Find or set up a physical ModRetro Chromatic, capture its USB video feed, stream a live ROM demo to it, or flash a homebrew cartridge.\n---\n\n# ModRetro Chromatic deployment\n\nThe plugin bundles its vendor backend; no separate CLI is needed. Use the public\n`device`, `device_capture`, `setup`, `play`, and `flash` tools. See the [device guide](../../docs/chromatic-device-testing.md)\nfor platform details and manual checks.\n\nIf the plugin itself needs preparation, use the [setup skill](../modretro-chromatic-setup/SKILL.md).\nDevice tools with an existing ROM need only the runtime component. The public\n`setup` tool below handles hardware, not plugin dependencies.\nFor a tool error, follow [recover the failed step](../../docs/agent-guide.md#recover-the-failed-step):\nmissing project context, denied access, and an uncertain device action need different responses.\n\n## Browser previews\n\nOpen every `web_preview` or `device_capture` URL, including screenshot Open links, only in **Codex's built-in browser**. If it is unavailable or blocked, retain the URL and report the concrete limitation. Never launch or fall back to an external browser.\n\nReuse the active preview URL or emulator/capture session for the same task. When temporary testing is complete, close only the session this task owns with `web_preview_close`, `emulator_close`, or `device_capture {\"action\":\"close\"}`. Preserve user play (including paused games), ongoing recordings, and unresolved saves or commands; inspect status and retain recovery evidence before closing. Never scan processes, kill by name, claim an unfamiliar port, or clean up another task's session. An unknown action is not safe to replay.\n\n## Choose the device and ROM\n\n`device {\"command\":\"status\"}` reports requirements without probing USB or proving\ndriver health. When discovery is in scope, use\n`device {\"command\":\"list_devices\",\"requestId\":\"<unique discovery ID>\"}` so a lost\nreply can be recovered. Read the returned operation and select the intended `deviceToken`, never player 1\nby default. Tokens identify the current enumeration, expire after five minutes,\nand are consumed by accepted cartridge detection, live play, or flash. After one\nof those actions settles, rediscover and reselect before another. Reconnection,\nchanged enumeration, or ambiguity also requires a fresh choice.\n\nPlayers 1–8 are supported. Report discovery `diagnostics` even when another\ndevice is selectable. `conflicts` contains duplicate player numbers without\ntokens: have the user assign distinct numbers on the devices, reconnect them,\nthen discover again. `unmatched` preserves incomplete USB associations; check\nthe reported connection/access issue without claiming a driver diagnosis.\n\nFor live play or flash, use `rom_inspect` on the intended file within the\nauthorized project or workspace. Pass its exact path, `sizeBytes`, and SHA-256;\nnever substitute a different ROM, digest, or device. If no project or workspace\nis authorized, follow [project selection](../../docs/agent-guide.md#start-and-select-the-intended-project).\n\n## Prepare a first write on a new computer\n\nDeveloper Mode activation is handled by the official [ModRetro Updater](https://support.modretro.com/en_us/articles/chromatic-firmware-updater-ryhoYnzCx),\nnot this plugin. For a known never-activated computer or an explicit\n`feature.developer_mode_required` result, direct the user to that updater.\nDo not request, accept, submit, store, or inspect activation codes through chat,\nplugin tools, a plugin browser form, or a terminal. The plugin has no activation or\nactivation-status workflow. Code correction also belongs in the updater.\n\nA new plugin installation, missing local record, or successful device discovery\ndoes not establish whether activation is needed. A generic write failure does\nnot establish an invalid code, a seat limit, or a USB cause. Preserve the original\nwrite result and any uncertain cartridge outcome; do not automatically retry it.\n\nAfter the user completes the updater workflow, return to the plugin for fresh\ndevice discovery, selection, and the normal flash confirmation. Reuse existing\nexplicit erase/write consent only when it covers this intended device and action.\nUpdater completion is not permission to write a cartridge and does not verify\nthat the game was installed. Build and emulator work can continue independently.\n\n## Choose the requested action\n\n- **Drivers:** `setup` with `command:\"install_drivers\"` uses the current session\n  ID. Explain Linux's all-user udev access or Windows's elevated unsigned driver\n  installer before acting; macOS reports `not_required` without launching one.\n  See [driver setup](../../docs/chromatic-device-testing.md#driver-setup-depends-on-the-platform)\n  for platform prerequisites.\n- **Cartridge detection:** `setup` with `command:\"detect_cartridge\"` uses the\n  selected token and may reconfigure the FPGA. Do not reset, activate, reinstall,\n  or invoke a privileged shell as automatic recovery.\n- **Live play:** `play` streams host-emulated video/audio without writing the\n  cartridge. See [live-demo options](../../docs/chromatic-device-testing.md#stream-a-live-demo)\n  for duration and saves; use the local emulator for automated input or profiling.\n- **Physical video:** `device_capture {\"action\":\"open\"}` returns a local page.\n  On macOS, open Connection settings with `open_settings`; the user explicitly\n  enables capture and grants normal OS access. Tools cannot enable it silently.\n  Linux x64/ARM64 uses Connect without an Enable or macOS permission step and is\n  video-only. Windows device capture is unavailable; other supported device\n  actions remain separate. The browser is display-only. Use `permission_status`\n  and `list_devices` to inspect access and exact Chromatic choices, then connect\n  that selection. Linux listing briefly opens matching nodes for capabilities\n  without streaming. Optional macOS audio requires the same player’s USB input,\n  never another camera or microphone. For “watch me play,” `start_recording` returns an accepted\n  capture ID immediately: 3 minutes default, 10 minutes maximum. Poll `status` with\n  that ID; the deadline stops the camera. Inspect fresh `live_frame` images during\n  recording, save `screenshot` PNGs, and use `read_capture` for the last two frame\n  IDs or completed video downloads/paths. `stop_recording` ends early; `close`\n  releases the session. Partial/unknown outcomes are not duration success.\n  Open the returned URL in Codex's built-in browser for the physical live view.\n  Emulator buttons, stepping, memory and profiling do not control this feed.\n  Screenshots return a real\n  physical-feed image; videos stay download-only. Keep emulator images and\n  host-to-device live demos distinct from this feed. Native labels do not prove\n  which ROM is installed. Do not replay a timed-out command; inspect its status\n  and preserve recovery downloads. See [physical capture](../../docs/chromatic-device-testing.md#capture-the-physical-device).\n- **Flash:** Apply the eligibility and consent rules below. Tell the user the ROM\n  path, size, digest, and device. For a flash-only request, report the original\n  write result; label gameplay unverified unless it was observed and offer the\n  [manual checks](../../docs/chromatic-device-testing.md#check-the-game-manually).\n  If gameplay verification was also requested, continue with available evidence\n  and ask only for missing observations the tools cannot make.\n\nSet `confirm:true` only when the user has explicitly requested the specific setup,\nlive-play, or write action. Give each approved attempt a unique `requestId`.\n\n## Check the ROM and get first-flash consent\n\nTreat the exact ROM you compiled from game project source as homebrew; no extra\nprovenance check is needed unless it is a known third-party commercial game.\nRefuse clearly third-party commercial games even if the user owns or modifies a\ncopy. A game the user or their team made is eligible even if sold. For other\nsupplied ROMs of unknown origin, try to boot the exact inspected file in the\n[local emulator](../../docs/agent-guide.md#playtest-real-roms) and use any credible\nevidence already available that identifies that file. If eligibility remains\nunclear, do not flash; ask only for the missing evidence. See the [flash guide](../../docs/chromatic-device-testing.md#flash-the-exact-inspected-rom)\nfor evidence examples and refusal wording.\n\nBefore the first flash on a device, explain that it **will erase the selected\ncartridge’s existing game data, saves may be lost, and no backup is made**. Get\nexplicit acknowledgement and permission to write; a bare flash request is not\nenough. A request that already acknowledges the loss and approves this write\nsatisfies it. Use that consent for later user-requested writes on the same device\nwithout asking again; a fresh discovery token alone does not reset it.\nAsk only if consent is unavailable or narrower, or device identity has changed or\nis uncertain.\n\n## Use the reported recovery guidance\n\nAfter the original operation settles, use its recognized failure and\n`error.details.recovery` guidance. A successful cartridge detection can also\nreturn `result.recovery` when its flash chip is explicitly unidentified.\nKeep unknown causes unknown and preserve original command evidence.\n\n`device.program_failed` alone does not identify an activation, USB, or cartridge\ncause. Read the original `device` `operation_status` by its `operationId` and\ninspect `error.message`, `error.details.vendorCode`, and any reported recovery.\nFor a copied preview error, use `operationId`: its displayed `requestId` is\npreview-scoped, not the service request ID. Start with **Copy error** and the\npublic error summary. Optional `failureDetails` records only supported structured\nevidence; an observed token does not establish a cause. If original diagnostics\nare unavailable, report that limit once and keep the cause unknown. Raw command\nevidence may contain sensitive text. A closed process still leaves\n`cartridgeWrite: \"outcome-unverified\"`; do not retry automatically.\n\nUSB/HID failures call for the indicated platform access checks, not automatic\ndriver installation. Cartridge contact guidance does not establish that a\nnon-ModRetro cartridge is supported. Developer Mode errors direct the user to the\nofficial ModRetro Updater. Unknown capacity stays unknown; do not request a code\nor automatically retry the write. See the\n[recovery guide](../../docs/chromatic-device-testing.md#use-the-original-failure-to-choose-recovery).\n\n## Recover an interrupted action\n\nPoll `device {\"command\":\"operation_status\",\"operationId\":\"<returned ID>\"}` until\nthe original attempt settles. If a direct MCP discovery, setup, play, or flash\nreply was lost, use its original caller-supplied `requestId` instead of\n`operationId`. A preview's request ID is not interchangeable; use its copied\noperation ID, or call `web_preview` action `install_status` with\n`installationRequestId` set to the original preview UUID. A supplied ID never\nfalls back to the latest request; omission inspects the latest request and must\nnot substitute for original-attempt recovery. Match the returned request ID and\nknown generation before adopting its result. `requestedOperationUnknown: true`\nleaves the original outcome unconfirmed. If exact public lookup is unavailable,\nthat same dialog's **Check status** sends its saved request ID. These reads\nnever retry an attempt or renew an expired device token. Activation and its\nstatus are managed outside the plugin by the official ModRetro Updater.\nProgress, cancellation, timeout, or a vendor `retryable` flag is not\nproof of process closure or permission to repeat the action. Do not delete an\nunresolved reservation, infer closure from a PID, or bypass it with a new request.\nPreserve error causes, process-close evidence, captured output, and any unverified\nhardware outcome. The journal survives server restarts but cannot supervise a\nchild after host termination. See [interruption and completion](../../docs/chromatic-device-testing.md#keep-interruption-and-completion-distinct).\n\n## First-run recovery\n\nKeep preview readiness and USB device readiness separate. A refused localhost\npreview does not justify installing a driver. When device diagnostics actually\nrequire Windows driver setup, explain the normal administrator prompt once,\nuse the existing `setup` driver action within the user's authorization, then\nrediscover devices. Installer exit success alone is not a connection check.\nContinue with fresh device selection and the existing write confirmation; never\nreplay an uncertain write. Missing activation goes to ModRetro Updater, never\nto code collection.\n"
}

SHA-256: a0bffc7aa1f941e998892bf3b9dced0972568af7c141e6bbb68225c6286ecca1