okstra 0.179.2 → 0.183.2

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

@@ -19,14 +19,14 @@ If the user asks for a recap without naming a task (e.g. "summarize this work"),
 Use the CLI output as the source of truth:
 
 ```bash
-okstra recap assemble <resolved-target> --project-root <projectRoot>
+okstra model-io recap-input --project-root <projectRoot> --task-ref <resolved-target>
 ```
 
-Parse the stdout JSON (`{taskKey, runCount, transitions[], latestPhaseStates}`) and narrate the per-run before/after transitions. For each `transitions[]` entry, show `fromPhase → toPhase` (previous run currentPhase → this run currentPhase), `status`, `lastCompletedPhase`, `nextRecommendedPhase`, and `reportPath` in chronological order. If `runCount == 0`, answer only "This task has no recorded runs." and do not claim to have read any file.
+Read the fixed-text `Run count` and repeated `Transition` blocks. Narrate each block's `From phase → To phase`, `Status`, `Last completed phase`, `Next phase`, and `Report` in the emitted chronological order. If `Run count: 0`, answer only "This task has no recorded runs." and do not claim to have read any file.
 
-`nextRecommendedPhase` in each entry is an **object** `{phase, status, rationale}`, not a phase-name string. Narrate it as `phase` when `phase` is non-empty, and as what `status` says otherwise — `pending` (that run did not settle the route), `blocked` (it stopped on something outside the run), `terminal` (the lifecycle ended there). Printing the object itself puts a raw dict in front of the reader.
+`Next phase` is already a fixed scalar projection. Narrate it when non-empty, and otherwise use `Next phase status`: `pending` means that run did not settle the route, `blocked` means it stopped on something outside the run, and `terminal` means the lifecycle ended there.
 
-For a run that has a `reportPath`, read that report record (`.data.json`) to enrich the summary only when the user wants a deeper one (do not read them all automatically).
+For a transition that has a `Report`, run `okstra render-final-report <Report>` and read the rendered Markdown only when the user wants a deeper summary. Do not open the report data JSON directly and do not render every report automatically.
 
 ### recap.3 — Free-form Q&A loop
 
@@ -90,7 +90,7 @@ Write the body to the scratchpad as markdown first, then pass it with `--body-fi
 
 **self-check rules (there is no validator, so you keep them yourself):**
 
-1. **Do not hand-edit a rendered report** (`*.md` / `*.data.json` / `*.html` under `runs/*/reports/`). Because it is regenerated from `data.json`, an edit is overwritten and diverges from the SSOT. Write findings to `notes/` instead.
+1. **Do not hand-edit a rendered report** (`*.md` / `*.data.json` / `*.html` under `runs/*/reports/`). Report assembly regenerates those artifacts, so write findings to `notes/` instead.
 2. **Do not author a `user-responses/` file or apply `created-by: user`.** That is the user's decision, and writing it for them forges a decision the user never made. If your evidence supports a particular answer, write that in `notes/` and leave the decision to the user. The one exception is the echo-back confirmation flow of the `okstra-user-response` skill — there the user makes the decision in-session and the CLI is merely a transcription channel, so recording a `created-by: user` sidecar with `write` is legitimate. This exception holds only after the user has explicitly confirmed "correct", and only for verbatim input.
 3. **Do not write to okstra-managed directories** (`runs/`, `instruction-set/`, `history/`, `recap/`, `.okstra/decisions/`). `notes/` is the only agent-owned lane. `recap/recap-log.jsonl` is the exception — write it, but not by hand; only via the `okstra recap record` CLI.
 4. **`notes/` is inert to okstra** — no run reads it automatically. After writing, relay the `clarificationResponseArg` the CLI printed (e.g. `--clarification-response <notePath>`) to the user verbatim, telling them it only takes effect when the next run is executed with that argument.

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

@@ -12,21 +12,17 @@ task-key format: `<project-id>:<task-group>:<task-id>`.
 
 **Normalization:** task-key matching is lowercase. Disk segments are slugified (lowercase + non-alphanumeric runs → `-`) per `scripts/okstra_ctl/ids.py:88` (`slugify_task_segment`, the SSOT; `interactive.sh` consumes it via import). Catalog lookup is case-insensitive; file path assembly uses slugified segments.
 
-Lookup methods (in priority order):
-
-A. **`task-catalog.json` (fast):** read `.okstra/discovery/task-catalog.json`, match `taskKey` lowercase. `latestReportRecordPath` is task-type-agnostic "most recent report".
-
-B. **`task-manifest.json` (direct):** if catalog missing, slugify task-group / task-id, read `.okstra/tasks/<group-segment>/<task-id-segment>/task-manifest.json`, use `latestReportRecordPath` (task-type-agnostic).
-
-C. **`timeline.json` (specific run):** for a specific date or run, read `.okstra/tasks/<group-segment>/<id-segment>/history/timeline.json`, filter `runs[]` by `runTimestamp` / `status` / `taskType`, use `runs[].reportPath`.
-
-D. **Specific task-type (fallback):** `latestReportRecordPath` is task-type-agnostic. For a specific task-type's latest report, look under `.okstra/tasks/<group-segment>/<id-segment>/runs/<task-type-segment>/reports/`, filename pattern `final-report-<task-type-segment>-<NNN>.data.json`. Highest seq is latest. Stage-isolated runs (`implementation`, single-stage `final-verification`) keep their reports one level deeper at `runs/<task-type-segment>/stage-<N>/reports/` — scan those subdirectories too; seq is independent per stage. Cross-verify with `timeline.json`'s `runs[].taskType` filter. If the user wants the full reading copy, render it with `okstra render-final-report <that data.json>`.
+Run `okstra model-io report-input --project-root <projectRoot> --task-ref
+<task-key>` and use `Latest report`. For a specific date, run `okstra model-io
+history-input --project-root <projectRoot> --task-ref <task-key>` and select the
+matching numbered run block's `Report` line. If the user wants the full reading copy,
+render the selected record with `okstra render-final-report <report-path>`.
 
 ### report.2 — Confirm existence
 
 1. Verify `latestReportRecordPath` is non-empty AND the file exists on disk. Either signal indicates report presence (tolerant).
 2. If present, display the path and ask the user whether to read it.
-3. If absent, check `task-manifest.json` signals:
+3. If absent, check the `Current status`, `Work status`, and `Next phase status` projection lines:
    - `latestReportRecordPath` empty/missing AND `currentStatus != completed` AND `workStatus != done` AND `workflow.nextRecommendedPhase.status != "terminal"` → `This task is not yet complete (currentStatus: <currentStatus>, workStatus: <workStatus>).`
    - Any signal indicates completion but the file is missing → `Report file does not exist: <path>`
 

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

@@ -8,7 +8,8 @@ Trigger phrases: "okstra status", "task status", "current phase", "next phase",
 
 ### status.1 — Overall project status
 
-Read `.okstra/discovery/task-catalog.json`. The catalog is the authoritative source — every field listed below (including `workStatus`, `workStatusUpdatedAt`, `workStatusNote`) is projected directly from each `task-manifest.json` by `scripts/okstra_ctl/render.py :: render_task_catalog_discovery`. Do NOT re-open individual manifests for the overview.
+Run `okstra model-io status-input --project-root <projectRoot>`. Use the fixed
+text task blocks as the overview source.
 
 | Field | Description |
 |------|------|
@@ -47,13 +48,13 @@ The `Next` cell is `nextRecommendedPhase.phase`, or `--` when that string is emp
 
 Given a specific `task-key` or `task-group + task-id`:
 
-1. If possible, quickly look it up in `task-catalog.json`.
-2. If necessary, read `.okstra/tasks/<task-group>/<task-id>/task-manifest.json` directly.
-3. If you need the latest run information, read `history/timeline.json` along with the latest run manifest.
+1. Run `okstra model-io status-input --project-root <projectRoot> --task-ref <task-key>`.
+2. Use only the named lines in that fixed text projection.
 
 Required fields: `taskKey`, `taskType`, `workCategory`, `currentStatus`, `latestRunStatus`, `workflow.{currentPhase, currentPhaseState, phaseStates, lastCompletedPhase, nextRecommendedPhase, awaitingApproval, lastSafeCheckpoint}`, `workStatus`, `workStatusUpdatedAt`, `workStatusNote`, `latestReportRecordPath`, `latestResumeCommandPath`, `historyTimelinePath`.
 
-`workflow.nextRecommendedPhase` is the `{phase, status, rationale}` object described in `status.1` — read its three fields, do not print it whole. A `task-manifest.json` written before the object existed still holds a bare string there; `scripts/okstra_ctl/next_phase.py::promote` is what turns that string into the object, and every CLI-projected surface you can read instead (`task-catalog.json`, `okstra rollup`, `okstra recap`) has already applied it. Prefer those over a raw manifest rather than promoting a legacy string yourself.
+The projection renders next phase, status, and rationale as separate lines.
+It has already promoted legacy values.
 
 ```markdown
 ## okstra Task Status — <task-key>
