# okstra-inspect facet — report

Loaded lazily by the dispatch table in `SKILL.md` (core). Shared rules — Step 0 preflight, the standard task-key resolution rule (0/1/N), the no-task fallback, and Output Rules — live in the core file and still apply here.

## 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.

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 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>`

`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 "just the gist" is wasteful:

- **Summary / verdict intent** ("summary", "just the key points", "conclusion", "did it pass?", "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 "Overall Verdict" / "Executive" / verdict heading and its body) to quote the gist. Offer to read the full report if the user wants detail.
- **Full-read intent** ("the whole thing", "read it all", "full body"): ingest the resolved report file.

After reading, surface follow-up options:

1. **Proceed to implementation:** based on the report's "Recommended Next Steps" section.
2. **Additional verification:** to launch a new okstra run with the same task-key, assemble the command through the `history` facet (load `facets/history.md`) — it offers the full option set (base-ref, workers, render-only) and renders a host-correct invocation.
3. **Check related tasks:** 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>`                                  |
```