okstra 0.147.0 → 0.148.0

package/docs/cli.md

@@ -58,10 +58,10 @@
 Base command for initial entry with full arguments:
 
 ```bash
-scripts/okstra.sh [--render-only] [--yes] [--no-plan-verification] --task-type <task-type> [--workers worker1,worker2] [--lead-runtime claude-code|codex] [--lead-model <model>] [--claude-model <model>] [--codex-model <model>] [--antigravity-model <model>] [--report-writer-model <model>] [--executor claude|codex|antigravity] [--critic off|claude|codex|antigravity] [--related-tasks taskA,taskB] [--work-category bugfix|feature|refactor|ops|improvement|unknown] [--base-ref <branch|tag|sha>] [--clarification-response <previous-final-report>] [--approved-plan <plan-path>] [--approve] --project-id <project-id> --task-group <task-group> --task-id <task-id> --task-brief <brief-path> [--directive <directive>] [--fix-cycle <yes|no>]
+scripts/okstra.sh [--render-only] [--yes] [--no-plan-verification] --task-type <task-type> [--workers worker1,worker2] [--lead-runtime claude-code|codex|antigravity|external] [--lead-provider <provider>] [--lead-model <model>] [--worker-model provider=model,...] [--report-writer-provider <provider>] [--report-writer-model <model>] [--executor claude|codex|antigravity] [--critic off|claude|codex|antigravity|grok|kimi] [--related-tasks taskA,taskB] [--work-category bugfix|feature|refactor|ops|improvement|unknown] [--base-ref <branch|tag|sha>] [--clarification-response <previous-final-report>] [--approved-plan <plan-path>] [--approve] --project-id <project-id> --task-group <task-group> --task-id <task-id> --task-brief <brief-path> [--directive <directive>] [--fix-cycle <yes|no>]
 ```
 
-Analysis input ownership is narrower than the base shell command. The `/okstra-run` wizard collects `--analysis-target` and `--evidence-inputs` values and passes them internally to `node bin/okstra render-bundle`. `scripts/okstra.sh` does not accept either flag. Because `feature-analysis` requires a target, start that task type with `/okstra-run`; the two option sections below document the internal Node render inputs, not standalone shell options.
+Analysis input ownership is narrower than the base shell command. The `/okstra-run` wizard collects `--analysis-target` and `--evidence-inputs` values and passes them internally to `node bin/okstra render-bundle`. `scripts/okstra.sh` does not accept either flag. Because `feature-analysis` requires a target, start that task type with the in-host skill; the two option sections below document the internal Node render inputs, not standalone shell options.
 
 Short form for a later phase when an existing task-manifest.json is available:
 
@@ -371,6 +371,7 @@ Lead runtime independence boundary:
 
 - `claude-code`: the current default execution path. Claude Code v2.1.178 removed `TeamCreate`, and the session owns an implicit team. Workers are dispatched with `Agent(name: ..., run_in_background: true)` without `team_name`. `teamName` is audit/display metadata; Claude session JSONL is used for usage accounting.
 - `codex`: the runtime marker for the Codex lead adapter. `okstra codex-run` owns `--render-only --lead-runtime codex` to prepare a task bundle, and the prepared run manifest can be passed to `okstra codex-dispatch` for CLI-backed worker execution.
+- `antigravity`: the runtime marker for the Antigravity CLI lead adapter. The current Antigravity session owns the native lead, keeps Antigravity assignments native, and routes every other provider through its registered CLI wrapper.
 - `external`: without Claude Code Teams, `--render-only --lead-runtime external` prepares the task bundle and external lead prompt. The lead manages the tmux-pane worker lifecycle with `okstra team dispatch`, `okstra team await`, and `okstra team teardown`. This path does not use `TeamCreate` / `Agent(...)` and uses artifact-only accounting.
 
 The current Claude Code independence boundary covers the external lead prompt and `okstra team *` worker dispatch. non-render `okstra_ctl.run --lead-runtime external` remains blocked; a complete external lead driver remains separate future work. `--runtime external` only selects the runtime adapter. `okstra install` creates `~/.agents/skills/` by default and also installs Claude skills and agents when `~/.claude` exists. Selecting the `claude` worker still requires the local Claude CLI wrapper.
@@ -381,32 +382,47 @@ Code session, that session may not have accepted workspace trust yet. The next
 `/okstra-run` preflight reports `runtimeReadiness.checks[id=workspace-trust]`
 and stops before the wizard when trust is required or cannot be verified. The
 user reopens the project, accepts the one Claude Code workspace prompt, and
-reruns the command. This check applies only to a `claude-code` host; `codex` and
-`external` hosts do not inspect Claude Code state, regardless of whether the
+reruns the command. This check applies only to a `claude-code` host; `codex`,
+`antigravity`, and `external` hosts do not inspect Claude Code state, regardless of whether the
 worker roster contains Claude, Codex, or Antigravity.
 
 ### Runtime auto-detection (`auto`)
 
-`okstra run` defaults to `auto`. `auto` resolves to one of `claude-code`, `codex`, or `external` based on the host through `src/lib/runtime-resolver.mjs`. Precedence: explicit runtime > the `OKSTRA_RUNTIME_HOST` environment variable > Claude Code skill handoff > external when tmux is available > fail fast otherwise. The safe fallback never silently selects a runtime different from the user's intent.
+`okstra run` defaults to `auto`. `auto` resolves to one of `claude-code`, `codex`, `antigravity`, or `external` based on the host through `src/lib/runtime-resolver.mjs`. Precedence: explicit runtime > the `OKSTRA_RUNTIME_HOST` environment variable > Claude Code skill handoff > external when tmux is available > fail fast otherwise. The safe fallback never silently selects a runtime different from the user's intent, and the presence of the `agy` binary alone never selects the Antigravity host.
 
-- Inside Claude Code, `/okstra-run` is the front door. bare `okstra run` cannot invoke Claude Code `TeamCreate` / `Agent(...)`.
-- On a Codex host, `okstra run` orchestrates `codex-run` -> `codex-dispatch`.
+- Inside Claude Code, `/okstra-run` is the front door. Bare `okstra run` cannot invoke host-native Claude workers.
+- On a Codex host, the installed `okstra-run` skill is the front door. Bare `okstra run` cannot invoke host-native Codex workers.
+- On an Antigravity host, the installed `okstra-run` skill is the front door. Bare `okstra run` cannot invoke host-native Antigravity workers.
 - In a generic terminal with tmux, `okstra run` orchestrates `render-bundle --lead-runtime external` -> `okstra team dispatch` -> `okstra team await`.
 
