okstra 0.7.0 → 0.9.0

package/runtime/skills/okstra-status/SKILL.md

@@ -43,7 +43,7 @@ Extract the following fields from each task.
 |------|------|
 | `taskKey` | `<project-id>:<task-group>:<task-id>` |
 | `taskType` | latest task type |
-| `workCategory` | bugfix / feature / improvement / refactor / ops-change / unknown |
+| `workCategory` | bugfix / feature / improvement / refactor / ops-change / unknown. Display `unknown` as-is, but flag with `(unset)` annotation so the reader knows the requirements-discovery classification was skipped or no `--work-category` flag was passed. |
 | `currentStatus` | task-level status |
 | `currentPhase` | lifecycle current phase |
 | `currentPhaseState` | lifecycle phase state |
@@ -128,6 +128,7 @@ Output format:
 - `implementation-planning`: `<state>`
 - `implementation`: `<state>`
 - `final-verification`: `<state>`
+- `release-handoff`: `<state>`
 
 ### Safe Resume Checkpoint
 
@@ -147,7 +148,8 @@ The status response always includes one of the following options:
 2. **Restart current phase**
 - Indicates whether the task can be re-run with the same `task-key` and the current `taskType`.
 3. **Start next phase**
-- If `workflow.nextRecommendedPhase` is one of `error-analysis`, `implementation-planning`, or `final-verification`, that phase is proposed as the next candidate for the Okstra run.
+- If `workflow.nextRecommendedPhase` is one of `error-analysis`, `implementation-planning`, `final-verification`, or `release-handoff`, that phase is proposed as the next candidate for the Okstra run.
+- If `nextRecommendedPhase` is `pending-release-handoff`, the prior `final-verification` run completed but its verdict still has to be inspected before entering `release-handoff` — surface this as a verdict-gated next step and present `release-handoff` as a candidate only when the cited verdict is `accepted`.
 4. **Need more information**
 - If `nextRecommendedPhase` is `pending-routing-decision` or `routingStatus` is `pending`, this indicates that additional information is required.
 
@@ -213,7 +215,16 @@ Accepted `<status>` values: `todo`, `in-progress`, `blocked`, `done`.
 
 ### Default Value Convention
 
-If `workStatus` is missing or empty in any manifest, treat it as `in-progress` for read purposes. Do not back-fill the field on read; only write it when the user explicitly issues an update.
+If `workStatus` is missing or empty in any manifest, infer the display value from the lifecycle state — DO NOT default to a static `in-progress`:
+
+| Manifest state | Inferred display |
+|---|---|
+| `currentStatus == "completed"` AND `workflow.nextRecommendedPhase` in (`done-or-follow-up`, empty) | `done` (inferred) |
+| `currentStatus == "completed"` AND `workflow.currentPhaseState == "completed"` | `phase-done` (inferred) |
+| `currentStatus == "contract-violated"` OR `workflow.currentPhaseState == "blocked"` | `blocked` (inferred) |
+| anything else | `in-progress` (default) |
+
+Annotate inferred values with `(inferred)` or `(default)` in the rendered output so the reader can see which value is user-set vs. system-inferred. Do not back-fill the field on read; only write it when the user explicitly issues an update.
 
 ### Catalog Sync Note
 

package/runtime/skills/okstra-team-contract/SKILL.md

@@ -209,6 +209,25 @@ A successful worker result must include the following sections in this exact ord
 
 Code evidence must include file paths and line numbers.
 