@@ -120,11 +121,11 @@ Accepted `<status>` values: `todo`, `in-progress`, `blocked`, `done`.
 **Procedure:** run the update through the CLI (one Bash call, literal `okstra` token) — never edit `task-manifest.json` by hand:
 
 ```bash
-okstra set-work-status <token> <status> --project-root <projectRoot> --json
+okstra set-work-status <token> <status> --project-root <projectRoot> --text
 ```
 
 - `<token>` is a full task-key or a bare task-id. Add `--task-group <group>` to scope a duplicated id, `--note "<note>"` to set `workStatusNote` (flag omitted → any existing note is left untouched).
-- Branch on the stdout JSON: `ok: true` → confirm below. `stage: "ambiguous"` → list `matches[]` (with `_matchedVia`) via a 3-option picker and retry with the chosen full task-key. `stage: "not-found"` → `<TASK-ID> cannot be found.` An invalid `<status>` makes the CLI exit 2 with the allowed-values list — surface it verbatim; nothing was modified.
+- Branch on the fixed text labels: `OK: True` → confirm below. `Stage: ambiguous` → list each `Match` via a 3-option picker and retry with the chosen full task-key. `Stage: not-found` → `<TASK-ID> cannot be found.` An invalid `<status>` makes the CLI exit 2 with the allowed-values list — surface it verbatim; nothing was modified.
 
 Confirm in Korean (the block below shows the message shape only — render the actual confirmation text in Korean):
 ```
@@ -144,4 +145,4 @@ Confirm in Korean (the block below shows the message shape only — render the a
 
 Annotate inferred values with `(inferred)` or `(default)`. Do not back-fill on read; only write when the user explicitly issues an update.
 
-**Catalog sync note:** the CLI updates `task-manifest.json` only. `discovery/task-catalog.json` may be stale until the next run regenerates it; downstream consumers (e.g. `okstra-schedule-gen`) re-read each manifest directly.
+The projection commands own catalog/manifest reconciliation; do not repair their storage while inspecting status.

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

@@ -15,11 +15,11 @@ Apply the standard task-key resolution rule from `SKILL.md` (core): full task-ke
 ### time.2 — Fetch aggregated data
 
 ```bash
