@ours.network/fleet 1.2.0-nightly.3 → 1.2.0-nightly.31

package/docs/room-layouts.md

@@ -0,0 +1,227 @@
+# YAML Room Layouts
+
+Room Layout describes room goals, participants and their shared or independent
+sessions. Rooms and agents have independent lifecycles.
+
+Place a layout at `fleet/room_layouts/<name>.yaml` beside the split configuration
+for `fleet.yaml`. Agent Templates remain in `fleet/agent_templates/`.
+
+```yaml
+version: 1
+participants:
+  product: {agent_template: Product}
+  developer: {agent_template: Developer}
+  qa: {agent_template: QA}
+rooms:
+  discovery:
+    goal: Clarify the problem and acceptance criteria
+    members: [product, developer, qa]
+  design:
+    goal: Review implementation choices
+    members: [developer, qa]
+  amigos:
+    goal: Resolve a concrete acceptance question
+    members: [product, developer, qa]
+    roles: {product: product, developer: developer, qa: qa}
+```
+
+Participant `instance_scope` controls instance reuse:
+
+- `layout` (default): repeating a participant key reuses its exact running instance
+  and session within this layout run.
+- `room`: each room using the key gets its own identity and session, lazily created
+  when that room opens. Repeated opens of the same active room reuse that instance.
+
+For example, one shared process doctor and one independent critic per room:
+
+```yaml
+version: 1
+participants:
+  doctor: {agent_template: ProcessDoctor, instance_scope: layout}
+  critic: {agent_template: Critic, instance_scope: room}
+rooms:
+  discovery:
+    goal: Agree on the problem
+    members: [doctor, critic]
+  design:
+    goal: Review the design
+    members: [doctor, critic]
+```
+
+Different keys using the same Agent Template still create independent instances.
+See the [shared](../examples/room-layouts/shared.yaml) and
+[fresh](../examples/room-layouts/fresh.yaml) examples, and the mixed
+[scoped](../examples/room-layouts/scoped.yaml) example. All choices can coexist.
+Fresh agents receive their room context. Supply relevant evidence through ordinary
+room messages or existing project documents when needed.
+
+A participant without `agent_template` requires a binding. `layout instance`
+returns a local exact reference (supervisor, agent, launch, CID and session).
+Pass participant-to-reference YAML to `create --bindings`. A stopped or replaced instance is rejected. Cross-Fleet bindings require
+an explicit owner grant, as described below.
+Room-scoped participants require `agent_template`; an explicit binding for them
+is rejected before creating resources. Bindings for layout-scoped participants
+keep their existing behavior.
+
+```sh
+ours-fleet layout validate work
+ours-fleet layout create work --id example
+ours-fleet layout open example design
+ours-fleet layout open example discovery
+ours-fleet layout open example amigos
+ours-fleet layout close-room example amigos
+ours-fleet layout status example
+ours-fleet layout close example
+```
+
+Any declared room may open first. `create` only saves the definition and resolved
+Agent Templates; `open` lazily starts missing participants and admits all members
+before sending their room context. The membership notification is informational. Existing room rules govern when
+an agent contributes. Each room opens through an explicit command.
+
+`close-room` archives a room and keeps agents available to other rooms. `close`
+archives opened rooms and stops only temporary participants created by this layout
+instance. Explicitly bound participants survive. Cleanup processes existing resources. A 3-Amigos room is an ordinary room with
+complementary members.
+Room-scoped instances follow the same cleanup rules: closing a room does not
+retire them, and a closed room cannot reopen. A new layout run creates new instances.
+
+Private state keeps the authorable definition unchanged. Its `participants` map
+uses the original key for shared instances and `<room>:<participant>` for
+room-scoped instances, with `participant` and `room` metadata. Declared but unopened
+rooms have no running instance. Status and task read models distinguish these
+entries and resolve their original Agent Template. Existing snapshots without
+`instance_scope` retain their original keys and require no migration. Snapshots
+using `room` require a Fleet version that supports this field; they are not a
+downgrade format for older Fleet versions.
+
+Supported room fields: `goal`, `members`, optional `roles`, `contract`,
+`quiet_membership`, `anonymous`. `contract` is briefing text.
+Top-level fields: `version: 1`, optional `description`, `participants`, `rooms`.
+Participant fields: optional `agent_template`, `instance_scope: layout|room`.
+Unknown fields, ambiguous YAML and invalid member references are rejected.
+Existing templates and tasks keep their behavior.
+
+Local Fleet control uses the existing authenticated control socket,
+agent runtime, `spawnTemp` and session queue. Cross-Fleet bindings delegate
+membership operations to their owning Fleet as described below. Private state
+snapshots template definitions; public status hides their environment values.
+Existing owner settings apply; owner CID/invite fingerprint are pinned. Unknown
+mutation outcomes stop new work for inspection rather than blindly replaying a
+spawn or room creation. `close` and `close-room` can still clean known resources.
+Cleanup continues after individual errors and does not stop replacement or borrowed
+instances. Confirmed stopped workers need no live control socket. An unknown
+original outcome remains recorded, and cleanup reports incomplete until inspected;
+it never claims that unknown resources were found or removed. Retrying cleanup
+checks known resources and skips completed cleanup. Reopening an active layout room
+checks its native state, CID and required seats and reports drift without repairing it.
+
+
+Shared sessions retain available conversation context, not guaranteed perfect
+recall or isolation between rooms. Compaction and model judgment still matter.
+Rooms keep their existing turn scheduling.
+
+Each layout instance creates distinct native room names, so several instances can
+open the same declared room key. Participant roles must differ from the attached
+owner role; a collision is rejected before creating resources.
+
+Definitions are loaded for authoring commands. Retained instances use their saved
+layout and Agent Templates. Status and cleanup operate on saved resources even
+when the source YAML is broken or removed. New agent launches continue to use
+Fleet's normal configuration and launch checks.
+
+## Borrowing an instance from another Fleet on the same host
+
+Fleet A can open rooms using standalone temporary or persistent agents supervised
+by Fleet B under another OS user. Both must select the same daemon instance and
+Cowork gateway. An agent's original Fleet keeps its session, identity and lifecycle
+control. This extends layout bindings; it does not add bindings to legacy
+`room create` / RoomTemplate provisioning.
+
+On the agent owner's Fleet B, use its existing web server and grant access to an
+exact live standalone instance:
+
+```sh
+ours-fleet web serve --port 49272 --no-open
+# In another terminal belonging to Fleet B's owner:
+ours-fleet layout share Architect --temporary --participant architect \
+  --server-url http://127.0.0.1:49272 --output ./architect.binding.yaml
+```
+
+The command prints the grant ID and output path. It creates a binding YAML and
+an adjacent `.token` file, both owner-only. The private owner record stores a
+SHA-256 token digest, not the token. `share` never overwrites an existing export.
+Transfer both files explicitly to Fleet A's user through your existing secure
+file-transfer method, keeping the receiving credential file owned by that user
+with mode `0600`. Do not share Fleet B's console session, client profile, daemon
+credential, private state directory or supervisor socket. This feature creates
+no additional server; Fleet B's existing web server must remain available.
+
+Export each specialist under its logical layout participant key, then merge the
+YAML mappings into one bindings document. Keep every adjacent token filename
+unique. Relative credential paths resolve against the bindings file's directory.
+The reusable layout contains participant factories or empty participant mappings,
+never concrete credentials or running-instance references:
+
+```yaml
+version: 1
+participants:
+  architect: {}
+  developer: {}
+  doctor: {}
+rooms:
+  product: {goal: Scope, members: [architect, doctor]}
+  design: {goal: Design, members: [architect, developer, doctor]}
+  delivery: {goal: Delivery, members: [developer, doctor]}
+```
+
+On Fleet A:
+
+```sh
+ours-fleet layout create project --id project-run --bindings ./bindings.yaml
+ours-fleet layout open project-run product
+ours-fleet layout open project-run design
+ours-fleet layout open project-run delivery
+ours-fleet layout close-room project-run product
+ours-fleet layout close project-run
+```
+
+The exact CID, launch and harness session are reused. Reopening an active room
+checks existing membership without delivering duplicate context. Closing rooms
+archives Cowork history and never stops borrowed instances. After acceptance,
+the original Fleet B owner explicitly retires its standalone temporary specialists
+using the existing lifecycle commands. Persistent specialists keep their ordinary
+lifecycle. Mixed local-created and borrowed participants are supported.
+
+An exported reference adds `remote` to the existing instance reference:
+
+```yaml
+remote:
+  url: http://127.0.0.1:49272
+  grant_id: 11111111-1111-4111-8111-111111111111
+  credential_file: architect.binding.yaml.token
+  daemon_instance_id: 22222222-2222-4222-8222-222222222222
+```
+
+The grant authorizes only `verify`, `join`, and `assign` for that exact instance.
+Room admission validates the requested room ID and CID against shared Cowork and
+uses an invite issued by Cowork on the owner side; caller-supplied contact invites
+are rejected before contact mutation. Context delivery also requires its active seat, expected room CID and role in
+Cowork. It cannot inspect inventory, spawn, stop, reconfigure, export identities,
+or authenticate browser console routes. It grants the holder room admission and
+room-context delivery, so transfer it only to the intended room creator.
+
+Owner-side revocation does not stop the agent or remove existing memberships:
+
+```sh
+ours-fleet layout revoke-binding <grant-id>
+```
+
+Stopped/replaced sessions, a different daemon, revoked grants or unavailable
+owner transport produce errors; no replacement is spawned. A lost response to a
+membership/context mutation retains the existing layout `uncertain` marker.
+Inspect the native room and owning Fleet before retrying; no mutation is blindly
+replayed. Only direct loopback HTTP origins (`127.0.0.1`) are supported;
+redirects, external hosts and forwarded requests are rejected. No cross-host
+support, discovery protocol, mission service, or room conversation limits are
+introduced.

