okstra 0.201.3 → 0.204.0

package/docs/for-ai/skills/okstra-pr-gen.md

@@ -1,49 +0,0 @@
-# okstra-pr-gen AI Manual
-
-## Sources
-
-- Skill source: [`skills/okstra-pr-gen/SKILL.md`](../../../skills/okstra-pr-gen/SKILL.md)
-- Template core (CLI): [`scripts/okstra_ctl/pr_template.py`](../../../scripts/okstra_ctl/pr_template.py)
-- Node wrapper: [`src/commands/pr/pr.mjs`](../../../src/commands/pr/pr.mjs)
-- Bundled default template: [`src/commands/pr/default.md`](../../../src/commands/pr/default.md)
-
-## Purpose
-
-`okstra-pr-gen` registers PR body templates and generates PR descriptions from a branch diff. Templates live in the user home at `~/.okstra/template/pr/`. This skill is **global** — it does not require `<PROJECT_ROOT>/.okstra/project.json`. PR generation additionally requires the current directory to be a git repository.
-
-## Check CLI availability
-
-A separate Bash call with a literal leading token:
-
-```bash
-okstra pr --help
-```
-
-If `okstra` is not on PATH: `okstra not installed — run npx okstra@latest install once, then retry`. Every Bash command starts with the literal `okstra` token and passes literal arguments (do not wrap it in `$(...)`/leading `VAR=`/`if`/`eval`/`||`/`&&`).
-
-## Pick the mode (always first)
-
-A 3-option picker via `AskUserQuestion`:
-
-1. `Generate PR` — generate a PR body from a branch diff
-2. `Register template` — save a new PR body template
-3. `Enter directly` — always last (okstra picker convention)
-
-## Mode A — Generate PR
-
-1. Pick a template: `okstra pr template list`. If the numbered `Templates` rows are empty, use the bundled default. Carry the chosen name as `<template>` (`default` for the bundled one).
-2. Pick the base branch: `okstra pr branches`. Build a 3-option picker from the numbered `Recommended` rows plus `Enter directly`. Carry the choice as `<base>`.
-3. Generation bundle: `okstra pr gen --base <base> --template <template>`. Read the fixed `Base`, `Current branch`, `Template name`, `Commits`, `Diff stat`, and `Template` sections. Then **read the real diff honestly** (SSOT): `git diff <base>...HEAD` (large diffs section by section). Fill the placeholders from the diff and commits, describing **only actual changes**. Mark a checklist box `[x]` only when the diff supports it (tests touched → tests box, docs touched → docs box). If `Commits` or `Diff stat` is empty, say there is nothing to describe and stop. **Never append AI trailers/footers.**
-4. Identifier allowlist for the title and body: only repo-relative source paths (optionally `path:line`), symbol names present in the diff, branch names / commit subjects / SHAs, and issue-tracker ticket ids the reviewer can open. okstra's own artifact identifiers are out of the allowlist — report item ids (`F-001`, `C-001`, `R-001`, `D-0001`, `PREP-001`), run artifact names and their `<task-type>-<seq>` suffixes, phase/stage/worker labels (`final-verification`, `stage-2`, `codex-worker`), and any path under `.okstra/`. They resolve to nothing for a reviewer; restate the substance in code terms instead of citing the id.
-5. Output and offer to create the PR: print the filled PR body as a single fenced markdown block. Ask whether to open a PR. **Only on an explicit yes**: write the body to a temp file and run `gh pr create --base <base> --title "<title>" --body-file <path>`. If `gh` is missing or unauthenticated (`gh auth status` fails), leave the text in chat and give manual-creation guidance. **No push/PR creation without the user's confirmation.**
-
-## Mode B — Register template
-
-1. Template name (`AskUserQuestion`, free text) — must match `^[A-Za-z0-9._-]+$`, otherwise re-ask.
-2. body — pasted text or an absolute path.
-3. Save: `okstra pr template add --name <name> --file <abs-path>` (or, for pasted text, `--content "<body>"`). Add `--yes` only when the user confirmed overwriting a same-named template. Report the saved path (`saved: ...`).
-
-## Output Rules
-
-- Not read-side — write actions (PR creation, template saving) happen only after the user's explicit confirmation.
-- Do not invent changes not in the diff. Stop if commit/diffStat is empty.

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