-okstra time-report <task-key> --project-root <projectRoot> --json
+okstra time-report <task-key> --project-root <projectRoot> --text
 ```
 
-Returns (all durations are **raw milliseconds**):
-- `byTaskType[]` — `{taskType, runs, leadMs, workersMs, cpuSumMs}`, plus `grandTotal`
+Returns fixed labeled text (all durations are **raw milliseconds**):
+- Repeated `Task type` blocks — task type, runs, lead ms, workers ms, and CPU sum ms, plus total labels
 - `perWorker` — `{<taskType>: [{workerId, agents[], runs, totalMs, avgMs}]}`; only workers with a nonzero run appear, and `agents[]` lists agent labels that differ from `workerId`
 - `perRunWallClock[]` — `{runTimestamp, taskType, wallClockMs}` (max `endedAt` − min `startedAt` per run)
 - `phaseTimelines[]` — `{runTimestamp, taskType, phases:[{phase, firstAt, wallMsToNext}]}`

package/runtime/skills/okstra-manager/SKILL.md

@@ -5,7 +5,7 @@ description: Use when the user wants to manage okstra work across multiple proje
 
 # OKSTRA Manager
 
-Thin conversational wrapper over `okstra manager`. Manager state and child launch decisions belong to the CLI JSON/output, not to this skill.
+Thin conversational wrapper over `okstra manager`. Manager state and child launch decisions belong to the CLI fixed output, not to this skill.
 
 ## Bash Invocation Rule
 
@@ -14,18 +14,20 @@ Every command in this skill must begin with the literal token `okstra`. Do not i
 ## Command Surface
 
 Use the CLI output as the source of truth.
+Nested project, manifest, child, snapshot, and directive values are carried by
+the CLI's numbered count/name/value rows; do not omit or reconstruct them.
 
 ```bash
-okstra manager init --manager-id <manager-id> --json
-okstra manager discover-projects --json
-okstra manager new project --manager-id <manager-id> --project-id <project-id> --project-root <abs-path> [--role <role>] [--tag <tag>] --json
-okstra manager new task-group --manager-id <manager-id> --task-group <task-group> --json
-okstra manager new task --manager-id <manager-id> --task-group <task-group> --task-id <task-id> --task <project-id:task-group:task-id> --json
-okstra manager task status --manager-id <manager-id> --task-group <task-group> --task-id <task-id> --json
-okstra manager task sync --manager-id <manager-id> --task-group <task-group> --task-id <task-id> --json
-okstra manager task assign --manager-id <manager-id> --task-group <task-group> --task-id <task-id> --project-id <project-id> [--child-task-id <child-task-id>] [--role <role>] [--tag <tag>] [--assignment <text>] --json
-okstra manager task note --manager-id <manager-id> --task-group <task-group> --task-id <task-id> --scope <shared|project> [--project-id <project-id>] --body <text> --json
-okstra manager task run --manager-id <manager-id> --project-id <project-id> --task-group <task-group> --task-id <task-id> [--child-task-id <child-task-id>] --json
+okstra manager init --manager-id <manager-id>
+okstra manager discover-projects
+okstra manager new project --manager-id <manager-id> --project-id <project-id> --project-root <abs-path> [--role <role>] [--tag <tag>]
+okstra manager new task-group --manager-id <manager-id> --task-group <task-group>
+okstra manager new task --manager-id <manager-id> --task-group <task-group> --task-id <task-id> --task <project-id:task-group:task-id>
+okstra manager task status --manager-id <manager-id> --task-group <task-group> --task-id <task-id>
+okstra manager task sync --manager-id <manager-id> --task-group <task-group> --task-id <task-id>
+okstra manager task assign --manager-id <manager-id> --task-group <task-group> --task-id <task-id> --project-id <project-id> [--child-task-id <child-task-id>] [--role <role>] [--tag <tag>] [--assignment <text>]
+okstra manager task note --manager-id <manager-id> --task-group <task-group> --task-id <task-id> --scope <shared|project> [--project-id <project-id>] --body <text>
+okstra manager task run --manager-id <manager-id> --project-id <project-id> --task-group <task-group> --task-id <task-id> [--child-task-id <child-task-id>]
 ```
 
 - Public child task identity is `project-id:task-group:task-id`.
@@ -36,9 +38,9 @@ okstra manager task run --manager-id <manager-id> --project-id <project-id> --ta
 
 For launching child work:
 
-1. Run `okstra manager task sync ... --json` if the manager snapshot must be refreshed first.
-2. Run `okstra manager task run ... --json`.
-3. Read the returned launch packet fields such as `backend`, `projectRoot`, `contextPath`, and `runArgs`.
+1. Run `okstra manager task sync ...` if the manager snapshot must be refreshed first.
+2. Run `okstra manager task run ...`.
+3. Read the returned fixed fields `Backend`, `Worker dispatch backend`, `Project root`, `Context path`, and every numbered `Run arg N`.
 4. Use that launch packet for the host-native child lead handoff.
 
 The launch packet remains the source of truth. Do not rebuild child args by hand.

package/runtime/skills/okstra-memory/SKILL.md

@@ -54,7 +54,7 @@ searching so the rest of the skill can scope to it.
 1. Enumerate existing groups to build recommendations:
 
    ```bash
-   okstra memory groups --json
+   okstra memory groups
    ```
 
 2. Present a 3-option picker (most-used existing group, next existing group,
@@ -107,5 +107,5 @@ okstra memory show "<memory-id>"
 okstra memory archive "<memory-id>"
 ```
 
-Prefer `--json` when you need to parse IDs, then present a short human summary
-to the user.
+Use the fixed text rows emitted by these commands, then present a short human
+summary to the user.

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

@@ -58,7 +58,7 @@ the user states explicitly wins verbatim; never rewrite it.
 ### A1. Pick a template
 
 ```bash
-okstra pr template list --json
+okstra pr template list
 ```
 
 - If `templates` is non-empty, present a picker: 1–2 recommended templates from