package/docs/task-workspaces.md

@@ -0,0 +1,130 @@
+# Task workspaces and artifact retention
+
+New Tasks allocate a private workspace at
+`$OURS_FLEET_HOME/.ours-fleet/workspaces/tasks/<task-id>` (the user's home is the
+default for `OURS_FLEET_HOME`). New standalone Rooms use
+`.ours-fleet/workspaces/rooms/<room-id>`. A linked Room shares its Task's workspace.
+The absolute path, owner kind/ID and random ownership token are stored in the
+record before directory allocation; `.fleet-workspace.json` proves ownership.
+The path is visible in Task/Room JSON from both CLI and API. A folder of the same
+name without the matching marker is never adopted.
+
+Every newly managed member starts at that exact workspace, including retries.
+An explicit template/member `cwd` remains in the sealed input execution plan as
+source context, but the owned workspace overrides the effective launch cwd.
+Copy or clone required source into the workspace; Fleet does not move or delete
+the configured source directory. Briefings explain this rule. Use separate
+per-agent branches/directories inside the workspace for concurrent edits.
+
+All execution artifacts, dependency checkouts and worktrees belong inside the
+workspace. Clone each repository there first, then use `git worktree add` with
+destinations inside the same workspace. Git's native worktree registry is the
+registry of record. Fleet audits `.git`, `commondir` and reverse `gitdir` links
+before deletion; both the common repository and all registered worktrees must
+be inside the workspace. An external repository's worktree inside the workspace,
+or an internal repository's worktree outside it, blocks deletion. No broad
+`git worktree prune`, branch deletion, reset or modification of unrelated Git
+metadata is performed. Removing the owned repositories also removes their
+complete internal worktree registries, including dirty and stale owned entries.
+
+| Operation | Workspace and execution artifacts | Member runtime evidence |
+| --- | --- | --- |
+| Complete, fail, cancel | Retained while Task is recorded | Retained in Fleet recovery archives |
+| Linked Room retirement or deletion | Task workspace retained | Retained |
+| Internal standalone Room retirement | Room workspace retained | Retained |
+| Explicit Task deletion | Removed after member retirement | All proven owned retired launches removed |
+| Explicit standalone Room deletion | Removed after member retirement | All proven owned retired launches removed |
+
+Internal room close means retirement, not destructive Task deletion.
+The existing CLI `room close ID ID` remains a deprecated alias for explicit
+`room delete ID ID`: it deletes standalone room-owned artifacts, but always
+retains a linked Task workspace. Its repeated-ID confirmation is unchanged. To remove a Task's
+artifacts, explicitly delete the Task. Cancellation is not deletion. Automatic
+compatibility cleanup of legacy closed Rooms skips records with owned workspaces.
+These choices reconcile close/remove wording with the requirement that completed,
+recorded Tasks retain all artifacts.
+
+Fleet's active member state (briefings, logs, session state and WORKLOG) remains
+under `.ours-fleet/tmp` while supervisors run, then in
+`.ours-fleet/recovery/temporary`. The launch stores the workspace descriptor.
+Explicit deletion first proves managed agents retired, then identifies all
+matching archived launches, including failed and replaced attempts, using the
+workspace descriptor plus role and termination/launch evidence. It preflights
+these archives and atomically transfers them to `.fleet-retired-agents` in the
+workspace before removal. Unrelated archives are not adopted by a name prefix.
+Explicit deletion also erases legacy archives with exact launch/action or room
+provenance, matching private supervisor journals and admission/launch descriptors,
+and the exact retired-launch rows in the global termination journal. It never
+infers ownership from an Agent's shared `cwd`. Artifact removal uses a durable
+manifest, ownership fingerprints and per-entry rename/removal checkpoints, so
+an interrupted deletion can resume without deleting a replacement at the old path.
+Task deletion acceptance receipts exist only during cleanup and are erased after
+settlement (including retry after a crash between Task unlink and receipt cleanup).
+Shared Fleet command audit and lifecycle delivery ledgers have exactly attributed
+target labels, configuration and command arguments removed; unrelated entries are
+preserved. Delivery/deduplication metadata and a content-free erased-resource ID
+registry remain so a running writer cannot resurrect erased content. Infrastructure
+logs without structured ownership, backups, and copies already delivered to other
+identities are external retention boundaries; this is not a claim to erase every
+external copy.
+
+Provisioning serializes Task operation then Room close locks, including bounded
+seat waits, so concurrent retries cannot publish competing members and deletion
+cannot race a member launch. Local published Rooms are reused if the Task link
+write was interrupted. Workspace allocation publishes a marked staging directory;
+restart reuses the durable token. Deletion renames the validated workspace to a
+token-specific sibling tombstone before removal. A crash during removal resumes
+that exact tombstone; the Task record is unlinked last. Before collecting archives,
+Task deletion durably checkpoints verified retirement evidence. Retries verify
+any remaining original archive and still refuse replacement live member state
+or a recreated identity even after the archive has been consumed. Failed deletion
+remains retryable with its recorded error.
+
+Deletion rejects traversal, foreign recorded paths, changed markers and symlinked
+workspace ancestors. Ordinary artifact symlinks are unlinked without following
+their targets. Git control symlinks and foreign pointers are refused. As with
+Fleet's other filesystem lifecycle operations, a hostile same-UID process that
+mutates paths during validation requires OS isolation; application checks are
+not a security boundary against that process. Fleet enforces launch cwd and
+safe deletion; unrestricted agents can still write outside cwd, so the artifact
+placement rule also requires agent compliance and/or filesystem isolation.
+
+## Compatibility and limits
+
+Records from before this feature without `workspace` remain unmanaged. Existing
+agents retain their cwd and exact briefing/fingerprint so restart matching works.
+Fleet never claims an old cwd, an outcome artifact path, or a legacy recovery
+archive as owned merely because it was mentioned by a Task. Create a new managed
+Task and explicitly copy desired artifacts to migrate; deleting a legacy Task
+continues its previous lifecycle and does not delete arbitrary old files.
+
+Changing `OURS_FLEET_HOME` does not silently rebase recorded absolute ownership
+paths. Restore the original state root or explicitly migrate records and files
+with the supervisors stopped; mismatched paths fail closed. Archive transfer
+uses same-filesystem rename and reports a recoverable failure across mounts.
+
+Cowork's remote create operation has no idempotency key in this interface. A crash
+after remote creation but before local Room publication is an existing uncertain
+remote result; this change deduplicates locally recorded rooms and does not claim
+to solve that remote transaction window. Inspect remote room ownership before
+retrying ambiguous remote creation. No services or installed Fleet code are
+changed by building or testing this feature.
+
+
+## Broken provisioning and deletion recovery
+
+Deletion accepts every lifecycle state. Missing temporary directories, identities,
+remote rooms and already-erased artifacts are settled outcomes. Retry the same
+explicit delete after an interruption. A missing local member CID is recovered
+only from a matching authenticated seat in the pinned room (exact invite and
+role, uniquely matched), or a supervisor journal tied to the selected daemon,
+temporary instance and recorded creation action. These sources must agree.
+The recovered CID is persisted before retirement consumes the evidence.
+
+A contradictory CID, replacement launch, ambiguous seat, unreadable/corrupt
+record, or unreachable authority is not evidence of absence. Cleanup retains its
+cursor and reports the conflict instead of deleting an unrelated resource or
+claiming complete erasure. An identity with no recoverable authenticated binding
+requires restoring its actual ownership evidence; a name-only force removal is
+not supported. Room deletion removes the linked Task's dead room/member links and preserves its workspace; use explicit
+Task deletion when the request includes the associated Task and its artifacts.

