@ours.network/fleet-codex 0.3.4 → 0.3.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (4) hide show
  1. package/.codex-plugin/plugin.json +1 -1
  2. package/package.json +1 -1
  3. package/skills/oversee-agents/SKILL.md +5 -1
  4. package/skills/spawn-ours-agent/SKILL.md +30 -17
package/.codex-plugin/plugin.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "ours-fleet",
3
- "version": "0.3.4",
3
+ "version": "0.3.5",
4
4
  "description": "Spawn, configure, and oversee ours-fleet roles from OpenAI Codex.",
5
5
  "author": {
6
6
  "name": "Adapt Framework Solutions Ltd",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@ours.network/fleet-codex",
3
- "version": "0.3.4",
3
+ "version": "0.3.5",
4
4
  "description": "Native Codex plugin for spawning, configuring, and overseeing ours-fleet agents.",
5
5
  "type": "module",
6
6
  "license": "FSL-1.1-Apache-2.0",
package/skills/oversee-agents/SKILL.md CHANGED
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: oversee-agents
3
- description: Inspect, monitor, and unstick ours-fleet agents from Codex using their tmux consoles and supervisor state. Use when the user asks to keep an eye on agents, oversee spawned roles, check agent status, babysit a subagent, resolve a fleet prompt, or when Codex has just spawned a role and should verify its progress.
3
+ description: Inspect, monitor, and unstick ours-fleet agents from Codex using their tmux or ACP session controls and supervisor state. Use when the user asks to keep an eye on agents, oversee spawned roles, check agent status, babysit a subagent, resolve a fleet prompt, or when Codex has just spawned a role and should verify its progress.
4
4
  ---
5
5
 
6
6
  # Oversee ours-fleet agents
@@ -8,6 +8,7 @@ description: Inspect, monitor, and unstick ours-fleet agents from Codex using th
8
8
  Use fleet state and console output as evidence:
9
9
 
10
10
  ```sh
11
+ ours-fleet docs
11
12
  ours-fleet ls
12
13
  ours-fleet peek <Name> [lines]
13
14
  ours-fleet status <Name>
@@ -16,6 +17,9 @@ ours-fleet send <Name> "<text>"
16
17
  ours-fleet send <Name> --key <key>
17
18
  ```
18
19
 
20
+ Text `send`, `peek`, and `attach` work for tmux and ACP. Raw `send --key` is
21
+ tmux-only; use the `/permit` control shown by ACP `attach` for ACP permissions.
22
+
19
23
  ## Establish scope
20
24
 
21
25
  Identify wards from the user's request, the current role briefing, or agents
package/skills/spawn-ours-agent/SKILL.md CHANGED
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: spawn-ours-agent
3
- description: Spawn and configure a new ours-fleet agent from Codex, either as a supervised persistent role or a temporary tmux agent. Use when the user asks to spawn an agent, create a fleet role, start a background agent, delegate work to another Codex session, choose its model or permissions, or create a subagent that should have its own ours identity and console.
3
+ description: Spawn and configure a new ours-fleet agent from Codex, with a permanent or temporary lifetime and a tmux or ACP session. Use when the user asks to spawn an agent, create a fleet role, start a background agent, delegate work to another Codex session, choose its model, session, or permissions, or create a subagent with its own ours identity and console.
4
4
  ---
5
5
 
6
6
  # Spawn an ours-fleet agent
@@ -13,18 +13,21 @@ the current conversation.
13
13
  Run:
14
14
 
15
15
  ```sh
16
+ ours-fleet docs
16
17
  ours-fleet doctor --harness codex
17
18
  ```
18
19
 
19
- Stop at a failed required check. Explain that `ours-codex` is preferred for
20
- background mail wake and native `codex` is the supported fallback.
20
+ Treat `ours-fleet docs` from the installed CLI as authoritative for supported
21
+ session backends, common permissions, and flags. Stop at a failed required
22
+ doctor check.
21
23
 
22
24
  ## 2. Resolve the role design
23
25
 
24
26
  Ask only for choices not already supplied:
25
27
 
26
28
  - **Lifetime:** permanent (supervised, restartable, survives reboot) or
27
- temporary (one tmux session, removed on exit).
29
+ temporary (detached supervisor, removed on exit/reboot).
30
+ - **Session:** `tmux` or `acp`; both permanent and temporary roles support both.
28
31
  - **Name:** `[A-Za-z0-9_-]+`; confirm it is absent from `ours-fleet config` and
29
32
  `ours-fleet ls`.
30
33
  - **Mission and working directory.**
@@ -36,20 +39,26 @@ Ask only for choices not already supplied:
36
39
  - **Mail monitoring:** explicitly ask whether to arm it. Pass `--monitor` only
37
40
  after a clear yes. This consent persists in the role configuration.
38
41
 
39
- Offer Codex controls when relevant; otherwise use safe defaults:
42
+ Prefer common permission intent:
43
+
44
+ - approval: `--approval ask|allow|deny`
45
+ - filesystem: `--filesystem read-only|workspace|unrestricted`
46
+ - unattended ACP behavior: `--unattended deny|wait`
47
+
48
+ Offer Codex-native controls when relevant:
40
49
 
41
50
  - model: launcher default or `--model <id>`
42
- - approval: `untrusted`, `on-request`, or `never`
43
- - sandbox: `read-only`, `workspace-write`, or `danger-full-access`
51
+ - native approval: `--permission-mode untrusted|on-request|never`
52
+ - native sandbox: `--sandbox read-only|workspace-write|danger-full-access`
44
53
  - launcher: `auto` (preferred), `ours-codex`, or `codex`
45
54
  - profile: `--profile <name>`
46
55
  - search: `--search`
47
56
  - arbitrary config: repeatable `--codex-config key=value`
48
57
  - additional writable roots: repeatable `--add-dir <path>`
49
58
 
50
- Default to `--harness codex --launcher auto --sandbox workspace-write
51
- --permission-mode on-request`. Never select `danger-full-access` or `never`
52
- without explicit user direction.
59
+ Default to `--harness codex --session tmux --launcher auto --approval ask
60
+ --filesystem workspace --unattended deny`. Never select unrestricted access,
61
+ `danger-full-access`, `never`, or common `allow` without explicit user direction.
53
62
 
54
63
  ## 3. Materialize approved profile text
55
64
 
@@ -62,13 +71,15 @@ Build an argument array from the approved choices. Permanent example:
62
71
 
63
72
  ```sh
64
73
  ours-fleet spawn Worker --harness codex --launcher auto \
74
+ --session <tmux|acp> \
65
75
  --mission "Own the worker implementation" --cwd /absolute/project \
66
76
  --bio-file /tmp/worker-bio.md --persona-file /tmp/worker-persona.md \
67
- --sandbox workspace-write --permission-mode on-request \
77
+ --approval ask --filesystem workspace --unattended deny \
68
78
  --coordinator Coordinator
69
79
  ```
70
80
 
71
- Add `--temp` for a temporary role and `--monitor` only after monitoring consent.
81
+ Add `--temp` for a temporary role; it can also use `--session acp`.
82
+ Pass `--monitor` only after monitoring consent.
72
83
  Pass model, profile, search, config, and additional directories exactly as
73
84
  approved. Do not persist secrets in `--codex-config` or fleet YAML; use the
74
85
  role's `env` configuration for environment-based credentials.
@@ -82,12 +93,14 @@ ours-fleet peek <Name> 60
82
93
  ours-fleet status <Name>
83
94
  ```
84
95
 
85
- For a temporary role, status may not have a system service; the tmux console is
86
- authoritative. Confirm that Codex loaded its briefing and reached identity
87
- binding. First use can display Codex authorization prompts for ours MCP tools.
96
+ For ACP, `status` must report `backend: acp`, `alive: true`, and a running/idle
97
+ readiness. For a temporary tmux role, the pane is authoritative. Confirm that
98
+ Codex loaded its briefing and reached identity binding. First use can display
99
+ Codex authorization prompts for ours MCP tools.
88
100
  Surface those prompts to the user; do not grant persistent trust without their
89
- explicit approval. Use `ours-fleet send <Name> --key <choice>` only for the
90
- authorization scope the user approved.
101
+ explicit approval. Use `ours-fleet send <Name> --key <choice>` only for tmux and
102
+ only for the authorization scope the user approved; ACP permissions are answered
103
+ through `ours-fleet attach`.
91
104
 
92
105
  If monitoring was approved, confirm the console reports `arm_monitor` success.
93
106
  Under native Codex, expect the role to surface the `ours-codex` recommendation