@@ -71,7 +71,7 @@ Carry the chosen template name as `<template>` (`default` for the bundled one).
 ### A2. Pick the base branch
 
 ```bash
-okstra pr branches --json
+okstra pr branches
 ```
 
 Present a 3-option base picker from `recommended` (top entries) plus `Enter directly`
@@ -80,10 +80,11 @@ last. Carry the choice as `<base>`.
 ### A3. Build the generation bundle and fill the template
 
 ```bash
-okstra pr gen --base <base> --template <template> --json
+okstra pr gen --base <base> --template <template>
 ```
 
-Parse `{base, currentBranch, templateName, template, commits, diffStat}`. Then
+Read the fixed `Base`, `Current branch`, `Template name`, `Commits`, `Diff stat`,
+and `Template` sections. Then
 read the full diff honestly — it is the source of truth:
 
 ```bash

package/runtime/skills/okstra-rollup/SKILL.md

@@ -17,10 +17,10 @@ Run one Bash tool call, starting with the literal token `okstra` (never wrapped
 <!-- END FRAGMENT: bash-invocation-rule -->
 
 ```bash
-okstra preflight --runtime claude-code --json
+okstra preflight --runtime claude-code
 ```
 
-Parse the stdout JSON. `ok: true` → carry `projectRoot` as a literal string. `ok: false` → tell the user to run `/okstra-setup` first, then stop.
+On `Okstra preflight: ready`, carry the fixed `Project root` line. On `Okstra preflight: failed`, show `Reason` and `Recovery`, then stop.
 
 <!-- BEGIN FRAGMENT: preflight-outdated-cli -->
 If the call fails with `unknown command: preflight`, the `okstra` binary on PATH predates this skill — tell the user to update it (`npm i -g okstra@latest`), then stop (`/okstra-setup` does not update the binary).
@@ -35,24 +35,14 @@ If the call fails with `unknown command: preflight`, the `okstra` binary on PATH
 ## Step 2: Fetch the roll-up
 
 ```bash
-okstra rollup --task-group <group> --project-root <projectRoot> --json
+okstra rollup --task-group <group> --project-root <projectRoot> --text
 ```
 
-Omit `--task-group` for the whole project. The JSON shape (all durations are **raw milliseconds**):
-
-- `taskGroup` — the scope (`null` = whole project), `taskCount` — number of tasks.
-- `tasks[]` — per task: `taskKey, taskGroup, taskId, taskType, workCategory, workStatus, currentPhase, currentPhaseState, nextRecommendedPhase, latestRunStatus, updatedAt, reportPath, runCount, cpuSumMs, wallClockMs, errorCount`, plus `criticRuns, criticGapsProposed, criticGapsMerged, criticGapsRejected, criticGapsUnverified`.
-  - `nextRecommendedPhase` is an **object** `{phase, status, rationale}`, not a phase-name string. Anywhere you surface it, print `nextRecommendedPhase.phase` — or `--` when that string is empty, which is what `status` `pending` / `blocked` / `terminal` all produce. Never interpolate the object into a table cell or a sentence: it renders as a raw dict.
-- `totals` — `runs, cpuSumMs, wallClockMs, errors`, plus `byWorkStatus`, `byWorkCategory`, `byCurrentPhase`, `byTaskType` (each a `{value: count}` map), plus `critic` (`runsWithCritic, gapsProposed, gapsMerged, gapsRejected, gapsUnverified`).
-- The coverage critic is opt-in, so `totals.critic.runsWithCritic == 0` means it was never used — report that as "not used", never as a zero-yield result. When it IS non-zero, the merge rate (`gapsMerged / gapsProposed`) is what tells the user whether the pass earns its tokens; state it only when at least one run used it.
-
-`runCount` counts every timeline run; `cpuSumMs`/`wallClockMs` only reflect runs that reached Phase 7 usage, so they can be `0` while `runCount > 0`. `reportPath` is project-relative and may be empty (task not yet reported).
-
-If `taskCount` is `0`, tell the user there are no okstra tasks in that scope and stop.
+Omit `--task-group` for the whole project. The command returns fixed, ordered label/value lines. Read only those labels; do not request machine output or open an artifact to recover omitted fields. Durations are raw milliseconds. If `Task count` is `0`, tell the user there are no okstra tasks in that scope and stop.
 
 ## Step 3: Render the roll-up table
 
-Convert every `*Ms` to `HH:MM:SS` (zero-pad; never show raw ms). `cpuSumMs` is CPU-sum (lead + workers overlap), not wall-clock — label it "CPU"; only surface `wallClockMs` when the user asks. Sort tasks by `updatedAt` desc.
+Convert each returned `ms` label to `HH:MM:SS` (zero-pad; never show raw ms). CPU sum includes overlapping lead and worker time. Use the returned task order.
 
 ```markdown
 ## okstra Rollup — <task-group or "whole project"> (<taskCount> tasks)
@@ -66,7 +56,7 @@ Convert every `*Ms` to `HH:MM:SS` (zero-pad; never show raw ms). `cpuSumMs` is C
 **workStatus:** done 1 · in-progress 1   **category:** bugfix 1 · feature 1
 ```
 
-Render `Report` as `✓` when `reportPath` is non-empty, else `—`. Build the status/category lines from the `totals` tally maps verbatim — do not count the `tasks[]` array yourself.
+Render `Report` as `✓` when the corresponding `Task N report path` is non-empty, else `—`. Use the numbered fixed labels and total labels verbatim; do not re-count tasks.
 
 ## Step 4: Synthesize the digest (the summary)
 

package/runtime/skills/okstra-run/SKILL.md

@@ -70,16 +70,16 @@ The host-native provider runs as the current lead session when its role is suppo
 Run one Bash tool call (Bash invocation rule from the top of this file applies):
 
 ```bash