package/examples/room-layouts/fresh.yaml

@@ -0,0 +1,27 @@
+version: 1
+description: Separate participant keys create independent agent sessions for each room
+participants:
+  productArchitect:
+    agent_template: Architect
+  productReviewer:
+    agent_template: Reviewer
+  designArchitect:
+    agent_template: Architect
+  designDeveloper:
+    agent_template: Developer
+  designReviewer:
+    agent_template: Reviewer
+  deliveryDeveloper:
+    agent_template: Developer
+  deliveryReviewer:
+    agent_template: Reviewer
+rooms:
+  product:
+    goal: Agree on the problem and acceptance criteria
+    members: [productArchitect, productReviewer]
+  design:
+    goal: Design the accepted solution
+    members: [designArchitect, designDeveloper, designReviewer]
+  delivery:
+    goal: Implement and verify the accepted design
+    members: [deliveryDeveloper, deliveryReviewer]

package/examples/room-layouts/scoped.yaml

@@ -0,0 +1,21 @@
+version: 1
+description: Shared specialists and one independent reviewer per room
+participants:
+  architect:
+    agent_template: Architect
+    instance_scope: layout
+  developer:
+    agent_template: Developer
+  reviewer:
+    agent_template: Reviewer
+    instance_scope: room
+rooms:
+  product:
+    goal: Agree on the problem and acceptance criteria
+    members: [architect, reviewer]
+  design:
+    goal: Design the accepted solution
+    members: [architect, developer, reviewer]
+  delivery:
+    goal: Implement and verify the accepted design
+    members: [developer, reviewer]

