Feat/cs/omp support

README.md

@@ -30,7 +30,7 @@ Organize related tasks into named groups, even when they run in different direct
 
 ### Resume agent sessions
 
-Start `claude`, `codex`, or `grok` normally. When you rerun the task or reload a saved session, `fleetcom` resumes the same conversation automatically.
+Start `claude`, `codex`, `grok`, or `omp` normally. When you rerun the task or reload a saved session, `fleetcom` resumes the same conversation automatically.
 
 ## Operational model
 
@@ -40,7 +40,7 @@ Running several long-lived commands is pesky once they span terminal panes or ne
 - Delegates tasks to a daemon, so a disconnecting client stops nothing.
 - Saves and reloads task recipes: directories, commands, group assignments, and display names.
 - Reruns a completed task in place, keeping its identity, group, and name.
-- Preserves `claude`, `codex`, and `grok` conversations, so saved or rerun tasks resume instead of starting fresh.
+- Preserves `claude`, `codex`, `grok`, and `omp` conversations, so saved or rerun tasks resume instead of starting fresh.
 - Automatically snapshots the current task set for recovery.
 
 ## Documentation
@@ -102,7 +102,7 @@ Every task runs in its own pseudo-terminal, emulated with `alacritty_terminal`.
 - Several long-lived commands need one place for observation, tagging, and attachment.
 - Jobs must survive a terminal closing and remain available for reattachment.
 - The same command set is launched often enough to justify a saved session.
-- Agent sessions (`claude`, `codex`, `grok`) must resume their conversations on rerun rather than start new ones.
+- Agent sessions (`claude`, `codex`, `grok`, `omp`) must resume their conversations on rerun rather than start new ones.
 
 ### When to avoid `fleetcom`
 

docs/README.md

@@ -7,7 +7,7 @@
 - [Commands](commands.md): every key and launch flag, including the routing mechanics
 - [How it works](how-it-works.md): the PTY emulation, input routing, and activity grouping
 - [Sessions](sessions.md): the task recipe format and where it lives