-`doctor` and `render-bundle` also default to `auto`, but a plain terminal without a host signal must specify a host. `okstra install` and `ensure-installed` are exceptions. Installation places the shared runtime and skill targets based on agent homes rather than the runtime host, so it records the `auto` request and unresolved state in the manifest and continues even without a host signal. Skill copy targets depend on the presence of agent homes and the default Agent target policy, not runtime resolution. `~/.agents/skills/` is always created, and Claude skills/agents are installed when `~/.claude` exists. Claude Code skills explicitly specify `--runtime claude-code` / `--lead-runtime claude-code`, so execution does not depend on host auto-detection.
+`doctor` and `render-bundle` also default to `auto`, but a plain terminal without a host signal must specify a host. `okstra install` and `ensure-installed` are exceptions. Installation places the shared runtime and skill targets based on agent homes rather than the runtime host, so it records the `auto` request and unresolved state in the manifest and continues even without a host signal. Skill copy targets depend on the presence of agent homes and the default Agent target policy, not runtime resolution. `~/.agents/skills/` is always created, and Claude skills/agents are installed when `~/.claude` exists. The host-aware `okstra-run` skill passes the current harness runtime explicitly; Claude-only maintenance skills continue to pass `--runtime claude-code` where that host is part of their contract.
 
 `installed-runtimes.json` uses schemaVersion 2 and separates `installRequest`, `runtimeResolution`, `installedRuntimes`, and `installedAssets`. `installed-skills.json` uses a schemaVersion 2 target list with `provider`, `root`, and `skills` to record Claude and Agent skill targets; uninstall removes files according to this list. `codexAdapter` / `externalAdapter` retain read compatibility with v1 manifests only.
 
 For a Codex lead dry run, use `okstra codex-run <args...>`. It adds `--render-only --lead-runtime codex` itself and prints the prepared task bundle and lead prompt without dispatching workers.
 The generated team-state, run manifest, and task manifest point `leadEventsPath` to `runs/<task-type>/state/lead-events-<task-type>-<seq>.jsonl`; rendering records a `bundle-prepared` event.
-Then `okstra codex-dispatch --project-root <dir> --run-manifest <run-manifest> --workers codex[,antigravity[,report-writer]]` executes workers through the existing CLI wrappers. Without `--workers`, it automatically selects the Codex-side supported workers from the run roster: `codex`, `antigravity`, and an opted-in `report-writer`. Explicitly requesting an unsupported worker fails. `report-writer` requires explicit opt-in with `--enable-codex-report-writer --report-writer-codex-model <model>`; on success, postprocessing runs token-usage substitution → render-views → spawn-followups → validate-run in order.
+Then `okstra codex-dispatch --project-root <dir> --run-manifest <run-manifest> [--workers <csv>]` reads each persisted assignment. `runner=native-session` rows stay with the current Codex host; `runner=cli-wrapper` rows run through their registered Claude, Antigravity, Grok, Kimi, or report-writer wrapper. The report-writer provider and model come from the manifest without a Codex-only opt-in flag; on success, postprocessing runs token-usage substitution → render-views → spawn-followups → validate-run in order.
 
-The Codex worker (`--workers codex`, `--codex-model`) and Codex lead runtime are separate. The former selects a worker provider dispatched by a Claude Code lead; the latter is the upper runtime boundary for running the lead itself through the Codex adapter.
+The Codex worker (`--workers codex`, `--codex-model`) and Codex lead runtime are separate. The former creates a worker assignment whose runner depends on the host; the latter selects Codex as the native lead boundary. On Claude Code the Codex worker uses a CLI wrapper, while on Codex it uses the host-native worker/session primitive.
 
 > Every `--*-model` flag accepts only aliases registered in the provider mappings in `scripts/okstra_ctl/models.py`. An unregistered value is immediately rejected with `UnknownModelError`, preventing a contract violation where the manifest's `modelExecutionValue` differs from the actual execution value. Allowed values:
-> - Claude (`--lead-model` / `--claude-model` / `--report-writer-model`): `fable`, `fable-5`, `claude-fable-5`, `opus`, `opus-5`, `claude-opus-5`, `opus-4-8`, `claude-opus-4-8`, `opus-4-7`, `claude-opus-4-7`, `opus-4-6`, `claude-opus-4-6`, `sonnet`, `sonnet-4-6`, `claude-sonnet-4-6`, `haiku`, `haiku-4-5`, `claude-haiku-4-5`, `claude-haiku-4-5-20251001`
+> - Claude (`--lead-model` / `--claude-model` / `--report-writer-model`): `fable`, `fable-5`, `claude-fable-5`, `opus`, `opus-5`, `claude-opus-5`, `opus-4-8`, `claude-opus-4-8`, `opus-4-7`, `claude-opus-4-7`, `opus-4-6`, `claude-opus-4-6`, `sonnet`, `sonnet-5`, `claude-sonnet-5`, `sonnet-4-6`, `claude-sonnet-4-6`, `haiku`, `haiku-4-5`, `claude-haiku-4-5`, `claude-haiku-4-5-20251001`
 > - Codex (`--codex-model`): `gpt-5.6-sol`, `gpt-5.6`, `gpt-5.5`, `gpt-5.4`, `gpt-5.4-mini`, `gpt-5.3-codex`, `gpt-5.2`, `codex-auto-review`
-> - Antigravity (`--antigravity-model`): `gemini-3.1-pro` (default), `gemini-3.5-flash`, and the space-separated aliases `gemini 3.1 pro` / `gemini 3.5 flash`. The antigravity worker uses the `agy` CLI to run Gemini-family models, so model IDs retain the `gemini-*` form.
+> - Antigravity (`--antigravity-model`): `gemini-3.1-pro` (default), `gemini-3.6-flash`, `gemini-3.5-flash`, and their space-separated aliases. The antigravity worker uses the `agy` CLI to run Gemini-family models, so model IDs retain the `gemini-*` form.
+> - Grok (`--worker-model grok=<model>`): `grok-build-0.1`, `grok-4.5`
+> - Kimi (`--worker-model kimi=<model>`): `kimi-k2.7-code`, `kimi-for-coding`, `kimi-k3`, `k3`, `k3-256k` and their registered display aliases
+
+### `--lead-provider`
+
+Compatibility assertion for previously recorded invocations. The value must match the host-native provider: `claude` on Claude Code, `codex` on Codex, and `antigravity` on Antigravity. It is not an independent lead selector. Other providers belong in the worker roster and run through CLI wrappers; preparation rejects a cross-provider lead rather than recording one model and silently running another.
+
+### `--worker-model`
+
+Adds generic `provider=model` overrides, separated by commas. It is the model input for registry providers without a legacy dedicated flag, including Grok and Kimi.
+
+### `--report-writer-provider`
+
+Selects a registry provider that declares the `report-writer` capability. Claude remains the default; Codex is also supported. The provider, model, and resolved runner are persisted in `workerAssignments[]`.
 
 ### `--claude-model`
 
@@ -415,8 +431,7 @@ When omitted, it uses the central default `OKSTRA_DEFAULT_CLAUDE_MODEL`, falling
 
 ### `--lead-model`
 