package/examples/room-layouts/shared.yaml

@@ -0,0 +1,19 @@
+version: 1
+description: Same agents retain their sessions across rooms
+participants:
+  architect:
+    agent_template: Architect
+  developer:
+    agent_template: Developer
+  reviewer:
+    agent_template: Reviewer
+rooms:
+  product:
+    goal: Agree on the problem and acceptance criteria
+    members: [architect, reviewer]
+  design:
+    goal: Design the accepted solution
+    members: [architect, developer, reviewer]
+  delivery:
+    goal: Implement and verify the accepted design
+    members: [developer, reviewer]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ours.network/fleet",
-  "version": "1.2.0-nightly.3",
+  "version": "1.2.0-nightly.31",
   "description": "Harness-agnostic fleet of persistent, identity-bound AI agents. Declarative fleet.yaml, managed native/ACP sessions, supervision, and ours.network messaging.",
   "type": "module",
   "license": "FSL-1.1-Apache-2.0",
@@ -18,21 +18,21 @@
     "examples",
     "presets",
     "README.md",
+    "docs/task-workspaces.md",
+    "docs/room-layouts.md",
     "LICENSE"
   ],
   "engines": {
-    "node": ">=22"
+    "node": ">=22.13.0"
   },
   "scripts": {
     "clean": "node -e \"require('node:fs').rmSync('dist',{recursive:true,force:true})\"",
-    "build": "npm run clean && tsc -p tsconfig.json && vite build && node scripts/build-info.mjs",
-    "typecheck": "tsc -p tsconfig.json --noEmit && tsc -p web/tsconfig.json --noEmit",
+    "build": "npm run clean && tsc -p tsconfig.json && node scripts/copy-web.mjs && node scripts/build-info.mjs",
+    "typecheck": "tsc -p tsconfig.json --noEmit",
     "lint": "npm run typecheck",
     "test": "vitest run",
     "test:web": "vitest run test/web",
     "test:pack": "vitest run --config vitest.integration.config.ts",
-    "test:e2e": "npm run build && playwright test",
-    "dev:web": "vite",
     "prepack": "npm run build",
     "prepublishOnly": "npm run build && npm test",
     "test:v1-recovery": "node test/fleet-v1-recovery.integration.mjs retry && node test/fleet-v1-recovery.integration.mjs terminal-after-failure && node test/fleet-v1-recovery.integration.mjs terminal-release-failure"
@@ -41,12 +41,12 @@
     "@agentclientprotocol/sdk": "^1.3.0",
     "@fastify/static": "^10.1.2",
     "@fastify/websocket": "^11.2.0",
-    "@ours.network/cli": "2.8.1-nightly.7",
-    "@ours.network/sdk": "3.8.1-nightly.9",
+    "@ours.network/cli": "2.8.1-nightly.13",
+    "@ours.network/mcp": "1.2.0-nightly.10",
+    "@ours.network/sdk": "3.8.1-nightly.15",
     "commander": "^12.1.0",
     "fastify": "^5.4.0",
-    "react": "^19.1.1",
-    "react-dom": "^19.1.1",
+    "qrcode": "1.5.4",
     "secure-json-parse": "^4.1.0",
     "ws": "^8.18.3",
     "yaml": "^2.5.0"
@@ -56,14 +56,11 @@
     "@agentclientprotocol/codex-acp": "1.10.0"
   },
   "devDependencies": {
-    "@playwright/test": "^1.54.1",
-    "@types/node": "^20.14.0",
-    "@types/react": "^19.1.9",
-    "@types/react-dom": "^19.1.7",
+    "@ours.network/daemon": "3.8.1-nightly.7",
+    "@types/node": "^22.20.4",
+    "@types/qrcode": "^1.5.6",
     "@types/ws": "^8.18.1",
     "typescript": "^5.5.0",
-    "vite": "^7.0.6",
-    "vitest": "^2.0.0",
-    "@ours.network/daemon": "3.8.1-nightly.1"
+    "vitest": "^2.0.0"
   }
 }

