okstra 0.186.7 → 0.187.0

package/runtime/schemas/final-report-v2.0.schema.json

@@ -251,7 +251,7 @@
     },
     "verdictCard": {
       "type": "object",
-      "description": "Top-of-report at-a-glance card. It carries no verdict token — the token lives once, in finalVerdict. `direction` and `nextStep` MUST byte-match finalVerdict and recommendedNextSteps[0].",
+      "description": "Top-of-report at-a-glance card. It carries no verdict token — the token lives once, in finalVerdict, and additionalProperties:false keeps it from being copied here. Authoring guideline: write `direction` to agree with finalVerdict.direction and `nextStep` to agree with recommendedNextSteps[0]. Nothing compares the two copies afterwards — assembly rewrites `nextStep` on both cards together when the plan-body gate passes, and leaves `direction` as the writer wrote it — so a disagreement between them is published as written.",
       "required": [
         "finalConclusion",
         "direction",
@@ -312,9 +312,8 @@
     },
     "summary": {
       "type": "array",
-      "description": "## Summary of the Problem or Verification Target. 3-5 rows.",
+      "description": "## Summary of the Problem or Verification Target. Usually 3-5 rows; no upper limit.",
       "minItems": 1,
-      "maxItems": 8,
       "items": {
         "$ref": "#/$defs/SummaryRow"
       }
@@ -3897,8 +3896,8 @@
         },
         "summary": {
           "type": "string",
-          "minLength": 1,
-          "maxLength": 120
+          "minLength": 1
+          
         },
         "details": {
           "type": "string",
@@ -7527,8 +7526,8 @@
               },
               "summary": {
                 "type": "string",
-                "minLength": 1,
-                "maxLength": 120
+                "minLength": 1
+                
               },
               "details": {
                 "type": "string",
@@ -9030,24 +9029,6 @@
             "type": "string",
             "minLength": 1
           }
-        },
-        "rewrittenPaths": {
-          "type": "array",
-          "description": "data.json paths this round actually rewrote for this cause group. A self-fix round is contractually a targeted correction, not a full draft regeneration; recording the reach is what makes that claim checkable later.",
-          "uniqueItems": true,
-          "items": {
-            "type": "string",
-            "minLength": 1
-          }
-        },
-        "outsideScopePaths": {
-          "type": "array",
-          "description": "The subset of rewrittenPaths that lies outside the sections this group's itemIds point at. Carrying a correction to its contradictions legitimately reaches further than the flagged item, so this is a measurement, not a violation.",
-          "uniqueItems": true,
-          "items": {
-            "type": "string",
-            "minLength": 1
-          }
         }
       }
     },
@@ -9569,10 +9550,12 @@
           "minLength": 1
         },
         "verdict": {
+          "description": "`not-run` is not a rejection: the verifier produced no verdict at all (timeout, error, usage limit). `FAIL` rejects the diff and opens the stage fix cycle, so spending it on a verifier that never ran manufactures a defect nobody found \u2014 see `_implementation-verifier.md` \"All-verifier-failure policy\".",
           "enum": [
             "PASS",
             "CONCERNS",
-            "FAIL"
+            "FAIL",
+            "not-run"
           ]
         },
         "readOnlyCommandLog": {

package/runtime/schemas/final-report-v3.0.schema.json

@@ -251,7 +251,7 @@
     },
     "verdictCard": {
       "type": "object",
-      "description": "Top-of-report at-a-glance card. It carries no verdict token — the token lives once, in finalVerdict. `direction` and `nextStep` MUST byte-match finalVerdict and recommendedNextSteps[0].",
+      "description": "Top-of-report at-a-glance card. It carries no verdict token — the token lives once, in finalVerdict, and additionalProperties:false keeps it from being copied here. Authoring guideline: write `direction` to agree with finalVerdict.direction and `nextStep` to agree with recommendedNextSteps[0]. Nothing compares the two copies afterwards — assembly rewrites `nextStep` on both cards together when the plan-body gate passes, and leaves `direction` as the writer wrote it — so a disagreement between them is published as written.",
       "required": [
         "finalConclusion",
         "direction",
@@ -312,9 +312,8 @@
     },
     "summary": {
       "type": "array",
-      "description": "## Summary of the Problem or Verification Target. 3-5 rows.",
+      "description": "## Summary of the Problem or Verification Target. Usually 3-5 rows; no upper limit.",
       "minItems": 1,
-      "maxItems": 8,
       "items": {
         "$ref": "#/$defs/SummaryRow"
       }
@@ -3043,10 +3042,7 @@
           "$ref": "#/$defs/ImplementationOptionDecisionContext"
         },
         "evaluationCriteria": {
-          "type": "array",
-          "items": {
-            "$ref": "#/$defs/ImplementationOptionEvaluationCriterion"
-          }
+          "$ref": "#/$defs/ImplementationOptionEvaluationCriteria"
         },
         "candidateAudit": {
           "type": "array",
@@ -3149,6 +3145,62 @@
         }
       }
     },
