okstra 0.180.0 → 0.184.0

package/runtime/skills/okstra-code-review/SKILL.md

@@ -38,12 +38,12 @@ 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
 ```
 
-Branch on the stdout JSON:
-- `ok: true` → carry `projectRoot` as a literal string; every later step is anchored on it.
-- `ok: false` → the check only sees the cwd of the Bash call, so a project that is not the cwd reads as missing setup. Ask whether the user pointed at a specific project directory; if they did, re-run targeting it: `okstra preflight --runtime claude-code --cwd <that-dir> --json` (`--cwd` is the sanctioned way to target a project — a leading `cd` would break the permission match). Only if this **also** returns `ok:false` do you tell the user: "this project has no okstra setup. Run `/okstra-setup` first." Then stop.
+Branch on the fixed first line:
+- `Okstra preflight: ready` → carry `Project root` as a literal string; every later step is anchored on it.
+- `Okstra preflight: failed` → the check only sees the cwd of the Bash call, so a project that is not the cwd can read as missing setup. Ask whether the user pointed at a specific project directory; if they did, re-run targeting it: `okstra preflight --runtime claude-code --cwd <that-dir>` (`--cwd` is the sanctioned way to target a project — a leading `cd` would break the permission match). Only if this also fails do you 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).
@@ -63,8 +63,8 @@ Pick the mode from what the user actually gave you:
 
 **Stage mode.**
 
-1. `okstra resolve-task-key <token> --project-root <projectRoot> --json` → branch on `matches[]`: **0** → report the task cannot be found and stop; **1** → take that entry's `taskKey`; **N** → list the candidates (with `updatedAt`) and ask via a 3-option picker (1–2 recommendations + `Enter directly`).
-2. `okstra stage-map <taskKey> --project <projectRoot> --json` → `stages[]` (`stage_number`, `title`, `depends_on`) and `doneStages[]`.
+1. A full `project-id:task-group:task-id` token is already the task key. For a bare token, run `okstra model-io task-selection-input --project-root <projectRoot> --task-ref <token>` and branch on the fixed `Match count`, `Task`, and `Updated at` rows: **0** → report the task cannot be found and stop; **1** → take `Task`; **N** → list the candidates and ask via a 3-option picker (1–2 recommendations + `Enter directly`).
+2. `okstra stage-map <taskKey> --project <projectRoot> --text` → use the fixed `Stages` and `Done stages` count/name/value rows.
 3. Choose the stage with a 3-option picker — recommend the highest done stage (the work that just finished) first, a second plausible stage if there is one, and `Enter directly` last. Pick silently only when exactly one stage exists.
 
 **Branch mode.**
@@ -75,13 +75,23 @@ Pick the mode from what the user actually gave you:
 **Then call the target CLI.** One call resolves everything the rest of this skill needs; the only reason to call it again is a base the user overrides in the confirmation step below.
 
 ```bash