package/presets/README.md

@@ -0,0 +1,78 @@
+# Predefined Brains
+
+`brain-catalog.json` is the source for generated `fleet/brains/*.yaml` files.
+Run `node scripts/generate-brain-presets.mjs` after changing it, and run the same
+command with `--check` to verify generated files. An empty `efforts` array generates
+one `-default` preset with no `effort` field. Bootstrap adds missing presets and
+preserves existing user files. Existing model presets remain available.
+
+## GPT-6.1 Sol (added 2026-09-29)
+
+The Codex presets `codex-gpt-6-1-sol-{low,medium,high,xhigh,max,ultra}`
+use the exact model ID `gpt-6.1-sol` with ACP sessions. The init wizard offers
+GPT-6.1 Sol for development, review, and coordination.
+
+[Official OpenAI documentation](https://developers.openai.com/api/docs/models/gpt-6.1-sol)
+supports low, medium, high, xhigh, and max API reasoning efforts. The local
+Codex `models_cache.json` inspected on 2026-09-29 additionally advertises
+`ultra`, a Codex harness mode. These presets reflect that six-effort Codex
+catalog; no inference or ACP launch was performed for this addition.
+
+## Current model additions (verified 2026-09-24)
+
+| Harness | Exact model ID | Preset efforts |
+| --- | --- | --- |
+| Codex | `gpt-6-sol` | low, medium, high, xhigh, max, ultra |
+| Codex | `gpt-6-luna` | low, medium, high, xhigh, max |
+| Claude Code | `claude-fable-5-1` | low, medium, high, xhigh, max |
+| Claude Code | `claude-opus-5-5` | low, medium, high, xhigh, max |
+| Claude Code (retained) | `claude-sonnet-5` | low, medium, high, xhigh, max |
+| Claude Code | `claude-haiku-4-5-20251001` | default, with no effort setting |
+
+For example, select `codex-gpt-6-sol-ultra`, `claude-opus-5-5-max`, or
+`claude-haiku-4-5-20251001-default` as a Brain reference. The init wizard offers
+models supporting its Quick/Balanced/Thorough (low/medium/high) choices; use the
+named Brain directly for Haiku, which does not support effort.
+
+### Runtime requirements and evidence
+
+Codex CLI **0.155.0** freshly queried through `app-server` `initialize` then
+`model/list` advertised the GPT rows above. A previously populated
+`~/.codex/models_cache.json` did not contain these models; refresh runtime discovery
+before concluding a model is unavailable. `ours-fleet doctor` compares presets to
+the local cache. The catalog is not an account entitlement guarantee.
+
+The [Sol](https://developers.openai.com/api/docs/models/gpt-6-sol) and
+[Luna](https://developers.openai.com/api/docs/models/gpt-6-luna) API model pages
+also support `none`, but the verified Codex runtime does not advertise it.
+Consequently there are no `none` presets. Sol's `ultra` is an advertised Codex
+harness mode, not an additional API reasoning level; Luna does not advertise it.
+
+Claude Code **2.1.281** was verified using the Agent SDK `supportedModels()`
+control request, with `pathToClaudeCodeExecutable` pointing to the installed
+Claude CLI, without sending an inference prompt. It reports Fable 5.1, Opus 5.5,
+Sonnet 5 and Haiku 4.5 with the capabilities above. These are verified versions,
+not asserted minimum versions. Provider references:
+[model IDs](https://platform.claude.com/docs/en/models/overview) and
+[Claude Code effort support](https://code.claude.com/docs/en/model-config#adjust-effort-level).
+
+**Check the executable used by ACP before selecting the new Claude presets.**
+The inspected `claude-agent-acp` **0.63.0** installation bundles Agent SDK
+**0.3.220**, whose default executable reports older models. To use the verified
+installed Claude CLI, set `CLAUDE_CODE_EXECUTABLE` to its absolute path in the
+launch environment (for example `/usr/bin/claude` on the verification host).
+Otherwise use a bundled SDK whose runtime advertises these models and efforts.
+The presets do not change your executable or restart agents. An older bundled
+runtime alone is not evidence of support for the new models.
+
+No-prompt ACP startup and `session/set_config_option` probes also verified all
+new GPT and Claude effort combinations, including Sol `ultra` and Claude `max`;
+Haiku startup advertises no effort option. The probes used Codex ACP 1.10.0
+with the installed Codex executable and Claude ACP 0.63.0 with the native override.
+
+ACP builds effort options from the selected model's `supportedEffortLevels` and
+applies the selection through the SDK's session flag settings. This supports
+`max` without writing it to persistent `effortLevel` settings. Fleet verifies
+that ACP applied the requested effort and fails on rejection. `ultracode` is a
+separate Claude orchestration setting and is not a model effort preset. Account
+and organization restrictions still apply at launch; no fallback model is added.

package/presets/brain-catalog.json

@@ -1,6 +1,6 @@
 {
   "schema_version": 1,
-  "catalog_revision": 2,
+  "catalog_revision": 4,
   "models": [
     { "harness": "codex", "session": "acp", "model": "gpt-6-astra", "efforts": ["low", "medium", "high", "xhigh", "max", "ultra"] },
     { "harness": "codex", "session": "acp", "model": "gpt-5.6-sol", "efforts": ["low", "medium", "high", "xhigh", "max", "ultra"] },
@@ -12,6 +12,12 @@
     { "harness": "codex", "session": "acp", "model": "gpt-5.3-codex-spark", "efforts": ["low", "medium", "high", "xhigh"] },
     { "harness": "claude-code", "session": "acp", "model": "claude-fable-5", "efforts": ["low", "medium", "high", "xhigh", "max"] },
     { "harness": "claude-code", "session": "acp", "model": "claude-opus-5", "efforts": ["low", "medium", "high", "xhigh", "max"] },
-    { "harness": "claude-code", "session": "acp", "model": "claude-sonnet-5", "efforts": ["low", "medium", "high", "xhigh", "max"] }
+    { "harness": "claude-code", "session": "acp", "model": "claude-sonnet-5", "efforts": ["low", "medium", "high", "xhigh", "max"] },
+    { "harness": "codex", "session": "acp", "model": "gpt-6.1-sol", "efforts": ["low", "medium", "high", "xhigh", "max", "ultra"] },
+    { "harness": "codex", "session": "acp", "model": "gpt-6-sol", "efforts": ["low", "medium", "high", "xhigh", "max", "ultra"] },
+    { "harness": "codex", "session": "acp", "model": "gpt-6-luna", "efforts": ["low", "medium", "high", "xhigh", "max"] },
+    { "harness": "claude-code", "session": "acp", "model": "claude-fable-5-1", "efforts": ["low", "medium", "high", "xhigh", "max"] },
+    { "harness": "claude-code", "session": "acp", "model": "claude-opus-5-5", "efforts": ["low", "medium", "high", "xhigh", "max"] },
+    { "harness": "claude-code", "session": "acp", "model": "claude-haiku-4-5-20251001", "efforts": [] }
   ]
 }

package/presets/fleet/agent_templates/Engineer.yaml

@@ -0,0 +1,5 @@
+role: { ref: Engineer }
+brain: { ref: claude-default }
+coordinator: FleetCoordinator
+permissions: { approval: ask, filesystem: workspace, unattended: deny }
+monitor: { mode: fleet, interrupt: after_tool }

package/presets/fleet/brains/claude-fable-5-1-high.yaml

@@ -0,0 +1,5 @@
+# Generated from presets/brain-catalog.json revision 4.
+harness: claude-code
+session: acp
+model: claude-fable-5-1
+effort: high

package/presets/fleet/brains/claude-fable-5-1-low.yaml

@@ -0,0 +1,5 @@
+# Generated from presets/brain-catalog.json revision 4.
+harness: claude-code
+session: acp
+model: claude-fable-5-1
+effort: low

package/presets/fleet/brains/claude-fable-5-1-max.yaml

@@ -0,0 +1,5 @@
+# Generated from presets/brain-catalog.json revision 4.
+harness: claude-code
+session: acp
+model: claude-fable-5-1
+effort: max

package/presets/fleet/brains/claude-fable-5-1-medium.yaml

@@ -0,0 +1,5 @@
+# Generated from presets/brain-catalog.json revision 4.
+harness: claude-code
+session: acp
+model: claude-fable-5-1
+effort: medium

package/presets/fleet/brains/claude-fable-5-1-xhigh.yaml

@@ -0,0 +1,5 @@
+# Generated from presets/brain-catalog.json revision 4.
+harness: claude-code
+session: acp
+model: claude-fable-5-1
+effort: xhigh

package/presets/fleet/brains/claude-fable-5-high.yaml

@@ -1,4 +1,4 @@
-# Generated from presets/brain-catalog.json revision 2.
+# Generated from presets/brain-catalog.json revision 4.
 harness: claude-code
 session: acp
 model: claude-fable-5

package/presets/fleet/brains/claude-fable-5-low.yaml

@@ -1,4 +1,4 @@
-# Generated from presets/brain-catalog.json revision 2.
+# Generated from presets/brain-catalog.json revision 4.
 harness: claude-code
 session: acp
 model: claude-fable-5