okstra 0.123.0 → 0.125.0

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

@@ -1,28 +1,30 @@
 ---
 name: okstra-inspect
 description: >-
-  Use this for everything that happens AFTER a single okstra task has already run — inspecting it or light bookkeeping on it, never launching new work. The tell is usually a named task id (PROD-1623, dev-9184), often dropped without the word "okstra." Reach for it when the user wants one task's: status, current/next phase, blockers, or approval gate; its final report — where it is or whether it passed (결론·통과); its elapsed time (소요 시간) or context/read cost (컨텍스트 비용); its run history, re-run, or resume; to mark it done / in-progress / blocked / todo; or a failed run's error logs gathered into a report (에러 리포트). Also bundles cross-project okstra errors into an anonymized feedback zip (에러 환류). Use it even for a bare "mark it done" or "where's the report." NOT for starting a run (okstra-run), rollups/schedules (okstra-rollup / okstra-schedule-gen), a brief (okstra-brief-gen), setup (okstra-setup), or cross-project management (okstra-manager).
+  Use this for everything that happens AFTER a single okstra task has already run — inspecting it or light bookkeeping on it, never launching new work. The tell is usually a named task id (PROD-1623, dev-9184), often dropped without the word "okstra." Reach for it when the user wants one task's: status, current/next phase, blockers, or approval gate; its final report — where it is or whether it passed (verdict / pass); its elapsed time or context/read cost; its run history, re-run, or resume; to mark it done / in-progress / blocked / todo; or a failed run's error logs gathered into a report (error report). Also bundles cross-project okstra errors into an anonymized feedback zip (error feedback). Use it even for a bare "mark it done" or "where's the report." NOT for starting a run (okstra-run), rollups/schedules (okstra-rollup / okstra-schedule-gen), a brief (okstra-brief-gen), setup (okstra-setup), or cross-project management (okstra-manager).
 ---
 
 # OKSTRA Inspect
 
-Single read-side entry point for okstra runtime inspection plus the one status mutation that belongs here (`workStatus`) and read-derived artifact rendering (`errors` report). Sub-commands:
+Single read-side entry point for okstra runtime inspection plus the one status mutation that belongs here (`workStatus`) and read-derived artifact rendering (`errors` report). Each sub-command's full procedure lives in a lazily loaded facet file — after dispatch, Read exactly the one facet you need.
 
-| Sub-command | What it does |
-|---|---|
-| `status` | Task / phase status, blockers, approval state. Also writes `workStatus` on user request. |
-| `history` | List past okstra runs; assemble re-run or resume command. |
-| `report` | Resolve final-report path for a task-key. Optionally read it. |
-| `time` | Per-task-type and per-worker duration breakdown for a task. |
-| `logs` | Inventory codex/antigravity wrapper `.log` sidecars; emit cleanup commands. |
-| `cost` | Estimate file/read context cost for a task bundle. |
-| `errors` | Aggregate okstra-run error logs for a task into a timestamped markdown report; print a summary. |
-| `error-zip` | Collect cross-project okstra error logs into an anonymized zip (report + raw) and summarize clusters. |
-| `recap` | Summarize a task's run-to-run phase transitions, then answer free-form questions over its `.okstra` artifacts. Appends each summary/Q&A to `recap/recap-log.jsonl`, and writes agent-authored notes to `notes/` for feeding into later runs. |
+| Sub-command | Facet file | What it does |
+|---|---|---|
+| `status` | `facets/status.md` | Task / phase status, blockers, approval state. Also writes `workStatus` on user request. |
+| `history` | `facets/history.md` | List past okstra runs; assemble re-run or resume command. |
+| `report` | `facets/report.md` | Resolve final-report path for a task-key. Optionally read it. |
+| `time` | `facets/time.md` | Per-task-type and per-worker duration breakdown for a task. |
+| `logs` | `facets/logs.md` | Inventory codex/antigravity wrapper `.log` sidecars; emit cleanup commands. |
+| `cost` | `facets/cost.md` | Estimate file/read context cost for a task bundle. |
+| `errors` | `facets/errors.md` | Aggregate okstra-run error logs for a task into a timestamped markdown report; print a summary. |
+| `error-zip` | `facets/error-zip.md` | Collect cross-project okstra error logs into an anonymized zip (report + raw) and summarize clusters. |
+| `recap` | `facets/recap.md` | Summarize a task's run-to-run phase transitions, then answer free-form questions over its `.okstra` artifacts. Appends each summary/Q&A to `recap/recap-log.jsonl`, and writes agent-authored notes to `notes/` for feeding into later runs. |
 
 ## Step 0: Preflight (shared)
 