@@ -1,114 +0,0 @@
-# okstra-rollup AI Manual
-
-## Source
-
-- Skill source: [`skills/okstra-rollup/SKILL.md`](../../../skills/okstra-rollup/SKILL.md)
-- aggregation core (CLI): [`scripts/okstra_ctl/rollup.py`](../../../scripts/okstra_ctl/rollup.py)
-- reused single-task aggregators: [`scripts/okstra_ctl/time_report.py`](../../../scripts/okstra_ctl/time_report.py), [`scripts/okstra_ctl/error_log_core.py`](../../../scripts/okstra_ctl/error_log_core.py)
-- catalog enumeration helper: [`scripts/okstra_project/state.py`](../../../scripts/okstra_project/state.py) (`list_project_tasks`)
-- unit tests: [`tests/inspect/test_okstra_rollup.py`](../../../tests/inspect/test_okstra_rollup.py)
-
-## Purpose
-
-`okstra-rollup` **collects and summarizes the run results of multiple tasks at once**. It is a cross-task read-side layer, in contrast to `okstra-inspect` which looks at a single task.
-
-- Input scope: one task-group, or the whole-project catalog when `--task-group` is omitted.
-- Deterministic aggregation (counts, time sums, error sums, status/category/phase distributions) is handled entirely by the `okstra rollup` CLI. The skill renders that table and reads each task's report body to write a **cross-task synthesis (digest)**.
-- Design principle: hand-computed aggregation is error-prone for an LLM, so it is pushed to the CLI (SSOT), and only the natural-language synthesis is left to the LLM. This is the same division of labor as `okstra-inspect time`, which insists on "never re-sum the time by hand".
-
-This skill is read-only. It does not mutate task artifacts.
-
-## When to use
-
-Use it when:
-
-- The user asks for "rollup", "task-group summary", "group-level report", "collect multiple task results", "whole-project task status summary", "run results all at once".
-- You want to look across **multiple tasks** rather than a single one.
-
-Do not use it when:
-
-- A single task's report/time/errors/recap → `okstra-inspect` (report / time / errors / recap facet).
-- "Where does the group stand" — which briefs are done / in progress / not started, what is next, each task's latest conclusion → `okstra-inspect` recap facet with `--task-group`. rollup keeps the numbers (runs, time, errors) and the cross-task digest.
-- A forward-looking work plan (a client-facing schedule of non-done tasks) → `okstra-schedule-gen`. rollup is **retrospective**, collecting past run results; schedule is **forward-looking**, planning future work.
-- Actual phase execution → `okstra-run`.
-
-## Preflight
-
-A single Bash call starting with the literal `okstra` token (not wrapped in `if`/`eval`/`$(...)`/`VAR=`/`||`/`&&`/`npx` fallback):
-
-```bash
-okstra preflight --runtime claude-code
-```
-
-On `Okstra preflight: ready`, carry `Project root` as a literal string. On
-`Okstra preflight: failed`, show `Reason` and `Recovery`, then stop.
-
-## scope resolution
-
-- The user named a task-group ("summarize the alpha group") → `--task-group <group>`.
-- "all tasks" / "the whole project" / no scope named → omit `--task-group` (whole catalog).
-- If genuinely ambiguous, ask once: one task-group or the whole project? Do not silently guess a specific group.
-
-## CLI call
-
-```bash
-okstra rollup --task-group <group> --project-root <projectRoot> --text
-```
-
-For the whole project, drop `--task-group`. The output is fixed, ordered label/value rows, and **all times are raw milliseconds**.
-
-## Interpreting the output
-
-Fixed fields:
-
-- `Task group` and `Task count` identify the scope.
-- Numbered `Tasks` rows carry task identity, status, phase, next phase, report path, run count, CPU, wall-clock, and error count.
-- `Totals runs`, `Totals CPU sum ms`, `Totals wall clock ms`, and `Totals errors` are the aggregate values.
-- Numbered `Work status`, `Work category`, `Current phase`, and `Task type` rows carry the aggregate distributions.
-
-Numeric meanings (must observe):
-
-- `Run count` is the **total number of runs** in the timeline. CPU and wall-clock rows reflect only runs that reached Phase 7 usage, so they can be `0` even when run count is positive.
-- `CPU sum ms` is the **CPU sum** of the overlapping lead + workers, not wall-clock.
-- `Report path` is project-relative and may be `-` for a task with no report yet.
-- If `Task count` is `0`, say there are no okstra tasks in that scope and stop.
-
-## Render
-
-Convert every `*Ms` to `HH:MM:SS` (zero-pad; never expose raw ms — the same rule as `okstra-inspect time`). Sort tasks by `updatedAt` descending.
-
-```markdown
-## okstra Rollup — <task-group or "whole project"> (<taskCount> tasks)
-
-| Task | Category | workStatus | Phase | Runs | CPU | Errors | Report |
-|------|----------|------------|-------|------|-----|--------|--------|
-| DEV-1 | bugfix | done | final-verification | 2 | 00:25:00 | 2 | ✓ |
-| DEV-2 | feature | in-progress | implementation | 1 | 00:00:00 | 0 | — |
-
-**Totals:** 3 runs · CPU 00:25:00 · 2 errors
-**workStatus:** done 1 · in-progress 1   **category:** bugfix 1 · feature 1
-```
-
-- `Report` column: `✓` when `reportPath` is present, `—` when not.
-- Build the status/category/phase lines from the `totals` tally maps **verbatim**. Do not count the `tasks[]` array yourself (the CLI is the SSOT for aggregation).
-
-## Writing the digest (the summary — the skill's core value)
-
-When the user asks to "summarize"/"organize"/"summarize"/"digest" (the common case):
-
-1. For each task with a non-empty `reportPath` whose `<projectRoot>/<reportPath>` file actually exists, read the report and summarize in 1–2 lines **what it accomplished and its recommended next step**.
-2. Above the per-task lines, write a 2–4 sentence group-level synthesis: what was delivered across the group, where the open work sits (using `byWorkStatus`/`byCurrentPhase`), and whether there are error hot-spots (tasks with high `errorCount`).
-3. Cite each per-task claim with the report path (`<reportPath>`) so the reader can open it directly.
-
-For a task with no report, do not invent a summary; state the current phase/workStatus instead. Do not read non-report artifacts to fill the gap (artifact-home rule). If a report is empty or missing, say so.
-
-If a deep single-task drill-down (full report, per-worker time, error breakdown, run-to-run recap) is needed, point the user to `/okstra-inspect`.
-
-## Forbidden patterns
-
-- Re-counting aggregate numbers (totals, distributions) by hand from `tasks[]`. `totals` is the SSOT.
-- Exposing raw ms. Always `HH:MM:SS`.
-- Labeling `cpuSumMs` as if it were wall-clock.
-- Inventing a summary for a task with no report. Substitute the current phase/workStatus.
-- Reading files outside okstra artifacts (non-`.okstra`) to fill the summary.
-- Handling single-task detail in rollup. Send it to `okstra-inspect`.

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

