v0.1.0 to v0.1.0

---

name: daemon-backend-oh-my-pi

description: >

Nested daemon-cli-backends reference for the Oh-My-Pi (`omp`) daemon

backend's flag surface. Read this only when a daemon task needs

Oh-My-Pi-specific CLI flags (model selection, tool or provider switches):

it routes you to the installed CLI's live help via shell and shows how to

translate that help into the generic `backend_options` mechanism. It is

not a flag catalog.

version: 0.1.0

related_files:

- src/lingtai/tools/daemon/manual/reference/cli-backends/SKILL.md

- src/lingtai/tools/bash/manual/reference/bash-oh-my-pi/SKILL.md

maintenance: |

Tracks the Oh-My-Pi daemon backend flag-discovery topic it documents; update when that integration changes.

---

# Oh-My-Pi Daemon Backend — Flag Discovery Entrypoint

## Discover flags from the installed CLI

1. Load `shell-manual` (its nested `reference/bash-oh-my-pi/SKILL.md` has

broader Oh-My-Pi CLI context).

2. Run, in bash: `omp --version` and `omp --help`. The daemon backend wraps

the root `omp` invocation (no subcommand), so the root help is the

relevant flag surface. These are local read-only commands; no session is

started. Run `omp <command> --help` only on demand for a subcommand the

installed root help itself lists — subcommands are outside the daemon

wrapper.

## Example: model selection

```jsonc

{

"backend": "oh-my-pi",

"tasks": [{

"task": "Implement and validate the change.",

"tools": [],

"backend_options": {

"model": "<model id from the installed CLI>"

}

}]

}

// argv: --model <model id from the installed CLI>

```

## Harness boundary: reserved flags

The daemon owns Oh-My-Pi's non-interactive JSON harness

(`omp --mode json --approval-mode yolo <task>`). `backend_options` refuses

exactly these reserved flags before spawn (one bad key refuses the whole

batch):

`--mode`, `--print`, `--auto-approve`, `--yolo`, `--approval-mode`,

`--session`, `--resume`, `--continue`, `--no-session`, `--session-dir`

Keys are written without leading dashes, and underscores become dashes, so

`{"approval_mode": "write"}` targets `--approval-mode` and is refused.

Overriding these would break JSON event capture, re-enable interactive

prompting, or hijack session ownership.

## Session, ask, and MCP status

- The first `type:session` JSON header line carries the resumable session id;

the OpenCode-family parser stores it as `oh_my_pi_session_id` in

`daemon.json`.

- `ask` is async and resumes via

`omp --mode json --approval-mode yolo --session <id> <message>`;

emanate-time `backend_options` persist for the session and are not

re-passed.

- Per-run `daemon_common` MCP injection is **not wired yet** for this backend

(pending source evidence of an accepted config/env path), so the MCP

`finish` completion contract does not apply here — and `backend_options`

is not the place to hand-wire MCP.