+### Ticket Tagging (mandatory for sections 1–5)
+
+Every item in sections 1–5 MUST be tagged with the ticket(s) it relates to. This applies whenever the run's task type is `requirements-discovery`, `error-analysis`, `implementation-planning`, or `implementation`.
+
+- **Table-form items**: include a `Ticket ID` column. The column is placed immediately after the row-ID column (e.g. after `F-001`, `M-001`).
+- **Bullet / numbered-list items**: prepend `[TICKETID: <id>]` to the item title, immediately after the row ID and before the body text. Example: `- F-001 [TICKETID: TICKET-123] — <summary> (path:line)`.
+- **Section headers in the final report** (e.g. `### 4.5.3 Recommended Option`): append `[TICKETID: <id>]` to the header when the section is scoped to a specific ticket. Headers that span all tickets in the run omit the tag.
+
+Ticket ID fill rule (in order):
+
+1. Use the `Issue / Ticket` value from the run's input template.
+2. If empty, fall back to the `Task ID` value (no prefix; write `8852` not `task:8852`).
+3. If both are absent, write `unknown`. This is allowed but signals an input-template defect — the worker SHOULD also record a `Missing Information` item noting the absent identifier.
+4. When a single item maps to multiple tickets, separate them with commas: `TICKET-123, TICKET-456`. Ticket IDs containing commas are not supported.
+
+Workers MUST apply these rules to every item in sections 1–5. Lead and report-writer MUST preserve the tagging when carrying worker findings into the final report.
+
+For phases other than the four listed above (e.g. `release-handoff`, `final-verification`), ticket tagging is optional.
+
 ### Optional errors sidecar (worker-reported)
 
 A worker MAY produce an errors sidecar file at:

package/runtime/skills/okstra-time-summary/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: okstra-time-summary
 description: Use when the user asks how long an okstra task took, time spent per task type, per-worker elapsed time, or for a duration/runtime breakdown of a specific task-id. Trigger words include "작업 시간", "소요 시간", "time summary", "duration", "elapsed", "얼마나 걸렸", "시간 분석".
+user-invocable: false
 ---
 
 # OKSTRA Time Summary

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

@@ -7,6 +7,7 @@
 - Task ID:
 - Related Tasks:
 - Issue / Ticket:
+  - 값이 비면 워커는 `Task ID`로 폴백한다 (prefix 없이 `8852`처럼). 한 run이 여러 ticket을 동시에 다루면 콤마로 구분 (`TICKET-123, TICKET-456`). 어느 쪽으로도 식별 불가하면 `unknown`을 허용한다.
 - Task Type: `error-analysis`
 - Requested Outcome:
 

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

@@ -6,6 +6,18 @@
 - Lead Model: `{{LEAD_MODEL}}`
 - Clarification Response Carried In: `{{CLARIFICATION_RESPONSE_RELATIVE_PATH}}`
 
+## User Approval Request (사용자 승인 게이트)
+
+> **이 블록은 `task-type` = `implementation-planning` 결과에서만 의미를 가집니다.** 다른 task-type의 보고서에서는 이 섹션 전체를 삭제하세요.
+>
+> 다음 `implementation` run은 아래 체크박스가 `[x]`로 표시되어 있을 때에만 진입할 수 있습니다 (`okstra_ctl.run._validate_approved_plan` 가 이 마커를 line-anchored 정규식으로 검사하여 통과/거부합니다). 본문(`Sections 1`–`4.5`)을 끝까지 읽고, `4.5.9 Open Questions`가 비어 있거나 모두 해소된 뒤 승인해 주세요.
+
+- 승인 여부 (사용자가 직접 편집): `- [ ] Approved` ← 승인하려면 `[ ]` 를 `[x]` 로 변경하여 저장하세요.
+- 승인 후 다음 단계 명령어 (방법 A — 수동 편집): `okstra --task-key {{TASK_KEY}} --task-type implementation --approved-plan <이 보고서 경로>`
+- 승인 + 실행 한 번에 (방법 B — CLI 자체를 승인 의사로): `okstra --task-key {{TASK_KEY}} --task-type implementation --approved-plan <이 보고서 경로> --approve`
+  - 방법 B 는 `--approve` 입력 행위 자체를 승인 의사로 모델링합니다. 런타임이 본 블록의 체크박스를 자동으로 `[x]` 로 바꾸고, 본 섹션 하단에 `승인 일시 (CLI ack): <ISO8601>` audit 라인을 한 줄 덧붙입니다.
+- 승인을 보류하거나 거부하려면 체크박스는 `[ ]` 로 두고 `--approve` 도 사용하지 마세요. 필요한 변경 사항은 `4.5.9 Open Questions` 또는 `Section 5 Clarification Requests` 에 기록한 뒤 같은 phase 를 재실행해 주세요.
+
 ## 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.