@@ -1,250 +0,0 @@
-# okstra-run AI Manual
-
-## Source
-
-- Skill source: [`skills/okstra-run/SKILL.md`](../../../skills/okstra-run/SKILL.md)
-- wizard CLI wrapper: [`src/commands/execute/wizard.mjs`](../../../src/commands/execute/wizard.mjs)
-- wizard state machine: [`scripts/okstra_ctl/wizard/`](../../../scripts/okstra_ctl/wizard/)
-- render-bundle CLI: [`src/commands/execute/render-bundle.mjs`](../../../src/commands/execute/render-bundle.mjs)
-- prepare entrypoint: [`scripts/okstra_ctl/run.py`](../../../scripts/okstra_ctl/run.py)
-
-## Purpose
-
-`okstra-run` starts an okstra task run inside the current supported agent host. Input collection is owned entirely by the `okstra wizard` state machine; the skill relays the wizard prompts to the user and then prepares the task bundle via `okstra render-bundle`. Once the bundle is ready, the current Claude Code, Codex, or Antigravity session takes over as the host-native Okstra lead.
-
-Single authority:
-
-- Question order: `scripts/okstra_ctl/wizard/registry.py` (`STEPS`); branching: `engine.py`; per-step validation: `steps_*.py`
-- task bundle materialization: `prepare_task_bundle()`
-- Skill document: thin prompt-relay loop
-
-## When to Use
-
-Use it when:
-
-- The user wants to start an okstra task in the current session.
-- The user wants to continue the next phase of an existing task.
-- "okstra run", "okstra start", "start okstra in this session", "run the next phase", etc.
-
-Do not use it when:
-
-- The user only wants status: `okstra-inspect status`
-- The user wants past runs or a resume command: `okstra-inspect history`
-- The user explicitly named a new terminal / new claude process: point them to inspect history/resume
-
-## Preflight
-
-Resolve `<host-runtime>` from the executing harness: Claude Code → `claude-code`, Codex → `codex`, Antigravity CLI → `antigravity`, and another adapter host → `external`. This is a host capability, not a `PATH` inference or worker-provider choice. The lead provider is derived from this value and cannot be selected independently. Then make one Bash call:
-
-```bash
-okstra preflight --runtime <host-runtime>
-```
-
-On `Okstra preflight: failed`, show `Reason`, `Recovery`, `Runtime readiness`,
-and every repeated `Readiness check` line, then stop. On
-`Okstra preflight: ready`, require `Runtime readiness: ready`, carry the fixed
-`Project root` line, and read the `Relay contract` path. Do not create an
-`export PYTHONPATH`.
-
-## Bash invocation rule
-
-Every okstra call begins with the literal token `okstra`. Read the `--state-file`, `--answer`, path, model, and worker values from the prior JSON/tool output and paste them as literal strings.
-
-Avoid:
-
-- `$STATE_FILE`, `$ANSWER`
-- `$(...)`
-- `VAR=... okstra ...`
-- `eval`, `export`
-- `okstra ... && okstra ...`
-
-Do not drop the flag even for an empty answer.
-
-```bash
-okstra wizard step --state-file /tmp/okstra-wizard/state.json --answer ""
-```
-
-## wizard initialization
-
-Create the state file:
-
-```bash
-okstra wizard new-state-file
-```
-
-Carry the printed absolute path verbatim.
-
-wizard init:
-
-```bash
-okstra wizard init --state-file /tmp/okstra-wizard/state.json --project-root /abs/project --project-id project-id --host-runtime <host-runtime>
-```
-
-The result is `{ok, next}` JSON. The first step is `task_pick`.
-
-## Interpreting the wizard JSON
-
-Pick the UI according to `next.kind`.
-
-| kind | Handling |
-|---|---|
-| `pick`, `multi: false` | Render every `options[]` verbatim as a selectable choice. Submit the chosen option's `value` |
-| `pick`, `multi: true` | Submit all chosen values as a comma-separated string. An empty selection still submits `--answer ""` |
-| `pick_group` | Render the wizard's `questions[]` as a single multi-question UI. Build a JSON object of per-step values and submit it in one shot |
-| `text` | Show a plain text label without a picker, then submit the user's next message verbatim |
-| `done` | Input collection finished. Move to render-args |
-| `aborted` | Delete the state file and stop. Do not call render-args/render-bundle |
-
-`progress.label` is a string the wizard composed. Append it verbatim after the UI prompt; do not compute it yourself.
-
-## wizard loop
-
-1. Render the prompt.
-2. Submit the user's answer as a literal `--answer`.
-3. `ok: true`: show `result.echo` to the user on one line and advance to the next step.
-4. `ok: false`: show `result.error` verbatim and retry the same step via `result.current`.
-5. `current: null`: a terminal error where the prompt cannot be reconstructed. Show the error and stop.
-
-Important: never trim, hide, or restructure the wizard-provided options into a "recommended + Enter directly" form. The wizard's `options[]` is the complete choice set.
-
-## brief candidate ordering
-
-The brief selection is handled by the wizard. A new task is asked for its brief right after task-group and **before** the task-type; an existing task is asked only on an entry phase (`requirements-discovery`, `error-analysis`, `improvement-discovery`, `project-analysis`, `feature-analysis`, `change-impact-analysis`).
-
-- task-group candidates are shown newest-first by combining recent task-catalog use with the recent brief creation/modification times under `.okstra/briefs/<group>/`.
-- brief file candidates are chosen from within the selected group's `.okstra/briefs/<task-group>/**/*.md`.
-- The brief-file sort key is `max(file created/modified time, task-catalog updatedAt of the task that used this brief)`.
-- direct input is always last.
-- for a new task the following task-type pick offers entry phases only, and its recommended slot is the selected brief's `Recommended next phase:` line (fallback `requirements-discovery`).
-
-## confirm step
-
-When `next.step == "confirm"`, first fetch the confirmation summary.
-
-```bash
-okstra wizard confirmation --state-file /tmp/okstra-wizard/state.json
-```
-
-Show `text` to the user, then render the Proceed/Edit/Abort picker as the final output of that turn — the rendered question is the last thing you emit in that turn, and text emitted after the call renders below the picker. `Edit` rewinds the wizard to an earlier step.
-
-## outcome and render-bundle
-
-When `next.kind == "done"`:
-
-```bash
-okstra wizard outcome --state-file /tmp/okstra-wizard/state.json
-```
-
-Run `outcome.persistActions[]` first, then pass each key of the `outcome.renderArgs` object exactly once as an `okstra render-bundle` flag. Pass empty string values explicitly too, and add `--lead-runtime <host-runtime>` from preflight. Do not enumerate provider-specific keys in this manual; the wizard and provider registry own the emitted arguments. Exception: the `chain-stages` key is not a render-bundle flag — it drives the Step 7 unattended-chaining loop, so do not pass it as a flag (`run.py` accepts only `--stage`/`--stages`).
-
-```bash
-okstra render-bundle \
-  --lead-runtime <host-runtime> \
-  --<first-renderArgs-key> "<first-renderArgs-value>" \
-  --<each-remaining-renderArgs-key> "<corresponding-value>"
-```
-
-Parse the following labeled lines from stdout.
-
-- `okstra task root:`
-- `okstra instruction-set:`
-- optionally `okstra concurrent-run stages:`
-
-render-bundle calls `prepare_task_bundle()` in render-only mode to prepare the manifests, run context, instruction set, and discovery files, and registers the run as `prepared` in `~/.okstra/recent.jsonl`.
-
-## conformance waiver
-
-Classify the entry before offering a waiver. If `requires` contains `db`,
-`http`, or `external`, do not offer a waiver: Okstra still attempts the command,
-but any non-PASS or unavailable outcome is an external advisory with a
-user-owned rerun method. If `requires=[]`, fail closed as a declaration or
-contract defect and do not offer a waiver. Offer the waiver only when
-`requires=[io]` and that blocking local conformance command is genuinely
-impossible to run in the environment. A waiver requires user approval and a
-verbatim reason. Neither the AI lead nor a worker creates a self-exemption.
-The resulting blocking/advisory policy is enforced by
-`scripts/okstra_ctl/conformance.py::decide_conformance_gate` and
-`validators/validate-run.py::_validate_conformance`; the picker restriction is
-defined by `prompts/host-orchestration/implementation.md` Step 5.1 (the
-`okstra-run` skill body carries a generated copy).
-
-When chosen, add it to `render-bundle` only.
-
-```bash
---qa-waiver "<stageKey>:<reason>"
-```
-
-Omit the flag entirely when there is no value.
-
-## concurrent-run branch
-
-If `render-bundle` stdout carries `okstra concurrent-run stages:`, the no-team background gate is already reflected in the prompt.
-
-Give the user three options.
-
-1. Proceed as no-team background.
-2. Wait — hold the dispatch, preserve the stage worktree·run context. After the occupying run finishes, print the resume command (`okstra-inspect` history → resume) so the user can resume the same stage.
-3. Enter directly.
-
-This picker is authored by the skill, so it is separate from the wizard-option-abbreviation ban.
-
-## stale git SHA recovery
-
-When a `PrepareError` such as `Recorded stage SHAs no longer match the git history` appears, do not fix the registry/consumers by hand.
-
-1. Run the `okstra git-reconcile ... --check --text` printed in the error message verbatim.
-2. For each confirm item, ask the user for the current branch tip, a different ref, or abort.
-3. Run `okstra git-reconcile ... --apply --stage <N> --use-ref <ref>` with the chosen ref.
-4. Retry the failed render-bundle with the same arguments.
-
-If the anchor is unresolvable, run `--reset-anchor <ref>` after user confirmation.
-
-## PR template persistence
-
-In release-handoff, when `outcome.persistActions[]` returns a `config.set` / `pr-template-path` action, save the config before render-bundle.
-
-```bash
-# action.scope == "project"
-okstra config set pr-template-path "<path>" --scope project
-# action.scope == "global"
-okstra config set pr-template-path "<path>" --scope global
-```
-
-Read the scope and path from the persist action of `okstra wizard outcome`, not from the wizard state file. Do not read the raw state file directly.
-
-## Okstra lead takeover
-
-After render-bundle, read the run manifest's `resources.leadExecutionPromptPath` (project-relative, under `runs/<task-type>/prompts/`), read that file verbatim, and proceed from Phase 1 in that prompt's order. Before any in-run approval or clarification question, follow the lead contract "User confirmation before an approval blocker": read cited plan items, worker findings, and files, then ask in the user's language with each option's outcome.
-
-Inform the user on one line.
-
-```text
-Took over as Okstra lead (`<host-runtime>`) for `<taskKey>` (`<task-type>`). Run dir: `<RUN_DIR_RELATIVE_PATH>`. Beginning Phase 1 (context loading).
-```
-
-For a single-element chain, the end of Step 6 is the end of the run. Step 7 below applies only when the `chain-stages` CSV has 2 or more elements. When the run is over, close with the user's next action — one command they can run now. A prohibition is not a next action. Take it from the `report-finalize` result: `nextCommand` (`{command, note}`) is the table below already applied, and `nextRecommendedPhase` (`phase`, `status`, `rationale`) is what it was applied to — do not re-derive either from the report, and treat `nextRecommendedPhaseError` as "pointer unreadable", said in one line before the `validate-run` branch. After `implementation-planning`: open approval blockers → `/okstra-user-response`; a recorded `accept-risk` / `select` / `answer` is not an open blocker; no open approval blocker → `/okstra-run` → `implementation` or `--approve` (do not start another planning run; do not say `/okstra-inspect`). For every other task type: pointer `ready` → `/okstra-run` for that phase; `validate-run` failed → one-line cause then `/okstra-run`; otherwise `/okstra-inspect status`.
-
-## implementation unattended chaining (chain-stages)
-
-When `task-type == implementation` and the render-args `chain-stages` CSV has 2 or more elements, the current session acts as the orchestrator and runs the stages as an unattended chain in dependency order. Queue = the topologically-sorted stage list from splitting `chain-stages` on `,`. For each stage `N` in the queue, in order:
-
-1. Re-call render-bundle with the same arguments but `--stage N` (the base commit is auto-computed by prepare from the predecessor's done `head_commit` — do not pass it by hand). The `io`-only conformance waiver·concurrent-run·git-reconcile gates apply identically to each stage's render-bundle.
-2. As in Step 6, become the host-native Okstra lead and run that stage's Phase 1–7 inline. Phase 6's lead persistence appends that stage's `status:"done"` row to `runs/<plan-task-key>/consumers.jsonl`.
-3. After confirming the `done` row was written, move to the next stage. Clean up context (leftover panes·finished teammates) at each stage boundary. A `status:"failed"` row in place of `done` means the stage ended `FAIL` — stop the queue per the FAIL branch below.
-4. One-line report at each stage start/finish: `stage N start` / `stage N done → next K`.
-
-Once the whole queue is consumed, end the chain and report completion.
-
-- **Next stage not yet ready — normal termination:** When a stage in the queue is occupied by another implementation run as started/reserved and render-bundle is rejected with `--stage N already in progress or reserved by another run` (StageTargetError), this is not an exception — **terminate the chain normally** and report the remaining queue (e.g. `remaining queue: stage 4, 5 — resume with okstra-run after occupancy is released`).
-- **Stage ended FAIL — stop the queue and report:** When a stage's synthesised verdict is `FAIL`, Phase 6 writes no carry sidecar and appends a `status:"failed"` row instead of `done`. **Stop the queue there** and report the failed stage, its report path, and the remaining queue. Do not continue to the next stage even when it is dependency-independent — later work must not be stacked on a confirmed regression. The `failed` row frees the occupancy, so `--stage <N>` re-enters that stage on its preserved worktree and branch.
-- **Exception gate during chaining:** If render-bundle raises a concurrent-run conflict or git stale-SHA reconciliation, **stop the chain at that stage** and present the gate to the user per the Step 5 procedure. Once the user resolves it, resume the remaining queue in place. Data corruption·concurrent-occupancy conflicts are confirmed by a human — this is the safety boundary of unattended chaining.
-
-## Forbidden patterns
-
-- Changing the question order the wizard emitted.
-- Hiding wizard options or keeping only the recommendations.
-- Turning a `text` prompt into a picker.
-- Dropping the `--answer` flag on an empty answer.
-- Bypassing the wizard/render-bundle path by calling `okstra.sh`.
-- Calling render-args on a state the user aborted before render-bundle.
-- Starting phase work arbitrarily before reading the Okstra lead prompt.

package/docs/for-ai/skills/okstra-schedule-gen.md

@@ -1,240 +0,0 @@
-# okstra-schedule-gen AI Manual
-
-## Source
-
-- Skill source: [`skills/okstra-schedule-gen/SKILL.md`](../../../skills/okstra-schedule-gen/SKILL.md)
-- Schedule template: [`templates/reports/schedule.template.md`](../../../templates/reports/schedule.template.md)
-- Schedule validator: [`validators/validate-schedule.py`](../../../validators/validate-schedule.py)
-- Stage Map read side: [`scripts/okstra_project/state.py`](../../../scripts/okstra_project/state.py)
-- Selection semantics: [`scripts/okstra_ctl/schedule_semantics.py`](../../../scripts/okstra_ctl/schedule_semantics.py)
-- Work-category source of truth: [`scripts/okstra_ctl/work_categories.py`](../../../scripts/okstra_ctl/work_categories.py)
-- workStatus inference reference: [`skills/okstra-inspect/SKILL.md`](../../../skills/okstra-inspect/SKILL.md)
-
-## Purpose and invocation
-
-`okstra-schedule-gen` gathers non-done tasks in a task group and produces one client-facing work schedule from user-selected unfinished implementation stages.
-
-Public invocation:
-
-```text
-/okstra-schedule-gen [task-group]
-```
-
-This is a host skill, not a schedule-generation shell command. Use `stage-map` and `validate-schedule.py` only as backend contracts inside the skill.
-
-Output location:
-
-```text
-<PROJECT_ROOT>/.okstra/tasks/<task-group-segment>/schedule/<task-group-segment>-plan-<YYYY-MM-DD_HH-MM-SS>.md
-```
-
-Do not use it for single-task status analysis or phase execution. Use `okstra-inspect status` and `okstra-run` for those jobs.
-
-## Preflight and task-group resolution
-
-Run one literal-token preflight call:
-
-```bash
-okstra preflight --runtime claude-code
-```
-
-On `Okstra preflight: failed`, show `Reason` and `Recovery`, then stop. On
-`Okstra preflight: ready`, carry the fixed `Project root` line. Resolve an
-explicit task-group from the invocation or host request. If none is unambiguous,
-run `okstra model-io task-selection-input --project-root <projectRoot>` and ask
-the user to choose from the fixed `Task` rows; never guess. Then run
-`okstra model-io schedule-input --project-root <projectRoot> --task-group <group>`
-and use only its fixed task metadata rows.
-
-On zero matches, report that the task group was not found and do not create a file.
-
-## Candidate filter
-
-`workStatus` is used only to decide which tasks are candidates. When it is missing or empty, use the `okstra-inspect` `status.4` inference table.
-
-- Exclude resolved `done` tasks.
-- Include every other resolved state.
-- If no task remains, report that all tasks are done and do not create a file.
-
-Do not render `workStatus` as the detailed task status. The per-task `Status` value is `<taskType> / <currentPhase>`.
-
-## Source-aware Stage Map resolution
-
-For every candidate task, call:
-
-```bash
-okstra stage-map <task-key> --text
-```
-
-The successful fixed response carries `Status`, `Task key`, `Task root`, `State`,
-`Source plan path`, and lossless numbered `Stages`, `Done stages`, and `Planning`
-count/name/value rows.
-
-Handle each result explicitly:
-
-- `Status: ready`, `State: ready`: use exactly `Source plan path`; do not pick a report by mtime or `latestReportRecordPath`. Select only stages not present in the done-stage rows.
-- `Status: ready`, `State: missing`: record an empty source and empty stage sets, mark the task `[NEEDS-PLANNING]`, and emit no forward Work Breakdown, Gantt, or day total for it.
-- `Status: error` or another state: stop before drafting and report `Failure stage` and `Failure reason`. A corrupt or conflicting source must never fall back to a guessed report.
-
-A valid selected set is dependency-closed: every transitive prerequisite of a selected stage is either also selected or present in `doneStages`. Completed prerequisites remain evidence only and are never scheduled forward.
-
-If a ready task has no unfinished stages, render `_Complete — no remaining stage_` and omit forward effort.
-
-## Stage selection
-
-Offer up to three dependency-closed cumulative bundles in topological order, plus all remaining stages. A custom set is accepted only after closing it over unfinished prerequisites; completed prerequisites are preserved separately.
-
-Skip the picker when the remaining work has only one possible bundle and use all unfinished stages. Record the final stage numbers as `selectedStages`.
-
-## Temporary selection contract
-
-Write a paired draft and selection input with one timestamp:
-
-```text
-.okstra/tasks/<task-group-segment>/schedule/.draft/<timestamp>.md
-.okstra/tasks/<task-group-segment>/schedule/.draft/<timestamp>.selection.json
-```
-
-The selection file is a temporary verification input. It freezes the exact source, full stage map, completed stages, and user-selected forward work so both validators judge the same facts instead of re-resolving mutable task state.
-
-Schema version 1:
-
-```json
-{
-  "schemaVersion": 1,
-  "tasks": [
-    {
-      "taskKey": "demo:group:DEV-1",
-      "taskId": "DEV-1",
-      "state": "ready",
-      "sourcePlanPath": "/absolute/path/final-report-implementation-planning-001.data.json",
-      "selectedStages": [2, 3],
-      "doneStages": [1],
-      "stages": [
-        {
-          "stageNumber": 1,
-          "title": "Prepare port",
-          "dependsOn": [],
-          "stepCount": 2
-        },
-        {
-          "stageNumber": 2,
-          "title": "Build adapter",
-          "dependsOn": [1],
-          "stepCount": 3
-        },
-        {
-          "stageNumber": 3,
-          "title": "Wire consumer",
-          "dependsOn": [2],
-          "stepCount": 2
-        }
-      ]
-    }
-  ]
-}
-```
-
-Include every candidate task. A `missing` task has an empty `sourcePlanPath`, `selectedStages`, `doneStages`, and `stages`. Convert the CLI stage-row keys to the camel-case selection boundary exactly as shown.
-
-## Phase classification
-
-Only these canonical categories are valid:
-
-| workCategory | Default phase |
-|---|---|
-| `bugfix` | Phase 1 for High or Med-High risk; otherwise Phase 2 |
-| `feature` | Phase 2 |
-| `improvement` | Phase 2 |
-| `refactor` | Phase 3 |
-| `ops` | Phase 3 |
-
-Priority overrides category: P0 maps to Phase 1, P1/P2 to Phase 2, and P3 to Phase 3. An unknown or missing raw category falls back to Phase 2 with a one-line rationale naming the raw value. Do not invent another category.
-
-## Template contract
-
-Follow `schedule.template.md` exactly. The required top-level order is:
-
-1. `## At a Glance`
-2. `## Executive Summary`
-3. `## Task Dependency Graph`
-4. optional `## Gantt Chart`
-5. `## Phase 1: Critical Fixes`
-6. `## Phase 2: Enhancements`
-7. `## Phase 3: Architecture`
-8. `## Execution Priority Matrix`
-9. `## Cross-Task Dependencies & Shared Concerns`
-10. `## Risk Mitigation Strategy`
-11. `## Recommended Immediate Actions`
-12. optional final `## Glossary`
-
-Keep an empty required section and render `_none_`. Headings and field labels stay as English template literals; body prose is Korean.
-
-Each scheduled task uses this stage-level Work Breakdown shape:
-
-```markdown
-| Stage | Title | Steps | Depends On | Days |
-|---:|---|---:|---|---:|
-| 2 | Build adapter | 3 | 1 (done) | 2.0 ~ 3.0 |
-| 3 | Wire consumer | 2 | 2 | 1.0 ~ 2.0 |
-```
-
-Use the template's Effort Sizing Criteria values without redefining them. Allocate a task's range across selected stages in `stepCount` proportion: round every stage except the last to 0.5 day and let the last absorb the remainder. The stage ranges must sum to the task range, and finite task ranges must sum to the displayed total. XXL, missing, and complete tasks contribute no forward total.
-
-An unrepresentable half-day allocation is a validation error. Do not substitute a fallback allocation algorithm; revise the task sizing or selected-stage scope.
-
-## Gantt contract
-
-Render a plain fenced relative-day Gantt when the selected stages have finite day ranges. Every forward row is identified by stage and repeats its Work Breakdown range:
-
-```text
-DEV-1 Stage 2  ████      days=2.0~3.0
-DEV-1 Stage 3      ████  days=1.0~2.0
-```
-
-A row is labelled `Stage <n>` when exactly one task is scheduled and `<TASK-ID> Stage <n>` when more than one is; the annotation is `days=<lower>~<upper>`. Spell the stage out — `S1` is an opaque code that costs the reader a lookup and saves five characters. Do not emit a row for a completed, unselected, missing, or unknown stage. Bar length is arithmetic: one column is half a day, so a bar runs `lower / 0.5` filled cells `█` then `(upper - lower) / 0.5` open cells `░`.
-
-Skip the chart only when no forward task has a finite day signal, and state the concrete reason. Do not use calendar dates, Mermaid, PlantUML, Graphviz, or another graph language.
-
-A host-supplied directive or the first `## Directive` in the configured analysis material may override the render/skip heuristic, but it cannot override stage selection, dependency closure, or validated day arithmetic.
-
-## Client-facing boundary
-
-Assume the team has the required authority. Exclude approval waits, permission checks, stakeholder coordination, decision checklists, and internal blocker codes from forward engineering work. Gantt duration and totals represent engineering work only.
-
-Resolve opaque source-report codes inline or in the optional final Glossary. Decision-item codes do not belong in the schedule.
-
-## Two validation gates
-
-Run both gates against the same draft and temporary selection contract.
-
-1. Deterministic gate:
-
-   ```bash
-   python3 ~/.okstra/lib/validators/validate-schedule.py <draft> --selection-json <selection>
-   ```
-
-2. Only after that command passes, create a new `.okstra/agent-invocations/schedule-verification/<invocation-id>.instructions.md` with the draft, selection JSON, and checks, but not the lead's reasoning. Run `okstra agent-prompt materialize --purpose schedule-verification --audience schedule-verifier ...` and verify the returned metadata before dispatch. A native host call uses the verified prompt body plus `hostModelValue`; a deterministic provider process uses `okstra worker-dispatch`, the prompt path, and `modelExecutionValue`. The verifier checks narrative coherence, phase rationale, executable order, engineering-only scope, and contradictions with the structured rows.
-
-Capture the raw verifier return under the purpose directory's `.tmp/`, then run `okstra agent-prompt materialize-result`, `complete`, and `verify-completion` in order. Parse only the verified `returnedBody`; an inline or unverified response cannot pass the narrative gate.
-
-If either gate finds a defect, revise the same draft in place and restart from the deterministic gate. Allow at most two revision rounds across both gates. Never publish a draft that has not passed both gates in that order.
-
-After both gates pass:
-
-1. Move the same draft content to the collision-safe final path; do not re-render it.
-2. Re-read it and run the installed format validator on the final path, falling back to the repository validator only when needed.
-3. Delete the temporary selection file only after final validation passes.
-4. Report completion in Korean with the output path, included/excluded counts, finite total range, and lead-plus-verifier mode.
-
-## Forbidden patterns
-
-- Guessing a planning report after `stage-map` reports a structured error.
-- Treating `workStatus` as the detailed schedule status.
-- Scheduling completed or non-selected stages.
-- Publishing a Gantt row without its `Stage <n>` label and `days=` range, or abbreviating that label to `S<n>`.
-- Drawing stage order in `## Task Dependency Graph` — that graph carries cross-task edges only; stage order lives in the Work Breakdown's `Depends On` column.
-- Dispatching narrative validation before deterministic `--selection-json` validation.
-- Re-rendering after validation instead of promoting the same draft.
-- Deleting the selection contract before final validation.
-- Publishing after more than two unsuccessful revision rounds.