okstra 0.1.0

package/runtime/templates/project-docs/task-index.template.md

@@ -0,0 +1,65 @@
+# OKSTRA Task Summary
+
+## Current Snapshot
+
+- Task Key: `{{TASK_KEY}}`
+- Task Type: `{{TASK_TYPE}}`
+- Work Category: `{{WORK_CATEGORY}}`
+- Current Task Status: `{{CURRENT_TASK_STATUS}}`
+- Current Run Status: `{{CURRENT_RUN_STATUS}}`
+- Related Tasks: `{{RELATED_TASKS_INLINE}}`
+- Worker Roster: `{{RECOMMENDED_ANALYSERS}}`
+- Lead Model: `{{LEAD_MODEL}}`
+- Latest Run: `{{LATEST_RUN_RELATIVE_PATH}}`
+- Latest Report: `{{LATEST_REPORT_RELATIVE_PATH}}`
+- Team State: `{{TEAM_STATE_RELATIVE_PATH}}`
+- Validation Status: `{{VALIDATION_STATUS}}`
+- Resume Command: `{{CLAUDE_RESUME_COMMAND_RELATIVE_PATH}}`
+
+## Workflow Snapshot
+
+- Current Phase: `{{WORKFLOW_CURRENT_PHASE}}`
+- Current Phase State: `{{WORKFLOW_CURRENT_PHASE_STATE}}`
+- Last Completed Phase: `{{WORKFLOW_LAST_COMPLETED_PHASE}}`
+- Next Recommended Phase: `{{WORKFLOW_NEXT_RECOMMENDED_PHASE}}`
+- Awaiting Approval: `{{WORKFLOW_AWAITING_APPROVAL}}`
+- Routing Status: `{{WORKFLOW_ROUTING_STATUS}}`
+
+## Phase States
+
+{{WORKFLOW_PHASE_STATE_LINES}}
+
+## Safe Resume Checkpoint
+
+{{WORKFLOW_LAST_SAFE_CHECKPOINT_LINES}}
+
+## Model Assignments
+
+{{MODEL_ASSIGNMENT_LINES}}
+
+## Canonical Metadata
+
+- Source of truth: `{{TASK_MANIFEST_RELATIVE_PATH}}`
+- Project discovery pointer: `{{OKSTRA_LATEST_TASK_RELATIVE_PATH}}`
+- Instruction set: `{{INSTRUCTION_SET_RELATIVE_PATH}}`
+- Reference expectations: `{{REFERENCE_EXPECTATIONS_RELATIVE_PATH}}`
+- Final report template: `{{FINAL_REPORT_TEMPLATE_RELATIVE_PATH}}`
+- Run manifests directory: `{{RUN_MANIFESTS_RELATIVE_PATH}}`
+- Run state directory: `{{RUN_STATE_RELATIVE_PATH}}`
+- Run prompts directory: `{{RUN_PROMPTS_RELATIVE_PATH}}`
+- Run reports directory: `{{RUN_REPORTS_RELATIVE_PATH}}`
+- Run status directory: `{{RUN_STATUS_RELATIVE_PATH}}`
+- Run sessions directory: `{{RUN_SESSIONS_RELATIVE_PATH}}`
+- Worker results directory: `{{WORKER_RESULTS_RELATIVE_PATH}}`
+- Run validator: `{{RUN_VALIDATOR_RELATIVE_PATH}}`
+
+## Notes
+
+- 이 문서는 사람용 quick summary입니다.
+- canonical metadata는 항상 `task-manifest.json`을 기준으로 확인합니다.
+- 동일한 버그나 작업을 다시 이어갈 때는 같은 `Task Group`과 `Task ID`를 재사용합니다.
+- `requirements-discovery`는 work category와 다음 phase routing 결정을 남기기 위한 초기 triage 단계입니다.
+- run directory는 `runs/<task-type>/` 규칙을 사용하여 서로 다른 task-type 실행을 경로 수준에서 분리합니다.
+- run directory 내부는 `manifests/`, `state/`, `prompts/`, `reports/`, `status/`, `sessions/`, `worker-results/`처럼 유형별 하위 폴더로 나뉩니다.
+- current run의 `prompts/` 디렉터리는 lead prompt snapshot과 worker prompt history file의 canonical 저장 위치입니다.
+- run-level artifact와 result 파일명은 같은 task-type 재실행을 구분하기 위해 `-YYYY-MM-DD_HH-MM-SS` suffix를 사용합니다.