@@ -16,6 +28,23 @@
 - Summarize the core problem, requirement, or verification target in 3 to 5 bullets.
 - Base the summary on the brief, source materials, and worker results.
 
+## Ticket Coverage
+
+이 run이 다룬 ticket을 한 자리에서 확인하는 인덱스 표입니다. 본 보고서의 본문 항목들은 모두 `Ticket ID` 컬럼 또는 `[TICKETID: <id>]` 태그로 ticket과 묶여 있으며, 이 표는 그 역방향 인덱스입니다.
+
+- 한 run이 단일 ticket만 다루는 경우: 표 대신 다음 한 줄로 대체할 수 있습니다 — `- Single ticket run: <TICKET-or-task-fallback>`
+- 다중 ticket이거나, `Issue / Ticket`이 비어 `Task ID` 폴백을 쓴 항목이 섞여 있는 경우: 표를 채웁니다.
+
+| Ticket ID | 등장 섹션 | 관련 항목 IDs |
+|-----------|-----------|---------------|
+| `<TICKET-123>` | `1.1, 3.1, 4.5.4` | `F-001, F-003, A1` |
+
+규칙:
+
+- `Ticket ID` 컬럼은 본문에서 등장한 ticket 키와 정확히 동일한 문자열을 사용합니다. `Issue / Ticket`이 비어 폴백된 경우 `Task ID` 값을 prefix 없이 그대로 적습니다 (예: `8852`). 어느 쪽으로도 식별 불가한 경우 `unknown`을 사용합니다.
+- `등장 섹션`은 본 보고서의 섹션 번호를 콤마로 구분합니다. 동일 ticket이 여러 섹션에 등장하면 모두 나열합니다.
+- `관련 항목 IDs`는 `F-001`, `M-002`, `A1`, `Q1` 같은 row ID를 콤마로 나열합니다. 섹션 헤더 단위로만 ticket이 표시된 경우(개별 row ID가 없는 경우)에는 헤더 번호 자체를 적습니다 (예: `4.5.3`).
+
 ## Execution Status by Agent
 - Summarize the status, assigned model, and key finding for each worker.
 - Do not replace worker outputs with unsupported claims.
@@ -34,11 +63,20 @@
 
 ## 1. Cross Verification Results
 ### 1.1 Consensus
-- Record the conclusions and evidence that multiple workers support.
+
+| ID | Ticket ID | Statement | Supporting workers | Evidence (path:line / log / worker report) |
+|----|-----------|-----------|--------------------|---------------------------------------------|
+| C-001 | `<TICKET-or-fallback>` | <합의된 결론> | claude, codex, gemini | <증거 위치> |
+
+- 합의된 결론을 row마다 기록합니다. `Ticket ID`는 본 보고서 상단 `Ticket Coverage` 규칙을 따릅니다.
 
 ### 1.2 Differences
-- Record meaningful differences in conclusions, interpretation, or evidence handling.
-- If there is no meaningful difference, state that clearly.
+
+| ID | Ticket ID | Disagreement | Workers (position) | Evidence |
+|----|-----------|--------------|--------------------|----------|
+| D-001 | `<TICKET-or-fallback>` | <차이 요약> | claude (A) / codex (B) / gemini (-) | <증거 위치> |
+
+- 유의미한 차이가 없을 경우 표 대신 다음 한 줄을 적습니다 — `- 유의미한 차이 없음. 1.1 Consensus가 그대로 유효합니다.`
 
 ## 2. Final Verdict
 - State the final conclusion clearly.
@@ -46,14 +84,26 @@
 
 ## 3. Evidence and Detailed Analysis
 ### 3.1 Primary Evidence
-- Cite concrete evidence such as file paths, line numbers, brief contents, logs, or worker reports.
+
+| ID | Ticket ID | Evidence | Source (path:line / log / worker report) |
+|----|-----------|----------|------------------------------------------|
+| E-001 | `<TICKET-or-fallback>` | <증거 한 줄 요약> | <출처> |
 
 ### 3.2 Secondary Evidence or Alternate Interpretations