-okstra code-review target --task-key <taskKey> --stage <N> --project-root <projectRoot> --json
-okstra code-review target --branch <name> [--base <ref>] --project-root <projectRoot> --json
+okstra code-review target --task-key <taskKey> --stage <N> --project-root <projectRoot> --text
+okstra code-review target --branch <name> [--base <ref>] --project-root <projectRoot> --text
 ```
 
-`ok: true` carries `projectRoot`, `mode`, `worktreePath`, `branch`, `baseCommit`, `headCommit`, `reviewPath`, `round`; stage mode adds `taskKey`, `taskRoot`, `stage`. Carry every field verbatim into the later steps — none of them is recomputed anywhere below.
+`Status: ready` carries `Project root`, `Mode`, `Worktree path`, `Branch`, `Base commit`, `Head commit`, `Review path`, and `Round`; stage mode adds `Task key`, `Task root`, and `Stage`. Carry every field verbatim into the later steps — none of them is recomputed anywhere below.
 
-`ok: false` carries `stage` (a failure code) and `reason`. Report both and stop, unless the Exceptions table names that case.
+`Status: error` carries `Failure stage` and `Failure reason`. Report both and stop, unless the Exceptions table names that case.
+
+After the range is resolved, render the only project identity and range values
+that later model prompts may consume:
+
+```bash
+okstra model-io code-review-input --project-root <projectRoot> --base <baseCommit> --head <headCommit>
+```
+
+Carry this fixed Markdown view into the census and reviewer prompts. Do not
+pass task manifests, target-CLI JSON, or arbitrary JSON fields to a reviewer.
 
 **You never derive the base.** Pass `--base <ref>` only when the user named one; otherwise the CLI resolves it. `baseCommit` is a **ref, not necessarily a commit id** — a caller-supplied `--base` passes through verbatim — so use it as given in `git diff <baseCommit>..<headCommit>` and never present it as "commit `<sha>`".
 
@@ -181,7 +191,7 @@ generatedAt: <YYYY-MM-DD HH:MM>
 
 | Situation | Handling |
 |---|---|
-| `preflight` returns `ok:false` | retry with `--cwd <dir>`; if that also fails, tell the user to run `/okstra-setup` first and stop |
+| `preflight` reports `Okstra preflight: failed` | retry with `--cwd <dir>`; if that also fails, tell the user to run `/okstra-setup` first and stop |
 | `unknown command: code-review` | the `okstra` binary predates this skill — tell the user to update it (`npm i -g okstra@latest`) and stop |
 | `worktreePath` is empty | not a hard stop and not a missing stage: run git in `projectRoot` against the stage's `branch` ref and continue |
 | `baseCommit` is not an ancestor of `headCommit` — `git -C <workdir> rev-list --count <headCommit>..<baseCommit>` returns a **non-zero** count, meaning a rebase or squash rewrote the history the stage was recorded against, and `<baseCommit>..<headCommit>` would drag predecessor work in backwards | code-review is read-only, so do not force a reconcile. Offer two options: review against the branch's current tip, or run `okstra git-reconcile` first and retry |

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

@@ -25,10 +25,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 pass it as `--project-root <projectRoot>` to every `okstra container` call below. `ok: false` → tell the user to run `/okstra-setup` first, then stop.
+On `Okstra preflight: ready`, carry the fixed `Project root` line and pass it as `--project-root <projectRoot>` to every `okstra container` call below. 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).
@@ -61,7 +61,7 @@ When the user chains multiple facets in one message (e.g. "bring it up, then sho
 Every sub-command needs a **task-key** (`<project-id>:<task-group>:<task-id>`) — the container group is bound to one implementation task's worktree. Resolve it the same way across sub-commands:
 
 1. If the user gave a full task-key, use it.
-2. If the user gave only a task-id, resolve it via `okstra resolve-task-key <task-id> --project-root <projectRoot> --json` and branch on the stdout `matches[]`: single → use its `taskKey`; multiple → list candidates and ask (3-option picker); none → report not found.
+2. If the user gave only a task-id, run `okstra model-io task-selection-input --project-root <projectRoot> --task-ref <task-id>`. Use the fixed `Selection status`, `Task key`, and numbered `Candidate` lines: one match → use its task key; multiple → list candidates and ask (3-option picker); none → report not found.
 3. `down --all` is the only call that does not need a task-key (see `down`).
 
 ---
@@ -78,12 +78,12 @@ Brings up the task's container group: integrates the implementation stages into
 Run:
 
 ```bash
-okstra container up --project-root <projectRoot> --task-key <task-key>
+okstra container up --project-root <projectRoot> --task-key <task-key> --text
 ```
 
-Parse the stdout JSON and report the provisioned services and the watcher pane. If a service failed its healthcheck, the call surfaces the failing services and the `docker compose ... logs` line to inspect — relay that line; do not invent your own.
+Read the fixed output fields and report the provisioned services and watcher pane. If a service failed its healthcheck, the call surfaces the failing services and the `docker compose ... logs` line to inspect — relay that line; do not invent your own.
 
-After a successful `up`, tell the user how to reach the running build (the compose file's published ports) and that `okstra container status <task-key>` / `okstra container down <task-key>` manage it from here. For *what to verify* once it is up, point the user to the implementation report's §5.7.9 Manual User Test (Draft) — its steps and expected results are the manual test script for this build.
+After a successful `up`, run the `status --text` command below and read its numbered container `ports` fields to tell the user how to reach the running build. Also explain that `okstra container status <task-key>` / `okstra container down <task-key>` manage it from here. For *what to verify* once it is up, point the user to the implementation report's §5.7.9 Manual User Test (Draft) — its steps and expected results are the manual test script for this build.
 
 ---
 
@@ -92,10 +92,10 @@ After a successful `up`, tell the user how to reach the running build (the compo
 Reports the running containers (queried by run-trace label — the source of truth for "is it up") plus the watcher metadata recorded in the registry.
 
 ```bash
