---
title: OKSTRA Error Analysis 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 Error Analysis Input

## Identity

- Project ID:
- Task Group:
- Task ID:
- Related Tasks:
- Issue / Ticket:
  - If left empty, workers fall back to the `Task ID` (without a prefix, like `8852`). When a single run handles multiple tickets at once, separate them with commas (`TICKET-123, TICKET-456`). If neither can be identified, `unknown` is allowed.
- Task Type: `error-analysis`
- Requested Outcome:

## Symptom Summary

- What is the visible problem?
- Who is affected?
- Since when has it been happening?
- Is it always reproducible or intermittent?

## Expected vs Actual

- Expected behavior:
- Actual behavior:

## Reproduction Context

- Reproduction steps:
- Trigger conditions:
- Environment or account conditions:
- Cases that do not reproduce:

## Evidence

- Main issue document:
- Logs:
- Raw samples:
- Screenshots or reports:
- Related code paths:
- Previous reports in the same task history:

## Current Hypotheses

- Current root-cause guess:
- Why this guess exists:
- What evidence is still missing:
- Alternative explanations:

## Config and Deployment References

- Relevant config files:
- Relevant deployment manifests:
- Expected values or invariants that may be violated:
- Unknown values that still require confirmation:

## Risk Notes

- Risk if the guess is wrong:
- Risk of changing code too early:
- Rollback concerns:

## Out of Scope

- Adjacent symptoms or subsystems deliberately excluded from this analysis:
- Items that look related but must be analysed in a separate task:
- Reason for exclusion (different owner, separate root cause, deferred decision):

> Analysers MUST NOT expand the hypothesis space or evidence collection into items listed here. If an analyser believes an excluded item is causally linked to the symptom, it is reported as a recommended follow-up analysis task in the final report — never silently merged into the current root-cause narrative. If this section is left empty, analysers treat any cause beyond what `Symptom Summary` and `Reproduction Context` describe as out of scope by default.

## Questions for Analysers

1. What is the most likely root cause?
2. What evidence is still missing before implementation starts?
3. What is the safest next step: more investigation, instrumentation, or code change?
4. Which adjacent symptoms or subsystems did you consider and **deliberately exclude** from this analysis, and why must each be a separate task instead of being folded in here?
5. Did the analysis propose any code-level fix or refactor? If yes, move it out — this phase produces analysis only, not solutions.

## Conversion Note

- This input can be used as a starting draft before creating `okstra-task-brief.md`.
- Reuse the same `Task Group` and `Task ID` if this issue should remain traceable under one stable task.