+    "ImplementationOptionEvaluationCriteria": {
+      "type": "array",
+      "minItems": 8,
+      "maxItems": 8,
+      "prefixItems": [
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionEvaluationCriterion"},
+            {"properties": {"criterion": {"const": "requirement-fit"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionEvaluationCriterion"},
+            {"properties": {"criterion": {"const": "architecture-fit"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionEvaluationCriterion"},
+            {"properties": {"criterion": {"const": "change-locality"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionEvaluationCriterion"},
+            {"properties": {"criterion": {"const": "implementation-complexity"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionEvaluationCriterion"},
+            {"properties": {"criterion": {"const": "correctness-risk"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionEvaluationCriterion"},
+            {"properties": {"criterion": {"const": "reversibility"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionEvaluationCriterion"},
+            {"properties": {"criterion": {"const": "verification-cost"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionEvaluationCriterion"},
+            {"properties": {"criterion": {"const": "rollout-cost"}}}
+          ]
+        }
+      ],
+      "items": false
+    },
     "ImplementationOptionCandidateAudit": {
       "type": "object",
       "required": [
@@ -3237,11 +3289,7 @@
           "$ref": "#/$defs/ImplementationOptionCoverageSummary"
         },
         "criterionScores": {
-          "type": "array",
-          "minItems": 1,
-          "items": {
-            "$ref": "#/$defs/ImplementationOptionCriterionScore"
-          }
+          "$ref": "#/$defs/ImplementationOptionCriterionScores"
         },
         "weightedScore": {
           "type": "number",
@@ -3339,11 +3387,7 @@
           "$ref": "#/$defs/ImplementationOptionExactCoverageSummary"
         },
         "criterionScores": {
-          "type": "array",
-          "minItems": 1,
-          "items": {
-            "$ref": "#/$defs/ImplementationOptionCriterionScore"
-          }
+          "$ref": "#/$defs/ImplementationOptionCriterionScores"
         },
         "weightedScore": {
           "type": "number",
@@ -3575,6 +3619,62 @@
         }
       }
     },
+    "ImplementationOptionCriterionScores": {
+      "type": "array",
+      "minItems": 8,
+      "maxItems": 8,
+      "prefixItems": [
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionCriterionScore"},
+            {"properties": {"criterion": {"const": "requirement-fit"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionCriterionScore"},
+            {"properties": {"criterion": {"const": "architecture-fit"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionCriterionScore"},
+            {"properties": {"criterion": {"const": "change-locality"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionCriterionScore"},
+            {"properties": {"criterion": {"const": "implementation-complexity"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionCriterionScore"},
+            {"properties": {"criterion": {"const": "correctness-risk"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionCriterionScore"},
+            {"properties": {"criterion": {"const": "reversibility"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionCriterionScore"},
+            {"properties": {"criterion": {"const": "verification-cost"}}}
+          ]
+        },
+        {
+          "allOf": [
+            {"$ref": "#/$defs/ImplementationOptionCriterionScore"},
+            {"properties": {"criterion": {"const": "rollout-cost"}}}
+          ]
+        }
+      ],
+      "items": false
+    },
     "ImplementationOptionFeasibilityVote": {
       "type": "object",
       "required": [
@@ -3905,8 +4005,8 @@
         },
         "summary": {
           "type": "string",
-          "minLength": 1,
-          "maxLength": 120
+          "minLength": 1
+          
         },
         "details": {
           "type": "string",
@@ -7302,7 +7402,8 @@
       "properties": {
         "id": {
           "type": "string",
-          "pattern": "^C-\\d{3,}$"
+          "pattern": "^C[V]?-\\d{3,}$",
+          "description": "Converged-finding row id. New reports are numbered `CV-NNN` so `C-NNN` names a clarification and nothing else; `C-NNN` stays accepted here only because reports written before that split are still read and re-validated. The generator emits `CV-` only — see report_projections.py and its test."
         },
         "ticketId": {
           "$ref": "#/$defs/TicketId"
@@ -7522,8 +7623,8 @@
               },
               "summary": {
                 "type": "string",
-                "minLength": 1,
-                "maxLength": 120
+                "minLength": 1
+                
               },
               "details": {
                 "type": "string",
@@ -8318,6 +8419,53 @@
         "rationale": {
           "type": "string",
           "description": "Required when disposition is not `addressed`: why this phase does not account for the id."
+        },
+        "blockedBy": {
+          "type": "object",
+          "description": "What holds this end state back. Required by validate-run.py when `disposition` is `blocked`, because that word alone carries five different situations and only one of them is something a person can answer. Derived from the 82 blocked rows on disk at the time it was added.",
+          "required": [
+            "kind"
+          ],
+          "additionalProperties": false,
+          "properties": {
+            "kind": {
+              "type": "string",
+              "enum": [
+                "clarification",
+                "finding",
+                "execution",
+                "upstream",
+                "not-observed"
+              ],
+              "description": "`clarification` — a decision only the reporter can make; the run cannot proceed without an answer. `finding` — a cross-verification finding or approval blocker this run must resolve. `execution` — a command or environment failure in this run (a server that would not boot, a placeholder credential, an artifact not reproducible at its tag). `upstream` — carried from an earlier report or stage that already recorded the same disposition. `not-observed` — this run did not re-check it and records no disproof."
+            },
+            "ref": {
+              "type": "string",
+              "description": "The blocker's id. Required for `clarification` (a `C-NNN` row of this report, or one carried in) and for `finding`. Only the `clarification` ref is resolved by validate-run.py — a `finding` ref legitimately names a row of the approved plan or an upstream report (`VC-003`, `CA-001`), which this document cannot see."
+            }
+          },
+          "allOf": [
+            {
+              "if": {
+                "properties": {
+                  "kind": {
+                    "enum": [
+                      "clarification",
+                      "finding"
+                    ]
+                  }
+                },
+                "required": [
+                  "kind"
+                ]
+              },
+              "then": {
+                "required": [
+                  "ref"
+                ]
+              }
+            }
+          ]
         }
       }
     },
@@ -9025,24 +9173,6 @@
             "type": "string",
             "minLength": 1
           }
-        },
-        "rewrittenPaths": {
-          "type": "array",
-          "description": "data.json paths this round actually rewrote for this cause group. A self-fix round is contractually a targeted correction, not a full draft regeneration; recording the reach is what makes that claim checkable later.",
-          "uniqueItems": true,
-          "items": {
-            "type": "string",
-            "minLength": 1
-          }
-        },
-        "outsideScopePaths": {
-          "type": "array",
-          "description": "The subset of rewrittenPaths that lies outside the sections this group's itemIds point at. Carrying a correction to its contradictions legitimately reaches further than the flagged item, so this is a measurement, not a violation.",
-          "uniqueItems": true,
-          "items": {
-            "type": "string",
-            "minLength": 1
-          }
         }
       }
     },
@@ -9561,10 +9691,12 @@
           "minLength": 1
         },
         "verdict": {
+          "description": "`not-run` is not a rejection: the verifier produced no verdict at all (timeout, error, usage limit). `FAIL` rejects the diff and opens the stage fix cycle, so spending it on a verifier that never ran manufactures a defect nobody found \u2014 see `_implementation-verifier.md` \"All-verifier-failure policy\".",
           "enum": [
             "PASS",
             "CONCERNS",
-            "FAIL"
+            "FAIL",
+            "not-run"
           ]
         },
         "readOnlyCommandLog": {

package/runtime/schemas/report-narrative-v3.0.schema.json

@@ -2,7 +2,7 @@
   "$schema": "https://json-schema.org/draft/2020-12/schema",
   "$id": "https://okstra.dev/schemas/report-narrative-v3.0.json",
   "title": "OKSTRA Report Writer Narrative Input (v3.0)",
-  "description": "Parsed report-writer Markdown. Only report-writer-owned judgments, plans, summaries, and user explanations are accepted.",
+  "description": "Parsed report-writer Markdown: the allowlist of top-level fields the report writer owns. Only report-writer-owned judgments, plans, summaries, and user explanations are accepted. This file constrains NAMES only \u2014 the per-value constraints (enums, required properties, item shapes) come from final-report-v3.0.schema.json, which okstra_ctl.report_narrative restricts to these names at parse time. Do not copy value constraints here; two copies drift.",
   "type": "object",
   "additionalProperties": false,
   "properties": {
@@ -25,6 +25,7 @@
     "implementation": {"type": "object"},
     "finalVerification": {"type": "object"},
     "recommendedNextSteps": {"type": "array"},
-    "followUpTasks": {"type": "array"}
+    "followUpTasks": {"type": "array"},
+    "endStateCoverage": {"type": "array"}
   }
 }

package/runtime/skills/okstra-brief-gen/SKILL.md

@@ -120,9 +120,13 @@ Run one Bash tool call, starting with the literal token `okstra` (never wrapped
 <!-- END FRAGMENT: bash-invocation-rule -->
 
 ```bash
-okstra preflight --runtime claude-code
+okstra preflight --runtime <current-host-runtime>
 ```
 
+Resolve `<current-host-runtime>` from the live harness or launcher's
+`OKSTRA_RUNTIME_HOST`; do not assume `claude-code` when the skill is running
+inside Codex or another registered host.
+
 On `Okstra preflight: ready`, carry the fixed `Project root` line as a literal string into the steps below. On `Okstra preflight: failed` (or `okstra` not on `PATH` at all), show the fixed `Reason` and `Recovery` lines, then stop.
 
 <!-- BEGIN FRAGMENT: preflight-outdated-cli -->
@@ -131,6 +135,22 @@ If the call fails with `unknown command: preflight`, the `okstra` binary on PATH
 
 Do **not** try `npx -y okstra@latest ...` as a fallback.
 
+### Host-native choice prompts
+
+Use the current host's native single-select control whenever it is available
+for an authored question with two or three mutually exclusive options. Keep a
+selection and the material it collects as separate interactions: a native
+choice selects the input path, and the next free-text interaction receives a
+path, URL, ticket reference, or body.
+
+In Codex, call `request_user_input` with the two or three listed options in
+their stated order. Do not add an `Other` option: the Codex client adds its
+own free-text `Other` row. When the user supplies a value through that row,
+classify it through the normal reporter-source rules (ticket, URL, or user
+input) and do not ask them to repeat it. If the host does not expose a
+compatible native control, render the same options as a numbered text choice
+and retain the explicit free-text follow-up where this skill specifies one.
+
 ## Step 1: Choose input source
 
 ### 1.0. brief variant
@@ -143,11 +163,16 @@ Do **not** try `npx -y okstra@latest ...` as a fallback.
   2. `Codebase scan` — take only the codebase scope + lens priorities and generate the input for the `improvement-discovery` phase.
   3. `Error feedback` (`error-feedback`) — convert one frequent cluster from the `.zip` produced by `okstra error-zip` into an `error-analysis` brief (for okstra self-repair).
 
+The three variants must be presented as a native choice when the current host
+supports it. A Codex `Other` response is direct Reporter input, not a fourth
+brief variant. Continue with Step 1.A using that response as the already
+collected source material, then classify a ticket reference or URL normally.
+
 ### 1.A. Reporter input (variant 1)
 
 If the user picked `Reporter input`, proceed to Step 1.A's sub-flow below — this is the existing 4-source flow. Choose ONE of:
 
-`AskUserQuestion` (tool constraint: max 4 options):
+`AskUserQuestion` (single-select):
 
 - **Label**: "Source of this brief?"
 - **Options** (single-select):
@@ -159,6 +184,14 @@ If the user picked `Reporter input`, proceed to Step 1.A's sub-flow below — th
      (default: conversation synthesis. If context is thin, fall back to a
      single free-text question.)
 
+When the current native control accepts only two or three options, present
+`File`, `Issue tracker ticket`, and `Link URL`; use its built-in `Other` row
+for `User input`. A value typed through `Other` is the source input itself;
+classify a file path, ticket reference, or URL normally and otherwise treat
+it as the user-input body without another free-text question. On a host
+without that control, render all four options as the numbered text choice
+above.
+
 If the user wants to bundle multiple sources into one brief (e.g. "this
 Linear ticket + this PR link"), repeat this step to collect them. Preserve
 each source's raw content **separately** under the `Source Material

package/runtime/skills/okstra-container-build/SKILL.md

@@ -1,20 +1,18 @@
 ---
 name: okstra-container-build
 description: |
-  Use to bring up, inspect, or tear down the okstra user-test container runtime for an implementation task — the docker-compose group okstra deploys from a task's worktree so a human can poke at the running build. Trigger words include "okstra container", "okstra container up", "okstra container down", "bring up the container", "spin up the container", "tear down the container", "container status", "container logs", "user-test environment", "user test environment", "docker compose up please", "spin up this task in a container", "stop the watcher", "stop watcher", "stop monitoring".
+  Use to bring up, inspect, or tear down the okstra user-test container runtime for an implementation task — the docker-compose group okstra deploys from a task's worktree so a human can poke at the running build. Trigger words include "okstra container", "okstra container up", "okstra container down", "bring up the container", "spin up the container", "tear down the container", "container status", "user-test environment", "user test environment", "docker compose up please", "spin up this task in a container".
 ---
 
 # OKSTRA Container Build
 
-Single entry point for the okstra user-test container runtime. okstra provisions a docker-compose group from an `implementation` task's worktree (the `docker-compose.yml` at the worktree root), labels it with the task's run-trace so later sub-commands can find the group, and tails it through a tmux watcher pane. This skill drives that lifecycle. Sub-commands:
+Single entry point for the okstra user-test container runtime. okstra provisions a docker-compose group from an `implementation` task's worktree (the `docker-compose.yml` at the worktree root), and labels it with the task's run-trace so later sub-commands can find the group. This skill drives that lifecycle. Sub-commands:
 
 | Sub-command | What it does |
 |---|---|
-| `up` | Integrate the task's stages into the worktree, run `docker compose up -d`, poll healthchecks, and attach a watcher pane. |
-| `status` | Query the running containers (by run-trace label) plus the watcher metadata for a task-key. |
-| `logs` | Point at the watcher findings dir and per-service watcher state (logs live in the tmux pane, not a file). |
-| `stop-watcher` | Reap the watcher/tail panes only — the containers keep running. |
-| `down` | Tear down the containers (label query) and reap orphan watcher panes; `--all` covers every container group in the project. |
+| `up` | Integrate the task's stages into the worktree, run `docker compose up -d`, and poll healthchecks. |
+| `status` | Query the running containers for a task-key (by run-trace label). |
+| `down` | Tear down the containers (label query); `--all` covers every container group in the project. |
 
 ## Step 0: Preflight (shared)
 
@@ -44,14 +42,14 @@ Every subsequent `okstra <subcmd>` call self-bootstraps its Python path, so this
 
 Classify the user's request into one sub-command using the sub-command table above.
 
-- Clear verbs route directly: "bring up/deploy/up" → `up`; "status" → `status`; "logs" → `logs`; "stop watcher/stop-watcher" → `stop-watcher`; "tear down/down" → `down`.
+- Clear verbs route directly: "bring up/deploy/up" → `up`; "status" → `status`; "tear down/down" → `down`.
 - If the request is ambiguous (e.g. "take a look at the okstra container"), present a numbered picker. Recommend the 1–2 most likely facets first, and make the **last option always "Enter directly"** so the user can name any facet:
 
   ```
   What would you like to do?
-  1. status — check running containers / watcher state (recommended)
+  1. status — check the running containers (recommended)
   2. up — bring up this task's containers
-  3. Enter directly (one of up / status / logs / stop-watcher / down)
+  3. Enter directly (one of up / status / down)
   ```
 
   The full facet list is the `Sub-command | What it does` table above — never hide a facet; if the user picks "Enter directly", let them name any row.
@@ -68,7 +66,7 @@ Every sub-command needs a **task-key** (`<project-id>:<task-group>:<task-id>`)
 
 ## up
 
-Brings up the task's container group: integrates the implementation stages into the task worktree, synthesizes the compose env override, runs `docker compose up -d`, polls healthchecks, and attaches a tmux watcher pane.
+Brings up the task's container group: integrates the implementation stages into the task worktree, synthesizes the compose env override, runs `docker compose up -d`, and polls healthchecks.
 
 **Preconditions** (state them if unmet, do not guess):
 - The task must be an `implementation` task whose worktree is registered in `~/.okstra/worktrees/registry.json`. If `up` fails with "task worktree is not in the registry" → the task has no implementation worktree yet; tell the user to run the `implementation` phase first.
@@ -81,7 +79,7 @@ Run:
 okstra container up --project-root <projectRoot> --task-key <task-key> --text
 ```
 
-Read the fixed output fields and report the provisioned services and watcher pane. If a service failed its healthcheck, the call surfaces the failing services and the `docker compose ... logs` line to inspect — relay that line; do not invent your own.
+Read the fixed output fields and report the provisioned services. If a service failed its healthcheck, the call surfaces the failing services and the `docker compose ... logs` line to inspect — relay that line; do not invent your own.
 
 After a successful `up`, run the `status --text` command below and read its numbered container `ports` fields to tell the user how to reach the running build. Also explain that `okstra container status <task-key>` / `okstra container down <task-key>` manage it from here. For *what to verify* once it is up, point the user to the implementation report's §5.7.9 Manual User Test (Draft) — its steps and expected results are the manual test script for this build.
 
@@ -89,57 +87,28 @@ After a successful `up`, run the `status --text` command below and read its numb
 
 ## status
 
-Reports the running containers (queried by run-trace label — the source of truth for "is it up") plus the watcher metadata recorded in the registry.
+Reports the running containers, queried by the run-trace label — the source of truth for "is it up".
 
 ```bash
 okstra container status --project-root <projectRoot> --task-key <task-key> --text
 ```
 
-Read the fixed `Project name`, `Containers`, and `Watchers` fields and report:
+Read the fixed `Project name` and numbered `Container` fields and report:
 
 | Field | Meaning |
 |---|---|
 | `projectName` | the compose project name (label group) |
 | `containers` | running containers found by label — empty array means nothing is up |
-| `watchers` | per-service watcher metadata from the registry (auxiliary; may lag the label query) |
 
-If `containers` is empty, say the group is not running and offer `up`. Treat the label query — not the registry `watchers` — as authoritative for whether containers are alive.
+If `containers` is empty, say the group is not running and offer `up`.
 
----
-
-## logs
-
-The live log stream lives in the tmux watcher pane, not in a file. This sub-command points at the watcher findings directory and the per-service watcher state.
-
-```bash
-okstra container logs --project-root <projectRoot> --task-key <task-key> --text
-```
-
-Add `--service <name>` to scope to one service:
-
-```bash
-okstra container logs --project-root <projectRoot> --task-key <task-key> --service <service> --text
-```
-
-Read the fixed `Watchers dir` and numbered `Watchers` fields. Report the host path and watcher entries. Explain that the live stream is in the attached tmux pane; to see raw container logs the user runs `docker compose -p <projectName> logs -f <service>` (get `<projectName>` from `status`).
-
----
-
-## stop-watcher
-
-Reaps the watcher/tail tmux panes for the task **without stopping the containers**. Use when the user wants to silence the monitor but keep the build running.
-
-```bash
-okstra container stop-watcher --project-root <projectRoot> --task-key <task-key> --text
-```
-
-Read the fixed `Reaped panes` and `Note` fields. Confirm which panes were reaped and that the containers are still running. If the user actually wants the containers gone, route to `down`.
+To follow a service's live logs, the user runs `docker compose -p <projectName> logs -f <service>` (get `<projectName>` from `status`).
 
 ---
 
 ## down
 
-Tears down the container group (removes containers found by the run-trace label) and reaps orphan watcher panes.
+Tears down the container group — removes the containers found by the run-trace label.
 
 Single task:
 
@@ -153,7 +122,7 @@ Every container group in the project (no task-key needed):
 okstra container down --project-root <projectRoot> --all --text
 ```
 
-Read the fixed `Downed` and `Orphan panes reaped` fields. Report each torn-down project name and the orphan panes reaped. `down` runs `docker compose -p <name> down --remove-orphans` — a compose-native teardown that removes the project's containers and the compose network, but deliberately keeps named volumes (e.g. DB data) by NOT passing `-v`. Confirm with the user before running `--all`, since it takes down every okstra container group in the project at once. A single-task `down` is safe to run directly once the task-key is resolved.
+Read the fixed `Downed` fields and report each torn-down project name. `down` runs `docker compose -p <name> down --remove-orphans` — a compose-native teardown that removes the project's containers and the compose network, but deliberately keeps named volumes (e.g. DB data) by NOT passing `-v`. Confirm with the user before running `--all`, since it takes down every okstra container group in the project at once. A single-task `down` is safe to run directly once the task-key is resolved.
 
 ---
 

package/runtime/skills/okstra-inspect/facets/history.md

@@ -58,7 +58,7 @@ Builds a fresh run — new run-seq, new manifest, new report — using parameter
    - `taskType` → `--task-type`
    - `taskBriefPath` → `--task-brief`
 3. Optional arguments (include only when present in source):
-   - `recommendedWorkers` → `--workers` (comma-separated)
+   - `Workers` → `--workers` (comma-separated provider ids; the projection already folds roster slot ids like `codex-verifier` down to their provider, so pass the line verbatim and never hand-assemble it from a roster)
    - `relatedTasks` → `--related-tasks`
    - model overrides → `--claude-model`, `--codex-model`, `--antigravity-model`
    - for `taskType: implementation`: `teamContract.executor.provider` → `--executor <claude|codex|antigravity>` when different from `claude`.