-Before any sub-command, run one Bash tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — a non-literal leading token defeats the `Bash(okstra:*)` permission match):
+<!-- BEGIN FRAGMENT: bash-invocation-rule -->
+Run one Bash tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — a non-literal leading token defeats the `Bash(okstra:*)` permission match):
+<!-- END FRAGMENT: bash-invocation-rule -->
 
 ```bash
 okstra preflight --runtime claude-code --json
@@ -32,758 +34,48 @@ The project check only sees the cwd of the Bash call. When the user is asking ab
 
 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. 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).
-
-Carry the resolved `projectRoot` into the sub-commands: read file artifacts under `<projectRoot>/.okstra/...`, and for sub-command CLIs that accept it (e.g. `recap`, `context-cost`) pass `--cwd <projectRoot>` / `--project-root <projectRoot>` so they target the same project rather than the Bash cwd. Subsequent `okstra <subcmd>` calls self-bootstrap their Python path, so this skill never needs `okstra paths --shell` / `export PYTHONPATH=...`.
-
-## Step 1: Dispatch by intent
-
-Classify the user's request into one sub-command using the trigger table above. If ambiguous (e.g. "okstra 보여줘"), ask which facet — do not silently default. After routing, the chosen sub-command's section below governs the rest of the response.
-
-When you ask which facet, the option list is **authoritative**: enumerate every sub-command in the `Sub-command | What it does` table above as a numbered text list, in table order, each with its one-line description, and let the user pick by number or name. Never present a hand-picked subset — the AskUserQuestion 4-option cap is not a reason to drop facets; render the full menu as text in the question body so no facet (e.g. a newly added one) is ever hidden. The table is the single source of truth for this menu; adding a row there is all it takes for the facet to appear here.
-
-When the user chains multiple facets in one message (e.g. "status, and then time for DEV-9047"), execute them sequentially — Step 0 runs once, each sub-command section runs once.
-
----
-
-## status
-
-Trigger phrases: "okstra status", "task status", "current phase", "next phase", "what is pending", "resume point", "okstra status set", "okstra mark", "<task-id> done", "<task-id> in-progress", "<task-id> 진행중", "<task-id> 완료".
-
-### 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.
-
-| Field | Description |
-|------|------|
-| `taskKey` | `<project-id>:<task-group>:<task-id>` |
-| `taskType` | latest task type |
-| `workCategory` | bugfix / feature / improvement / refactor / ops / unknown. Display `unknown` as-is, but flag with `(unset)` annotation so the reader knows the requirements-discovery classification was skipped or no `--work-category` flag was passed. |
-| `currentStatus` | task-level status |
-| `currentPhase` | lifecycle current phase |
-| `currentPhaseState` | lifecycle phase state |
-| `nextRecommendedPhase` | next recommended phase |
-| `routingStatus` | routing decision status |
-| `awaitingApproval` | approval 대기 여부 |
-| `latestRunStatus` | latest run status |
-| `latestReportPath` | latest report path |
-| `latestResumeCommandPath` | latest resume command |
-| `workStatus` | user-managed work status (todo / in-progress / blocked / done; default in-progress) |
-| `updatedAt` | last update time |
-
-Sort by `updatedAt` desc, then `taskKey`.
-
-The overview table is intentionally narrow so it renders cleanly in a terminal. Only six columns are shown; for any task that needs a closer look (phase state, routing, approval gate, last run status, resume path, etc.) tell the user to run `/okstra-inspect status <task-key>` for the detail view in `status.2`.
-
-If `awaitingApproval` is true OR `routingStatus == "pending"`, append a `*` to the `Next` cell and explain the marker once below the table.
-
-```markdown
-## okstra Status — <project-id>
-
-| # | Task Key | Category | Phase | workStatus | Next |
-|---|----------|----------|-------|------------|------|
-| 1 | proj:group:id | bugfix | error-analysis | in-progress | implementation-planning |
-| 2 | proj:group:id2 | feature | requirements-discovery | done | pending-routing-decision* |
-
-`*` = awaiting user approval or pending routing decision. Run `/okstra-inspect status <task-key>` for details.
-```
-
-### status.2 — Specific task status
-
-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.
-
-Required fields: `taskKey`, `taskType`, `workCategory`, `currentStatus`, `latestRunStatus`, `workflow.{currentPhase, currentPhaseState, phaseStates, lastCompletedPhase, nextRecommendedPhase, awaitingApproval, routingStatus, lastSafeCheckpoint}`, `workStatus`, `workStatusUpdatedAt`, `workStatusNote`, `latestReportPath`, `latestResumeCommandPath`, `historyTimelinePath`.
-
-```markdown
-## okstra Task Status — <task-key>
-
-- Work category: `<category>`
-- Current phase: `<phase>`
-- Current phase state: `<phase-state>`
-- Last completed phase: `<phase-or-->`
-- Next recommended phase: `<phase>`
-- Awaiting approval: `<yes|no>`
-- Routing status: `<routing-status>`
-- Task status: `<task-status>`
-- Latest run status: `<run-status>`
-- Latest report: `<relative-path-or-->`
-- Resume command: `<relative-path-or-->`
-- workStatus: `<todo|in-progress|blocked|done>` (updated `<workStatusUpdatedAt-or-->`)
-- workStatus note: `<workStatusNote-or-->`
-
-### Phase States
-
-- `requirements-discovery`: `<state>`
-- `error-analysis`: `<state>`
-- `implementation-planning`: `<state>`
-- `implementation`: `<state>`
-- `final-verification`: `<state>`
-- `release-handoff`: `<state>`
-
-### Safe Resume Checkpoint
-
-- Label: `<checkpoint-label>`
-- Run manifest: `<relative-path-or-->`
-- Team state: `<relative-path-or-->`
-- Report: `<relative-path-or-->`
-- Resume command: `<relative-path-or-->`
-```
-
-### status.3 — Resume / next-step guidance
-
-The status response always includes one of:
+- `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.
 
-1. **Resume current run** — if `latestResumeCommandPath` exists, display that path.
-2. **Restart current phase** — task can be re-run with the same `task-key` and current `taskType`.
-3. **Start next phase** — if `workflow.nextRecommendedPhase` is one of `error-analysis`, `implementation-planning`, `implementation`, `final-verification`, `release-handoff`, that phase is proposed. If `nextRecommendedPhase` is `pending-release-handoff`, surface as verdict-gated and propose `release-handoff` only when the cited verdict is `accepted`.
-4. **Need more information** — if `nextRecommendedPhase` is `pending-routing-decision` or `routingStatus` is `pending`.
-5. **Task complete (terminal)** — if `nextRecommendedPhase` is `done-or-follow-up`, the task lifecycle has reached its terminal signal. This is **not** a "next phase" — do not propose a new okstra run. Surface the latest report and ask the user whether any follow-up task should be opened separately.
+<!-- 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).
+<!-- END FRAGMENT: preflight-outdated-cli -->
 
-### status.4 — Update workStatus (write)
+Carry the resolved `projectRoot` into the sub-commands: read file artifacts under `<projectRoot>/.okstra/...`, and for sub-command CLIs that accept it (e.g. `recap`, `context-cost`) pass `--cwd <projectRoot>` / `--project-root <projectRoot>` so they target the same project rather than the Bash cwd.
 
