omp-headless-orchestration

Topics in the source

• OMP headless orchestration
• When to Use
• Rule: never launch OMP as a bare background job of the session
• Why headless (not TUI)
• Pitfalls (each one observed in production)
• Recovery after a session restart
• When a TUI is still right
• Related

Delegate bounded work to OMP (omp -p) without losing runs when the dispatching session, gateway or terminal goes down. Delegating a repo task to OMP that will run longer than a couple of minutes. You are working from chat (Discord/Slack) and cannot watch a terminal, but the run must not die when the session ends. Recovering an OMP run that was killed mid-turn (needs its session id). Deciding between headless -p and an attachable tmux TUI. A background child of the orchestrating session receives SIGTERM when that session ends, and omp -p prints only at exit — a run killed at minute 37 leaves a 0-byte output file. Always launch through the tmux wrapper shipped with this skill: A detached tmux session hangs off the tmux server (init), not off your session, so it survives session and gateway restarts. Verify with the ancestor chain of the omp pid, not by assumption. The implementation is maintained once, with skill goal-driven-delivery (scripts/adapters/omp-run.sh), because that skill's gdd.py defaults to it; the copy here (scripts/omp-run.sh) is a forwarder, so manual and dispatched runs share one code path. Headless output is a machine-checkable artifact; you can work from chat and a

This is an excerpt. Refer to the complete source and its current requirements.