overlord-cli 0.2608311101.0 → 0.2609011854.0

package/dist/connectors/AGENTS.md

@@ -162,12 +162,23 @@ emits back to the harness.
 
 ### Where the session channel comes from
 
+**As of the Latch v2 cutover, this creation path is not currently wired into either launch
+surface.** `createSessionChannel` (`packages/core/service/agent-session/channels.ts`) has no
+production callers today: `POST /api/missions/:id/session-channel` is a permanent stub that
+throws `410 session_controls_gone` for every caller (`backend/agent-session-routes.ts`,
+`prepareMissionSessionChannel`), and neither `ovld launch`'s call site nor the runner-dispatched
+launch call site passes a `sessionChannelId`/`sessionChannelToken` into `launchAgent`. In
+practice, a launched agent's environment does not carry `OVERLORD_SESSION_CHANNEL_ID` today, so
+`connectors/core/scripts/agent-session-hook.sh` exits before spawning `ovld` on every
+invocation. Treat the table below as the intended design this module retains, not live
+behavior — do not build against it assuming a channel exists at launch.
+
 The credential your adapter's CLI call presents is not something the adapter finds or derives:
 
 | Launch                 | Channel created at                       | Credential reaches the process via                  |
 | ---------------------- | ---------------------------------------- | --------------------------------------------------- |
-| Queued (runner)        | the `launching` transition               | owner-only local cache, keyed by channel id         |
-| Manual (`ovld launch`) | `POST /api/missions/:id/session-channel` | owner-only local cache, keyed by channel id         |
+| Queued (runner)        | the `launching` transition (not wired)   | owner-only local cache, keyed by channel id         |
+| Manual (`ovld launch`) | `POST /api/missions/:id/session-channel` (retired; returns 410) | owner-only local cache, keyed by channel id |
 | Virtual gateway        | the same preparation service             | `OVERLORD_SESSION_CHANNEL_TOKEN` in the environment |
 
 Only `OVERLORD_SESSION_CHANNEL_ID` is exported into the launch environment and the terminal

package/dist/connectors/README.md

@@ -86,10 +86,10 @@ contributor adding an adapter can tell signal from neglect. Source of truth for
 
 | Adapter       | Commands      | Hooks                                                 | Local MCP shim | MCP config        | Rules    | Native resume |
 | ------------- | ------------- | ----------------------------------------------------- | -------------- | ----------------- | -------- | ------------- |
-| `claude`      | `commands/`   | `hooks/hooks.json` (5 types)                          | —              | —                 | —        | —             |
+| `claude`      | `commands/`   | `hooks/hooks.json` (3 types)                          | —              | —                 | —        | —             |
 | `codex`       | —             | `.codex-plugin/hooks.json` + `scripts/*.sh` (2 types) | rendered       | `.mcp.json`       | —        | yes           |
 | `cursor`      | `commands/`   | `hooks/*.sh` (4 types)                                | rendered       | `mcp.json`        | `rules/` | —             |
-| `antigravity` | `skills/*.md` | `hooks.json` + `scripts/*.sh` (2 types)               | rendered       | `mcp_config.json` | —        | —             |
+| `antigravity` | `skills/*.md` | `hooks.json` (0 types — none shipped yet)             | rendered       | `mcp_config.json` | —        | —             |
 | `pi`          | —             | `extensions/overlord.ts` (input/tool/session events)  | —              | —                 | —        | yes           |
 | `opencode`    | —             | none — control plane, see below                       | —              | —                 | —        | —             |
 
@@ -103,6 +103,11 @@ Intentional omissions:
   yet start it automatically. A supervised execution target must supply that launch integration.
 - **`claude` ships no local MCP shim.** The Claude plugin reaches Overlord's hosted
   MCP server, so a local stdio bridge would duplicate it.