-okstra preflight --runtime <host-runtime> --json
+okstra preflight --runtime <host-runtime>
 ```
 
-Parse the stdout JSON. If `ok: false` with `stage: runtime_readiness`, show `runtimeReadiness.status` and every readiness check, including each adapter-provided `action`, then stop before Step 2. Do not relabel a host login, license, daemon, trust, or other readiness failure as missing Okstra setup. Any other `ok: false` response (or `okstra` not on `PATH` at all) → tell the user: "okstra not set up — run `/okstra-setup` first." Then stop. If the call fails with `unknown command: preflight`, the `okstra` binary on PATH predates this skill — tell the user to update it (`npm i -g okstra@latest`), then stop (`/okstra-setup` does not update the binary). Do **not** try to invoke `npx -y okstra@latest ...` as a fallback — `npx` is not on the literal-token allow-list and will force a confirmation prompt on every wizard call afterward. Every subsequent `okstra <subcmd>` call self-bootstraps its Python path, so never `export PYTHONPATH=...`.
+Read the fixed text lines. If the first line is `Okstra preflight: failed`, show `Runtime readiness` and every repeated `Readiness check`, `Readiness check status`, and `Readiness check action`, then stop before Step 2. Show `Reason` and `Recovery` for every failure. Do not relabel a host login, license, daemon, trust, or other readiness failure as missing Okstra setup. If the call fails with `unknown command: preflight`, the `okstra` binary on PATH predates this skill — tell the user to update it (`npm i -g okstra@latest`), then stop (`/okstra-setup` does not update the binary). Do **not** try to invoke `npx -y okstra@latest ...` as a fallback — `npx` is not on the literal-token allow-list and will force a confirmation prompt on every wizard call afterward. Every subsequent `okstra <subcmd>` call self-bootstraps its Python path, so never `export PYTHONPATH=...`.
 
-When `runtimeReadiness` is present on an `ok: true` response, require `runtimeReadiness.status: ready` before Step 2. These checks come from the selected host adapter and are independent of worker-provider choices. A `blocked` or `unknown` status is a host readiness failure regardless of check IDs: show the status and checks, then stop before Step 2. Any other readiness status is unrecognized runtime output: show it and stop before Step 2 instead of guessing that the host is ready.
+On `Okstra preflight: ready`, require `Runtime readiness: ready` before Step 2. These checks come from the selected host adapter and are independent of worker-provider choices. Any other readiness value is unrecognized runtime output: show it and stop before Step 2 instead of guessing that the host is ready.
 
-For a ready response, read the absolute file path in `runtimeReadiness.relayContract` with the current host's file-read primitive. Do not derive the path from the host ID or search `PATH`. In that file, find the `Wizard interaction relay` JSON block, require `schemaVersion: 1` and `runtime` equal to `runtimeReadiness.runtime`, then take its `semanticFunctions` allowlist and intersect it with the functions the live harness exposes. Pass only that intersection to Step 2; `plain_text_input` must be present. Keep the parsed `interactions` object for Step 3's function/input/response conversion. An unreadable file, malformed block, runtime mismatch, absent `plain_text_input`, or later interaction kind missing from the object is a host relay contract failure: show the problem and stop rather than guessing.
+For a ready response, read the absolute path in the fixed `Relay contract` line with the current host's file-read primitive. Do not derive the path from the host ID or search `PATH`. In that file, find the `Wizard interaction relay` JSON block, require `schemaVersion: 1` and `runtime` equal to the fixed `Runtime` line, then take its `semanticFunctions` allowlist and intersect it with the functions the live harness exposes. The live harness does not expose tools named `native_single_select`. Map each allowlist token to the matching `interactions` kind (`native_single_select` → `native-single`, `native_multi_select` → `native-multi`, `native_question_group` → `native-group`). Include the token in the intersection only when this session can call the string in that kind's `function` field. If the kind is absent from `interactions`, omit the token. Pass only that intersection to Step 2; `plain_text_input` must be present. Keep the parsed `interactions` object for Step 3's function/input/response conversion. An unreadable file, malformed block, runtime mismatch, absent `plain_text_input`, or later interaction kind missing from the object is a host relay contract failure: show the problem and stop rather than guessing.
 
-If `runtimeReadiness` is absent, preserve compatibility with an older preflight response: carry `projectRoot` and `projectId` into Step 2 and treat it as a response with no `relayContract`. If readiness exists but `relayContract` is absent, also enter the compatibility branch below. In that branch only, declare `plain_text_input` and keep its built-in `interactions` mapping for Step 3; do not assume a native tool from the host ID. The existing `unknown command: preflight` branch remains the authoritative stale-CLI failure.
+If the successful fixed projection has `Relay contract: -`, enter the compatibility branch below. In that branch only, declare `plain_text_input` and keep its built-in `interactions` mapping for Step 3; do not assume a native tool from the host ID. The existing `unknown command: preflight` branch remains the authoritative stale-CLI failure.
 
 ### Legacy text relay compatibility
 
@@ -158,7 +158,7 @@ Output: the same `{ok, next}` JSON described above. The first `next` is always `
 
 Repeat until `next.kind == "done"` (or `"aborted"` — terminal cancel, see "How the wizard talks to you"):
 