-Selects the model used by the `Claude lead`.
-When omitted, it uses the central default `OKSTRA_DEFAULT_LEAD_MODEL`, falling back to `opus`.
+Selects the model used by the host-native Okstra lead. Claude Code resolves it through the Claude catalog; Codex resolves it through the Codex catalog; Antigravity resolves it through the Antigravity catalog. When omitted, the host-native provider's lead default applies.
 
 ### `--codex-model`
 
@@ -444,7 +459,9 @@ The central-default environment variables are:
 
 Fallback defaults are:
 
-- `Claude lead`: `opus`
+- Claude Code lead: `opus`
+- Codex lead: `gpt-5.6-sol`
+- Antigravity lead: `gemini-3.1-pro`
 - `Report writer worker`: `sonnet`
 - `Claude worker`: `opus`
 - `Codex worker`: `gpt-5.6-sol`
@@ -478,7 +495,7 @@ scripts/okstra.sh --task-type implementation \
 
 ### `--critic`
 
-Selects the provider for the opt-in Phase 5.6 critic pass. The value is `off`, `claude`, `codex`, or `antigravity`; the default is `off`.
+Selects the provider for the opt-in Phase 5.6 critic pass. The value is `off`, `claude`, `codex`, `antigravity`, `grok`, or `kimi`; the default is `off`. The selected critic receives its own role-default model even when that provider is not in the initial analyser roster.
 
 - Critic dispatch runs concurrently with the first convergence reverify round in Phase 5.5, with critic input fixed to the integrated Round 0 result. One gap/blocker verification round runs in Phase 5.6 after convergence finishes. It detects coverage gaps in discovery, error-analysis, and implementation-planning, and acts as an acceptance devil's advocate in final-verification. Follow the "Coverage critic pass" and "Acceptance critic pass" sections of `prompts/lead/convergence.md` for the detailed contract.
 - It shares the same value space as the critic-selection step in the in-session `okstra-run` wizard. `_resolve_model_bindings` in `prepare_task_bundle` validates the value; anything else is rejected immediately with `PrepareError`.
@@ -690,13 +707,13 @@ The `okstra` Node CLI (`bin/okstra`) provides both installer/admin commands and
 | Command | Purpose |
 |---|---|
 | `okstra paths [--field <name>\|--shell]` | Print package, runtime, home, bin, Python path, and version locations |
-| `okstra install [--runtime claude-code\|codex\|external\|all] [--refresh\|--dry-run\|--link <repo>]` | Install or update the runtime, templates, skills, and agents. The default runtime is `auto`; skill targets are not runtimes. `~/.agents/skills/` is always created, and Claude skills and agents are also installed when `~/.claude` exists |
-| `okstra ensure-installed [--runtime claude-code\|codex\|external\|all] [-q]` | Check installation state and reinstall stale assets for the same runtime. Default `auto` continues without a host signal and checks drift in the Agent skill target and any existing Claude target |
+| `okstra install [--runtime claude-code\|codex\|antigravity\|external\|all] [--refresh\|--dry-run\|--link <repo>]` | Install or update the runtime, templates, skills, and agents. The default runtime is `auto`; skill targets are not runtimes. `~/.agents/skills/` is always created, and Claude skills and agents are also installed when `~/.claude` exists |
+| `okstra ensure-installed [--runtime claude-code\|codex\|antigravity\|external\|all] [-q]` | Check installation state and reinstall stale assets for the same runtime. Default `auto` continues without a host signal and checks drift in the Agent skill target and any existing Claude target |
 | `okstra uninstall [--purge -y]` | Remove installed assets. By default, removes files listed by the `installed-skills.json` targets and `installed-agents.json` while preserving user data |
-| `okstra doctor [--runtime claude-code\|codex\|external\|all] [--phase <phase>] [--json]` | Diagnose the runtime, Python imports, and skill/agent installation. The `codex` and `external` runtimes omit Claude skill checks. `--phase` adds readiness checks for `implementation`, `final-verification`, `release-handoff`, or `improvement-discovery` |
+| `okstra doctor [--runtime claude-code\|codex\|antigravity\|external\|all] [--phase <phase>] [--json]` | Diagnose the runtime, Python imports, and skill/agent installation. The `codex`, `antigravity`, and `external` runtimes omit Claude skill checks. `--phase` adds readiness checks for `implementation`, `final-verification`, `release-handoff`, or `improvement-discovery` |
 | `okstra setup --project-id <id>` | Create or update `.okstra/project.json` in the current project |
 | `okstra check-project [--json]` | Verify that the current project is registered |
-| `okstra preflight [--runtime <name>] [--cwd <dir>] [--json]` | Single skill-preflight call combining `ensure-installed`, with silent reinstall when stale, `check-project`, and host-specific `runtimeReadiness` into one JSON response. A `claude-code` host checks project workspace trust; `codex` and `external` hosts return ready without reading Claude Code state. Step 0 of every project-scoped skill converges on this command |
+| `okstra preflight [--runtime <name>] [--cwd <dir>] [--json]` | Single skill-preflight call combining `ensure-installed`, with silent reinstall when stale, `check-project`, and host-specific `runtimeReadiness` into one JSON response. A `claude-code` host checks project workspace trust; `codex`, `antigravity`, and `external` hosts return ready without reading Claude Code state. Step 0 of every project-scoped skill converges on this command |
 | `okstra convergence seed --groups <path> --work-state <path> --final-state <path> --migration-dir <dir> [--restart-from-round0]` | Create, resume, reuse, or explicitly recover deterministic convergence state |
 | `okstra convergence plan-round --work-state <path> --plan <path>` | Persist the next roster-aware dispatch plan without mutating working state |
 | `okstra convergence apply-round --work-state <path> --plan <path> --results <path>` | Validate one complete structured result set and atomically reduce it into working state |
@@ -729,7 +746,7 @@ The `okstra` Node CLI (`bin/okstra`) provides both installer/admin commands and
 | `okstra plan-validate <plan-path>` | Run `_validate_approved_plan` and report frontmatter `approved` recognition plus unresolved Blocks=approval rows |
 | `okstra render-bundle <args…> [--stage <auto\|N>] [--stages <csv>]` | Thin shim over `prepare_task_bundle(render_only=True)` with the same signature as `python3 -m okstra_ctl.run --render-only`. `--stage` is for `implementation` and `final-verification`: for implementation, `auto` (default) selects the earliest incomplete stage with satisfied dependencies, while `<N>` forces a stage; for final-verification, `<N>` verifies one stage with artifacts under `runs/final-verification/stage-<N>/` and a `-fv-s<N>` team suffix, while an empty value performs whole-task verification with the flat layout. The separate `--stages <csv>` channel is for `release-handoff`: stage-group mode bundles the listed stage numbers into one PR, while an empty value selects whole-task mode. Preparation enforces eligibility—`done` + accepted `verified` + not yet `pr`—and automatically creates an input document that cites verification reports |
 | `okstra codex-run <args…>` | Codex lead-adapter dry-run entry point. Accepts the same arguments as `render-bundle` but owns `--render-only --lead-runtime codex`. It prepares the task bundle and prints the prompt for the Codex lead without dispatching workers |