-- Record supporting evidence, alternate hypotheses, or lower-confidence interpretations when relevant.
+
+| ID | Ticket ID | Hypothesis or supporting evidence | Source / confidence |
+|----|-----------|-----------------------------------|---------------------|
+| S-001 | `<TICKET-or-fallback>` | <보조 증거 또는 대안 해석> | <출처 + low/mid> |
+
+- 해당 없음 시: `- 보조 증거 또는 대안 해석 없음.`
 
 ## 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.
+
+| ID | Ticket ID | Item | Risk if ignored |
+|----|-----------|------|-----------------|
+| R-001 | `<TICKET-or-fallback>` | <누락 정보 또는 불확실 항목> | <무시할 때의 위험> |
+
+- `I don't know` / `uncertain`으로 표기해야 하는 항목은 모두 표 안에 두고 본문 산문 형식으로 흩지 않습니다.
 
 ## 4.5 Implementation Plan Deliverables (implementation-planning runs only)
 
@@ -63,7 +113,11 @@
 
 ### 4.5.1 Option Candidates (옵션 후보)
 - 최소 두 개의 구현 옵션을 제시합니다. 각 옵션마다 다음을 포함합니다.
-  - **File Structure**: `Create: <path> — <responsibility>` / `Modify: <path>:<line-range> — <change summary>` / `Delete: <path> — <reason>` 형식으로 파일 단위 책임을 한 줄씩 명시합니다.
+  - **File Structure**: 다음 표 형식으로 파일 단위 책임을 한 줄씩 명시합니다. 행마다 `Ticket ID` 컬럼을 채웁니다.
+
+    | ID | Ticket ID | Action | Path (and line-range) | Change summary |
+    |----|-----------|--------|------------------------|----------------|
+    | OF-001 | `<TICKET-or-fallback>` | Create / Modify / Delete | `<path>[:<line-range>]` | <한 줄 요약> |
   - 영향을 받는 인터페이스 / 공개 계약 / 다운스트림 소비자.
   - 폭발 반경 추정(units, configs, deployment manifests, data migrations).
 