-1. **Render** the prompt according to `next.interaction.kind` using the relay rules above. **Always append the progress marker to the rendered question label**: suffix it with ` (<next.progress.label>)` — render `progress.label` exactly as the wizard sent it, never recompute it. Example: label `Step 8/11 · 3 steps remaining` → `Select a model (Step 8/11 · 3 steps remaining)`. Re-prompts after `ok: false` reuse `current.progress.label` the same way. The progress marker is presentation-only — never send it back to the wizard as part of an answer.
+1. **Render** the prompt according to `next.interaction.kind` using the relay rules above. For a native kind, invoke the `function` string from that same `interactions` entry — the Claude Code picker, the Grok picker, and the Codex picker are different names, and substituting one for another is a relay-contract failure. **Always append the progress marker to the rendered question label**: suffix it with ` (<next.progress.label>)` — render `progress.label` exactly as the wizard sent it, never recompute it. Example: label `Step 8/11 · 3 steps remaining` → `Select a model (Step 8/11 · 3 steps remaining)`. Re-prompts after `ok: false` reuse `current.progress.label` the same way. The progress marker is presentation-only — never send it back to the wizard as part of an answer.
 2. **Submit** the answer — call `okstra wizard step` with the literal state-file path from Step 2 and the literal user answer (no shell variables, no `$(...)`):
    ```bash
    okstra wizard step --state-file /var/folders/.../okstra-wizard.AbCd.json --answer preprod
@@ -323,7 +323,7 @@ If `render-bundle` stdout carries an `okstra concurrent-run stages: <stages>` la
 
 If `render-bundle` fails with a `PrepareError` containing `Recorded stage SHAs no longer match the git history`, the git history changed outside okstra (rebase / squash / review-feedback amend / branch deletion). Never fix the registry/consumers by hand; recover in this order:
 
-1. Run the `okstra git-reconcile … --check --json` command printed in the error message verbatim to get the stale report. (Items whose content-identity is proven by patch-id were already auto-reconciled by prepare, so only confirm items remain here.)
+1. Run the `okstra git-reconcile … --check --text` command printed in the error message verbatim to get the stale report. (Items whose content-identity is proven by patch-id were already auto-reconciled by prepare, so only confirm items remain here.)
 2. For each confirm item, present a 3-option picker to the user:
    - **Re-record to the `stage-<N>` branch's current tip (recommended)** — when an intended change such as review feedback lives on that branch.
    - **Enter a different ref directly** — the user names a commit/branch/tag.

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

@@ -24,10 +24,10 @@ Run one Bash tool call, starting with the literal token `okstra` (never wrapped
 <!-- END FRAGMENT: bash-invocation-rule -->
 
 ```bash
-okstra preflight --runtime claude-code --json
+okstra preflight --runtime claude-code
 ```
 
-Parse the stdout JSON. `ok: true` → carry `projectRoot` as a literal string and use it to locate `.okstra/discovery/task-catalog.json` and the task-group directory. `ok: false` → tell the user to run `/okstra-setup` first, then stop.
+On `Okstra preflight: ready`, carry the fixed `Project root` line for the later `model-io` calls. On `Okstra preflight: failed`, show `Reason` and `Recovery`, then stop.
 
 <!-- BEGIN FRAGMENT: preflight-outdated-cli -->
 If the call fails with `unknown command: preflight`, the `okstra` binary on PATH predates this skill — tell the user to update it (`npm i -g okstra@latest`), then stop (`/okstra-setup` does not update the binary).
@@ -78,15 +78,19 @@ One computation rule the template scaffold cannot carry inline:
 
 ### Step 1: Resolve task-group and collect tasks
 
-1. Read `.okstra/discovery/task-catalog.json`.
-2. **Resolve which task-group to schedule — never silently guess.**
-   - The user **explicitly named a task-group** (as the `/okstra-schedule-gen [task-group]` argument or unambiguously in the request) → use that token; skip the picker and go to sub-step 3.
-   - The user **named no task-group, or the named token matches 0 or ≥2 groups** → present a 3-option picker via `AskUserQuestion` and do NOT proceed until the user chooses. Build the options from the catalog: walk `tasks[]` in catalog order (already `updatedAt` desc — see `scripts/okstra_ctl/render.py:654`), collect distinct `taskGroupPathSegment` values that have ≥1 entry whose resolved `workStatus` is **non-done** (defer to Step 2's inference table), and offer the newest **1–2** such groups as recommendations. The **last option is always `Enter directly`** (free-text group token, fed into sub-step 3). Label each recommendation with its non-done task count (e.g. `uploadFont (non-done 3)`).
-   - If **zero groups have a non-done task** (or the catalog is empty), do NOT open a picker — emit `All tasks in this task-group are done. There is no schedule to generate.` (or `That task-group could not be found.` when the catalog has no tasks at all) and stop **without creating a file**.
-3. **Normalise the resolved `<task-group>`:** lowercase it, then strip every character that is not `[a-z0-9]`. Apply the same transform to each entry's `taskGroupPathSegment`. Match on equality — this is the single comparison rule; do NOT also fall back to the raw `taskGroup` field.
-4. If no tasks found, output `That task-group could not be found.` and stop.
-5. For each matched task, read `.okstra/tasks/<task-group-segment>/<task-id-segment>/task-manifest.json` directly. Catalog data may be stale; the manifest is authoritative.
-6. **Derive `<project-id>`** for the header: prefer `task-catalog.json`'s top-level `projectId`, otherwise the first matched manifest's `projectId`. Do not invent a value.
+1. **Resolve which task-group to schedule — never silently guess.** The user may name it in the `/okstra-schedule-gen [task-group]` argument. If the user did not name one, ask one free-text question for its task-group token before continuing.
+2. Render the group's authoritative task metadata with the fixed view:
+
+   ```bash
+   okstra model-io schedule-input --project-root <projectRoot> --task-group <task-group>
+   ```
+
+   The `## Tasks` section is authoritative for each task's key, status,
+   category, type, and current phase. If it is `- None`, output `That
+   task-group could not be found.` and stop without creating a file. Do not
+   read task catalogs or task manifests directly.
+3. **Derive `<project-id>`** for the header from the fixed view's `Project ID`.
+   Do not invent a value.
 
 ### Step 2: Filter by workStatus
 