-| `okstra codex-dispatch --project-root <dir> --run-manifest <path> [--workers codex,antigravity,report-writer]` | Read a run manifest prepared by `codex-run` and execute the Codex-side supported worker subset. Without `--workers`, unsupported roster members such as `claude` are skipped; explicitly requesting one fails. The report writer requires opt-in with `--enable-codex-report-writer --report-writer-codex-model <model>`. On success, it automatically performs token-usage substitution, HTML view rendering, follow-up task-stub generation, and run validation |
+| `okstra codex-dispatch --project-root <dir> --run-manifest <path> [--workers <csv>]` | Read a Codex-host run manifest and dispatch every requested `runner=cli-wrapper` assignment through its registered provider wrapper. Native Codex rows remain in-session. The persisted report-writer assignment needs no Codex-specific opt-in; successful report completion triggers token substitution, HTML rendering, follow-up generation, and validation |
 | `okstra team dispatch --project-root <dir> --run-manifest <path> [--workers <csv>] [--jobs-file <path>] [--dry-run]` / `okstra team await --project-root <dir> --run-manifest <path> [--json]` / `okstra team teardown --project-root <dir> --run-manifest <path> [--dry-run] [--json]` | Read a `leadRuntime=external` run manifest and dispatch, await, or tear down tmux-pane workers. If a tmux pane cannot be created, gracefully degrade to the CLI wrapper and record the fallback in `workerDispatches[].degradedFrom` |
 | `okstra report-finalize --project-root <dir> --run-manifest <path> --report <final-report.md>` | Run the whole Phase 7 post-report sequence in its contractual order: `token-usage` → `render-views` → `spawn-followups` → `validate-run`. Stops at the first non-zero exit and names the failing step, then prints a per-step `[ok]` / `[FAIL]` / `[skip]` summary on stderr so the outcome is legible without parsing the JSON payload. Every step is idempotent, so re-running after a fix is safe — but `--only <step>` (repeatable) reruns just the named steps in contractual order, which matters because `validate-run` is the step that usually fails and retrying it otherwise repeats the three steps before it at full token and wall-clock cost. This is the same code path (`scripts/okstra_ctl/report_finalize.py`) the Codex lead adapter runs automatically after its report-writer completes, so a Claude-led and a Codex-led run finalize identically. `--workspace-root` is owned by the Node wrapper. Prefer this over invoking the four steps individually |
 | `okstra render-views <final-report.data.json\|final-report.md>` | The Phase 7 `render-views` step, runnable on its own. Schema v2 data is rendered directly (contract: `schemas/final-report-v2.0.schema.json`) into an always-generated, task-specific human HTML sibling while `templates/reports/final-report-v2.template.md` independently owns the AI handoff Markdown. Passing the Markdown sibling locates the same v2 data.json. Schema v1 and quick reports keep the legacy conditional renderer. The Node wrapper calls `scripts/okstra-render-report-views.py`; `validators/validate-report-views.py` verifies source/schema/template digests, required human fields, form controls, external assets, diagram/table ID parity, and Response ID parity |

package/docs/for-ai/skills/okstra-run.md

@@ -10,7 +10,7 @@
 
 ## Purpose
 
-`okstra-run` starts an okstra task run inside the current Claude Code session. Input collection is owned entirely by the `okstra wizard` state machine; the skill relays the wizard prompts to the user and then prepares the task bundle via `okstra render-bundle`. Once the bundle is ready, the current session takes over as Claude lead.
+`okstra-run` starts an okstra task run inside the current supported agent host. Input collection is owned entirely by the `okstra wizard` state machine; the skill relays the wizard prompts to the user and then prepares the task bundle via `okstra render-bundle`. Once the bundle is ready, the current Claude Code, Codex, or Antigravity session takes over as the host-native Okstra lead.
 
 Single authority:
 
@@ -34,10 +34,10 @@ Do not use it when:
 
 ## Preflight
 
-A single Bash call:
+Resolve `<host-runtime>` from the executing harness: Claude Code → `claude-code`, Codex → `codex`, Antigravity CLI → `antigravity`, and another adapter host → `external`. This is a host capability, not a `PATH` inference or worker-provider choice. The lead provider is derived from this value and cannot be selected independently. Then make one Bash call:
 
 ```bash
-okstra preflight --runtime claude-code --json
+okstra preflight --runtime <host-runtime> --json
 ```
 
 If there is no runtime or project setup (`ok:false`), point the user to `/okstra-setup` and stop. Do not create an `export PYTHONPATH`.
@@ -73,7 +73,7 @@ Carry the printed absolute path verbatim.
 wizard init:
 
 ```bash
-okstra wizard init --state-file /tmp/okstra-wizard/state.json --project-root /abs/project --project-id project-id
+okstra wizard init --state-file /tmp/okstra-wizard/state.json --project-root /abs/project --project-id project-id --host-runtime <host-runtime>
 ```
 
 The result is `{ok, next}` JSON. The first step is `task_pick`.
@@ -130,34 +130,13 @@ When `next.kind == "done"`:
 okstra wizard outcome --state-file /tmp/okstra-wizard/state.json
 ```
 
-Run `outcome.persistActions[]` first, then pass each key of the `outcome.renderArgs` object as an `okstra render-bundle` flag. Pass empty string values explicitly too. Exception: the `chain-stages` key is not a render-bundle flag — it drives the Step 7 unattended-chaining loop, so do not pass it as a flag (`run.py` accepts only `--stage`/`--stages`). In the render-bundle block, `--stage` is implementation·final-verification only, and `--stages` is release-handoff only (empty value = whole-task).
+Run `outcome.persistActions[]` first, then pass each key of the `outcome.renderArgs` object exactly once as an `okstra render-bundle` flag. Pass empty string values explicitly too, and add `--lead-runtime <host-runtime>` from preflight. Do not enumerate provider-specific keys in this manual; the wizard and provider registry own the emitted arguments. Exception: the `chain-stages` key is not a render-bundle flag — it drives the Step 7 unattended-chaining loop, so do not pass it as a flag (`run.py` accepts only `--stage`/`--stages`).
 
 ```bash
 okstra render-bundle \
