---
title: OKSTRA Implementation 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 Implementation 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: `implementation`
- Requested Outcome:

## Approved Plan Reference (mandatory)

- Approved plan path: `runs/implementation-planning/<run-id>/reports/final-report.md`
- Approval evidence (quoted exactly from the plan's YAML frontmatter, e.g. `approved: true`):
- Planning contract: `selected-direction` or `legacy-option-candidates`
- Selected-direction reference and snapshot digest (required for `selected-direction`):
- Legacy implementation option name (legacy plans only):
- Plan's bite-sized step list (paste or reference by anchor):

> The run MUST refuse to start (status `contract-violated`) if the approved plan path does not exist or does not contain an explicit user approval marker. A selected-direction plan also requires `outcome: plan-ready`, exact plan coverage, and a valid selected-direction reference. It rejects `--implementation-option`; an existing approved legacy plan keeps that option-selection path.

## Scope From Plan

- File list authoritative for this run (copy from plan's File Structure section):
- Out-of-plan edits anticipated (leave empty if none — record rationale here in advance if known):
- Dependencies introduced by the plan:
- Migrations / schema changes referenced by the plan (must remain dry-run only in this phase if any):

## Out of Scope

- Adjacent areas deliberately excluded from this run (even if they appear in the plan's surrounding context):
- Items that look related but must be handled in a separate task:
- Reason for exclusion (deadline, risk, separate owner, distinct decision):

> The executor MUST NOT modify items listed here, even when an edit looks "trivial" or "while I'm in this file". Excluded items that block plan execution are reported back as a recommended follow-up task and the run halts for re-planning rather than silently expanding scope. This section is enforced together with `Forbidden In This Run` below.

## Validation Commands (must be runnable from clean state)

- Pre-execution checks:
- Mid-execution checks (per step or per commit):
- Post-execution checks:
- TDD-applicable steps (list step indices that should produce a failing test before implementation):

## Rollback Plan

- Revert path (commits, feature flags, migrations):
- Trigger signal that warrants rollback:
- Rollback dry-run command (if available):

## Forbidden In This Run (reminder)

- `git push`, publish, deploy, migration execution, third-party write APIs, production credentials
- Edits or Bash mutations performed by any verifier role
- Sub-agent dispatch beyond the required worker roster
- Silent scope expansion — every file touched outside the plan's list MUST be recorded in `Out-of-plan edits`

## Verifier Worker Inputs

- Diff scope hint: `git diff <base>..HEAD -- <plan-files>`
- Test output paths verifiers should consult:
- Specific risks the plan flagged that verifiers must check explicitly:

## Questions for Workers

1. (Executor) Can every plan step be satisfied without out-of-plan edits? If not, list each deviation with rationale.
2. (Executor) Did any change touch a file or symbol that appears in `Out of Scope`? If yes, halt and report — do not silently include it.
3. (Verifiers) Does the diff match the plan's File Structure and step ordering?
4. (Verifiers) Does the validation evidence include actual command output and exit codes for every plan checkpoint?
5. (Verifiers) Does the diff contain any "while I'm here" edits (rename, reformat, comment cleanup, adjacent refactor) that the plan did not authorise? Flag each such hunk explicitly.

## Phase Boundary

- This task type modifies source code. Edits are bounded by the approved plan's file list; deviations must be recorded.
- The run must NOT push to any remote, publish artefacts, deploy, run real migrations, or call write APIs against third-party services.
- Final-verification phase, not this phase, owns acceptance assessment. Do not declare overall success here — only "ready for final-verification" or "needs new planning loop".

## Conversion Note

- This input is paired with the approved `final-report.md` from the immediately preceding `implementation-planning` run.
- Reuse the same `Task Group` and `Task ID` as the planning run for traceability.