-okstra container status --project-root <projectRoot> --task-key <task-key>
+okstra container status --project-root <projectRoot> --task-key <task-key> --text
 ```
 
-Parse the stdout JSON (`{projectName, containers, watchers}`) and report:
+Read the fixed `Project name`, `Containers`, and `Watchers` fields and report:
 
 | Field | Meaning |
 |---|---|
@@ -112,16 +112,16 @@ If `containers` is empty, say the group is not running and offer `up`. Treat the
 The live log stream lives in the tmux watcher pane, not in a file. This sub-command points at the watcher findings directory and the per-service watcher state.
 
 ```bash
-okstra container logs --project-root <projectRoot> --task-key <task-key>
+okstra container logs --project-root <projectRoot> --task-key <task-key> --text
 ```
 
 Add `--service <name>` to scope to one service:
 
 ```bash
-okstra container logs --project-root <projectRoot> --task-key <task-key> --service <service>
+okstra container logs --project-root <projectRoot> --task-key <task-key> --service <service> --text
 ```
 
-Parse the stdout JSON (`{watchersDir, watchers}`). Report the `watchersDir` host path (under `~/.okstra/...`-style project artifacts — display the absolute path the CLI returns) and the watcher entries. Explain that the live stream is in the attached tmux pane; to see raw container logs the user runs `docker compose -p <projectName> logs -f <service>` (get `<projectName>` from `status`).
+Read the fixed `Watchers dir` and numbered `Watchers` fields. Report the host path and watcher entries. Explain that the live stream is in the attached tmux pane; to see raw container logs the user runs `docker compose -p <projectName> logs -f <service>` (get `<projectName>` from `status`).
 
 ---
 
@@ -130,10 +130,10 @@ Parse the stdout JSON (`{watchersDir, watchers}`). Report the `watchersDir` host
 Reaps the watcher/tail tmux panes for the task **without stopping the containers**. Use when the user wants to silence the monitor but keep the build running.
 
 ```bash
-okstra container stop-watcher --project-root <projectRoot> --task-key <task-key>
+okstra container stop-watcher --project-root <projectRoot> --task-key <task-key> --text
 ```
 
-Parse the stdout JSON (`{reapedPanes, note}`). Confirm which panes were reaped and that the containers are still running (the `note` says so). If the user actually wants the containers gone, route to `down`.
+Read the fixed `Reaped panes` and `Note` fields. Confirm which panes were reaped and that the containers are still running. If the user actually wants the containers gone, route to `down`.
 
 ---
 
@@ -144,23 +144,23 @@ Tears down the container group (removes containers found by the run-trace label)
 Single task:
 
 ```bash
-okstra container down --project-root <projectRoot> --task-key <task-key>
+okstra container down --project-root <projectRoot> --task-key <task-key> --text
 ```
 
 Every container group in the project (no task-key needed):
 
 ```bash
-okstra container down --project-root <projectRoot> --all
+okstra container down --project-root <projectRoot> --all --text
 ```
 
-Parse the stdout JSON (`{downed, orphanPanesReaped}`). Report each torn-down `projectName` and the orphan panes reaped. `down` runs `docker compose -p <name> down --remove-orphans` — a compose-native teardown that removes the project's containers and the compose network, but deliberately keeps named volumes (e.g. DB data) by NOT passing `-v`. Confirm with the user before running `--all`, since it takes down every okstra container group in the project at once. A single-task `down` is safe to run directly once the task-key is resolved.
+Read the fixed `Downed` and `Orphan panes reaped` fields. Report each torn-down project name and the orphan panes reaped. `down` runs `docker compose -p <name> down --remove-orphans` — a compose-native teardown that removes the project's containers and the compose network, but deliberately keeps named volumes (e.g. DB data) by NOT passing `-v`. Confirm with the user before running `--all`, since it takes down every okstra container group in the project at once. A single-task `down` is safe to run directly once the task-key is resolved.
 
 ---
 
 ## Output Rules (shared)
 
 - Responses should be concise and written in Korean unless the user requests otherwise.
-- The stdout JSON from each `okstra container` call is the source of truth — do not run raw `docker` commands to second-guess it unless the CLI fails and the user explicitly asks for a manual fallback.
+- The fixed text fields from each `okstra container` call are the source of truth — do not run raw `docker` commands to second-guess them unless the CLI fails and the user explicitly asks for a manual fallback.
 - Show the resolved `<task-key>` in the heading so the user can confirm disambiguation.
 - Surface failure messages from the CLI verbatim (compose-up failures, missing worktree/compose file) — do not paraphrase the remediation line.
-- Display container/service states as-is from the JSON; do not normalize or remap.
+- Display container/service states as-is from the fixed fields; do not normalize or remap.

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

@@ -28,14 +28,14 @@ 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
 ```
 