@@ -99,18 +103,18 @@ If 0 tasks remain, output `All tasks in this task-group are done. There is no sc
 For each in-scope task, the **authoritative source is its `implementation-planning` Stage Map resolved by the CLI**. Do not hand-parse it or use `latestReportRecordPath` to choose its source. Call:
 
 ```bash
-okstra stage-map <task-key> --json
+okstra stage-map <task-key> --text
 ```
 
-The response is source-aware: `{ok, taskKey, taskRoot, state, sourcePlanPath, stages:[…], doneStages:[int], planning:{…}}`. Each stage row carries `stage_number`, `title`, `depends_on`, `step_count`, `exit_contract_summary` and — from a schema-v2 report — that stage's `stepwiseExecution` (the numbered steps, each with `action`, `files`, `command`, `expected`), `sliceValue`, `acceptance` and `exitContract`. `planning` carries the report's task-level rows: `rollbackStrategy`, `validationChecklist`, `crossProjectDependencies`, `dependencyMigrationRisk`, `recommendedOption`. Branch on it explicitly:
+The fixed response is source-aware. It carries `Status`, `Task key`, `Task root`, `State`, `Source plan path`, plus lossless numbered `Stages`, `Done stages`, and `Planning` count/name/value rows. Stage fields include `stage_number`, `title`, `depends_on`, `step_count`, `exit_contract_summary` and — from a schema-v2 report — that stage's `stepwiseExecution` (`action`, `files`, `command`, `expected`), `sliceValue`, `acceptance` and `exitContract`. Planning fields include `rollbackStrategy`, `validationChecklist`, `crossProjectDependencies`, `dependencyMigrationRisk`, and `recommendedOption`. Branch on those fixed fields explicitly:
 
 The resolved source, when ready, is a report under `runs/implementation-planning`; the CLI owns choosing exactly one report from that domain.
 
-- `ok: true, state: "ready"` — preserve `sourcePlanPath`, stage rows, and `doneStages`. Compute unfinished stages as `stages − doneStages`. Only unfinished stages can be selected. Every selected stage's transitive prerequisites must be either selected or present in `doneStages`; the completed prerequisite closure is retained as evidence, never rendered as forward work.
-- `ok: true, state: "missing"` — record an empty source and empty stage sets. Tag the task `[NEEDS-PLANNING]`, skip the stage picker, and render task-level metadata only, with no forward Work Breakdown row, Gantt row, or day total.
-- `ok: false` or any state other than `ready` and `missing` — this is a structured Stage Map error, such as a corrupt or conflicting plan source. Stop before drafting, preserve the CLI `stage` and `reason` in the user-facing error, and do not guess from another report.
+- `Status: ready`, `State: ready` — preserve `Source plan path`, stage rows, and done stages. Compute unfinished stages as stages minus done stages. Only unfinished stages can be selected. Every selected stage's transitive prerequisites must be either selected or done; the completed prerequisite closure is retained as evidence, never rendered as forward work.
+- `Status: ready`, `State: missing` — record an empty source and empty stage sets. Tag the task `[NEEDS-PLANNING]`, skip the stage picker, and render task-level metadata only, with no forward Work Breakdown row, Gantt row, or day total.
+- `Status: error` or any state other than `ready` and `missing` — stop before drafting, preserve `Failure stage` and `Failure reason` in the user-facing error, and do not guess from another report.
 
-For `ready`, the CLI response is the source for everything the schedule renders — stage rows and `planning` together. Read `sourcePlanPath` only for the task-level Priority / Risk / Scope / Repos that the payload does not carry, and read no further into it: transcribing the payload is the whole point of Step 4. Read header metadata from `task-manifest.json`: `taskId`, `taskGroup`, `taskKey`, `workCategory`, `workStatus`, `taskType`, and `workflow.currentPhase`. Blocking and approval items are not extracted (see Audience & authority).
+For `ready`, the CLI response is the source for everything the schedule renders — stage rows and `planning` together. Read `sourcePlanPath` only for the task-level Priority / Risk / Scope / Repos that the payload does not carry, and read no further into it: transcribing the payload is the whole point of Step 4. Take task key, category, status, type, and current phase from the fixed `model-io schedule-input` view. Blocking and approval items are not extracted (see Audience & authority).
 
 If unfinished stages are empty while `workStatus` is not `done`, render `_Complete — no remaining stage_` under the task's phase section and contribute no forward day total.
 

package/runtime/skills/okstra-setup/SKILL.md

@@ -58,29 +58,37 @@ running the legacy `okstra-install.sh` — that path is dev-only.
 ## Step 2: Resolve PROJECT_ROOT
 
 ```bash
-okstra check-project --json
+okstra preflight
 ```
 
-Parse the JSON from stdout. The shape is `{ok, projectRoot, projectJsonPath, projectId, stage?}`.
+Read the fixed `Okstra preflight`, `Project root`, `Project JSON`, `Project ID`,
+`Reason`, and `Recovery` lines.
 
-- `ok: true` → carry `projectRoot` as a literal absolute string and paste it into every subsequent command in this skill.
-- `ok: false`, `stage: "resolve"` → ask the user (`AskUserQuestion`, free text) for an absolute project root and rerun as a separate Bash tool call with the literal absolute path:
+- `Ok: true` → carry `Project root` as a literal absolute string and paste it into every subsequent command in this skill.
+- `Ok: false`, `Stage: resolve` → ask the user (`AskUserQuestion`, free text) for an absolute project root and rerun as a separate Bash tool call with the literal absolute path:
 
   ```bash