package/runtime/templates/reports/error-analysis-input.template.md

@@ -0,0 +1,80 @@
+# OKSTRA Error Analysis Input
+
+## Identity
+
+- Project ID:
+- Task Group:
+- Task ID:
+- Related Tasks:
+- Issue / Ticket:
+- 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.

package/runtime/templates/reports/final-report.template.md

@@ -0,0 +1,167 @@
+# {{TASK_KEY}} - Multi-Agent Cross Verification Final Report
+- Created at: {{RUN_TIMESTAMP_ISO}}
+- Task Key: {{TASK_KEY}}
+- Task Type: {{TASK_TYPE}}
+- Report Owner: `Claude lead`
+- Lead Model: `{{LEAD_MODEL}}`
+- Clarification Response Carried In: `{{CLARIFICATION_RESPONSE_RELATIVE_PATH}}`
+
+## 0. Clarification Response Carried In From Previous Run
+- Source file: `{{CLARIFICATION_RESPONSE_RELATIVE_PATH}}`
+- If the source path is empty, write `- No prior clarification response was provided for this run.` and skip the rest of this section.
+- If the source path is set, walk through both halves of the prior section 5 — material requests (`A1`, `A2`, ...) from sub-section 5.1 and user questions (`Q1`, `Q2`, ...) from sub-section 5.2 — and summarize how each one was used or invalidated by this run's evidence. Keep the two prefixes separate; do not collapse them into a single list.
+- Cite the entry id (`A*` or `Q*`) and the new evidence (file path, line number, log excerpt, worker finding, etc.) that resolves or refutes the prior answer or material.
+
+## Summary of the Problem or Verification Target
+- Summarize the core problem, requirement, or verification target in 3 to 5 bullets.
+- Base the summary on the brief, source materials, and worker results.
+
+## Execution Status by Agent
+- Summarize the status, assigned model, and key finding for each worker.
+- Do not replace worker outputs with unsupported claims.
+{{EXECUTION_STATUS_TABLE_ROWS}}
+
+## Token Usage Summary
+
+| 항목 | 처리 토큰 | 환산 토큰 (input 기준) | 비용 (USD) |
+|------|-----------|------------------------|------------|
+| Lead | `{{LEAD_TOTAL_TOKENS}}` | `{{LEAD_BILLABLE_TOKENS}}` | `{{LEAD_COST_USD}}` |
+| Worker 합계 | `{{WORKER_TOTAL_TOKENS}}` | `{{WORKER_BILLABLE_TOKENS}}` | `{{WORKER_COST_USD}}` |
+| **전체 합계** | **`{{GRAND_TOTAL_TOKENS}}`** | **`{{GRAND_BILLABLE_TOKENS}}`** | **`{{GRAND_COST_USD}}`** |
+| Codex/Gemini CLI 추가 비용 |  |  | `{{CLI_COST_USD}}` |
+
+> 처리 토큰 = input + output + cache_creation + cache_read (raw). 환산 토큰 = cache_read×0.1 + cache_creation×1.25 + output×5 + input (input-등가). 비용은 공시 가격 기준 추정치.
+
+## 1. Cross Verification Results
+### 1.1 Consensus
+- Record the conclusions and evidence that multiple workers support.
+
+### 1.2 Differences
+- Record meaningful differences in conclusions, interpretation, or evidence handling.
+- If there is no meaningful difference, state that clearly.
+
+## 2. Final Verdict
+- State the final conclusion clearly.
+- Recommend the most appropriate direction: continue investigation, begin implementation, approve, reject, or hold.
+
+## 3. Evidence and Detailed Analysis
+### 3.1 Primary Evidence
+- Cite concrete evidence such as file paths, line numbers, brief contents, logs, or worker reports.
+
+### 3.2 Secondary Evidence or Alternate Interpretations
+- Record supporting evidence, alternate hypotheses, or lower-confidence interpretations when relevant.
+
+## 4. Missing Information and Risks
+- Explicitly state any item that requires `I don't know` or `uncertain`.
+- Record the missing information and risks that weaken the current conclusion.
+
+## 4.5 Implementation Plan Deliverables (implementation-planning runs only)
+
+> **이 섹션은 `task-type` = `implementation-planning` 실행 결과에만 포함하세요. 다른 task-type에서는 섹션 전체를 삭제하고 5번 섹션으로 바로 넘어갑니다.**
+>
+> 아래 8개 하위 섹션의 **영문 제목 키워드는 그대로 유지해야 합니다**. `validate-run.py`가 다음 8개 문자열을 본문에서 찾습니다 — `Option Candidates` / `Trade-off` / `Recommended Option` / `Stepwise Execution Order` / `Dependency` / `Validation Checklist` / `Rollback` / `User Approval Request`. 한국어 번역은 괄호 안에 병기해도 좋지만 영문 키워드는 반드시 보존하세요. 본문은 한국어로 작성합니다.
+
+### 4.5.1 Option Candidates (옵션 후보)
+- 최소 두 개의 구현 옵션을 제시합니다. 각 옵션마다 다음을 포함합니다.
+  - **File Structure**: `Create: <path> — <responsibility>` / `Modify: <path>:<line-range> — <change summary>` / `Delete: <path> — <reason>` 형식으로 파일 단위 책임을 한 줄씩 명시합니다.
+  - 영향을 받는 인터페이스 / 공개 계약 / 다운스트림 소비자.
+  - 폭발 반경 추정(units, configs, deployment manifests, data migrations).
+
+### 4.5.2 Trade-off Matrix (트레이드오프 매트릭스)
+| Option | Complexity | Risk | Reversibility | Test Coverage Cost | Rollout Cost |
+|--------|-----------|------|---------------|--------------------|--------------|
+| <Option A> | <…> | <…> | <…> | <…> | <…> |
+
+### 4.5.3 Recommended Option (권장 옵션)
+- 어떤 옵션을 권장하는지와 이유를 작성합니다. 근거는 `4.5.2`의 비교 결과 + 디자인 원칙(isolation, files-that-change-together, follow-established-patterns, YAGNI)에 묶어 설명합니다.
+
+### 4.5.4 Stepwise Execution Order (단계별 실행 순서)
+1. 한 단계는 약 2~5분 안에 완료할 수 있는 작은 작업이어야 합니다(예: "X에 실패하는 테스트 작성", "테스트 실행해 실패 확인", "최소 구현", "테스트 통과 확인", "commit").
+2. 모든 단계는 정확한 파일 경로와 정확한 명령어를 포함해야 합니다. 코드 단계라면 실제 코드 또는 diff 스케치를 함께 적습니다.
+3. TDD 순서(failing test → implementation → green → commit)가 가능한 영역이라면 이 순서를 따릅니다.
+
+### 4.5.5 Dependency / Migration Risk (의존성·마이그레이션 위험)
+- 순서 제약, 데이터 백필, feature-flag 선행 조건, 팀 간 조율 등을 모두 나열합니다.
+
+### 4.5.6 Validation Checklist (검증 체크리스트)
+- pre / mid / post 검증 항목을 각각 정확한 명령어 또는 관찰 가능한 결과로 적습니다. 추상적 서술은 금지.
+
+### 4.5.7 Rollback Strategy (롤백 전략)
+- 정확한 revert 경로(commits, flags, migrations 등)와 롤백을 트리거하는 신호(에러율, latency, 사용자 보고 등)를 명시합니다.
+
+### 4.5.8 User Approval Request (사용자 승인 요청)
+- 다음 `implementation` run을 시작해도 되는지에 대한 명시적 승인 요청 블록입니다. 사용자가 명시적으로 승인하기 전까지는 이 plan을 코드로 옮기지 않습니다.
+- 승인 시 사용할 명령어 한 줄을 함께 적습니다: `okstra --task-key {{TASK_KEY}} --task-type implementation --approved-plan <이 보고서 경로>`
+
+### 4.5.9 Open Questions
+- pre-planning에서 발견된 모든 모호점을 항목으로 남겨, 사용자가 승인 전에 해소해야 할 질문 목록으로 사용합니다.
+
+## 5. Clarification Requests for the Next Run
+
+이 섹션은 다음 run으로 넘어가기 전에 사용자에게 받아야 할 입력을 정리하는 자리입니다. `task-type`이 `error-analysis` 또는 `requirements-discovery`이고 지금까지의 증거만으로는 확신 있는 최종 판단이 어려울 때 반드시 채웁니다. 그 외의 `task-type`에서는 lead가 추가 run이 필요하다고 판단했을 때만 채우고, 그렇지 않다면 `- 추가 정보 요청 없음. Section 2의 최종 판단이 그대로 유효합니다.` 라고만 한 줄 적은 뒤 Section 6으로 넘어갑니다.
+
+작성 원칙:
+
+- 개발자가 아닌 사람도 한 번 읽고 무엇을 어디서 가져와야 하는지 이해할 수 있게, 줄임말과 내부 용어 대신 풀어 쓴 문장으로 작성합니다. (예: "QPS" 대신 "초당 평균 요청 수", "AC 미정" 대신 "합격 기준이 아직 정의되지 않았습니다")
+- 한 항목은 "왜 묻는지", "구체적으로 무엇을 묻는지", "어떤 형태의 답을 기대하는지"가 모두 분명히 드러나야 합니다. 한 줄짜리 단답형 질문은 피하고, 필요한 배경을 1~2문장으로 함께 적습니다.
+- 사용자에게 추가로 부탁드리는 자료(로그, 스크린샷, 설정 파일 사본, 재현 절차 등)와, 사용자에게 답을 받아야 하는 질문은 **반드시 두 개의 별도 하위 섹션으로 나누어 적습니다.** 같은 표나 같은 항목 안에 섞지 않습니다.
+- run 사이에 일관된 추적이 가능하도록 항목별 ID(`A1`, `A2` / `Q1`, `Q2`)는 한 번 부여한 뒤 다음 run에서도 유지합니다. 이미 답변된 항목은 다음 run에서도 삭제하지 말고 `Status`만 `resolved` 또는 `obsolete`로 갱신합니다.
+- Status 값의 의미는 다음과 같습니다.
+  - `open`: 요청했지만 아직 받지 못했습니다.
+  - `answered`: 사용자가 아래 답변 칸을 채워 두었습니다(다음 run의 lead가 검증해야 합니다).
+  - `resolved`: 다음 run에서 lead가 답변을 받아 검증을 마쳤습니다.
+  - `obsolete`: 이후 분석 결과로 더 이상 필요 없어진 항목입니다.
+
+이 보고서에 답을 채우신 뒤에는 `okstra --resume-clarification --task-key {{TASK_KEY}}` 한 줄로 같은 phase를 다시 실행하실 수 있습니다(자동으로 `$EDITOR`가 이 파일을 열고, 저장하면 같은 phase가 `--clarification-response`로 carry-in 되어 재실행됩니다). 스크립트로 자동화하실 때는 기존 형식 `okstra --task-key {{TASK_KEY}} --task-type {{TASK_TYPE}} --clarification-response <이 파일 경로>`도 그대로 사용하실 수 있습니다.
+
+### 5.1 추가 자료 요청 (Additional Materials Requested)
+
+이 하위 섹션에는 **사용자가 다음 run 전에 첨부 또는 공유해 주셨으면 하는 자료**만 적습니다. 질문이 아니라 자료 요청입니다. 자료가 어디에 있는지(파일 경로, 페이지 URL, 데이터베이스 쿼리 결과 등), 어떤 시점/조건의 데이터를 받아야 하는지, 받은 자료를 어디에 두면 되는지(예: `<project-root>/.project-docs/<task-group>/<task-id>/` 아래)를 함께 적습니다. 받을 자료가 없다면 `- 추가로 요청드릴 자료가 없습니다.` 한 줄만 남깁니다.
+
+| 자료 ID | 무엇을 / 왜 필요한지 (문장으로 서술) | 어디에서 가져올 수 있는지 (파일 경로, 시스템 이름, URL 등) | 어디에 두면 되는지 / 어떻게 전달해 주실지 | Status | 사용자가 첨부한 위치 또는 메모 (다음 run 전에 사용자가 채움) |
+|---------|--------------------------------------|------------------------------------------------------------|--------------------------------------------|--------|---------------------------------------------------------------|
+| A1 | <어떤 자료를 왜 받아야 하는지를 1~2문장으로. 예: "오류가 처음 보고된 시각 전후 30분 동안의 worker 로그가 필요합니다. 어떤 task가 실패했고 그때 큐에 무엇이 쌓여 있었는지를 함께 확인해야 root cause 가설을 좁힐 수 있기 때문입니다." > | <예: "Datadog 로그에서 `service:worker env:prod` 필터, 시각 범위 2026-04-30 09:30~10:30 KST" / 또는 정확한 파일 경로> | <예: "`.project-docs/tasks/8852/logs/` 아래에 `worker-2026-04-30.log` 라는 이름으로 저장해 주시면 됩니다."> | open | <빈칸으로 두고 다음 run 전에 사용자가 채움> |
+
+### 5.2 사용자 확인 질문 (Questions for the User)
+
+이 하위 섹션에는 **사용자가 직접 결정해 주시거나 확인해 주셔야만 다음 단계로 진행할 수 있는 질문**만 적습니다. 자료 요청은 위 5.1에 두고 여기에는 의사결정/확인 질문만 둡니다. 질문이 없다면 `- 추가로 확인이 필요한 질문이 없습니다.` 한 줄만 남깁니다.
+
+각 질문은 다음을 분명히 보여주어야 합니다.
+
+- **왜 이 답이 필요한가**: 이 답에 따라 무엇이 어떻게 달라지는지 한 두 문장으로.
+- **무엇을 묻는가**: 약어 없이 풀어 쓴 완전한 문장의 질문.
+- **어떤 형태의 답을 기대하는가**: 예/아니오인지, 둘 중 하나를 고르는 선택인지, 숫자/날짜/파일경로인지, 아니면 짧은 자유서술인지. 가능하면 보기를 함께 제시합니다.
+
+| 질문 ID | 이 답이 필요한 이유 (왜) | 질문 본문 (무엇을 묻는지, 풀어 쓴 문장) | 기대하는 답의 형태 / 보기 | Blocking (예 / 아니오) | Status | 사용자 답변 (다음 run 전에 사용자가 채움) |
+|---------|--------------------------|-----------------------------------------|----------------------------|------------------------|--------|--------------------------------------------|
+| Q1 | <예: "이 결정에 따라 `bugfix`로 이어갈지 `feature`로 이어갈지가 갈리며, 다음 run에서 사용할 task-type이 달라집니다."> | <예: "지난 주 새벽에 보고된 결제 실패가 일회성 사고였는지, 아니면 같은 증상이 다시 발생한 적이 있는지 알려주실 수 있을까요? 같은 증상이 다시 발생했다면 가장 최근 발생 시각과 영향 받은 사용자 수도 함께 부탁드립니다."> | <예: "다음 중 한 줄로 답해 주시면 됩니다 — (a) 일회성으로 그 후 재발 없음, (b) 재발 있음, 가장 최근 시각: YYYY-MM-DD HH:MM, 영향 사용자 수 약 N명"> | 예 | open | <빈칸으로 두고 다음 run 전에 사용자가 채움> |
+
+## 6. Recommended Next Steps
+
+This section is **always present** in every final report — never omit the heading. If there are no concrete actions to take, write the single line `- No further action required. Final verdict in section 2 stands.` under the heading and stop.
+
+When concrete actions exist, list them as a numbered list using the rules below. Each item must include the exact command(s) the user can copy-paste. Prefer the `--task-key` shorthand for follow-up runs and `--resume-clarification` for clarification answer turn-arounds; show the equivalent full-args form only when useful.
+
+1. **Highest-priority next action.** State what to do and why in one sentence, then the command. Example shortcut forms:
+   - Same phase rerun: `okstra --task-key {{TASK_KEY}} --task-type {{TASK_TYPE}}`
+   - Next phase: `okstra --task-key {{TASK_KEY}} --task-type <next-phase>` (omit `--task-type` to use the manifest's `workflow.nextRecommendedPhase` automatically when it is a concrete phase, not `pending-routing-decision` / `done-or-follow-up`).
+2. **Additional verification needed before implementation or release.** List read-only checks (test commands, log queries, dashboard URLs) that the user should run before moving to the next phase. No state-mutating commands here.
+3. **Follow-up tasks or related tasks if needed.** Reference them by `task-key` when they already exist; otherwise describe the new brief to draft.
+4. **If section 5 has any `open` rows**, the highest-priority next step MUST be the clarification turn-around. Show both forms:
+   - Preferred (interactive): `okstra --resume-clarification --task-key {{TASK_KEY}}` — opens this file in `$EDITOR`, then auto-reruns the same phase with `--clarification-response` carry-in.
+   - Scripted: `okstra --task-key {{TASK_KEY}} --task-type {{TASK_TYPE}} --clarification-response <path-to-this-file-after-editing>`.
+
+Empty-state placeholder, copy verbatim when nothing else applies:
+
+```
+- No further action required. Final verdict in section 2 stands.
+```
+
+## Writing Rules
+- Write the final report in Markdown.
+- Write the final report body in Korean.
+- Keep technical identifiers such as file paths, code symbols, model names, and status values in their original form when needed.
+- Keep the section structure unless the brief explicitly requires a different structure.
+- Prioritize evidence-based statements over speculation.
+- Do not replace the report body with meta commentary about storage, session limits, or prior messages.
+- This document is the final synthesis by `Claude lead`, not a raw dump of worker outputs.

package/runtime/templates/reports/final-verification-input.template.md

@@ -0,0 +1,67 @@
+# 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 Evidence
+
+- PR or change summary:
+- Test results:
+- Manual verification notes:
+- 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
+
+- 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. Are there any acceptance blockers?
+2. What residual risks remain?
+3. Is additional validation needed before release?
+4. 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?
+5. 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.

package/runtime/templates/reports/implementation-input.template.md

@@ -0,0 +1,81 @@
+# OKSTRA Implementation Input
+
+## Identity
+
+- Project ID:
+- Task Group:
+- Task ID:
+- Related Tasks:
+- Issue / Ticket:
+- 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 `User Approval Request` resolution):
+- Recommended option name selected from the plan:
+- 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.
+
+## 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) Is the rollback path still valid after the changes?
+6. (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.

package/runtime/templates/reports/implementation-planning-input.template.md

@@ -0,0 +1,93 @@
+# OKSTRA Implementation Planning Input
+
+## Identity
+
+- Project ID:
+- Task Group:
+- Task ID:
+- Related Tasks:
+- Issue / Ticket:
+- Task Type: `implementation-planning`
+- Requested Outcome:
+
+## Requirement Summary
+
+- What needs to change?
+- Why is this work required?
+- What result must be achieved?
+
+## Current State
+
+- Current behavior:
+- Known limitations:
+- Existing related implementation:
+- Related code paths:
+- Previous reports in the same task history:
+
+## Constraints
+
+- Business constraints:
+- Technical constraints:
+- Delivery constraints:
+- Backward compatibility concerns:
+
+## Out of Scope
+
+- Adjacent areas deliberately excluded from this plan:
+- Items that look related but must be planned in a separate task:
+- Reason for exclusion (deadline, risk, separate owner, distinct decision):
+
+> Analysers MUST NOT expand option candidates, file lists, or step plans into items listed here. If an analyser believes an excluded item must be addressed to satisfy the requirement, it is reported as a recommended follow-up task in the final report — never silently folded into a candidate option. If this section is left empty, analysers treat any change beyond what `Requirement Summary` explicitly demands as out of scope by default.
+
+## Planning Concerns
+
+- Possible implementation options:
+- Expected trade-offs:
+- Dependencies or migrations:
+- Validation approach:
+- Rollback approach:
+
+## Config and Deployment Expectations
+
+- Relevant config files:
+- Relevant deployment manifests:
+- Expected target values or invariants:
+- Values that must remain unchanged:
+
+## Open Questions
+
+- What is still unclear in the requirement?
+- What could block implementation?
+- What must be confirmed before coding?
+
+## Questions for Analysers
+
+1. What is the safest implementation direction?
+2. What are the main trade-offs between options?
+3. What should be validated before, during, and after implementation?
+4. Which adjacent changes did you consider and **deliberately exclude** from this plan, and why must each be a separate task instead of being folded in here?
+5. If a candidate option's file list grew beyond the explicit requirement, justify each extra file or remove it.
+
+## Required Plan Deliverable
+
+The final report of an `implementation-planning` run MUST contain every section below. Missing any one of them is a contract violation.
+
+1. **Option Candidates** — at least two viable options, each with the exact list of files to create or modify and the principal change per file.
+2. **Trade-off Matrix** — comparison of the candidates across complexity, risk, reversibility, performance impact, scope, and required test surface.
+3. **Recommended Option** — selected option with explicit rationale referencing the trade-off matrix.
+4. **Stepwise Execution Order** — ordered steps where each step is independently verifiable; each step lists the files it touches and the test/command that proves it works.
+5. **Dependency and Migration Risk** — schema, data, ordering, feature-flag, and cross-service risks that the recommended option introduces.
+6. **Validation Checklist** — pre-execution, mid-execution, and post-execution checks (commands, expected outputs, observability points).
+7. **Rollback Strategy** — exact reverse procedure or compensating action for each significant step.
+8. **Scope Boundary** — an explicit list of adjacent areas, files, refactors, or quality improvements that this plan **does NOT** cover, each with a one-line reason (deferred, separate owner, separate decision, out of requirement). Any item the analysers were tempted to fold in but chose to exclude MUST appear here. An empty list is allowed only when the analysers explicitly state "no adjacent expansion was considered" — silence is not acceptable.
+9. **User Approval Request** — a labelled block stating that the plan is awaiting explicit user approval. The next `implementation` run MUST NOT begin until the user has replied with explicit approval to this block.
+
+## Phase Boundary
+
+- This task type produces a plan only. Source code MUST NOT be modified, builds/migrations/deployments MUST NOT be executed, and follow-up phases MUST NOT be started inside the same run.
+- If workers detect that the plan cannot be completed without further error analysis or new requirements, record that in the final report and recommend re-routing to `error-analysis` or `requirements-discovery` rather than guessing.
+
+## Conversion Note
+
+- This input can be used as a planning draft before creating `okstra-task-brief.md`.
+- Reuse the same `Task Group` and `Task ID` if this plan belongs to the same long-lived task.

package/runtime/templates/reports/quick-input.template.md

@@ -0,0 +1,64 @@
+# OKSTRA Quick Input
+
+## Basic Identity
+
+- Project ID:
+- Task Group:
+- Task ID:
+- Related Tasks:
+- Issue / Ticket:
+- Requested Task Type:
+- Requested Outcome:
+
+## Current Context Summary
+
+- What is the current state or request?
+- What should happen instead?
+- Why do you want cross verify now?
+- Should this continue an existing task or start a new one?
+
+## Current Evidence
+
+- Main note or issue document:
+- Existing analysis:
+- Logs or raw samples:
+- Related code paths:
+
+## Constraints
+
+- Known constraints:
+- Known assumptions:
+- Still uncertain:
+
+- Adjacent areas deliberately excluded from this run:
+- Items that look related but must be handled in a separate task:
+- Reason for exclusion:
+
+> Workers MUST NOT expand into items listed here.
+> If left blank, any changes beyond the explicit requirements of the input will be treated as out of scope by default.
+> Any exclusions that appear necessary will be recorded only as follow-up recommendations in the final report, and no further action will be taken.
+
+## Config and Deployment References
+
+- Related config files:
+- Related deployment manifests:
+- Expected values or invariants:
+- What is still uncertain:
+
+## Questions to Answer
+
+1.
+2.
+3.
+
+### Standing Scope-Discipline Questions (always answered)
+
+- Which adjacent changes did you consider and **deliberately exclude** from this run? List each with a one-line reason.
+- Did any part of your output go beyond what `Current Context Summary` and the `Out of Scope` block define? If yes, move it to follow-up recommendations and remove it from the main answer.
+
+## Recommended Next Step
+
+- Should this be converted into a full cross verify task brief?
+- Is `requirements-discovery` the right first phase?
+- If yes, what materials still need to be added?
+- If this is a reopened task, should the same `Task Group` and `Task ID` be reused?