-Recognize requests to change a task's `workStatus` and update the corresponding `task-manifest.json`.
+<!-- BEGIN FRAGMENT: python-bootstrap-note -->
+Every subsequent `okstra <subcmd>` call self-bootstraps its Python path, so this skill never needs `okstra paths --shell` / `export PYTHONPATH=...`.
+<!-- END FRAGMENT: python-bootstrap-note -->
 
-**Trigger patterns** (recognize both):
-
-Natural language: "DEV-6827 done으로 바꿔줘", "PROD-1623을 blocked로 표시", "DEV-9047 진행중", "Mark DEV-6827 as done".
-
-Explicit phrasing (recognized user utterances — normalize each to a `okstra set-work-status` call below):
-- `okstra status set <task-id> <status>`
-- `okstra status set <task-group> <task-id> <status>` (disambiguation)
-- `okstra mark <task-id> <status>`
-- `okstra status set <task-id> <status> --note "<note>"`
-
-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
-```
-
-- `<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>를 찾을 수 없습니다.` An invalid `<status>` makes the CLI exit 2 with the allowed-values list — surface it verbatim; nothing was modified.
-
-Confirm in Korean:
-```
-✓ <TASK-ID> workStatus: <previousWorkStatus> → <workStatus>
-✓ task-manifest.json 업데이트됨
-```
-`<previousWorkStatus>` = `(없음)` when the JSON's `previousWorkStatus` is empty.
-
-**Default value convention:** if `workStatus` is missing or empty, infer the display value from lifecycle state (DO NOT default to a static `in-progress`):
-
-| Manifest state | Inferred display |
-|---|---|
-| `currentStatus == "completed"` AND `workflow.nextRecommendedPhase == "done-or-follow-up"` | `done` (inferred) |
-| `currentStatus == "completed"` AND `workflow.currentPhaseState == "completed"` | `phase-done` (inferred) |
-| `currentStatus == "contract-violated"` OR `workflow.currentPhaseState == "blocked"` | `blocked` (inferred) |
-| anything else | `in-progress` (default) |
-
-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.
-
----
-
-## history
-
-Trigger phrases: "okstra history", "past runs", "run history", "re-run", "list tasks", "다시 실행", "resume", "이어서".
-
-**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
-
-1. Read `.okstra/discovery/task-catalog.json`.
-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`, `latestReportPath`, `latestResumeCommandPath`, `historyTimelinePath`.
-
-```markdown
-## okstra Task History — <project-id>
-
-| # | Task Key | Type | currentStatus | latestRunStatus | Last Run | Report |
-|---|----------|------|---------------|------------------|----------|--------|
-| 1 | proj:group:id | error-analysis | completed | completed | 2026-04-05 22:59 | .project-docs/.../final-report-*.md |
-| 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.`
-
-### 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`.
-
-```markdown
-## Runs for <task-key>
-
-| # | Timestamp | Type | Status | Report |
-|---|-----------|------|--------|--------|
-| 1 | 2026-04-05 22:59 | error-analysis | completed | .../final-report-*.md |
-| 2 | 2026-04-04 15:30 | error-analysis | error | -- |
-```
-
-### history.3 — Re-run (NEW run from old parameters)
-
-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:
-   - `projectId` → `--project-id`
-   - `taskGroup` → `--task-group`
-   - `taskId` → `--task-id`
-   - `taskType` → `--task-type`
-   - `taskBriefPath` → `--task-brief`
-3. Optional arguments (include only when present in source):
-   - `recommendedWorkers` → `--workers` (comma-separated)
-   - `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.
-5. Display the assembled command:
-   ```bash
-   ~/.okstra/bin/okstra.sh \
-     --project-id <project-id> \
-     --task-group <task-group> \
-     --task-id <task-id> \
-     --task-type <task-type> \
-     --task-brief <brief-path> \
-     --workers <worker-list>
-   ```
-6. Once the user confirms, execute it.
-
-### history.4 — Resume (continue an interrupted run)
-
-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).
-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.`
-
----
-
-## report
-
-Trigger phrases: "find report", "show report for", "read the okstra report", "continue from report".
-
-### report.1 — Resolve report path
-
-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. `latestReportPath` 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>/<id-segment>/task-manifest.json`, use `latestReportPath` (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):** `latestReportPath` 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>.md` per `scripts/okstra_ctl/sequence.py:30`. 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.
-
-### report.2 — Confirm existence
-
-1. Verify `latestReportPath` 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:
-   - `latestReportPath` empty/missing AND `currentStatus != completed` AND `workStatus != done` AND `workflow.routingStatus` not completion-like → `이 task는 아직 완료되지 않았습니다 (currentStatus: <currentStatus>, workStatus: <workStatus>).`
-   - Any signal indicates completion but the file is missing → `보고서 파일이 존재하지 않습니다: <path>`
-
-`workStatus` enum: `todo | in-progress | blocked | done`. `currentStatus`: `completed` / `contract-violated` etc. `"completed"` string does NOT exist in `workStatus` — do not confuse the two.
-
-### report.3 — Read + next-step guidance
-
-Match the depth of read to the request — final reports routinely run 300+ lines / 50K+ tokens, so ingesting the whole file just to answer "핵심만 요약" is wasteful:
-
-- **Summary / verdict intent** ("요약", "핵심만", "결론", "통과했어?", "verdict"): do **not** read the whole report first. Read the `final-<task-type-segment>-<NNN>.status` sidecar under `runs/<task-type-segment>/status/` (stage-isolated: `runs/<task-type-segment>/stage-<N>/status/`) for the machine verdict, then read only the report's leading summary block (the first "종합 판정" / "Executive" / verdict heading and its body) to quote the gist. Offer to read the full report if the user wants detail.
-- **Full-read intent** ("전체", "다 읽어", "본문"): ingest the resolved report file.
-
-After reading, surface follow-up options:
-
-1. **구현 진행:** based on the report's "권장 다음 단계" section.
-2. **추가 검증:** to launch a new okstra run with the same task-key, assemble the command through the `history` sub-command — it offers the full option set (base-ref, workers, render-only) and renders a host-correct invocation.
-3. **관련 task 확인:** if the report references related task-keys, fetch their reports too.
-
-### report — Output template
-
-```markdown
-## Report for <task-key>
-
-| Field        | Value                                              |
-| ------------ | -------------------------------------------------- |
-| Status       | `<status>`                                         |
-| Task type    | `<task-type>`                                      |
-| Run seq      | `<NNN>`                                            |
-| Run date     | `<runTimestamp ISO-8601>`                          |
-| Report (rel) | `<relative-path-from-project-root>`                |
-| Report (abs) | `<absolute-path>`                                  |
-```
-
----
-
-## time
-
-Trigger phrases: "작업 시간", "소요 시간", "time summary", "duration", "elapsed", "얼마나 걸렸", "시간 분석".
-
-Aggregate elapsed work time for a task, grouped by **task type** and broken down by **worker** (lead + each worker). The `time-report` CLI reads both data sources (`history/timeline.json` runs + each run's `team-state-*.json` usage blocks) and does **all** aggregation — cross-run sums, CPU-sum vs wall-clock, timestamp parsing, unavailable detection. You only resolve the task-key, call it, and render. **Never recompute durations by hand.**
-
-### time.1 — Resolve the task-key
-
-Same standard as `cost.1`: full task-key → use directly; bare token (task-id or task-group) → `okstra resolve-task-key <token> --project-root <projectRoot> --json` and branch on `matches[]` (0 = not found, 1 = use, N = 3-option picker). If no okstra history exists, say `No okstra history found. Run /okstra-run first.`
-
-### time.2 — Fetch aggregated data
-
-```bash
-okstra time-report <task-key> --project-root <projectRoot> --json
-```
-
-Returns (all durations are **raw milliseconds**):
-- `byTaskType[]` — `{taskType, runs, leadMs, workersMs, cpuSumMs}`, plus `grandTotal`
-- `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}]}`
-- `unavailable[]` — `{runTimestamp, taskType, reason}` for runs with no Phase-7 durations (never summed into totals)
-
-### time.3 — Render
-
-Convert every `*Ms` to `HH:MM:SS` (zero-pad; never show raw ms). Task types in `byTaskType` are already in chronological (first-appearance) order.
-
-- **By task type** — `| Task type | Runs | CPU sum | Lead | Workers |` from `byTaskType`, plus a `grandTotal` row. `CPU sum` (= Lead + Workers) overlaps because workers run inside the lead's window — it is *not* wall-clock. Surface wall-clock only when the user explicitly asks, from `perRunWallClock`.
-- **Per worker** (per task type) — `| Worker | Runs | Total | Avg/run |` from `perWorker`. Render the worker as bare `workerId` when `agents` is empty, else `workerId (agent1, agent2)`.
-- **Phase breakdown** — "단계별"/"stage별"/"어느 단계가 오래" in okstra most often means the **lifecycle stage (task-type)** view, which the *By task type* table above already answers — lead with that table, do not treat the request as unanswerable. Render the intra-run phase timeline only when the user clearly means within-a-run phases ("어느 phase가", "Phase 1~7", "phase timeline"): one table per run from `phaseTimelines`: `| Phase | Start | Wall to next |` using `firstAt`/`wallMsToNext` (`null` → `--`). When `phaseTimelines` is empty, do **not** headline "측정 불가" — the By-task-type table is the stage answer; mention the missing intra-run markers only as a trailing footnote.
-- If `unavailable[]` is non-empty, append a trailing note listing each run with its reason. Never fold them into totals.
-- Show the resolved `<task-key>` in the heading.
-
-```markdown
-## Time summary — <task-key>
-
-### By task type
-
-| Task type              | Runs | CPU sum   | Lead     | Workers  |
-|------------------------|------|-----------|----------|----------|
-| requirements-discovery | 2    | 00:33:12  | 00:12:08 | 00:21:04 |
-| **Grand total**        | 6    | **03:03:06** | 01:05:49 | 01:57:17 |
-
-### Per worker — requirements-discovery
-
-| Worker               | Runs | Total    | Avg/run  |
-|----------------------|------|----------|----------|
-| lead                 | 2    | 00:12:08 | 00:06:04 |
-| claude (sonnet-eval) | 2    | 00:09:12 | 00:04:36 |
-
-> Unavailable: 1 run (implementation / 2026-04-30_03-03-48) — Phase 7 not reached
-```
-
----
-
-## cost
-
-Trigger phrases: "okstra context-cost", "context cost", "context-cost", "컨텍스트 비용", "읽기 비용", "산출물 비용", "task bundle cost", "agent read cost".
-
-Read-only estimate of how much file/context surface a prepared task bundle asks the lead, analysis workers, and report-writer to absorb. This sub-command does **not** mutate task artifacts.
-
-### cost.1 — Resolve target
+## Step 1: Dispatch by intent
 
-Accepted target forms:
+Classify the user's request into one sub-command using the trigger table above. If ambiguous (e.g. "show me okstra"), ask which facet — do not silently default. After routing, **Read the chosen row's facet file** (path relative to this skill's base directory) and follow it for the rest of the response. Load exactly one facet per sub-command — never preload the others.
 
-1. Full task-key: `<project-id>:<task-group>:<task-id>`.
-2. Bare token — a task-id (e.g. `DEV-9184`) **or** a task-group (e.g. `PROD`).
-3. Task root path, e.g. `<projectRoot>/.okstra/tasks/<group>/<task-id>`.
+When you ask which facet, the option list is **authoritative**: enumerate every sub-command in the dispatch table above as a numbered text list, in table order, each with its one-line description, and let the user pick by number or name. Never present a hand-picked subset — the AskUserQuestion 4-option cap is not a reason to drop facets; render the full menu as text in the question body so no facet (e.g. a newly added one) is ever hidden. The table is the single source of truth for this menu; adding a row there (plus its facet file) is all it takes for the facet to appear here.
 
-If the user gives a task root path, run `okstra context-cost <absolute-or-user-provided-path>` directly.
+When the user chains multiple facets in one message (e.g. "status, and then time for DEV-9047"), execute them sequentially — Step 0 runs once, then load and run each facet in turn.
 
-If the user gives a full task-key, run:
+## Shared rules (referenced by facets)
 
-```bash
-okstra context-cost <task-key> --project-root <projectRoot>
-```
+### Standard task-key resolution (0/1/N)
 
-If the user gives a bare token, 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 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"`):
 
 ```bash
 okstra resolve-task-key <token> --project-root <projectRoot> --json
 ```
 
-Branch on the stdout JSON `matches[]` — this **standard 0/1/N rule** is referenced by `errors`/`recap` below:
-- **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 추천 + `직접 입력`), then use the chosen `taskKey`.
+Branch on the stdout JSON `matches[]`:
+- **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`.
 
-If the user asks generally ("컨텍스트 비용 보여줘") and does not name a task:
+### No-task fallback
+
+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.
-3. If multiple tasks exist, show the latest 10 by `updatedAt` and ask which task to measure. Do not guess.
-
-### cost.2 — Run estimator
-
-Use the CLI output as the source of truth:
-
-```bash
-okstra context-cost <resolved-target> --project-root <projectRoot>
-```
-
-Do not re-count files manually unless the CLI fails and the user explicitly asks for manual fallback.
-
-### cost.3 — Render
-
-Render the CLI JSON into the cost.4 template. Each row's Files / Size / ~Tokens come from the matching output block — `totals` (Task bundle, Current run, Legacy timestamp), `instructionSet`, `leadPhase1`, `analysisWorker`, `reportWriter`, `skillAssets`; their exact field names are in the CLI output (do not re-list them here). Format bytes as raw + rounded KB/MB.
-
-Field-specific notes (these affect interpretation, not just display):
-- Analysis worker uses per-worker fields (`bytesPerWorker`, `estimatedTokensPerWorker`). Use `analysisWorker.estimatedReductionPercent` directly for the worker-input reduction — do **not** recompute it from `bytesPerWorker` when `mode == "analysis-packet-primary"` (that value is already the packet-primary cost).
-- `estimatedTokens*` are a static ranking heuristic (~4 ASCII chars/token, non-ASCII ≈ 1 token/char), never billing numbers — actual cost is the token-usage collector's domain.
-- `skillAssets` = the per-run hot-path instruction assets loaded OUTSIDE the task bundle (skill bodies + agent specs), sorted by size — the prompt-diet target.
-
-### cost.4 — Output template
-
-```markdown
-## okstra Context Cost — <task-key>
-
-| Surface | Files | Size | ~Tokens |
-|---|---:|---:|---:|
-| Task bundle | <N> | <bytes> (<human>) | - |
-| Current run | <N> | <bytes> (<human>) | - |
-| Instruction set | <N> | <bytes> (<human>) | <estimatedTokens> |
-| Lead Phase 1 (`<mode>`) | <N> | <bytes> (<human>) | <estimatedTokens> |
-| Analysis worker / worker (`<mode>`) | <N> | <bytes> (<human>) | <estimatedTokensPerWorker> |
-| Report writer synthesis | <N> | <bytes> (<human>) | <estimatedTokens> |
-| Skill assets (hot path) | <N> | <bytes> (<human>) | <estimatedTokens> |
-
-- Current run: `<currentRunPath-or-->`
-- Legacy timestamp artifacts: `<N>`
-- Legacy full worker contract: `<legacyFullContractBytesPerWorker>` bytes (`<human>`) per analysis worker
-- Packet estimate: `<estimatedPacketModeBytesPerWorker>` bytes (`<human>`) per analysis worker
-- Estimated worker-input reduction: `<percent>%`
-
-### Reading
-
-<One or two Korean sentences explaining the main bottleneck and the next likely optimization target.>
-```
-
-Interpretation rules:
-
-- `leadPhase1.mode == "active-run-context"` means the compact lead intake file is present and should be treated as the primary lead read surface.
-- `leadPhase1.mode == "legacy-five-file"` means this task was prepared before active-run-context, or the manifest does not reference it.
-- `analysisWorker.mode == "analysis-packet-primary"` means new workers should read `analysis-packet.md` first and open full source inputs only for evidence checks or missing detail.
-- If `analysisWorker.mode == "full-input-contract"` and `estimatedReductionPercent` is low, the next target is worker prompt/input contract slimming.
-- If `reportWriter.bytes` dominates, the next target is a compact `synthesis-input` artifact.
-- If `skillAssets.estimatedTokens` dominates the per-run fixed cost, the next target is slimming the largest `skillAssets.files[]` entries (prompt diet — perf plan v2 P2), e.g. thin-core + lazy-sidecar split.
-- If `legacyTimestampFileCount` is high, recommend current-view/cold-artifact separation or retention cleanup, not destructive deletion by default.
-
----
-
-## logs
-
-Trigger phrases: "okstra logs", "로그 현황", "로그 파일", "log files", "log size", "log status", "로그 정리", "log cleanup".
-
-Read-only inventory of codex/antigravity wrapper log files written next to each prompt history file (`<prompt>.log`). Reports sizes, ages, totals, and suggests cleanup commands. **Does not delete** — the user runs whichever `find … -delete` line they like.
-
-**Background:** codex/antigravity wrappers (`okstra-codex-exec.sh`, `okstra-antigravity-exec.sh`) write a sidecar log next to each prompt history file:
-
-```
-.okstra/tasks/<task-group>/<task-id>/runs/<phase>/prompts/
-  <worker>-worker-prompt-<phase>-<seq>.md    <-- prompt (git-tracked)
-  <worker>-worker-prompt-<phase>-<seq>.log   <-- live stdout+stderr mirror
-```
-
-The log is truncated at each dispatch (`: > "$log_path"`) — only the latest run for a given seq is preserved. Different seqs keep separate files. Long-running implementation dispatches can produce multi-MB logs; analysis-phase dispatches are typically smaller.
-
-### logs.1 — Inventory
-
-```bash
-okstra log-report --project-root <projectRoot> --json
-```
-
-Scans `<projectRoot>/.okstra/tasks/**/runs/*/prompts/*.log` and parses task/phase/worker/seq from each path. Returns (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}`
-
-If `totals.fileCount` is 0, report `No wrapper log files found under <projectRoot>` and stop.
-
-### logs.2 — Summary tables
-
-Render from the CLI output (format bytes → KB/MB; epoch → `Nd`/`Nh` relative to now):
-
-**Table A — Top largest logs** (from `topLargest`): `| # | Task | Phase | Worker | Seq | Size | Age | Path |`.
-
-**Table B — Per-task totals** (from `perTask`): `| Task Key | Files | Total Size | Oldest | Newest |`.
-
-**Footer:** `Total: <fileCount> files, <totalBytes→MB> across <taskCount> tasks under <PROJECT_ROOT>`.
-
-### logs.3 — Suggested cleanup commands
-
-Emit a fenced bash block the user can copy-paste. Do NOT execute. Each block pairs a dry-run preview (`-print`) with the destructive (`-delete`) command:
-
-```markdown
-## Cleanup options (manual)
-
-# 7일 이상 된 로그만 삭제
-find <PROJECT_ROOT>/.okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -mtime +7 -print    # dry-run
-find <PROJECT_ROOT>/.okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -mtime +7 -delete
-
-# 30일 이상 된 로그만 삭제
-find <PROJECT_ROOT>/.okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -mtime +30 -print   # dry-run
-find <PROJECT_ROOT>/.okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -mtime +30 -delete
-
-# 특정 task-group 의 로그 일괄 삭제 (예: dev-9388)
-find <PROJECT_ROOT>/.okstra/tasks/dev-9388 \
-  -type f -name '*.log' -print    # dry-run
-find <PROJECT_ROOT>/.okstra/tasks/dev-9388 \
-  -type f -name '*.log' -delete
-
-# 특정 task-id 의 로그 일괄 삭제 (예: dev-9428)
-find <PROJECT_ROOT>/.okstra/tasks/*/dev-9428 \
-  -type f -name '*.log' -print    # dry-run
-find <PROJECT_ROOT>/.okstra/tasks/*/dev-9428 \
-  -type f -name '*.log' -delete
-
-# 전체 일괄 삭제 (주의)
-find <PROJECT_ROOT>/.okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -print    # dry-run
-find <PROJECT_ROOT>/.okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -delete
-```
-
-Substitute the literal `<PROJECT_ROOT>` with the resolved absolute path so the commands are directly copy-pasteable.
-
-### logs.4 — Notes for the user
-
-- Logs are truncated on each re-dispatch of the same `seq`, so deleting an in-flight run's log will cause the wrapper to recreate an empty file on the next dispatch — no data loss beyond the current trace.
-- **If a dispatch is currently running, check the `status` sub-command first** and avoid deleting logs for tasks in `in-progress` state — you will lose the live trace for the active run.
-- Prompt history files (`.md`) are separate and are NOT touched by these commands — only `.log` sidecars.
-- This sub-command **does not modify any external files itself**, including `.gitignore`. If the project commits `.okstra/`, the user may want to add `.okstra/tasks/**/runs/**/prompts/*.log` to `.gitignore` manually to keep large logs out of git.
-
----
-
-## errors
-
-Trigger phrases: "okstra errors", "error report", "에러 리포트", "에러 보고", "에러 모아줘", "실패 로그 정리".
-
-Aggregate a task's okstra-run error logs (`runs/*/logs/errors-*.jsonl`, lead-observed + worker-reported) into a timestamped markdown report and summarize it. This sub-command renders a **read-derived artifact** (a `.md` file) but never mutates task state (`task-manifest.json`, catalog, timeline).
-
-### errors.1 — Resolve target
-
-Accepted target forms (same as `cost`):
-
-1. Full task-key: `<project-id>:<task-group>:<task-id>`.
-2. Bare token (task-id or task-group) — resolve via `okstra resolve-task-key <token> --project-root <projectRoot> --json` and branch on `matches[]` using the standard 0/1/N rule from `cost.1` (0 = not found, 1 = use, N = picker).
-3. Task root path.
-
-사용자가 task 를 지정하지 않고 그냥 에러 리포트를 요청하면, `cost.1` 과 동일한 no-task fallback 을 적용한다 — 플레이스홀더 형식만 나열하고 되묻지 않는다: `.okstra/discovery/task-catalog.json` 을 읽어 task 가 1개면 그대로 사용하고, 여러 개면 `updatedAt` 최신 10개를 실제 task-key 로 나열해 물어본다(추측 금지).
-
-### errors.2 — Run the renderer
-
-Use the CLI output as the source of truth:
-
-```bash
-okstra error-report <resolved-target> --project-root <projectRoot>
-```
-
-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:
-
-| Field | Source |
-|---|---|
-| Report file | `reportPath` (project-root-relative `.md`) |
-| Total errors | `totals.errorCount` |
-| Logs (runs) | `totals.runCount` |
-| By errorType | `totals.byErrorType` (tool-failure / cli-failure / contract-violation) |
-| By source | `totals.bySource` (lead-observed / worker-reported) |
-| By phase | `byPhase[]` |
-| By agent | `byAgent[]` |
-| Parse-skipped lines | `parseSkipped` |
-
-- If `reportPath` is empty AND `totals.errorCount == 0`: report `이 task 에는 기록된 에러 로그가 없습니다.` and do not claim a file was written.
-- Otherwise show the `.md` path and offer to read it.
-- If `parseSkipped > 0`, surface it (do not silently hide malformed lines).
-
-### errors — Output template
-
-```markdown
-## okstra Error Report — <task-key>
-
-- Report: `<reportPath-or-->`
-- Total errors: <N> across <runCount> log(s)
-- By type: <tool-failure: a, cli-failure: b, ...>
-- By source: <lead-observed: x, worker-reported: y>
-
-| Phase | Count |
-|---|---:|
-| implementation | 3 |
-
-| Agent | Count |
-|---|---:|
-| codex-worker | 2 |
-
-<If parseSkipped > 0: "⚠ 파싱 건너뛴 줄: <N>">
-```
-
----
-
-## error-zip
-
-Trigger phrases: "okstra error-zip", "에러 zip", "에러 환류", "에러 번들", "cross-project 에러".
-
-머신 내 모든 타겟 프로젝트의 okstra 실행 에러(`runs/*/logs/errors-*.jsonl`)를 글로벌 run-index 로 수집·익명화해 `.zip`(집계 리포트 + 익명화 JSONL)으로 묶는다. 모든 타겟의 `.okstra/` 에 대해 read-only.
-
-### error-zip.1 — 출력 경로 결정 (picker)
-
-이전 출력 경로를 `~/.okstra/error-zip.json` 의 `lastOutputPath` 에서 읽는다. 그 값이 있으면 3-옵션 picker 로 제시:
-
-1. (이전 경로 있음) `<lastOutputPath>` 재사용 — 추천, 첫 옵션.
-   (이전 경로 없음) 기본 경로 `~/okstra-error-feedback-<YYYY-MM-DD>.zip` 제안 — 추천.
-2. 직접 입력 (항상 마지막 옵션).
-
-`~/.okstra/error-zip.json` 읽기는 Read 로 직접 수행한다(없으면 이전 경로 없음으로 간주).
-
-### error-zip.2 — 렌더 실행
-
-```bash
-okstra error-zip --out <결정된 경로>
-```
-
-### error-zip.3 — 요약 보고
-
-stdout JSON 을 파싱해 보고:
-
-| 필드 | 출처 |
-|---|---|
-| 출력 zip | `outPath` |
-| 총 에러 | `errorCount` |
-| 로그(run) | `runCount` |
-| 도달 불가 run | `unreachableRuns` |
-| 클러스터 수 | `clusterCount` |
-| 프로젝트 수 | `projectCount` |
-
-- `unreachableRuns > 0` 이면 표면화한다(침묵 누락 금지).
-- 끝에 다음 단계를 안내한다: "이 zip 으로 okstra 자신을 고치려면 `/okstra-brief-gen` 의 error-feedback variant 로 brief 를 만든 뒤 `okstra-run --task-type error-analysis` 를 okstra 레포에서 실행하세요."
-
----
-
-## recap
-
-Trigger phrases: "okstra recap", "recap", "작업 요약", "이 task 요약", "전후 요약", "이 작업 설명해줘", "task 질문".
-
-task-id 하나에 쌓인 `.okstra` 산출물 위에서 (a) 처리 전/후 요약을 내고, (b) 그 작업에 대한 자유 질문에 답한다. 기본은 `.okstra/` 서브트리만 읽는다(artifact 모드). 사용자가 명시적으로 코드 변경까지 봐 달라고 요청할 때만 code 모드로 확장한다. 이 sub-command 는 `recap/recap-log.jsonl` append 와 `notes/` 노트 작성(recap.5)만 수행하고 `task-manifest.json` / catalog / timeline 은 절대 mutate 하지 않는다.
-
-### recap.1 — Resolve target
-
-`cost` / `errors` 와 동일한 3형식: ① full task-key, ② bare token(task-id 또는 task-group → `okstra resolve-task-key <token> --project-root <projectRoot> --json`; `cost.1` 의 표준 0/1/N 분기), ③ task-root path.
-
-사용자가 task 를 지정하지 않고 그냥 recap 을 요청하면(예: "이 작업 요약해줘"), `cost.1` 과 동일한 no-task fallback 을 적용한다 — 절대 `<task-group>` 같은 플레이스홀더 형식만 나열하고 되묻지 않는다:
-
-1. `.okstra/discovery/task-catalog.json` 을 읽는다.
-2. task 가 정확히 1개면 그 task 를 그대로 사용한다.
-3. 여러 개면 `updatedAt` 최신 10개를 실제 task-key 로 나열하고 어느 task 인지 물어본다(추측 금지).
-
-### recap.2 — Assemble the before/after summary
-
-CLI 출력을 source of truth 로 쓴다:
-
-```bash
-okstra recap assemble <resolved-target> --project-root <projectRoot>
-```
-
-stdout JSON(`{taskKey, runCount, transitions[], latestPhaseStates}`)을 파싱해 run 단위 전/후 전이를 서술한다. 각 `transitions[]` 항목의 `fromPhase → toPhase`(직전 run currentPhase → 이번 run currentPhase), `status`, `lastCompletedPhase`, `nextRecommendedPhase`, `reportPath` 를 시간순으로 보여준다. `runCount == 0` 이면 "이 task 에는 기록된 run 이 없습니다." 라고만 답하고 파일을 읽었다고 주장하지 않는다.
-
-`reportPath` 가 있는 run 은 사용자가 더 깊은 요약을 원할 때만 해당 final-report 를 읽어 보강한다(자동으로 모두 읽지 않는다).
-
-### recap.3 — Free-form Q&A loop
-
-요약 출력 뒤 사용자의 임의 질문을 받는다.
-
-- **artifact 모드(기본)**: `.okstra/` 산출물(timeline, task-manifest, 해당 run 의 final-report)만 근거로 답한다. 모든 사실 주장은 `.okstra` 파일 `path:line` 인용을 동반한다.
-- **code 모드(opt-in)**: 사용자가 "코드 변경까지 / diff 까지 봐줘" 류로 **명시적으로 요청**할 때만, 해당 task 의 worktree/브랜치에서 `git diff` · `git log` 를 추가로 읽어 코드 레벨로 답한다. recap 진입만으로는 절대 code 모드로 넘어가지 않는다.
-
-### recap.4 — Persist each turn
-
-요약 1건과 각 Q&A 답변을 로그에 남긴다(append-only):
-
-```bash
-okstra recap record <resolved-target> --project-root <projectRoot> \
-  --kind <summary|qa> --mode <artifact|code> \
-  --question "<질문 또는 생략>" --answer "<한두 줄 요약>" \
-  --citation "<path:line>" --citation "<path:line>"
-```
-
-`--answer` 에는 전체 답변 전사가 아니라 한두 줄 요약을 넣는다. 인용이 여러 개면 `--citation` 을 반복한다. 기록 실패(비정상 종료)는 조용히 넘기지 말고 사용자에게 알린다.
-
-### recap — Output template
-
-```markdown
-## okstra Recap — <task-key>
-
-전/후 요약 (runs: <N>):
-
-| # | when | task-type | from → to | status | next |
-|---|---|---|---|---|---|
-| 1 | <ts> | requirements-discovery | (시작) → requirements-discovery | done | error-analysis |
-
-<이후 자유 질문을 받습니다. 코드 변경까지 보려면 "diff 까지 봐줘" 라고 요청하세요.>
-```
-
-### recap.5 — Agent 저작 노트 (`notes/`)
-
-recap 중에 네가 **okstra task 를 위해** 만든 산출물 — 검증 증거, 설계·decision 초안, 분석 노트 — 이 앞으로의 run 에 근거로 쓰일 수 있고, 그 내용이 **렌더된 report 도 아니고 사용자 결정도 아닐 때**만 `notes/` 에 남긴다.
-
-**소유권으로 라우팅한다.** 지금 쓰려는 것이 아래 어디에 해당하는지 먼저 판별한다:
-
-| 내용 | 레인(경로) | 저작 주체 |
-|---|---|---|
-| final report 본문 | `runs/<type>/reports/*.md` (`*.data.json` 에서 렌더) | okstra 렌더러 — 절대 수기 편집 금지 |
-| clarification 에 대한 사용자 답변 | `runs/<type>/user-responses/*.md` (`created-by: user`) | 사용자만 |
-| 확정된 ADR | `.okstra/decisions/NNNN-*.md` | 승격·관리됨 |
-| **Agent 증거 / 설계 초안 / 분석** | **`.okstra/tasks/<group>/<id>/notes/`** | 너(AI) |
-
-렌더 산출물도, 사용자 결정도 아닌 **너 자신의 근거·초안**이면 `notes/` 로 간다. 노트는 손으로 찍지 말고 CLI 로 쓴다 — 경로·frontmatter·날짜를 코드가 보장하고, 다음 run 에 넘길 인자를 출력해 준다:
-
-```bash
-okstra recap note <resolved-target> --project-root <projectRoot> \
-  --kind <verification-evidence|decision-draft|analysis-note> \
-  --slug <short-topic-slug> \
-  --purpose "<한 줄 — 무엇이며 어느 run/decision 에 투입되는지>" \
-  --scope-note "<한 줄 — 무엇이 아닌지, 예: C-00x 에 대한 사용자 결정이 아님>" \
-  --body-file <노트 본문 마크다운 경로>
-```
-
-본문은 먼저 scratchpad 에 마크다운으로 쓴 뒤 `--body-file` 로 넘긴다(짧으면 `--body "<md>"` 인라인도 가능). CLI 는 `.okstra/tasks/<group>/<id>/notes/<slug>-<YYYY-MM-DD>.md` 를 생성하고 stdout JSON 으로 `notePath` 와 `clarificationResponseArg` 를 돌려준다.
-
-**self-check 규칙 (validator 가 없으니 스스로 지킨다):**
-
-1. **렌더된 report 를 수기 편집하지 않는다** (`runs/*/reports/` 아래 `*.md` / `*.data.json` / `*.html`). `data.json` 에서 재생성되므로 편집은 덮어써지고 SSOT 와 어긋난다. 발견 내용은 `notes/` 에 쓴다.
-2. **`user-responses/` 파일을 작성하거나 `created-by: user` 를 달지 않는다.** 그건 사용자의 결정이며, 대신 쓰면 사용자가 내리지 않은 결정을 위조하는 것이다. 네 증거가 특정 답을 뒷받침하면 `notes/` 에 그렇게 적고 결정은 사용자에게 맡긴다. 단, `okstra-user-response` 스킬의 에코백 확인 흐름은 예외다 — 그 흐름에서는 사용자가 세션에서 직접 결정을 내리고 CLI 는 전사 채널일 뿐이므로, `write` 로 `created-by: user` sidecar 를 기록하는 것이 정당하다. 이 예외는 사용자가 명시적으로 "맞음" 을 확인한 뒤에만, verbatim 입력에 대해서만 성립한다.
-3. **okstra 관리 디렉토리에 쓰지 않는다** (`runs/`, `instruction-set/`, `history/`, `recap/`, `.okstra/decisions/`). `notes/` 만이 agent 소유 레인이다. `recap/recap-log.jsonl` 은 예외적으로 쓰되 손으로 편집하지 말고 `okstra recap record` CLI 로만 남긴다.
-4. **`notes/` 는 okstra 에 inert 하다** — 어떤 run 도 자동으로 읽지 않는다. 작성 후 CLI 가 출력한 `clarificationResponseArg`(예: `--clarification-response <notePath>`)를 사용자에게 그대로 알려, 다음 run 을 그 인자와 함께 실행해야만 반영된다는 것을 전한다.
-
-**Guardrail:** `.okstra/` 는 gitignored 다 — `notes/` 는 로컬 scratch 로 취급하고 절대 `git add` 하지 않는다. 새 노트 생성은 되돌리기 쉬우니(파일 삭제), 생성물이나 사용자 소유 파일을 편집하는 것보다 항상 이쪽을 택한다.
-
----
+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)