+- **`claude` ships a 4th hook script, `scripts/permission-hook.sh`, that is not registered in
+  `hooks/hooks.json`.** It is a declared hazard (`shipped-permission-hook-inert` in
+  `connectors/adapters/claude/CAPABILITIES.md`), not live behavior: it calls a
+  `ovld protocol permission-request` subcommand that does not exist and is structurally
+  incapable of returning a decision even once wired in.
 - **`pi` ships no shim, hooks directory, or commands.** PI integrates through one TypeScript
   extension. It has no native permission dialog; its optional `tool_call` decision interceptor
   is fail-open and requires explicit workspace and project opt-in.

package/dist/connectors/VERSION

@@ -1 +1 @@
-0.3.40
+0.3.41

package/dist/connectors/adapters/antigravity/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://antigravity.google/schemas/v1/plugin.json",
   "name": "overlord",
-  "version": "0.3.40",
+  "version": "0.3.41",
   "description": "Chat-driven access to Overlord mission protocol workflows through skills and MCP.",
   "author": {
     "name": "Cooperativ",

package/dist/connectors/adapters/claude/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "overlord",
-  "version": "0.3.40",
+  "version": "0.3.41",
   "description": "Overlord mission protocol workflow for Claude Code — attach/update/ask/deliver, slash commands, and hook-driven activity capture.",
   "author": {
     "name": "Cooperativ",

package/dist/connectors/adapters/codex/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "overlord",
-  "version": "0.3.40",
+  "version": "0.3.41",
   "description": "Chat-driven access to Overlord mission protocol workflows with hook-driven activity capture.",
   "author": {
     "name": "Cooperativ",

package/dist/connectors/adapters/cursor/.cursor-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "overlord",
-  "version": "0.3.40",
+  "version": "0.3.41",
   "description": "Overlord mission protocol workflow for Cursor — attach/update/ask/deliver, slash commands, MCP bridge, and follow-up capture.",
   "author": {
     "name": "Cooperativ",

package/dist/connectors/core/overlord-mission/SKILL.md

@@ -21,7 +21,7 @@ Use this mode when the prompt already contains a mission ID or explicitly says t
 2. The attach response prints JSON to stdout containing `session.sessionKey`. The CLI also persists this key automatically so subsequent `ovld protocol` commands in the same working directory resolve it without `--session-key`. If auto-resolution fails, pass `--session-key <sessionKey>` explicitly on every subsequent call.
 3. Treat the Overlord mission prompt as authoritative for the objective, constraints, and delivery target. Begin executing the current objective immediately after attach; do not wait for more instructions or ask for confirmation. This differs from `connect` or `load-context`, which only retrieve mission context and never imply the agent should act.
 4. Post updates while working: `ovld protocol update --session-key <sessionKey> --mission-id <mission_id> --summary "..." --phase execute`.
-   During long mechanical stretches with nothing meaningful to post, send `ovld protocol heartbeat --session-key <sessionKey> --mission-id <mission_id> [--phase execute] [--percent <0-100>] [--note "..."]` instead of an empty update.
+   During long mechanical stretches with nothing meaningful to post, send `ovld protocol heartbeat --session-key <sessionKey> --mission-id <mission_id> [--phase execute] [--note "..."]` instead of an empty update.
 5. Follow-up messages after the initial mission are captured automatically by the installed `UserPromptSubmit` hook and stay in discussion intent while the mission is in review. Do not post `user_follow_up` manually unless the hook is unavailable.
 6. If blocked, call `ovld protocol ask --session-key <sessionKey> --mission-id <mission_id> --question "..."` and stop.
 7. Deliver last with `ovld protocol deliver --session-key <sessionKey> --mission-id <mission_id> --summary "..."`. Normal delivery is summary-only; objective-ledger evidence syncs independently.
@@ -116,7 +116,7 @@ ovld protocol update --session-key <sessionKey> --mission-id $MISSION_ID --summa
 ### Heartbeat
 
 ```bash
-ovld protocol heartbeat --session-key <sessionKey> --mission-id $MISSION_ID --phase execute --percent 40 --note "Running the integration suite"
+ovld protocol heartbeat --session-key <sessionKey> --mission-id $MISSION_ID --phase execute --note "Running the integration suite"
 ```
 
 Use `heartbeat` for liveness pings and transient UI telemetry when you have no meaningful narrative summary to post. It updates the attached session without creating a mission event.
@@ -293,7 +293,7 @@ ovld protocol create --agent <agent-identifier> --objectives-json '[{"objective"
 ```
 
 ```bash
-ovld protocol prompt --agent <agent-identifier> --objectives-json '[{"objective":"Implement feature X"}]' --priority medium
+ovld protocol prompt --agent <agent-identifier> --objectives-json '[{"objective":"Implement feature X"}]'
 ```
 
 ```bash
@@ -304,17 +304,6 @@ ovld protocol add-objectives --mission-id 1:899 --objectives-json '[{"objective"
 ovld protocol update-objective --objective-id <objective-uuid> --auto-advance
 ```
 
-#### Local Durability For New Missions
-
-`create`, `prompt`, `add-objectives`, and `record-work` save the objective/mission text to a local draft (`~/.overlord/pending-missions/`) **before** sending it, and delete that draft only once the server confirms the write. If the network drops mid-call, your text is never lost — the failure message points at the saved file. Manage outstanding drafts with `pending-missions`:
-
-```bash
-ovld protocol pending-missions               # list drafts the server never confirmed
-ovld protocol pending-missions --retry <id>  # re-send a saved draft; clears it on success
-ovld protocol pending-missions --clear <id>  # delete one draft after confirming it landed
-ovld protocol pending-missions --clear-all   # delete every draft
-```
-
 To inspect project resolution explicitly:
 
 ```bash
@@ -343,11 +332,17 @@ ovld protocol create-project --name "Acme Web" --directory /path/to/repo
 ovld protocol create-project --name "Acme Web" --no-directory
 ```
 
-`ovld create-project` is a friendly top-level alias for `ovld protocol create-project`.
-When a directory is registered the command also writes `.overlord/project.json` so
-future cwd-based resolution finds the project. Pass `--organization-id <id>` to create
-in a specific organization (defaults to your membership); `--color <#rrggbb>` sets the
-project color.
+`ovld create-project --name "<name>"` is the top-level convenience command; it accepts
+only `--name`, `--directory`/`--no-directory`, and `--json`, and always creates the
+project in your resolved workspace. When a directory is registered it also writes
+`.overlord/project.json` so future cwd-based resolution finds the project.
+
+`ovld protocol create-project --name "<name>"` is the parentless Protocol surface;
+unlike the top-level command it does not link a local directory. Pass
+`--workspace-id <id|slug|name>` to choose a workspace when you belong to more than one
+(omitting it returns `workspace_selection_required` with your choices); optional
+`--description <text>` and `--slug <text>` are also accepted. There is no `--color`
+flag on either surface.
 
 #### Resolving the project ID when you don't have one
 

package/dist/connectors/core/overlord-mission/reference/cli.md

@@ -41,7 +41,7 @@ ovld protocol update --session-key <sessionKey> --mission-id $MISSION_ID --summa
 ## Heartbeat
 
 ```bash
-ovld protocol heartbeat --session-key <sessionKey> --mission-id $MISSION_ID --phase execute --percent 40 --note "Running the integration suite"
+ovld protocol heartbeat --session-key <sessionKey> --mission-id $MISSION_ID --phase execute --note "Running the integration suite"
 ```
 
 Use `heartbeat` for liveness pings and transient UI telemetry when you have no meaningful narrative summary to post. It updates the attached session without creating a mission event.
@@ -189,7 +189,7 @@ ovld protocol create --agent <agent-identifier> --objectives-json '[{"objective"
 ```
 
 ```bash
-ovld protocol prompt --agent <agent-identifier> --objectives-json '[{"objective":"Implement feature X"}]' --priority medium
+ovld protocol prompt --agent <agent-identifier> --objectives-json '[{"objective":"Implement feature X"}]'
 ```
 
 ```bash
@@ -223,17 +223,6 @@ EOF
 The full submission format, including the `record-work`-only `changedFiles` field and MCP
 equivalent, is in [record-work.md](record-work.md).
 
-### Local Durability For New Missions
-
-`create`, `prompt`, `add-objectives`, and `record-work` save the objective/mission text to a local draft (`~/.overlord/pending-missions/`) **before** sending it, and delete that draft only once the server confirms the write. If the network drops mid-call, your text is never lost — the failure message points at the saved file. Manage outstanding drafts with `pending-missions`:
-
-```bash
-ovld protocol pending-missions               # list drafts the server never confirmed
-ovld protocol pending-missions --retry <id>  # re-send a saved draft; clears it on success
-ovld protocol pending-missions --clear <id>  # delete one draft after confirming it landed
-ovld protocol pending-missions --clear-all   # delete every draft
-```
-
 To inspect project resolution explicitly:
 
 ```bash
@@ -262,11 +251,17 @@ ovld protocol create-project --name "Acme Web" --directory /path/to/repo
 ovld protocol create-project --name "Acme Web" --no-directory
 ```
 
-`ovld create-project` is a friendly top-level alias for `ovld protocol create-project`.
-When a directory is registered the command also writes `.overlord/project.json` so
-future cwd-based resolution finds the project. Pass `--organization-id <id>` to create
-in a specific organization (defaults to your membership); `--color <#rrggbb>` sets the
-project color.
+`ovld create-project --name "<name>"` is the top-level convenience command; it accepts
+only `--name`, `--directory`/`--no-directory`, and `--json`, and always creates the
+project in your resolved workspace. When a directory is registered it also writes
+`.overlord/project.json` so future cwd-based resolution finds the project.
+
+`ovld protocol create-project --name "<name>"` is the parentless Protocol surface;
+unlike the top-level command it does not link a local directory. Pass
+`--workspace-id <id|slug|name>` to choose a workspace when you belong to more than one
+(omitting it returns `workspace_selection_required` with your choices); optional
+`--description <text>` and `--slug <text>` are also accepted. There is no `--color`
+flag on either surface.
 
 ### Resolving the project ID when you don't have one
 

package/dist/connectors/core/scripts/overlord-mcp.mjs

@@ -1175,7 +1175,7 @@ process.stdin.on('data', async chunk => {
         result: {
           protocolVersion: PROTOCOL_VERSION,
           capabilities: { tools: { listChanged: false } },
-          serverInfo: { name: 'overlord-__OVERLORD_ADAPTER_KEY__', version: '0.3.40' }
+          serverInfo: { name: 'overlord-__OVERLORD_ADAPTER_KEY__', version: '0.3.41' }
         }
       });
       continue;

package/dist/connectors/docs/05-connectors-and-agent-plugins.md

@@ -236,6 +236,14 @@ Requirements:
 - Degrades gracefully without a web app open: the harness's own fallback
   decision (allow/deny/ask) applies when no one answers in time.
 
+As of the Latch v2 cutover, no shipped launch path currently supplies the session-channel
+credential this mechanism depends on (`createSessionChannel` has no production callers), so
+"blocks the harness's tool call until answered" does not happen end-to-end for any existing
+adapter today — do not assume a new connector can exercise this path against a real Overlord
+deployment without first restoring that wiring. The one decision kind that is still remotely
+answerable — a blocking **question** — goes through the mission protocol's `ask`/resolve flow
+and a live Latch terminal session, not through this session-channel mechanism.
+
 ### Stop Hook
 
 Future requirement:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "overlord-cli",
-  "version": "0.2608311101.0",
+  "version": "0.2609011854.0",
   "description": "Overlord CLI — management, agent protocol, and runner for OpenOverlord",
   "type": "module",
   "engines": {