overlord-cli 0.2611091052.0 → 0.2611131839.0

package/README.md

@@ -250,7 +250,7 @@ resolved project directory. The queue state remains in the backend.
 ### Contract Components
 
 This module is the developer-facing home for three components defined in
-[`CONTRACT.md`](https://github.com/cooperativ-labs/OpenOverlord/blob/main/CONTRACT.md):
+[`contract/CONTRACT.md`](https://github.com/cooperativ-labs/OpenOverlord/blob/main/contract/CONTRACT.md):
 
 | Component      | Stable id  | What it owns                                                                                                                                                                        |
 | -------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -345,5 +345,5 @@ would run untested working-tree code against your real mission data.
 
 Per the contract, the CLI/protocol/runner surfaces reach persistence only
 through the configured **REST/backend API** — never direct table writes.
-See the Interaction Surfaces section of [`CONTRACT.md`](https://github.com/cooperativ-labs/OpenOverlord/blob/main/CONTRACT.md) before
+See the Interaction Surfaces section of [`contract/architecture.md`](https://github.com/cooperativ-labs/OpenOverlord/blob/main/contract/architecture.md) before
 making any cross-module change.

package/dist/connectors/AGENTS.md

@@ -1,6 +1,6 @@
 # Connectors Module — Agent Extension Guide
 
-This file tells agents how to extend the Connectors module to add new agent harness connectors for users. Read [`CONTRACT.md`](../CONTRACT.md) and the [component-contract skill](../.claude/skills/component-contract/SKILL.md) before making any cross-module change.
+This file tells agents how to extend the Connectors module to add new agent harness connectors for users. Read [`contract/CONTRACT.md`](../contract/CONTRACT.md) and the [component-contract skill](../.claude/skills/component-contract/SKILL.md) before making any cross-module change.
 
 ---
 
@@ -21,7 +21,7 @@ Each type has a different procedure below.
 
 ## Before You Start
 
-1. Read `CONTRACT.md` — Connector Layer section (stable id: `connector`).
+1. Read `contract/architecture.md` — Connector Layer section (stable id: `connector`).
 2. Read [`connectors/docs/05-connectors-and-agent-plugins.md`](docs/05-connectors-and-agent-plugins.md) for the four-layer model: connector core, plugins, adapters, and prompt wrappers.
 3. Read [`connectors/docs/agent-harness-configuration-architecture.md`](docs/agent-harness-configuration-architecture.md) for ownership boundaries.
 4. Check the `agentSession` vocabularies in `contract/extension-points.yaml` and the descriptor schema before adding a normalized capability, integration shape, or fixture kind.
@@ -266,7 +266,7 @@ wrong and that is worth raising rather than working around.
 6. **Create `connectors/adapters/<agent-name>/conformance-manifest.yaml`** declaring:
 
    ```yaml
-   contractVersion: '116'
+   contractVersion: '168.0.0'
    componentType: connector
    componentKey: <agent-name>
    label: <human-readable label>
@@ -350,7 +350,7 @@ The Claude and Codex adapters are the reference implementations; Cursor, Pi, Ant
 
 ## Cross-Module Checklist
 
-- [ ] Read `CONTRACT.md` Connector Layer section
+- [ ] Read `contract/architecture.md` Connector Layer section
 - [ ] New capability id, integration shape, or fixture kind → update the contract vocabulary and descriptor schema first
 - [ ] Hook scripts → use `ovld protocol` commands only, no direct DB writes
 - [ ] Conformance manifest created and validated for every new connector

package/dist/connectors/README.md

@@ -59,14 +59,14 @@ migrate existing installations.
 
 A custom agent connector is a sanctioned extension point: a new adapter plus a
 `conformance-manifest.yaml` validated by `ovld contract check`. See the
-[Conformance Requirements](../CONTRACT.md) and the example manifest at
+[Conformance Requirements](../contract/conformance.md) and the example manifest at
 [`../contract/examples/connector-claude-conformance-manifest.yaml`](../contract/examples/connector-claude-conformance-manifest.yaml).
 
 ## For Developers
 
 ### Contract Component
 
-Maps to the **Connector Layer** (`connector`) in [`CONTRACT.md`](../CONTRACT.md), which owns:
+Maps to the **Connector Layer** (`connector`) in [`contract/architecture.md`](../contract/architecture.md), which owns:
 
 - Connector core workflow instructions
 - Per-agent plugin/adapter files and their managed-file manifests

package/dist/connectors/VERSION

@@ -1 +1 @@
-0.3.59
+0.3.60

package/dist/connectors/adapters/antigravity/conformance-manifest.yaml

@@ -1,4 +1,4 @@
-contractVersion: "168"
+contractVersion: "170.0.0"
 componentType: connector
 componentKey: antigravity
 label: "Antigravity Connector"

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

@@ -1,7 +1,7 @@
 {
   "$schema": "https://antigravity.google/schemas/v1/plugin.json",
   "name": "overlord",
-  "version": "0.3.59",
+  "version": "0.3.60",
   "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.59",
+  "version": "0.3.60",
   "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/claude/conformance-manifest.yaml

@@ -1,4 +1,4 @@
-contractVersion: "168"
+contractVersion: "170.0.0"
 componentType: connector
 componentKey: claude
 label: "Claude Code Connector"

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

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

package/dist/connectors/adapters/codex/conformance-manifest.yaml

@@ -1,4 +1,4 @@
-contractVersion: "168"
+contractVersion: "170.0.0"
 componentType: connector
 componentKey: codex
 label: "Codex Connector"

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

@@ -1,6 +1,6 @@
 {
   "name": "overlord",
-  "version": "0.3.59",
+  "version": "0.3.60",
   "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/adapters/cursor/conformance-manifest.yaml

@@ -1,4 +1,4 @@
-contractVersion: "168"
+contractVersion: "170.0.0"
 componentType: connector
 componentKey: cursor
 label: "Cursor Connector"

package/dist/connectors/adapters/opencode/conformance-manifest.yaml

@@ -1,4 +1,4 @@
-contractVersion: "168"
+contractVersion: "170.0.0"
 componentType: connector
 componentKey: opencode
 label: "OpenCode Connector"

package/dist/connectors/adapters/pi/conformance-manifest.yaml

@@ -1,4 +1,4 @@
-contractVersion: "168"
+contractVersion: "170.0.0"
 componentType: connector
 componentKey: pi
 label: "PI Connector"

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

@@ -13,7 +13,7 @@ Connector adapters may add harness-specific commands, hooks, MCP tools, or launc
 
 Use this mode when the prompt already contains a mission ID or explicitly says the session was launched by Overlord.
 
-**`<mission_id>` is always the short display id** — `coo:695`, `1:899`: a workspace prefix, a colon, and a number. Pass it as `--mission-id`. **`<objective_id>`** is the objective display id (`coo:695.k7xm`) or UUID; pass it as `--objective-id` when you know which objective to execute. Never pass an objective id as `--mission-id`. If the prompt includes `OVERLORD_OBJECTIVE_ID` or an Objective ID line, include `--objective-id` on attach. If the only id you can find is a bare UUID with no mission display id, re-read the prompt or run `ovld protocol search-missions` rather than guessing.
+**`<mission_id>` is always the short display id** — `coo:695`, `1:899`: a workspace prefix, a colon, and a number. Pass it as `--mission-id`. **`<objective_id>`** is the objective display id (`coo:695.k7xm`) or UUID; pass it as `--objective-id` when you know which objective to execute. Never pass an objective id as `--mission-id`. If the prompt includes `OVERLORD_OBJECTIVE_ID` or an Objective ID line, include `--objective-id` on attach. If the only id you can find is a bare UUID with no mission display id, re-read the prompt or run `ovld protocol search` rather than guessing.
 
 **An objective display id is a complete address.** `coo:695.k7xm` already spells its mission, so `--mission-id` is optional on every command whenever you pass a full objective display id as `--objective-id`; Overlord derives `coo:695` from it. This is the identifier to reach for when reconnecting to a mission that is running more than one objective, where "the active objective" is ambiguous and a mission id alone is not enough. An objective **UUID** names no mission, so it still needs `--mission-id` alongside it.
 
@@ -97,7 +97,7 @@ Use this mode when the conversation starts normally and the user asks the agent
    When you open or discuss an existing mission that has a draft objective, submit it with `ovld protocol discuss-objective --mission-id <mission_id>`.
 4. If the user wants to route the current session onto an existing mission by ID, run `ovld protocol connect --mission-id <mission_id>` (add `--objective-id <objective_id>` to pin the session to a specific objective).
 5. If the user wants to establish a persistent session with a mission by ID, run `ovld protocol attach --mission-id <mission_id>`.
-6. If the user wants to find a mission but does not know the ID, run `ovld protocol search-missions --query "..." --status execute,review` and ask the user to confirm.
+6. If the user wants to find a mission but does not know the ID, run `ovld protocol search --query "..." --status execute,review` and ask the user to confirm.
 7. If you need to understand project routing before prompting, use `ovld protocol discover-project`.
 8. If the user wants to **record work that is already finished** in this chat (for example, something you just built in a chat app) as a completed mission, run `ovld protocol record-work --project-id <project-id>` (or the hosted `overlord_record_work` MCP tool). This creates a mission with one completed objective, records any paths you declare as Declared evidence, lands it in the review column, and runs the standard Gemini delivery summary — all in one call, with no `attach`/`deliver`. Do **not** use it for in-progress work. The exact submission format is in [reference/record-work.md](reference/record-work.md).
 9. If you need other lifecycle commands or flags, run `ovld protocol help` and use the real subcommand list instead of guessing.
@@ -384,7 +384,7 @@ When creating missions from within a repository:
 - Prefer `create` by default for draft mission creation.
 - Use `prompt` only when the user explicitly asks to start execution immediately.
 - `create`, `prompt`, and `record-work` require an explicit `--project-id`; use `discover-project` first when the project is known only from the checkout. They never infer a destination project.
-- Use `create --unassigned-to-project` only when the user deliberately requests an account-owned inbox capture. `--inbox` is a compatibility alias.
+- Use `create --unassigned-to-project` only when the user deliberately requests an account-owned inbox capture.
 - Create multiple missions when each prompt represents a different feature or goal.
 - Add objectives to the same mission when each prompt is a sequential step toward the same feature or goal; use `ovld protocol add-objectives --mission-id <mission_id> --objectives-json '[{"objective":"..."}]'`.
 - `create` and `prompt` require `--objectives-json` or `--objectives-file` with an ordered array of `{ "objective": "...", "title": "...", "autoAdvance": true }` objects. A single objective is just an array with one item. `--auto-advance` / `--no-auto-advance` set the default when an item omits `autoAdvance` (default off).

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

@@ -180,7 +180,7 @@ When creating missions from within a repository:
 - Prefer `create` by default for draft mission creation.
 - Use `prompt` only when the user explicitly asks to start execution immediately.
 - `create`, `prompt`, and `record-work` require an explicit `--project-id`; use `discover-project` first when the project is known only from the checkout. They never infer a destination project.
-- Use `create --unassigned-to-project` only when the user deliberately requests an account-owned inbox capture. `--inbox` is a compatibility alias.
+- Use `create --unassigned-to-project` only when the user deliberately requests an account-owned inbox capture.
 - Create multiple missions when each prompt represents a different feature or goal.
 - Add objectives to the same mission when each prompt is a sequential step toward the same feature or goal; use `ovld protocol add-objectives --mission-id <mission_id> --objectives-json '[{"objective":"..."}]'`.
 - `create` and `prompt` require `--objectives-json` or `--objectives-file` with an ordered array of `{ "objective": "...", "title": "...", "autoAdvance": true }` objects. A single objective is just an array with one item. `--auto-advance` / `--no-auto-advance` map each opted-in item to authoritative Run Queue membership (default off).

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

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

package/dist/contract/conformance-manifest.schema.yaml

@@ -28,9 +28,15 @@ properties:
 
   contractVersion:
     type: string
-    description: "The Overlord contract version this component was validated against (e.g. '0')"
+    # Strict MAJOR.MINOR.PATCH (contract/VERSION). A bare integer N is the former
+    # integer form, read as N.0.0, and stays valid for manifests outside this
+    # repository until they are restamped; `yarn check:conformance-versions`
+    # requires the strict form, the same major as contract/VERSION and a version
+    # not newer than it (contract/decisions/0009-manifests-pin-major-version.md).
+    pattern: "^(0|[1-9][0-9]*)([.](0|[1-9][0-9]*)[.](0|[1-9][0-9]*))?$"
+    description: "The Overlord contract version this component was validated against, as strict Semantic Versioning (e.g. '168.0.0')"
     examples:
-      - "0"
+      - "168.0.0"
 
   componentType:
     type: string
@@ -177,7 +183,7 @@ properties:
           - postgres
       schemaContractVersion:
         type: string
-        description: "Database schema contract version this adapter implements (from 09-database-schema-contract.md)"
+        description: "Database schema contract version this adapter implements (from contract/data/README.md)"
       conformanceTestStatus:
         type: string
         enum: