[DISCUSSION] Define OS-scheduled bridging wrapper contract and parity

Why discuss this

Windows materializes a generated PowerShell wrapper, while Unix guides ask the agent to write a shell wrapper. Both eventually run a prompt file through a headless agent, but their surrounding execution semantics are maintained through different paths.

For example, Windows registers an explicit task working directory; Cursor's Unix wrapper explicitly changes into the host working tree; Claude Code and Hermes Unix examples currently do not. These differences may be deliberate, but the contract is not yet stated in one place.

Questions

Before proposing code changes, establish which wrapper properties are required across OS-scheduled hosts and which are platform- or host-specific:

• scheduled-run marker (MEMU_BRIDGING_RUN=1);
• host working directory and workspace-trust scope;
• scheduler-safe PATH construction;
• prompt-file loading and headless-agent invocation;
• output/error logging and exit propagation; and
• single-instance/stale-lock behavior.

Then decide whether Unix should remain guide-authored or gain a code renderer, and what compatibility/migration plan that would require.

Out of scope

• Changing wrapper behavior in this discussion.
• Native scheduler lifecycle or native-scheduler hosts.
• The Agent-facing platform-guide isolation in #626.

Desired outcome

A small documented wrapper contract and a scoped follow-up implementation proposal, if one is justified.