-  okstra check-project --cwd /abs/path/from/user --json
+  okstra preflight --cwd /abs/path/from/user
   ```
 
-- `ok: false`, `stage: "project_json_missing"` → proceed to Step 3 (this is the normal create path).
-- `ok: false`, any other `stage` (`python`, `parse`, `project_json_invalid`) → show the JSON `reason` field to the user verbatim and follow the recovery it names (typically `okstra doctor` to diagnose, then `okstra ensure-installed` or re-running the Step 1 install). `reason` is the SSOT — do not hand-enumerate stage causes.
+- `Ok: false`, `Stage: project_json_missing` → proceed to Step 3 (this is the normal create path).
+- `Ok: false`, any other `Stage` (`python`, `parse`, `project_json_invalid`) → show the fixed `Reason` line to the user verbatim and follow the `Recovery` line (typically `okstra doctor` to diagnose, then `okstra ensure-installed` or re-running the Step 1 install). `Reason` is the SSOT — do not hand-enumerate stage causes.
 
-## Step 3: Inspect or create `project.json`
+## Step 3: Project metadata setup
 
-Use the `Read` tool on the literal absolute path `<projectRoot>/.okstra/project.json` (substitute the literal `projectRoot` value parsed in Step 2). If `Read` errors with "file does not exist", treat that as the "create" branch below; otherwise the file exists and you can inspect its contents inline.
+Render the existing project metadata with the purpose-specific view. Paste the
+literal `projectRoot` value parsed in Step 2:
 
-If the file exists, surface its `projectId`/`projectRoot` and ask whether to
-keep or overwrite. Default is to keep — okstra refuses to change `projectId`
-on an existing project (see `okstra_project.resolver.upsert_project_json`),
-so overwriting requires manually deleting the file first.
+```bash
+okstra model-io project-context --project-root /abs/path/to/projectRoot
+```
+
+If the command reports that project metadata is missing, treat that as the
+"create" branch below. Otherwise, surface the rendered `Project ID` and
+`Project root`, then ask whether to keep or overwrite. Default is to keep —
+okstra refuses to change `projectId` on an existing project (see
+`okstra_project.resolver.upsert_project_json`), so overwriting requires
+manually deleting the file first.
 
 If the file does NOT exist, ask via `AskUserQuestion`:
 

package/runtime/skills/okstra-setup/references/project-config.md

@@ -1,6 +1,6 @@
 # Optional project configuration (okstra-setup)
 
-Read this only when the user asks to customise one of the areas below after
+Use this reference only when the user asks to customise one of the areas below after
 `project.json` exists. The built-in defaults work for most projects — none of
 these sections is required for a working setup.
 
@@ -189,7 +189,7 @@ okstra config set pr-template-path "<typed-path>" --scope <project|global>
 ```
 
 The command validates the value (global rejects relative paths) and writes
-atomically. Surface its stdout JSON. If the user chose `Later`, tell them
+atomically. Surface its fixed text result. If the user chose `Later`, tell them
 they can register later via the same `okstra config set` command or the
 per-run override prompt during the next release-handoff run.
 

package/runtime/skills/okstra-usage/SKILL.md

@@ -17,11 +17,11 @@ Read-only project usage snapshot. The CLI owns every sum; never re-add rows.
 Run one literal Bash call:
 
 ```bash
-okstra preflight --runtime claude-code --json
+okstra preflight --runtime claude-code
 ```
 
-On `ok:true`, carry `projectRoot`. On `ok:false`, tell the user to run `/okstra-setup` first
-and stop.
+On `Okstra preflight: ready`, carry the fixed `Project root` line. On
+`Okstra preflight: failed`, show `Reason` and `Recovery`, then stop.
 
 <!-- BEGIN FRAGMENT: preflight-outdated-cli -->
 If the call fails with `unknown command: preflight`, the `okstra` binary on PATH predates this skill — tell the user to update it (`npm i -g okstra@latest`), then stop (`/okstra-setup` does not update the binary).
@@ -37,7 +37,7 @@ If the call fails with `unknown command: preflight`, the `okstra` binary on PATH
 ## Step 2: Fetch once
 
 ```bash
-okstra usage-report --days 30 --project-root <projectRoot> --json
+okstra usage-report --days 30 --project-root <projectRoot> --text
 ```
 
 Replace `30` only with the resolved positive integer. Do not wrap the command in
@@ -45,23 +45,23 @@ Replace `30` only with the resolved positive integer. Do not wrap the command in
 
 ## Step 3: Render
 
-If `ok:false`, report `stage` and `reason`, then stop. If `runs.total == 0`, say
+If `Status` is `error`, report `Failure stage` and `Failure reason`, then stop. If `Runs total` is `0`, say
 `No okstra usage found in the last N days.`, omit the table, and continue to Step 4.
 
-Otherwise, render `byTaskType` in returned order:
+Otherwise, render the numbered `Task type N ...` fixed fields in returned order:
 
 | Task type | Runs | Coverage | Raw tokens | Billable | Cost | CPU | Wall |
 |---|---:|---:|---:|---:|---:|---:|---:|
 
-- `Coverage` = returned `collectedRuns/runs`; never calculate a new aggregate.
+- `Coverage` = returned `Task type N collection rate`; never divide or calculate a new aggregate.
 - Format tokens with K/M suffixes, milliseconds as zero-padded `HH:MM:SS`, and
   USD to two decimals. For tokens, use one decimal at `>= 1,000` (`K`) and
   `>= 1,000,000` (`M`), trimming a trailing `.0`; below 1,000 render the integer.
-- Render the `totals` object as the final bold row.
+- Render the fixed total labels as the final bold row.
 - Never treat unavailable usage as collected zero usage.
 
 ## Step 4: Diagnostics
 
-- Render non-zero `unavailable` and `warnings` counts after the Step 3 output.
-- If `unmatchedModels` is non-empty, mark Cost with `*` when the table exists and
+- Render non-zero numbered `Unavailable N` and `Warning N` fields after the Step 3 output.
+- If numbered `Unmatched model N name` fields exist, mark Cost with `*` when the table exists and
   always say known-price cost excludes those exact model names.