-  --lead-runtime claude-code \
-  --project-root "<args.project-root>" \
-  --project-id "<args.project-id>" \
-  --task-group "<args.task-group>" \
-  --task-id "<args.task-id>" \
-  --task-type "<args.task-type>" \
-  --task-brief "<args.task-brief>" \
-  --executor "<args.executor>" \
-  --critic "<args.critic>" \
-  --approved-plan "<args.approved-plan>" \
-  --stage "<args.stage>" \
-  --stages "<args.stages>" \
-  --base-ref "<args.base-ref>" \
-  --workers "<args.workers>" \
-  --directive "<args.directive>" \
-  --lead-model "<args.lead-model>" \
-  --claude-model "<args.claude-model>" \
-  --codex-model "<args.codex-model>" \
-  --antigravity-model "<args.antigravity-model>" \
-  --report-writer-model "<args.report-writer-model>" \
-  --related-tasks "<args.related-tasks>" \
-  --clarification-response "<args.clarification-response>" \
-  --pr-template-path "<args.pr-template-path>" \
-  --fix-cycle "<args.fix-cycle>"
+  --lead-runtime <host-runtime> \
+  --<first-renderArgs-key> "<first-renderArgs-value>" \
+  --<each-remaining-renderArgs-key> "<corresponding-value>"
 ```
 
 Parse the following labeled lines from stdout.
@@ -227,14 +206,14 @@ okstra config set pr-template-path "<path>" --scope global
 
 Read the scope and path from the persist action of `okstra wizard outcome`, not from the wizard state file. Do not read the raw state file directly.
 
-## Claude lead takeover
+## Okstra lead takeover
 
-After render-bundle, read `<INSTRUCTION_SET_PATH>/claude-execution-prompt.md` verbatim and proceed from Phase 1 in that prompt's order.
+After render-bundle, read `<INSTRUCTION_SET_PATH>/lead-execution-prompt.md` verbatim and proceed from Phase 1 in that prompt's order.
 
 Inform the user on one line.
 
 ```text
