I’m developing a Windows audio application with my dot in ChatGPT, using delegated Codex tasks. The biggest bottleneck is testing the actual Windows application. My dot can inspect code, make changes and run synthetic tests in Linux. But the cloud environment available in my workflow cannot run the Windows audio stack. In this environment, Wine could not start because the local IPC it requires was restricted. This matters in practice: my application produces robotic audio at small buffer sizes and still crackles at larger ones. Passing synthetic tests does not establish that the Windows audio path is working correctly. I end up repeatedly installing builds and manually testing problems that my dot cannot reproduce in its own environment. Please add an optional Windows testing environment for dots, with: 1. A real Windows runtime for applications and audio components. 2. Virtual audio input/output and loopback, so my dot can send a known signal through the application and automatically measure discontinuities, dropouts and latency. 3. Automated tests across buffer sizes and sample rates, with logs and results linked to the exact build tested. 4. Persistent project storage and recoverable checkpoints, so source changes and test evidence survive environment replacement. 5. Clear reporting of what was tested in a simulation, in Windows, or on physical hardware. I understand that virtual audio cannot reproduce every hardware-driver issue. Physical-device testing would still be necessary. But a Windows test environment would let my dot catch more failures before handing a build back to me and reduce the amount of manual testing required from users. Is this planned, or is there an officially supported way to give a dot this testing capability today?