-The project check only sees the cwd of the Bash call. When the user is asking about a project that is **not** the cwd (a sibling repo, a monorepo subdir, or a project named explicitly in the request), the bare form resolves to the wrong project or none and returns `ok:false` — a false negative, not a missing setup; do not hard-stop on it.
+The project check only sees the cwd of the Bash call. When the user is asking about a project that is **not** the cwd (a sibling repo, a monorepo subdir, or a project named explicitly in the request), the bare form can report `Okstra preflight: failed` — a false negative, not a missing setup; do not hard-stop on it.
 
-Branch on the stdout JSON:
-- `ok: true` → carry `projectRoot` as a literal string; it is the base for every sub-command step below.
-- `ok: false` → before concluding "no setup", ask whether the user pointed at a specific project directory. If they did, re-run targeting it: `okstra preflight --runtime claude-code --cwd <that-dir> --json` (`--cwd` is the sanctioned way to target a project — a leading `cd` would break the permission match). Only if this **also** returns `ok:false` do you tell the user: "this project has no okstra setup. Run `/okstra-setup` first." Then stop.
+Branch on the fixed first line:
+- `Okstra preflight: ready` → carry `Project root` as a literal string; it is the base for every sub-command step below.
+- `Okstra preflight: failed` → before concluding "no setup", ask whether the user pointed at a specific project directory. If they did, re-run targeting it: `okstra preflight --runtime claude-code --cwd <that-dir>` (`--cwd` is the sanctioned way to target a project — a leading `cd` would break the permission match). Only if this also fails do you 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).
@@ -59,13 +59,14 @@ When the user chains multiple facets in one message (e.g. "status, and then time
 
 ### Standard task-key resolution (0/1/N)
 
-Facets that accept a bare token (a task-id like `DEV-9184` **or** a task-group like `PROD`) resolve it with the shared resolver (SSOT — `scripts/okstra_ctl/resolve_task_key.py` / `okstra_project.resolve_task_reference`). The resolver matches the token as a task-id **and** as a task-group, unioning both (a group expands to its member tasks); each entry carries `_matchedVia` (`"taskId"` | `"taskGroup"`):
+Facets that accept a bare token (a task-id like `DEV-9184` **or** a task-group like `PROD`) resolve it through the fixed text projection:
 
 ```bash
-okstra resolve-task-key <token> --project-root <projectRoot> --json
+okstra model-io task-selection-input --project-root <projectRoot> --task-ref <token>
 ```
 
-Branch on the stdout JSON `matches[]`:
+Branch on `Match count` in the projection and use only its repeated `Task`,
+`Updated at`, and `Matched via` lines:
 - **0** → report the task cannot be found. Do not guess.
 - **1** → use that entry's `taskKey`.
 - **N** → list the candidate `taskKey`s (with `updatedAt`, and `_matchedVia` so the user sees which came from a task-id vs a task-group) and ask via a 3-option picker (1–2 recommendations + `Enter directly`), then use the chosen `taskKey`.
@@ -74,8 +75,8 @@ Branch on the stdout JSON `matches[]`:
 
 When a facet needs a task but the user did not name one:
 
-1. Read `.okstra/discovery/task-catalog.json`.
-2. If exactly one task exists, use it.
+1. Run `okstra model-io task-selection-input --project-root <projectRoot>`.
+2. Branch on `Match count`; if exactly one task exists, use it.
 3. If multiple tasks exist, show the latest 10 by `updatedAt` as real task-keys and ask which one. Do not guess, and do not answer with placeholder forms only.
 
 ## Output Rules (shared)
@@ -84,7 +85,7 @@ When a facet needs a task but the user did not name one:
   status values the first time each appears — the reader has not seen the report you are summarizing.
 - Use project-relative paths whenever possible.
 - If there is no recent report, display `--`.
-- If a specific task does not exist, explicitly state that it cannot be found based on `task-catalog.json`.
+- If a specific task does not exist, explicitly state that the task resolver returned no match.
 - If `awaitingApproval` is true, clearly indicate that the task is awaiting user approval.
 - Display status fields as-is from disk (`completed`, `contract-violated`, `todo`, `error`, empty, ...). Do not normalize or remap.
 - Dates in `YYYY-MM-DD HH:MM` format.

package/runtime/skills/okstra-inspect/facets/error-zip.md

@@ -10,23 +10,23 @@ Collect and anonymize the okstra run errors (`runs/*/logs/errors-*.jsonl`) of ev
 
 ### error-zip.1 — Decide the output path (picker)
 
-Read the previous output path from `lastOutputPath` in `~/.okstra/error-zip.json`. If that value exists, present it in a 3-option picker:
+First run the fixed text projection below. If `Previous output path` is not `-`,
+offer it as the recommended first option. Otherwise recommend
+`~/okstra-error-feedback-<YYYY-MM-DD>.zip`. Keep `Enter directly` last.
 
-1. (previous path exists) reuse `<lastOutputPath>` — recommended, first option.
-   (no previous path) propose the default path `~/okstra-error-feedback-<YYYY-MM-DD>.zip` — recommended.
-2. Enter directly (always the last option).
-
-Read `~/.okstra/error-zip.json` directly with Read (if absent, treat it as no previous path).
+```bash
+okstra model-io error-zip-input
+```
 
 ### error-zip.2 — Run the renderer
 
 ```bash
-okstra error-zip --out <resolved-path>
+okstra error-zip --out <resolved-path> --text
 ```
 
 ### error-zip.3 — Report the summary
 
-Parse the stdout JSON and report:
+Use the fixed text labels and report:
 
 | Field | Source |
 |---|---|

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

@@ -23,14 +23,14 @@ If the user asks for an error report without naming a task, apply the core no-ta
 Use the CLI output as the source of truth:
 
 ```bash
-okstra error-report <resolved-target> --project-root <projectRoot>
+okstra error-report <resolved-target> --project-root <projectRoot> --text
 ```
 
 For a task-root path, run `okstra error-report <path>` directly. Do not parse the jsonl files by hand unless the CLI fails and the user explicitly asks for a manual fallback.
 
 ### errors.3 — Summarize output
 
-Parse the stdout JSON and report:
+Use the fixed text labels and report:
 
 | Field | Source |
 |---|---|

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

@@ -8,16 +8,16 @@ Trigger phrases: "okstra history", "past runs", "run history", "re-run", "list t
 
 **Re-run vs Resume — decide upfront.** Re-run = start a fresh run (new run-seq, new manifest, new report) reusing an old run's parameters → `history.3`. Resume = continue an interrupted Claude session for an existing run, no new run-seq → `history.4`. If the user is ambiguous, ask — defaulting to the wrong one either wastes a fresh run-seq or silently abandons a recoverable session.
 
-### history.1 — Read the task catalog
+### history.1 — Project task history
 
-1. Read `.okstra/discovery/task-catalog.json`.
+1. Run `okstra model-io history-input --project-root <projectRoot>`.
 2. Apply filters from user input (all optional, AND-combined):
    - `--task-type <type>` → keep entries whose `taskType` matches.
    - `--latest-run-status <status>` → keep entries whose `latestRunStatus` matches (`completed`, `contract-violated`, `error`).
    - `--task-group <group>` → keep entries whose `taskGroup` matches.
 3. Sort by `updatedAt` desc.
 4. Page: default `--limit 20`. If truncated, add `... <N> more (pass --limit <N> to see all)`.
-5. Extract: `taskKey`, `taskType`, `currentStatus`, `latestRunStatus`, `latestRunManifestPath`, `updatedAt`, `latestReportRecordPath`, `latestResumeCommandPath`, `historyTimelinePath`.
+5. Use the task/status/time/report lines emitted by the fixed text projection.
 
 ```markdown
 ## okstra Task History — <project-id>
@@ -28,19 +28,14 @@ Trigger phrases: "okstra history", "past runs", "run history", "re-run", "list t
 | 2 | proj:group:id2 | final-verification | todo | error | 2026-04-04 15:30 | -- |
 ```
 
-**Catalog absent — fallback.** Do NOT bail out. Manifests on disk are the source of truth.
-
-1. Glob `<projectRoot>/.okstra/tasks/*/*/task-manifest.json`.
-2. For each manifest, read the same fields as above.
-3. Apply the same filters/sort/limit and print the same table, prefixed with: `note: task-catalog.json missing; reconstructed from task manifests on disk.`
-4. Only if the glob yields zero manifests: `There is no okstra execution history yet.`
+If stdout `taskCount` is zero, answer `There is no okstra execution history yet.`
 
 ### history.2 — Run history by task
 
 When a user selects a specific task:
 
-1. Retrieve `historyTimelinePath`, read `runs` array.
-2. Extract: `runTimestamp`, `runDateTimeSegment`, `taskType`, `status`, `runManifestPath`, `reportPath`, `resumeCommandPath`, `relatedTasks`.
+1. Run `okstra model-io history-input --project-root <projectRoot> --task-ref <task-key>`.
+2. Use each numbered run block for chronological status, report, run-manifest, and resume paths.
 
 ```markdown
 ## Runs for <task-key>
@@ -56,7 +51,7 @@ When a user selects a specific task:
 Builds a fresh run — new run-seq, new manifest, new report — using parameters from a previous `run-manifest-*.json`. Does NOT touch old artifacts; use `history.4` to continue an interrupted session.
 
 1. Pick the source run-manifest: `runManifestPath` from `history.2`, or task's `latestRunManifestPath` from `history.1`. Note: `latestRunManifestPath` is projected from the timeline's latest run, so it is empty when the task has no recorded run yet (timeline absent) — in that case fall back to a `history.2` per-run `runManifestPath`, or ask the user.
-2. Read the manifest and extract required arguments:
+2. Run `okstra model-io rerun-input --run-manifest <runManifestPath>` and use its required argument lines:
    - `projectId` → `--project-id`
    - `taskGroup` → `--task-group`
    - `taskId` → `--task-id`
@@ -67,7 +62,7 @@ Builds a fresh run — new run-seq, new manifest, new report — using parameter
    - `relatedTasks` → `--related-tasks`
    - model overrides → `--claude-model`, `--codex-model`, `--antigravity-model`
    - for `taskType: implementation`: `teamContract.executor.provider` → `--executor <claude|codex|antigravity>` when different from `claude`.
-4. **`taskType: implementation` only — resolve `--base-ref`:** base ref is NOT in the run-manifest; it lives in the worktree registry at `~/.okstra/worktrees/registry.json`. If a worktree is already registered, existing branch & base are reused — omit `--base-ref` unless the user explicitly wants a different starting point. If no worktree is registered (cleaned up), `--base-ref` is mandatory — ask the user before running.
+4. **`taskType: implementation` only — resolve `--base-ref`:** do not inspect the worktree registry. Omit `--base-ref` to reuse an existing registration. If the launch reports that no worktree is registered and a base is required, ask the user before retrying.
 5. Display the assembled command:
    ```bash
    ~/.okstra/bin/okstra.sh \
@@ -84,7 +79,7 @@ Builds a fresh run — new run-seq, new manifest, new report — using parameter
 
 Continues an existing Claude session for an unfinished run. Does NOT create a new run-seq — for a fresh dispatch use `history.3`.
 
-1. Read `latestResumeCommandPath` from `history.1` (or `resumeCommandPath` from a `history.2` timeline entry).
+1. Use `Latest resume command` from status input or `Resume command` from a history run block.
 2. Verify the file exists on disk.
 3. If it exists: `bash <resume-command-path>`.
 4. If the path is empty or the file is missing: `No resume script available for this run. Use 'history.3' to start a fresh run instead.`

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

@@ -21,10 +21,10 @@ The log is rewritten from scratch at each dispatch — only the latest run for a
 ### logs.1 — Inventory
 
 ```bash
-okstra log-report --project-root <projectRoot> --json
+okstra log-report --project-root <projectRoot> --text
 ```
 
-Scans `<projectRoot>/.okstra/tasks/**/runs/*/prompts/*.log` and parses task/phase/worker/seq from each path. Returns (sizes are **raw bytes**, mtimes **epoch seconds**):
+Scans `<projectRoot>/.okstra/tasks/**/runs/*/prompts/*.log` and returns fixed labeled text (sizes are **raw bytes**, mtimes **epoch seconds**):
 - `topLargest[]` — `{path, sizeBytes, mtimeEpoch, taskKey, taskGroup, taskId, phase, worker, seq}`, size desc (widen with `--top <N>`)
 - `perTask[]` — `{taskKey, fileCount, totalBytes, oldestEpoch, newestEpoch}`, total-size desc
 - `totals` — `{fileCount, totalBytes, taskCount}`

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.