-Took over as Claude lead for `<taskKey>` (`<task-type>`). Run dir: `<RUN_DIR_RELATIVE_PATH>`. Beginning Phase 1 (context loading).
+Took over as Okstra lead (`<host-runtime>`) for `<taskKey>` (`<task-type>`). Run dir: `<RUN_DIR_RELATIVE_PATH>`. Beginning Phase 1 (context loading).
 ```
 
 For a single-element chain, the end of Step 6 is the end of the run. Step 7 below applies only when the `chain-stages` CSV has 2 or more elements.
@@ -244,7 +223,7 @@ For a single-element chain, the end of Step 6 is the end of the run. Step 7 belo
 When `task-type == implementation` and the render-args `chain-stages` CSV has 2 or more elements, the current session acts as the orchestrator and runs the stages as an unattended chain in dependency order. Queue = the topologically-sorted stage list from splitting `chain-stages` on `,`. For each stage `N` in the queue, in order:
 
 1. Re-call render-bundle with the same arguments but `--stage N` (the base commit is auto-computed by prepare from the predecessor's done `head_commit` — do not pass it by hand). The `io`-only conformance waiver·concurrent-run·git-reconcile gates apply identically to each stage's render-bundle.
-2. As in Step 6, become Claude lead and run that stage's Phase 1–7 inline. Phase 6's lead persistence appends that stage's `status:"done"` row to `runs/<plan-task-key>/consumers.jsonl`.
+2. As in Step 6, become the host-native Okstra lead and run that stage's Phase 1–7 inline. Phase 6's lead persistence appends that stage's `status:"done"` row to `runs/<plan-task-key>/consumers.jsonl`.
 3. After confirming the `done` row was written, move to the next stage. Clean up context (leftover panes·finished teammates) at each stage boundary.
 4. One-line report at each stage start/finish: `stage N/<total> start` / `stage N done → next K`.
 
@@ -261,4 +240,4 @@ Once the whole queue is consumed, end the chain and report completion.
 - Dropping the `--answer` flag on an empty answer.
 - Bypassing the wizard/render-bundle path by calling `okstra.sh`.
 - Calling render-args on a state the user aborted before render-bundle.
-- Starting phase work arbitrarily before reading the Claude lead prompt.
+- Starting phase work arbitrarily before reading the Okstra lead prompt.

package/docs/performance-improvement-plan-v2.md

@@ -63,7 +63,7 @@ The current documentation and code contain two layers with similarly named phase
 
 Each okstra invocation performs exactly one task type. Moving to the next task type requires a new invocation.
 
-#### Claude lead operating phases
+#### Okstra lead operating phases
 
 Phases 1–7 in `prompts/lead/okstra-lead-contract.md` are operating steps that the lead performs within one task-type run.
 
@@ -81,7 +81,7 @@ Therefore, "P1 convergence improvement" in this document does not change the tas
 
 `prepare_task_bundle()` writes the instruction set and manifest-related files sequentially.
 
-- Instruction set: `analysis-profile.md`, `analysis-material.md`, `task-brief.md`, optional carry-in/directive, `reference-expectations.md`, `final-report-template.md`, `claude-execution-prompt.md`, and the prompt snapshot.
+- Instruction set: `analysis-profile.md`, `analysis-material.md`, `task-brief.md`, optional carry-in/directive, `reference-expectations.md`, `final-report-template.md`, canonical `lead-execution-prompt.md`, and the prompt snapshot.
 - Manifest/discovery: `team-state`, `task-manifest`, `task-index`, `run-manifest`, `timeline`, task catalog, and latest task.
 
 This serial rendering has room for improvement, but it is generally cheaper than external worker dispatch. Render parallelization is therefore not the first priority.

package/docs/pr-template-usage.md

@@ -1,6 +1,6 @@
 # PR template usage guide
 
-Summarizes the resolution rules, storage locations, and configuration methods for the Markdown template that `Claude lead` uses to write the PR body during the `release-handoff` phase.
+Summarizes the resolution rules, storage locations, and configuration methods for the Markdown template that the host-native `Okstra lead` uses to write the PR body during the `release-handoff` phase.
 
 Authoritative source of the resolution logic: [`scripts/okstra_ctl/pr_template.py`](../scripts/okstra_ctl/pr_template.py).
 

package/docs/project-structure-overview.md

@@ -20,7 +20,7 @@
 
 ## 1. Project identity
 
-`okstra` is a multi-agent cross-verification runtime for Claude Code, distributed as the npm package `okstra`. It is not a one-shot reviewer; it runs a lead + worker model across multiple lifecycle phases around a stable task key.
+`okstra` is a host-aware, multi-provider cross-verification runtime distributed as the npm package `okstra`. It is not a one-shot reviewer; it runs one neutral lifecycle core through Claude Code, Codex, or an explicit external adapter around a stable task key.
 
 Current baseline:
 
@@ -28,8 +28,8 @@ Current baseline:
 - Node CLI entrypoint: `bin/okstra`
 - Python orchestration authority: `scripts/okstra_ctl/run.py::prepare_task_bundle`
 - lifecycle: `requirements-discovery → error-analysis → implementation-planning → implementation → final-verification → release-handoff`
-- installed skills: 8
-- worker agents: `claude`, `codex`, `antigravity`, `report-writer`
+- installed skills: 13
+- provider workers: `claude`, `codex`, `antigravity`, `grok`, `kimi`; functional report writer: `report-writer`
 - final report SSOT: current `schemas/final-report-v2.0.schema.json` + `*.data.json`; schema v1 remains a compatibility contract
 
 Design principles:
@@ -180,7 +180,7 @@ Runtime/install asset changes follow this checklist:
 | `worktree-lookup` | `src/commands/execute/worktree-lookup.mjs` | Look up a task-key's registered worktree |
 | `plan-validate` | `src/commands/execute/plan-validate.mjs` | Check approved-plan approval marker |
 | `render-bundle` | `src/commands/execute/render-bundle.mjs` | Preview `prepare_task_bundle(render_only=True)` |
-| `run` | `src/commands/execute/run.mjs` | Host-aware execution front door (`auto` → Claude/Codex/external path selection) |
+| `run` | `src/commands/execute/run.mjs` | Host-aware execution front door (`auto` → Claude/Codex/Antigravity/external path selection) |
 | `codex-run`, `codex-dispatch` | `src/commands/execute/codex-*.mjs` | Codex lead dry-run bundle preparation and CLI-backed worker dispatch |
 | `team` | `src/commands/execute/team.mjs` | External lead tmux-pane worker dispatch / await / teardown |
 | `convergence` | `src/commands/execute/convergence.mjs` | Internal admin CLI for the deterministic Phase 5.5 convergence engine (`seed`/`plan-round`/`apply-round`/`apply-critic-gaps`/`finalize`/`validate`/`example`; Python: `okstra_ctl.convergence`) |
@@ -288,7 +288,7 @@ Important modules:
 | `manager_store.py` | Manager-owned state mutation — project membership, task planning, assignment, directives, event append |
 | `manager_sync.py` | One-way child project `.okstra` snapshot reader; corrupt child state becomes row-level `error` so other children continue |
 | `manager_launch.py` | Child launch packet and manager child context renderer; records `prepared` launch metadata/events without changing project-local task state |
-| `dispatch_core.py` | Backend-neutral worker dispatch core — worker execution/collection logic shared by any lead runtime (Claude/Codex/external); gates selected initial prompts through the shared cross-task contract before launch |
+| `dispatch_core.py` | Backend-neutral worker dispatch core — worker execution/collection logic shared by any lead runtime (Claude/Codex/Antigravity/external); gates selected initial prompts through the shared cross-task contract before launch |
 | `codex_dispatch.py` | Codex lead CLI-worker dispatcher — the `okstra codex-dispatch` backend. Reads the run manifest to run the Codex-side supported worker subset, applies the same cross-task initial-prompt gate, and performs token-usage substitution, view render, follow-up, and validation |
 | `analysis_packet.py` | assembles the compact analysis-worker input packet for a task run from worker-owned profile sections; report/lead procedure stays outside the packet |
 | `analysis_inputs.py` | shared input boundary for `project-analysis`, `feature-analysis`, and `change-impact-analysis` — validates evidence-report identity and review status, enforces the type-to-type relation allowlist, computes `exact`/`stale` freshness, and resolves free-text or `PF-NNN` feature targets for both wizard and prepare paths |
@@ -298,7 +298,7 @@ Important modules:
 | `work_categories.py` | requirements-discovery work-category (domain) **SSOT** (`is_valid_category`) — the work-category allowlist is defined only here |
 | `model_discovery.py` | pre-dispatch model-identity normalization for CLI workers — roster-gated label correction + a per-role reasoning-effort policy (deterministic, no per-run improvisation) for CLIs (agy) that bake effort into the model name |
 | `lead_runtime.py` | lead runtime metadata shared by the render and prepare paths (`LeadRuntimeInfo`) |
-| `lead_events.py` | structured JSONL events emitted by non-Claude lead runtimes |
+| `lead_events.py` | structured JSONL events emitted by artifact-accounted lead runtimes |
 | `team_reconcile.py` | stale team-member reconciliation at run-end teardown |
 | `worker_prompt_headers.py` | shared rendering of phase-aware worker prompt anchors (`worker_prompt_headers`): coding-preflight only for implementation and compact target identity for final-verification |
 | `worker_prompt_body.py` | provider-neutral initial analysis body/input renderer shared by Codex and external/team dispatch paths |
@@ -399,7 +399,7 @@ Boilerplate shared by several skills (bash invocation rule, outdated-CLI preflig
 | Skill | User-invocable | Role |
 |---|---:|---|
 | `okstra-brief-gen` | yes | Produce task brief from ticket/doc/link/conversation |
-| `okstra-run` | yes | Start/resume okstra task in current Claude Code session |
+| `okstra-run` | yes | Start/resume an okstra task in the current Claude Code, Codex, or Antigravity host session |
 | `okstra-memory` | yes | Store/search/archive global conversation memory under `~/.okstra/memory-book` |
 | `okstra-inspect` | yes | Unified read-side — sub-commands `status` (lifecycle + workStatus), `history` (past runs / re-run / resume), `report` (find final-report), `time` (elapsed-time breakdown), `logs` (wrapper log inventory + cleanup), `cost` (task bundle context/read cost), `errors` (error-log aggregation), `error-zip` (anonymized cross-project error bundle), `recap` (cross-run phase recap). `SKILL.md` is a thin core (preflight + dispatch table + shared rules) and each sub-command body lives in `skills/okstra-inspect/facets/<sub-command>.md`, lazily read only after dispatch resolves; the 1:1 match between dispatch rows and facet files is enforced by `tests/contract/test_okstra_inspect_facets.py` |
 | `okstra-rollup` | yes | Cross-task roll-up — aggregate runs/time/errors across a task-group (or whole project) and synthesize a digest from the report files |
@@ -421,9 +421,11 @@ Boilerplate shared by several skills (bash invocation rule, outdated-CLI preflig
 | `agents/workers/claude-worker.md` | Claude analyzer/verifier/executor spec |
 | `agents/workers/codex-worker.params.json` | Codex analyzer/verifier/executor wrapper params (build renders `.md` via `_cli-wrapper-template.md`) |
 | `agents/workers/antigravity-worker.params.json` | Antigravity analyzer/verifier/executor wrapper params (build renders `.md` via `_cli-wrapper-template.md`) |
+| `agents/workers/grok-worker.params.json` | Grok read-only analyser/critic wrapper params |
+| `agents/workers/kimi-worker.params.json` | Kimi read-only analyser/critic wrapper params |
 | `agents/workers/report-writer-worker.md` | data.json SSOT author and audit sidecar writer |
 
-The neutral lead lifecycle contract lives at `prompts/lead/okstra-lead-contract.md`. Host mappings live under `prompts/lead/adapters/`: `claude-code.md`, `codex.md`, and `external.md`. All are runtime resources installed under `~/.okstra/prompts/lead/`, not agent skills.
+The neutral lead lifecycle contract lives at `prompts/lead/okstra-lead-contract.md`. Host mappings live under `prompts/lead/adapters/`: `claude-code.md`, `codex.md`, `antigravity.md`, and `external.md`. All are runtime resources installed under `~/.okstra/prompts/lead/`, not agent skills.
 
 ### 4.12 `tests/` and `tests-e2e/`
 

package/docs/task-process/README.md

@@ -10,7 +10,7 @@
 
 ## 1. Reading order
 
-`okstra-run` is the path that starts a task inside a Claude Code session. This folder organizes that execution flow into two layers.
+`okstra-run` is the path that starts a task inside a supported Claude Code, Codex, or Antigravity host session. This folder organizes that execution flow into two layers.
 
 1. First read [common-flow.md](common-flow.md). It is the wizard, render-bundle, lead phase, and artifact flow shared by every task-type.
 2. Then read the document for the task-type you want to run.
@@ -20,14 +20,14 @@
 
 ```mermaid
 flowchart TD
