---
title: OKSTRA Final Verification 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 Final Verification Input

## Identity

- Project ID:
- Task Group:
- Task ID:
- Related Tasks:
- Issue / Ticket:
- Task Type: `final-verification`
- Requested Outcome:

## Delivery Summary

- What was implemented?
- What was supposed to be delivered?
- What is the intended acceptance decision?

## Verification Mode

- The default is **whole-task** verification (`--stage auto`): it runs once after every Stage Map stage has been implemented and merged.
- To verify only a specific stage in isolation, use **single-stage** mode with `--stage N` (cannot enter release-handoff; partial verification).
- okstra automatically resolves worktree / base / head from the registry and `consumers.jsonl`, so do not fill them in manually in this input sheet.

## Source Implementation Report

- Path (project-relative) to the originating `implementation` final-report:
- Quoted `Commit list` / `Diff summary` excerpt from the implementation report:

> If the report path is empty or points to a missing report, final-verification ends with status `blocked`. Cause defects route to `error-analysis`, direction defects route to `implementation-option-selection`, and detailed-plan defects route to `implementation-planning`. The verification target (worktree/base) is resolved automatically by okstra, so a mismatched manual entry cannot cause a block.

## Requirement Coverage Source

- Approved implementation-planning report path:
- Requirement source used for coverage (plan section / brief end-state items):
- Requirement IDs / acceptance IDs to verify:
- Requirements intentionally excluded from this verification:

> final-verification MUST cite an artifact in Validation Evidence for each requirement / acceptance id in the source above. If the source is empty, use the brief's `## Expected Behavior` / `## Expected Outcome` items as the default source.

## Verification Evidence

- PR or change summary:
- Test results:
- Manual verification notes (execute the source implementation report's §5.7.9 Manual User Test Draft and record results here):
- Related code paths:
- Release or rollout notes:
- Previous reports in the same task history:

## Remaining Concerns

- Known issues:
- Edge cases still not fully verified:
- Regression concerns:
- Documentation gaps:

## Acceptance Criteria

<!-- This is the verification run's own acceptance input, not the brief's end-state sections. Seed it from the brief's `EB-NNN` / `EO-NNN` items. -->

- Must-pass acceptance points:
- Optional quality improvements:
- Conditions that should block release:

## Out of Scope

- Acceptance areas deliberately excluded from this verification:
- Items that look related but belong to a separate verification task:
- Reason for exclusion (different release, separate owner, deferred decision):

> Verifiers MUST NOT extend acceptance checks, regression scans, or sign-off recommendations into items listed here. If a verifier believes an excluded item must pass before release, it is reported as a recommended follow-up verification task in the final report — never silently included in the pass/fail decision of this run. If this section is left empty, verifiers treat any check beyond what `Acceptance Criteria` enumerates as out of scope by default.

## Config and Deployment Verification Targets

- Relevant config files:
- Relevant deployment manifests:
- Expected final values or invariants:
- Values that still require explicit verification:

## Questions for Analysers

1. Did your analysis run against the injected `VERIFICATION_TARGET` (base ref / worktree), and does the worktree's delivered diff fully cover the stage(s) under verification? (A worktree you cannot confirm against the injected target is a `tool-failure`, not a silent proceed.)
2. For each requirement / acceptance criterion, what exact artifact (commit SHA, test output, log line, config value) proves coverage?
3. Are there any acceptance blockers?
4. What residual risks remain?
5. Is additional validation needed before release?
6. Which acceptance checks did you consider and **deliberately exclude** from this verification, and why must each be a separate verification task instead of being folded in here?
7. Did any check go beyond `Acceptance Criteria` (e.g., quality improvements, unrelated regressions)? If yes, separate them from the pass/fail decision and report as follow-up only.

## Conversion Note

- This input can be used as a final verification draft before creating `okstra-task-brief.md`.
- Reuse the same `Task Group` and `Task ID` if verification should remain attached to the same task history.