@@ -76,26 +130,95 @@
 - 어떤 옵션을 권장하는지와 이유를 작성합니다. 근거는 `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)가 가능한 영역이라면 이 순서를 따릅니다.
+
+| Step | Ticket ID | Action (≤ 5min) | Files | Command / Test | Expected outcome |
+|------|-----------|------------------|-------|----------------|-------------------|
+| 1 | `<TICKET-or-fallback>` | <예: 실패하는 테스트 작성> | `tests/foo_test.py` | `pytest tests/foo_test.py::test_x -v` | FAIL with <reason> |
+
+규칙:
+
+- 한 step은 약 2~5분 안에 완료할 수 있는 작은 작업이어야 합니다(예: "X에 실패하는 테스트 작성", "테스트 실행해 실패 확인", "최소 구현", "테스트 통과 확인", "commit").
+- 모든 step은 정확한 파일 경로와 정확한 명령어를 포함합니다. 코드 단계라면 실제 코드 또는 diff 스케치를 함께 적습니다 (`Action` 셀에 줄바꿈 가능).
+- TDD 순서(failing test → implementation → green → commit)가 가능한 영역이라면 이 순서를 따릅니다.
+- 한 step이 여러 ticket을 동시에 진행한다면 `Ticket ID`에 콤마로 함께 적습니다.
 
 ### 4.5.5 Dependency / Migration Risk (의존성·마이그레이션 위험)
 - 순서 제약, 데이터 백필, feature-flag 선행 조건, 팀 간 조율 등을 모두 나열합니다.
 
 ### 4.5.6 Validation Checklist (검증 체크리스트)
-- pre / mid / post 검증 항목을 각각 정확한 명령어 또는 관찰 가능한 결과로 적습니다. 추상적 서술은 금지.
+
+| Phase | Ticket ID | Check | Command / Observation | Expected outcome |
+|-------|-----------|-------|------------------------|-------------------|
+| pre   | `<TICKET-or-fallback>` | <체크 이름> | `<정확한 명령어 또는 관찰 지점>` | <기대 출력 / 상태> |
+| mid   | `<TICKET-or-fallback>` | <체크 이름> | `<...>` | <...> |
+| post  | `<TICKET-or-fallback>` | <체크 이름> | `<...>` | <...> |
+
+추상적 서술 금지. 모든 row는 명령어 또는 관찰 가능한 결과를 포함해야 합니다.
 
 ### 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.8 User Approval Request (사용자 승인 요청 — 본 보고서 상단 참조)
+- 실제 승인 게이트는 본 보고서 **상단 `User Approval Request (사용자 승인 게이트)` 블록**에 있습니다. 이 하위 섹션은 validator가 요구하는 영문 키워드(`User Approval Request`)와 본문 구조 일관성을 위해 남겨 둡니다.
+- 본 섹션에는 승인 결정에 영향을 주는 *플랜 측 보충 메모*만 적습니다(예: 위험을 줄이기 위한 사전 작업, 승인 전 사용자가 확인해 두어야 할 사항). 승인 마커는 본 섹션이 아니라 상단 블록의 체크박스로만 부여합니다.
 
 ### 4.5.9 Open Questions
 - pre-planning에서 발견된 모든 모호점을 항목으로 남겨, 사용자가 승인 전에 해소해야 할 질문 목록으로 사용합니다.
 
+## 4.6 Release Handoff Deliverables (release-handoff runs only)
+
+> **이 섹션은 `task-type` = `release-handoff` 실행 결과에만 포함하세요. 다른 task-type에서는 섹션 전체를 삭제하고 5번 섹션으로 넘어갑니다.**
+>
+> 이 섹션은 git/gh mutating 명령이 실행된 phase의 감사 기록입니다. 모든 mutating command 는 반드시 위 `User Selections` 표의 사용자 응답과 1:1로 대응되어야 하며, 대응되지 않는 mutating command 가 있으면 self-review 가 `contract-violated` 로 종료해야 합니다.
+
+### 4.6.1 Source Verification Report (선행 final-verification 인용)
+- Path (project-relative): `<runs/final-verification/.../reports/final-report-final-verification-<seq>.md>`
+- Quoted final verdict line (정확히 `accepted` 토큰을 포함해야 함):
+  > <원문 인용>
+- 만약 원본 verdict 가 `accepted` 가 아니라면 본 run 은 **실행되지 않아야 했습니다**. self-review 단계에서 contract-violated 로 처리하고 routing 을 `final-verification` 으로 되돌립니다.
+
+### 4.6.2 Feature Branch & Working-Tree State (run 시작 시점)
+- Feature branch (`git rev-parse --abbrev-ref HEAD`): `<branch-name>`
+- `git status --short` 출력:
+  ```
+  <원문 그대로>
+  ```
+- 기존 PR 존재 여부 (`gh pr list --head <branch> --state open --json url --jq '.[0].url'`): `<URL or empty>`
+
+### 4.6.3 User Selections (메뉴 응답 기록)
+| 질문 ID | 질문 본문 | 사용자 응답 (원문) | 응답이 가능한 보기 |
+|---------|-----------|--------------------|--------------------|
+| H1 | 어떤 작업을 실행할까요? | <`commit only` / `commit + PR` / `skip`> | `commit only` / `commit + PR` / `skip` |
+| H2 | PR base 브랜치를 골라주세요. (H1=`commit + PR` 인 경우에만 묻습니다) | <`staging` / `preprod` / `prod` / `main` / `dev` / 사용자가 입력한 브랜치명> | `staging` / `preprod` / `prod` / `main` / `dev` / 직접 입력 |
+| H3 | 워커가 작성한 commit 메시지 / PR 본문 초안을 어떻게 처리할까요? | <`use as-is` / `edit then proceed` / `cancel`> | `use as-is` / `edit then proceed` / `cancel` |
+
+H1 이 `skip` 이거나 H3 가 `cancel` 인 경우, 본 섹션 다음의 4.6.4 ~ 4.6.6 은 빈 결과로 채우고 (mutating 명령 미실행) 4.6.7 routing 만 채웁니다.
+
+### 4.6.4 Executed Commands (실행한 git / gh 명령 로그)
+- **Mutating commands**: 정확한 명령행 / exit code / 한 줄 stdout 요약을 한 행씩 모두 기록합니다. 누락은 contract-violated 입니다.
+- **Read-only inspection commands**: 요약 또는 명령행 목록만 적어도 됩니다.
+
+| # | command (verbatim) | exit code | stdout/stderr 요약 |
+|---|---------------------|-----------|--------------------|
+| 1 | `<예: git add path/to/file.py>` | `0` | `<요약>` |
+
+### 4.6.5 Commit List (생성된 commit)
+- 각 commit 의 short SHA / full SHA / subject / 영향 파일 목록을 한 항목씩 기록합니다.
+- staged 변경이 없어 commit 이 만들어지지 않았다면 다음 한 줄만 적습니다.
+  > `- No commit was produced (working tree had no staged changes).`
+
+### 4.6.6 Pull Request Outcome (PR 결과)
+- 다음 네 가지 중 정확히 하나의 형식으로 한 줄을 적습니다.
+  - `- No PR action requested.` (H1=`commit only` 또는 `skip` 인 경우)
+  - `- PR created: <url>` + 타이틀 + base 브랜치
+  - `- PR reused: <url>` (run 시작 시점에 같은 head 의 open PR 이 이미 존재해 `gh pr create` 를 생략한 경우)
+  - `- PR creation skipped: <reason>` (H3=`cancel`, 또는 push/PR 생성 도중 사용자가 중단 지시한 경우. reason 은 풀어 쓴 한 문장)
+
+### 4.6.7 Routing Recommendation (마지막 phase 라우팅)
+- `release-handoff` 는 lifecycle 의 종착 phase 이므로 일반적으로 `done` 으로 라우팅합니다.
+- 단, H1=`skip` 또는 H3=`cancel` 로 종료된 경우 사용자가 추후 재진입해 다시 release-handoff 를 실행할 수 있는지 한 줄로 명시합니다.
+- 형식 예시: `- Routing: done. PR <url> opened against <base>; no follow-up required.`
+
 ## 5. Clarification Requests for the Next Run
 
 이 섹션은 다음 run으로 넘어가기 전에 사용자에게 받아야 할 입력을 정리하는 자리입니다. `task-type`이 `error-analysis` 또는 `requirements-discovery`이고 지금까지의 증거만으로는 확신 있는 최종 판단이 어려울 때 반드시 채웁니다. 그 외의 `task-type`에서는 lead가 추가 run이 필요하다고 판단했을 때만 채우고, 그렇지 않다면 `- 추가 정보 요청 없음. Section 2의 최종 판단이 그대로 유효합니다.` 라고만 한 줄 적은 뒤 Section 6으로 넘어갑니다.
@@ -118,9 +241,9 @@
 
 이 하위 섹션에는 **사용자가 다음 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 전에 사용자가 채움> |
+| 자료 ID | Ticket ID | 무엇을 / 왜 필요한지 (문장으로 서술) | 어디에서 가져올 수 있는지 (파일 경로, 시스템 이름, URL 등) | 어디에 두면 되는지 / 어떻게 전달해 주실지 | Status | 사용자가 첨부한 위치 또는 메모 (다음 run 전에 사용자가 채움) |
+|---------|-----------|--------------------------------------|------------------------------------------------------------|--------------------------------------------|--------|---------------------------------------------------------------|
+| A1 | `<TICKET-or-fallback>` | <어떤 자료를 왜 받아야 하는지를 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)
 
@@ -132,9 +255,9 @@
 - **무엇을 묻는가**: 약어 없이 풀어 쓴 완전한 문장의 질문.
 - **어떤 형태의 답을 기대하는가**: 예/아니오인지, 둘 중 하나를 고르는 선택인지, 숫자/날짜/파일경로인지, 아니면 짧은 자유서술인지. 가능하면 보기를 함께 제시합니다.
 
-| 질문 ID | 이 답이 필요한 이유 (왜) | 질문 본문 (무엇을 묻는지, 풀어 쓴 문장) | 기대하는 답의 형태 / 보기 | Blocking (예 / 아니오) | Status | 사용자 답변 (다음 run 전에 사용자가 채움) |
-|---------|--------------------------|-----------------------------------------|----------------------------|------------------------|--------|--------------------------------------------|
-| Q1 | <예: "이 결정에 따라 `bugfix`로 이어갈지 `feature`로 이어갈지가 갈리며, 다음 run에서 사용할 task-type이 달라집니다."> | <예: "지난 주 새벽에 보고된 결제 실패가 일회성 사고였는지, 아니면 같은 증상이 다시 발생한 적이 있는지 알려주실 수 있을까요? 같은 증상이 다시 발생했다면 가장 최근 발생 시각과 영향 받은 사용자 수도 함께 부탁드립니다."> | <예: "다음 중 한 줄로 답해 주시면 됩니다 — (a) 일회성으로 그 후 재발 없음, (b) 재발 있음, 가장 최근 시각: YYYY-MM-DD HH:MM, 영향 사용자 수 약 N명"> | 예 | open | <빈칸으로 두고 다음 run 전에 사용자가 채움> |
+| 질문 ID | Ticket ID | 이 답이 필요한 이유 (왜) | 질문 본문 (무엇을 묻는지, 풀어 쓴 문장) | 기대하는 답의 형태 / 보기 | Blocking (예 / 아니오) | Status | 사용자 답변 (다음 run 전에 사용자가 채움) |
+|---------|-----------|--------------------------|-----------------------------------------|----------------------------|------------------------|--------|--------------------------------------------|
+| Q1 | `<TICKET-or-fallback>` | <예: "이 결정에 따라 `bugfix`로 이어갈지 `feature`로 이어갈지가 갈리며, 다음 run에서 사용할 task-type이 달라집니다."> | <예: "지난 주 새벽에 보고된 결제 실패가 일회성 사고였는지, 아니면 같은 증상이 다시 발생한 적이 있는지 알려주실 수 있을까요? 같은 증상이 다시 발생했다면 가장 최근 발생 시각과 영향 받은 사용자 수도 함께 부탁드립니다."> | <예: "다음 중 한 줄로 답해 주시면 됩니다 — (a) 일회성으로 그 후 재발 없음, (b) 재발 있음, 가장 최근 시각: YYYY-MM-DD HH:MM, 영향 사용자 수 약 N명"> | 예 | open | <빈칸으로 두고 다음 run 전에 사용자가 채움> |
 
 ## 6. Recommended Next Steps
 

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

@@ -7,6 +7,7 @@
 - Task ID:
 - Related Tasks:
 - Issue / Ticket:
+  - 값이 비면 워커는 `Task ID`로 폴백한다 (prefix 없이 `8852`처럼). 한 run이 여러 ticket을 동시에 다루면 콤마로 구분 (`TICKET-123, TICKET-456`). 어느 쪽으로도 식별 불가하면 `unknown`을 허용한다.
 - Task Type: `implementation`
 - Requested Outcome:
 

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

@@ -7,6 +7,7 @@
 - Task ID:
 - Related Tasks:
 - Issue / Ticket:
+  - 값이 비면 워커는 `Task ID`로 폴백한다 (prefix 없이 `8852`처럼). 한 run이 여러 ticket을 동시에 다루면 콤마로 구분 (`TICKET-123, TICKET-456`). 어느 쪽으로도 식별 불가하면 `unknown`을 허용한다.
 - Task Type: `implementation-planning`
 - Requested Outcome:
 

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

@@ -7,6 +7,7 @@
 - Task ID:
 - Related Tasks:
 - Issue / Ticket:
+  - 값이 비면 워커는 `Task ID`로 폴백한다 (prefix 없이 `8852`처럼). 한 run이 여러 ticket을 동시에 다루면 콤마로 구분 (`TICKET-123, TICKET-456`). 어느 쪽으로도 식별 불가하면 `unknown`을 허용한다.
 - Requested Task Type:
 - Requested Outcome:
 

package/runtime/templates/reports/release-handoff-input.template.md

@@ -0,0 +1,73 @@
+# OKSTRA Release Handoff Input
+
+## Identity
+
+- Project ID:
+- Task Group:
+- Task ID:
+- Related Tasks:
+- Issue / Ticket:
+- Task Type: `release-handoff`
+- Requested Outcome:
+
+## Source Verification Report
+
+- Path (project-relative) to the `final-verification` final-report whose verdict authorises this handoff:
+- Verbatim quoted line from that report's `## 2. Final Verdict` (MUST read exactly `accepted`):
+- Run timestamp of that final-verification run:
+
+> If this section is empty or cites a verdict other than `accepted`, the lead MUST end the run immediately and route back to `final-verification`. Release-handoff never operates on `conditional-accept` or `blocked` outcomes.
+
+## Working-Tree Snapshot (filled at run start)
+
+- Feature branch (`git rev-parse --abbrev-ref HEAD`):
+- `git status --short` output at run start:
+- Existing PR for this head, if any (`gh pr list --head <branch> --state open --json url --jq '.[0].url'`):
+
+## Candidate PR Base Branches
+
+- Default options offered to the user: `staging` | `preprod` | `prod` | `main` | `dev` | 직접 입력
+- Repo-specific preference, if known (e.g. `main` is the integration branch):
+- Branches that MUST NOT be used as a base in this repo (security / freeze rules):
+
+## Commit Message Drafter Inputs
+
+- Commit type convention this repo follows (`release-please` types, plain conventional commits, free-form):
+- `git diff <base>..HEAD --stat` (or equivalent change summary) for the drafter to ground its message on:
+- Files known to be part of the prior `implementation` run's approved plan:
+- Files appearing in the diff that were in the prior run's `Out-of-plan edits` block:
+
+## PR Body Drafter Inputs
+
+- Linked issues / tickets the PR should reference (URLs):
+- Test plan items the prior `implementation` run already validated:
+- Reviewer hints (teams or individuals the PR should request review from):
+
+## User-Selection Defaults (advisory only — the user still chooses interactively)
+
+- Suggested action (Q1): `commit only` | `commit + PR` | `skip`
+- Suggested base (Q2): one of the candidate base branches above
+- Suggested message handling (Q3): `use as-is` | `edit then proceed`
+
+> These suggestions help the lead phrase its `AskUserQuestion` prompts. They are NOT pre-approvals — every mutating command still requires an explicit user pick at run time.
+
+## Out of Scope
+
+- Actions deliberately excluded from this handoff:
+- Items that look related but belong to a separate handoff or release task:
+- Reason for exclusion (different release window, separate owner, deferred decision):
+
+> The lead MUST NOT extend handoff actions into items listed here. If an excluded item should ship in this PR, edit this section before the run starts — do not silently fold it in.
+
+## Questions for Drafter Worker
+
+1. What commit type and scope best describe the cumulative diff?
+2. What single subject line summarises the change in under 72 characters?
+3. What changed at a behavioural level (not just file-level) that reviewers need to know?
+4. Which prior commits in this feature branch should be referenced or amended by this commit?
+5. Does the diff include any change that requires a follow-up PR (migration squash, config split, etc.) — and if so, should that be noted in the PR body's `## Follow-ups` block?
+
+## Conversion Note
+
+- This input can be used as the release-handoff brief before creating `okstra-task-brief.md`.
+- Reuse the same `Task Group` and `Task ID` as the originating implementation / final-verification runs so the handoff stays attached to the same task history.

package/runtime/templates/reports/task-brief.template.md

@@ -9,6 +9,7 @@
 - Task Key: `<project-id>:<task-group>:<task-id>`
 - Related Tasks:
 - Issue / Ticket:
+  - 값이 비면 워커는 `Task ID`로 폴백한다 (prefix 없이 `8852`처럼). 한 run이 여러 ticket을 동시에 다루면 콤마로 구분 (`TICKET-123, TICKET-456`). 어느 쪽으로도 식별 불가하면 `unknown`을 허용한다.
 - Task Type:
 - Requested Outcome:
 - Owner:
@@ -96,6 +97,10 @@
 2.
 3.
 
+### Standing Ticket-Tagging Rule (always applied by every worker)
+
+- 모든 항목 및 표 행에 ticket을 명시한다. 표 형식은 `Ticket ID` 컬럼, bullet/번호목록·섹션 헤더는 `[TICKETID: <id>]` 태그를 사용한다. 채움 우선순위·폴백·다중 ticket 규칙은 `okstra-team-contract` SKILL의 Ticket Tagging 절을 따른다.
+
 ### Standing Scope-Discipline Questions (always answered by every worker)
 
 - Which adjacent changes did you consider and **deliberately exclude** from this run? List each with a one-line reason.