-    U[User in Claude Code] --> S[/okstra-run skill/]
+    U[User in supported host] --> S[okstra-run skill]
     S --> R[Step 1<br/>ensure-installed / paths / check-project]
     R --> W[okstra wizard<br/>state machine]
     W --> A[render-args]
     A --> B[okstra render-bundle<br/>--render-only]
     B --> P[prepare_task_bundle()]
-    P --> I[instruction-set<br/>claude-execution-prompt.md]
-    I --> L[Current Claude session<br/>takes over as Claude lead]
+    P --> I[instruction-set<br/>lead-execution-prompt.md]
+    I --> L[Current host session<br/>takes over as Okstra lead]
     L --> F[Phase 1-7 lead workflow]
     F --> O[final-report + manifests + status]
 ```

package/docs/task-process/common-flow.md

@@ -6,21 +6,21 @@
 - [2. Where the two entrypoints meet](#2-where-the-two-entrypoints-meet)
 - [3. wizard input collection flow](#3-wizard-input-collection-flow)
 - [4. render-bundle and prepare_task_bundle](#4-render-bundle-and-prepare_task_bundle)
-- [5. Claude lead phase 1-7](#5-claude-lead-phase-1-7)
+- [5. Okstra lead phase 1-7](#5-okstra-lead-phase-1-7)
 - [6. artifact layout](#6-artifact-layout)
 - [7. Common branching rules](#7-common-branching-rules)
 - [8. Inconsistencies to watch for](#8-inconsistencies-to-watch-for)
 
 ## 1. One-line summary
 
-`okstra-run` is not a "skill that decides questions on its own" but a thin loop that relays the `okstra wizard` JSON state machine to the user. Once input collection finishes, it calls `okstra render-bundle`, and that command builds the task bundle through `python3 -m okstra_ctl.run --render-only`. After that, the current Claude Code session switches over to `Claude lead`.
+`okstra-run` is not a "skill that decides questions on its own" but a thin loop that relays the `okstra wizard` JSON state machine to the user. Once input collection finishes, it calls `okstra render-bundle`, and that command builds the task bundle through `python3 -m okstra_ctl.run --render-only`. After that, the current Claude Code, Codex, or Antigravity session switches over to the host-native `Okstra lead`.
 
 ## 2. Where the two entrypoints meet
 
 ```mermaid
 flowchart LR
-    subgraph InSession["Claude Code in-session"]
-        A[/okstra-run skill/] --> B[okstra wizard]
+    subgraph InSession["supported host session"]
+        A[okstra-run skill] --> B[okstra wizard]
         B --> C[okstra render-bundle<br/>forces --render-only]
     end
 
@@ -32,7 +32,7 @@ flowchart LR
     E --> P
     P --> G[task bundle artifacts]
     G --> H{launch mode}
-    H -->|render-only| I[current Claude reads lead prompt]
+    H -->|render-only| I[current host reads lead prompt]
     H -->|non-render-only| J[exec claude --session-id ...]
 ```
 
@@ -93,19 +93,19 @@ sequenceDiagram
     Py->>Home: record_start status=prepared
     Py-->>Node: task root, instruction-set, rendered lead prompt
     Node-->>Skill: stdout
-    Skill->>FS: read claude-execution-prompt.md
+    Skill->>FS: read lead-execution-prompt.md
 ```
 
-The Node shim for `render-bundle` is [`src/commands/execute/render-bundle.mjs`](../../src/commands/execute/render-bundle.mjs). This shim attaches the `--workspace-root`, `--render-only`, and runtime resolution arguments directly. As a result, on the okstra-run path the initial run status starts at `prepared` and the task status starts at `instruction-set-generated`.
+The Node shim for `render-bundle` is [`src/commands/execute/render-bundle.mjs`](../../src/commands/execute/render-bundle.mjs). This shim attaches the `--workspace-root`, `--render-only`, and runtime resolution arguments directly. As a result, on the okstra-run path the initial run status starts at `prepared` and the task status starts at `ready-for-lead`.
 
-## 5. Claude lead phase 1-7
+## 5. Okstra lead phase 1-7
 
 ```mermaid
 flowchart TD
     P1[Phase 1<br/>task bundle intake] --> P2[Phase 2<br/>worker prompt preparation]
-    P2 --> P3[Phase 3<br/>TeamCreate]
-    P3 -->|team ok| P4[Phase 4<br/>dispatch workers with team_name]
-    P3 -->|team unavailable| P5[Phase 5<br/>background fallback]
+    P2 --> P3[Phase 3<br/>resolve persisted runners]
+    P3 -->|native session| P4[Phase 4<br/>host-native dispatch]
+    P3 -->|CLI wrapper| P5[Phase 4<br/>provider CLI dispatch]
     P4 --> C[Phase 5.5<br/>convergence]
     P5 --> C
     C --> P6[Phase 6<br/>report-writer synthesis]
@@ -127,7 +127,7 @@ flowchart TD
     Root --> Hist[history/timeline.json]
     IS --> Profile[analysis-profile.md]
     IS --> Brief[task-brief.md]
-    IS --> Lead[claude-execution-prompt.md]
+    IS --> Lead[lead-execution-prompt.md]
     Runs --> Man[manifests/run-manifest-*.json]
     Runs --> Prompts[prompts/*-worker-prompt-*.md]
     Runs --> Results[worker-results/*.md]

package/docs/task-process/final-verification.md

@@ -45,7 +45,7 @@ sequenceDiagram
     participant C as consumers.jsonl
     participant Reg as worktree registry
     participant Git as verification worktree
-    participant Lead as Claude lead
+    participant Lead as Okstra lead
 
     P->>C: backfill carry and read done rows
     P->>Reg: resolve task or stage worktree
@@ -75,7 +75,7 @@ Once started, the lead treats `VERIFICATION_TARGET` as authoritative. It does no
 ```mermaid
 flowchart TD
     Gate[entry gate passed] --> Target[injected VERIFICATION_TARGET]
-    Target --> Lead[Claude lead confirms target snapshot]
+    Target --> Lead[Okstra lead confirms target snapshot]
     Lead --> CW[Claude verifier<br/>read-only]
     Lead --> XW[Codex verifier<br/>read-only]
     Lead --> GW{Antigravity opt-in?}

package/docs/task-process/implementation.md

