---
title: OKSTRA Improvement Discovery Input - {{TASK_KEY}}
id: {{FM_ID}}
tags: {{FM_TAGS}}
status: ready-for-agent
aliases: {{FM_ALIASES}}
date: {{TASK_DATE}}
task-id: "{{TASK_ID}}"
task-group: "{{TASK_GROUP}}"
project-id: "{{PROJECT_ID}}"
taskType: "{{FM_TASK_TYPE}}"
---

# OKSTRA Improvement Discovery Input

## Identity

- Project ID:
- Task Group:
- Task ID:
- Related Tasks:
- Issue / Ticket:
  - If left empty, workers fall back to the `Task ID`.
- Task Type: `improvement-discovery`
- Requested Outcome:

## Scope (from brief frontmatter)

- scan-scope:
- out-of-scope:
- priority-lenses:
- candidate-cap (1..12, default 8):

## Context

- Why this scope is being scanned now:
- Recent change context (last N commits to scan-scope):
- Stakeholders or owners of the scope:

## Desired Outcome

- What kinds of improvements do you want surfaced?
- Anti-goals (improvements you do NOT want this run to propose):

## Constraints

- Untouchable areas:
- Compatibility / deadline constraints:
- Performance / regression budget (if applicable):

## Phase 1.5 — Lead Reflect-Back Grilling

This section is filled in by the lead during Phase 1.5 before worker dispatch.
Workers MUST read the resolved values from the log the lead points to via the
`**Phase 1.5 Grilling Log:** <abs-path>` dispatch-prompt anchor
(`runs/improvement-discovery/<seq>/state/phase-1.5-grilling.md`) rather than the unresolved brief.

- Reflect-back summary:
- Open questions (Q1..QN):
- Resolved scope:
- Resolved lenses:

## Improvement Candidates (workers populate this)

| Cand ID | Lens | Title | Scope | Severity | Effort | Consensus | Source workers | Recommended next-phase | Expected behavior after | Evidence |
|---------|------|-------|-------|----------|--------|-----------|----------------|------------------------|-------------------------|----------|

## Questions for Analysers

1. Within the resolved scope and priority lenses, what are the highest-impact improvement candidates?
2. Which candidates have full cross-worker consensus, and which are worker-unique?
3. For each candidate, what is the safest next phase (requirements-discovery / implementation-option-selection / error-analysis)?
4. Which candidates would you intentionally exclude despite being technically valid, and why?
5. Are there any signals that the scope itself is mis-defined (and should be re-narrowed before discovery proceeds)?

## Conversion Note

- Each candidate the user picks becomes a new okstra task. Suggested task-key: `<task-group>/imp-<Cand-ID>`.
- The candidate row's Recommended next-phase determines which `--task-type` to launch with.