-- [Agent session resume](agent-resume.md): how `fleetcom` captures and resumes supported `claude`, `codex`, and `grok` sessions
+- [Agent session resume](agent-resume.md): how `fleetcom` captures and resumes supported `claude`, `codex`, `grok`, and `omp` sessions
 - [Storage paths](#storage-paths): runtime and session paths
 - [First-run walkthrough](#first-run-walkthrough): a first run, start to finish
 - [Security](#security): the trust boundary, on-disk state, and what is not protected
@@ -153,7 +153,7 @@ The attached status bar shows both: `[attached] api tests · cargo watch -x test
 | `<sessions>/<name>.json` | `0600` | directories, commands, groups, display names |
 | `<sessions>/recovery/` | `0700` | [automatic snapshots](sessions.md#recovery) |
 | `<sessions>/recovery/<snapshot>.json` | `0600` | one automatic session recipe |
-| `<capture-root>/<pid>-<nonce>/` | `0700` | [agent hook and notifier assets plus per-run capture payloads](agent-resume.md#capture-state-and-isolation) |
+| `<capture-root>/<pid>-<nonce>/` | `0700` | [agent hook, notifier, and extension-module assets plus per-run capture payloads](agent-resume.md#capture-state-and-isolation) |
 
 Saves are atomic: `fleetcom` writes a mode-`0600` temporary file in the destination directory, syncs it, then renames it over the target. This does not expose a partial or world-readable recipe. New session and recovery directories use mode `0700`; each save also removes group and other permissions from the destination directory.
 

docs/agent-resume.md

@@ -1,13 +1,13 @@
 # Agent session resume
 
-Session files preserve launch commands, not process state. Relaunching a bare `claude`, `codex`, or `grok` command ordinarily starts another conversation. For accepted commands, `fleetcom` captures a validated conversation ID when available and builds a canonical resume command when saving a session or rerunning a finished task (`r`).
+Session files preserve launch commands, not process state. Relaunching a bare `claude`, `codex`, `grok`, or `omp` command ordinarily starts another conversation. For accepted commands, `fleetcom` captures a validated conversation ID when available and builds a canonical resume command when saving a session or rerunning a finished task (`r`).
 
 ## Workflow
 
 Start a supported agent without flags:
 
-1. Press `n` and run `claude`, `codex`, or `grok`. The task appears in the dashboard under the command you typed. Instrumentation changes only the string executed through `$SHELL -c`, so a direct spawn still displays the requested command.
-2. Work in it. `Enter` attaches; `Ctrl-\` returns to the dashboard. Depending on the agent, `fleetcom` pins an ID at launch and may update it from a hook or notifier while the task runs or from terminal output after it exits.
+1. Press `n` and run `claude`, `codex`, `grok`, or `omp`. The task appears in the dashboard under the command you typed. Instrumentation changes only the string executed through `$SHELL -c`, so a direct spawn still displays the requested command.
+2. Work in it. `Enter` attaches; `Ctrl-\` returns to the dashboard. Depending on the agent, `fleetcom` pins an ID at launch and may update it from a hook, notifier, or extension while the task runs or from terminal output after it exits.
 3. Press `w`, enter a session name, and press `Enter`. If the earlier sources produced no ID, the save also checks the agent's on-disk session store. A captured bare command becomes its canonical resume form, such as `claude --resume '<uuid>'`.
 4. Run `fleetcom <session>`, or press `o` in the dashboard, to start new processes from the saved commands. A stored resume command reopens its captured conversation.
 
@@ -19,23 +19,25 @@ Capture is best-effort and narrow by design. A command carrying a prompt, extra
 
 The capture boundary is intentionally narrow. Only these forms participate:
 
-- `claude`, `codex`, or `grok`
+- `claude`, `codex`, `grok`, or `omp`
 - `claude --resume <uuid>`
 - `codex resume <uuid>`
 - `grok --resume <uuid>`
+- `omp --resume <uuid>`
 
 The program word may be a path such as `/usr/local/bin/claude` when its basename matches and the token contains no shell syntax. A resume UUID may be bare or single-quoted, but it must be the final argument.
 
 Everything else remains opaque and runs, displays, and saves verbatim. This includes prompts, flags, alternate resume spellings, subcommands, trailing arguments, and shell syntax. The narrow boundary prevents injected arguments from binding to a different shell command than the detector recognized.
 
 ## Capture state and isolation
 
-Hooks and notifiers run outside the supervisor, so they need stable paths. The supervisor installs those assets once for each runtime root. An explicit `FLEETCOM_RUNTIME_DIR` becomes that root. Otherwise, `fleetcom` uses the platform runtime or cache directory and partitions it by session directory.
+Hooks, notifiers, and extension modules are loaded by the agent rather than the supervisor, so they need stable paths. The supervisor installs those assets once for each runtime root. An explicit `FLEETCOM_RUNTIME_DIR` becomes that root. Otherwise, `fleetcom` uses the platform runtime or cache directory and partitions it by session directory.
 
 Each supervisor installation creates a private mode-`0700` `<root>/<pid>-<nonce>` namespace containing:
 
 - `claude-settings.json`, mode `0600`
 - `codex-notify.sh`, mode `0700`
+- `omp-capture.js`, mode `0600`: omp imports the module rather than executing it, so it needs no executable bit
 - `task-<id>-<run>.json` capture paths
 
 The random nonce separates concurrent supervisors and prevents PID reuse from selecting an existing namespace. The run number gives each rerun a distinct capture file, so a displaced process cannot overwrite the replacement run's session state. Installation leaves every other root entry unchanged.
@@ -78,6 +80,24 @@ Grok accepts a launch-time ID but exposes no injectable live-capture channel. A
 
 After exit, the harness scans retained terminal text for the last `grok -r <uuid>` or `grok --resume <uuid>` hint. Save-time filesystem correlation checks `<grok-home>/sessions/<encoded-cwd>/<uuid>/`, percent-encoding the canonical working directory, falling back to a group whose `.cwd` file names that path when the encoded name is too long, and ignoring `session_kind: subagent` directories.
 
+### `omp`
+
+omp cannot pin an ID at launch: it has no `--session-id`, and `--resume` requires an existing session. Both accepted forms therefore receive the same injection and no pinned ID:
+
+```text
+-e '<namespace>/omp-capture.js'
+```
+
+`-e` loads the JavaScript module into the agent process and appends it to the user's extensions. Its `session_start` and `session_switch` handlers write `sessionId` as JSON to `FLEETCOM_CAPTURE_FILE`. The second handler follows in-TUI `/resume` changes. Capture writes are best-effort: the module returns when the capture path is empty and ignores write errors.
+
+After exit, the harness scans retained terminal text for the last trusted `omp --resume <uuid>` hint. It accepts ordinary exit hints and `Main:` entries in `[Recovery]` blocks. Other labels identify subagent sessions that `omp --resume` cannot open, so they contribute no exit evidence. The aliases `-r`, `--session`, and `-c` remain opaque because `fleetcom` rewrites only the canonical form it detects exactly.
+
+Save-time filesystem correlation reads `<sessions root>/<encoded-cwd>/<iso-ts>_<uuid>.jsonl`, where the sessions root comes from omp's own variable chain rather than one home override; the [environment-variable table](#environment-variables) lists it. `PI_CODING_AGENT_SESSION_DIR` is the exception: omp passes that path straight through as the session file's parent and never computes a bucket, so the store is flat under it. The scan covers the root and one level below without inferring which layout is in play.
+
+Correlation enumerates buckets instead of deriving their names, then verifies each session header's `cwd` against the task path and its canonical target. A candidate must be the sole UUIDv7 session created within 30 seconds of task spawn. UUIDs found in multiple buckets count once.
+
+An empty sessions root or bucket contributes no candidate.
+
 ## ID precedence
 
 Several channels can identify different conversations during one task. To make the result deterministic, `fleetcom` chooses the first available ID in this order:
@@ -96,6 +116,7 @@ Saving and rerunning rewrite accepted commands to one of these forms:
 claude --resume '<uuid>'
 codex resume '<uuid>'
 grok --resume '<uuid>'
+omp --resume '<uuid>'
 ```
 
 The program word is preserved as typed. If no valid ID is available, the original command remains unchanged. A rerun increments the run number before spawning its replacement, so capture data from the displaced run cannot affect the new run.
@@ -110,21 +131,28 @@ Each tool implements the `Harness` trait in [`src/harness/mod.rs`](../src/harnes
 
 - `shape` supplies the program word and resume selector. The default `detect` and `resume_command` methods derive the accepted and canonical forms from that pair.
 - `instrument` returns spawn-time arguments, environment entries, and an optional pinned ID.
-- `parse_capture` reads an ID from hook or notify JSON.
+- `parse_capture` reads an ID from hook, notify, or extension JSON.
 - `scrape_exit` reads an ID from retained terminal text.
 - `live_session_id` reads the ID a live session publishes on disk. It defaults to `None` for tools that publish no registry.
 - `live_blocked_status` reads that same registry for one display fact: whether the tool says it is blocked on the user. It returns preview text, never an ID, and defaults to `None`.
 - `correlate_fs` finds one matching on-disk session.
+- `resolve_home` turns the task's launch environment into the tool's store root.
 
-The supervisor resolves each harness home from the task's launch environment: the tool-specific variable first, then `$HOME` plus the tool's dot directory. That resolved path remains attached to the task for later filesystem correlation.
+The supervisor supplies the launch environment and delegates the decision to `resolve_home`. Its default is the two-step rule three of the four tools follow: the tool-specific variable first, then `$HOME` plus the tool's dot directory. omp overrides it, because its store root comes from a chain of variables and a filesystem-conditional XDG branch that no single override can express. Either way, the resolved path remains attached to the task for later filesystem correlation.
 
 ## Environment variables
 
 | Variable | Meaning |
 | -- | -- |
 | `FLEETCOM_RUNTIME_DIR` | Explicit capture-asset root as well as the daemon runtime override. |
-| `FLEETCOM_CAPTURE_FILE` | Per-run capture file used by the injected hook or notifier. |
+| `FLEETCOM_CAPTURE_FILE` | Per-run capture file used by the injected hook, notifier, or extension module. |
 | `FLEETCOM_NOTIFY_CHAIN` | Newline-joined argv for the configured Codex notifier; empty when none is active. |
 | `CLAUDE_CONFIG_DIR` | Claude home holding the `sessions/<pid>.json` registry and the transcripts used for correlation; defaults to `$HOME/.claude`. |
 | `CODEX_HOME` | Codex home used for notify routing and rollout correlation; defaults to `$HOME/.codex`. |
 | `GROK_HOME` | Grok home used for session-directory correlation; defaults to `$HOME/.grok`. |
+| `PI_CODING_AGENT_SESSION_DIR` | omp sessions root, used verbatim for correlation. The rest of omp's chain builds that path instead of naming it. |
+| `PI_CODING_AGENT_DIR` | omp agent directory, whose `sessions` subdirectory is the store. A selected profile ignores it. |
+| `PI_CONFIG_DIR` | omp config directory under `$HOME`; defaults to `.omp`. Under `fleetcom`, an absolute value replaces `$HOME`. |
+| `OMP_PROFILE` | omp profile, read by presence: it selects a profile when non-empty and suppresses `PI_PROFILE` when empty. |
+| `PI_PROFILE` | omp profile used only when `OMP_PROFILE` is absent. A profile inserts `profiles/<name>` under the config directory. |
+| `XDG_DATA_HOME` | Redirects the still-default omp agent directory to `<value>/omp`, flattening the `agent/` level, when that target already exists. |

docs/commands.md

@@ -104,7 +104,7 @@ Destroy is Shift-gated: only uppercase `X` acts. It kills a running task or remo
 
 `r` acts only on a finished task. A running task remains untouched because rerunning it would first require a destructive kill.
 
-The replacement starts in the same directory using the requesting client's environment. Most tasks reuse their stored command. A supported `claude`, `codex`, or `grok` task instead uses its captured resume command when a valid conversation ID is available.
+The replacement starts in the same directory using the requesting client's environment. Most tasks reuse their stored command. A supported `claude`, `codex`, `grok`, or `omp` task instead uses its captured resume command when a valid conversation ID is available.
 
 Rerunning preserves the task's ID, `◆` tag, group, name, and spawn order; its clock and screen reset. Since lifecycle affects sorting, the task may move to another section when it starts. The same key works inside peek, which remains open while the replacement starts.
 

docs/sessions.md

@@ -51,7 +51,7 @@ The file is plain JSON and practical to edit by hand. Editing the `name` field c
 
 Commands with neither a group nor a name use the string form. String and object entries can appear in the same directory array.
 
-A bare agent command does not identify its conversation, so saving it verbatim would start another one on load. When `fleetcom` captures an ID for `claude`, `codex`, or `grok`, it stores the resume form instead. The result remains an ordinary command string that can run directly in a shell:
+A bare agent command does not identify its conversation, so saving it verbatim would start another one on load. When `fleetcom` captures an ID for `claude`, `codex`, `grok`, or `omp`, it stores the resume form instead. The result remains an ordinary command string that can run directly in a shell:
 
 ```json
 {