@@ -102,7 +102,7 @@ These outcomes are enforced by
 
 ```mermaid
 flowchart TD
-    Lead[Claude lead] --> Exec[Executor<br/>selected provider]
+    Lead[Okstra lead<br/>host native] --> Exec[Executor<br/>selected provider]
     Lead --> CV[Claude verifier<br/>read-only]
     Lead --> XV[Codex verifier<br/>read-only]
     Lead --> GV{Antigravity in roster?}

package/docs/task-process/release-handoff.md

@@ -16,7 +16,7 @@
 
 `release-handoff` is the terminal phase that pushes an already-committed implementation result with an `accepted` verdict, or hands it off as a PR. whole-task mode packages the verified task branch as-is. stage-group mode can assemble the selected stages into a collector branch and bundle them into a single PR, and the merge commit created here is produced only by `okstra handoff assemble`.
 
-This phase has no worker dispatch. It does not use the `claude`, `codex`, or `report-writer` roster; the Claude lead performs git/gh inspection, user questions, the PR draft, and the final report all inline.
+This phase has no worker dispatch. It does not use a provider or report-writer roster; the host-native Okstra lead performs git/gh inspection, user questions, the PR draft, and the final report inline.
 
 ## 2. okstra-run wizard flow
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "okstra",
-  "version": "0.147.0",
-  "description": "Multi-agent cross-verification orchestrator runtime + Claude Code skills.",
+  "version": "0.148.0",
+  "description": "Host-aware multi-provider cross-verification orchestrator runtime and agent skills.",
   "license": "MIT",
   "author": "devonshin",
   "repository": {

package/runtime/BUILD.json

@@ -1,5 +1,5 @@
 {
-  "package": "0.147.0",
-  "builtAt": "2026-08-03T08:30:05.489Z",
+  "package": "0.148.0",
+  "builtAt": "2026-08-03T19:00:08.212Z",
   "repoRoot": "/home/runner/work/okstra/okstra"
 }

package/runtime/agents/workers/antigravity-worker.md

@@ -39,7 +39,7 @@ The wrapper internally runs:
 agy --print "<prompt>" --model "<model>" --add-dir "<project-root>" [--add-dir "<worktree-path>"] --dangerously-skip-permissions
 ```
 
-The wrapper exists because Claude Code's Bash permission matcher rejects simple-prefix matches when the command contains stdin/stderr redirects. Calling `agy --print ... < <path> 2>/dev/null` directly triggers a permission prompt every dispatch even when `Bash(agy:*)` is allowlisted. The wrapper folds the redirects inside, so the harness sees a single non-redirect command that matches `Bash($HOME/.okstra/bin/okstra-antigravity-exec.sh:*)`.
+The wrapper exists because agent-host Bash permission matchers can reject simple-prefix matches when the command contains stdin/stderr redirects. Calling `agy --print ... < <path> 2>/dev/null` directly may trigger a permission prompt even when `Bash(agy:*)` is allowlisted. The wrapper folds the redirects inside, so the harness sees a single non-redirect command that matches `Bash($HOME/.okstra/bin/okstra-antigravity-exec.sh:*)`.
 
 **Do NOT** invoke `agy --print ... 2>>log > >(tee)` directly — always go through the wrapper. agy has no `--cd` flag, so the wrapper anchors workspace correctness via `--add-dir <project-root>` regardless of inherited cwd.
 
@@ -251,6 +251,6 @@ When this run's `task_type` is `implementation` and you are acting as the **Exec
 }
 ```
 
-Emit this as a fenced ```json``` block in your worker result under the heading `### Stage Carry Evidence`. The lead (`Claude lead`) is responsible for persisting the block as `runs/<impl-task-key>/carry/stage-<N>.json` — you do not write the file yourself.
+Emit this as a fenced ```json``` block in your worker result under the heading `### Stage Carry Evidence`. The host-native Okstra lead is responsible for persisting the block as `runs/<impl-task-key>/carry/stage-<N>.json` — you do not write the file yourself.
 
 This applies only when `task_type` is `implementation`. For other task types, skip this block entirely.

package/runtime/agents/workers/claude-worker.md

@@ -120,6 +120,6 @@ When this run's `task_type` is `implementation` and you are acting as the **Exec
 }
 ```
 
-Emit this as a fenced ```json``` block in your worker result under the heading `### Stage Carry Evidence`. The lead (`Claude lead`) is responsible for persisting the block as `runs/<impl-task-key>/carry/stage-<N>.json` — you do not write the file yourself.
+Emit this as a fenced ```json``` block in your worker result under the heading `### Stage Carry Evidence`. The host-native Okstra lead is responsible for persisting the block as `runs/<impl-task-key>/carry/stage-<N>.json` — you do not write the file yourself.
 
 This applies only when `task_type` is `implementation`. For other task types, skip this block entirely.

package/runtime/agents/workers/codex-worker.md

@@ -39,7 +39,7 @@ The wrapper internally runs:
 codex exec -C "<project-root>" [--add-dir "<worktree-path>"] --model "<model>" --sandbox workspace-write -c approval_policy=never - < "<prompt-path>" 2>/dev/null
 ```
 
-The wrapper exists because Claude Code's Bash permission matcher rejects simple-prefix matches when the command contains stdin/stderr redirects. Calling `codex exec ... < <path> 2>/dev/null` directly triggers a permission prompt every dispatch even when `Bash(codex exec:*)` is allowlisted. The wrapper folds the redirects inside, so the harness sees a single non-redirect command that matches `Bash($HOME/.okstra/bin/okstra-codex-exec.sh:*)`.
+The wrapper exists because agent-host Bash permission matchers can reject simple-prefix matches when the command contains stdin/stderr redirects. Calling `codex exec ... < <path> 2>/dev/null` directly may trigger a permission prompt even when `Bash(codex exec:*)` is allowlisted. The wrapper folds the redirects inside, so the harness sees a single non-redirect command that matches `Bash($HOME/.okstra/bin/okstra-codex-exec.sh:*)`.
 
 **Do NOT use** the non-existent `-q` flag. The approval policy MUST be set with `-c approval_policy=never` (the `-a`/`--ask-for-approval` flag is NOT accepted by `codex exec` — it errors with `unexpected argument '-a'`); without `approval_policy=never` codex runs under the default `on-request` policy and, having no TTY to answer an approval prompt, ends the turn in a few seconds with exit 0 and no result file. **Do NOT** invoke `codex exec ... < ... 2>/dev/null` directly — always go through the wrapper.
 
@@ -251,6 +251,6 @@ When this run's `task_type` is `implementation` and you are acting as the **Exec
 }
 ```
 
-Emit this as a fenced ```json``` block in your worker result under the heading `### Stage Carry Evidence`. The lead (`Claude lead`) is responsible for persisting the block as `runs/<impl-task-key>/carry/stage-<N>.json` — you do not write the file yourself.
+Emit this as a fenced ```json``` block in your worker result under the heading `### Stage Carry Evidence`. The host-native Okstra lead is responsible for persisting the block as `runs/<impl-task-key>/carry/stage-<N>.json` — you do not write the file yourself.
 
 This applies only when `task_type` is `implementation`. For other task types, skip this block entirely.