okstra 0.36.0 → 0.36.1

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

@@ -18,7 +18,7 @@ The skill runs as a single Claude lead synthesis (lightweight mode). A `--cross-
 - User wants a single document that summarizes all non-done tasks with effort, risk, and dependencies
 - A `task-group` exists in `.project-docs/okstra/discovery/task-catalog.json` with at least one task whose `workStatus` is not `done`
 
-**Do NOT use** for single-task analysis (use `okstra-status` instead) or when the user wants to actually execute one task (use the parent `okstra` skill).
+**Do NOT use** for single-task analysis (use `okstra-inspect status` instead) or when the user wants to actually execute one task (use the parent `okstra` skill).
 
 ## Trigger Patterns (recognize both)
 
@@ -78,7 +78,7 @@ This skill performs cross-task synthesis (multi-task classification, dependency
 
 Since the `feat(scripts/render): project workStatus fields into task-catalog entries` change (commit `c44c36b`), `workStatus` is also surfaced directly inside each catalog entry — Step 1 still re-reads each `task-manifest.json` because the manifest is authoritative, but no extra fetch is needed beyond that.
 
-For inference rules when `workStatus` is missing or empty, **defer to the inference table in `skills/okstra-status/SKILL.md` ("Step 4 → Inferring workStatus")** instead of duplicating it here. Apply that table to derive a working value, then filter:
+For inference rules when `workStatus` is missing or empty, **defer to the inference table in `skills/okstra-inspect/SKILL.md` (`status.4` → "Default value convention")** instead of duplicating it here. Apply that table to derive a working value, then filter:
 
 - If the resolved value is `done` (set by the user OR inferred via `currentStatus == "completed"` + terminal next-phase) → exclude.
 - Otherwise (`todo` / `in-progress` / `blocked` / `phase-done` / explicit user value / inferred non-done) → include.
@@ -444,45 +444,15 @@ After writing the file and before printing the completion message in Step 7, you
    python3 validators/validate-schedule.py <output-path>
    ```
 3. If the validator exits non-zero, **fix the file and re-validate**. Do not print the completion message until the validator passes.
-4. If `validators/validate-schedule.py` is not present in the repo, fall back to a manual checklist: confirm each of the 11 mandatory headings appears in the file with the exact spelling above, the title ends with `— Work Schedule`, and the metadata `> Generated:` block is present.
+4. If `validators/validate-schedule.py` is not present in the repo, fall back to a manual checklist: confirm each of the 11 mandatory headings from `### MUST — exact ordered heading list` (above) appears in the file with that exact spelling, the title ends with `— Work Schedule`, and the metadata `> Generated:` block is present.
 
 ## Schedule Document Template
 
-The generated Markdown file MUST follow this structure exactly, mirroring `templates/reports/schedule.template.md`. Do not omit sections; if data is unavailable for a section, include the section with the placeholder `_없음_` rather than skipping it.
+[`templates/reports/schedule.template.md`](../../templates/reports/schedule.template.md) is the byte-for-byte SSOT for section ordering, heading spelling, table columns, and per-section HTML-comment guidance (Dependency Graph Shape A/B, Gantt rules, optional Glossary gate). Do not omit sections; if data is unavailable, render the section with `_없음_` rather than skipping it.
 
-### Required Top Header
+The two rules below complement the template — they encode COMPUTATION that the template scaffold cannot carry inline.
 
-```markdown
-# <Title> — Work Schedule
-
-> Generated: <YYYY-MM-DD HH:MM> | Project: <project-id> | Task Group: <task-group>
-> Source: okstra <mode> (<N> tasks included, <M> done excluded)
-
----
-```
-
-### Section: At a Glance (FIRST content section after header)
-
-This section gives the reader the entire schedule scope at a single screen.
-
-```markdown
-## At a Glance
-
-**총 <N>개 task / 예상 소요: <X.X> ~ <Y.Y> days (Effort 합산)**
-
-| # | Task ID | Title | Category | Priority | Effort | Days | taskType | Risk | Phase |
-|---|---------|-------|----------|----------|--------|------|----------|------|-------|
-| 1 | <TASK-ID> | <Title> | <category> | <P0~P3> | <S/M/L/XL> | <range> | <taskType> | <risk> | <1/2/3> |
-| ... |
-
-**Effort 분포**: S × <n> / M × <n> / L × <n> / XL × <n>
-**Risk 분포**: Very Low × <n> / Low × <n> / Medium × <n> / Med-High × <n> / High × <n>
-**Repo별 영향**: <repo1> (<n>) / <repo2> (<n>) / ...
-
----
-```
-
-Effort-to-Day mapping (used to compute the total day range):
+### Effort-to-Day mapping (At a Glance total)
 
 | Size | Day(s)   |
 |------|----------|
@@ -491,131 +461,18 @@ Effort-to-Day mapping (used to compute the total day range):
 | L    | 3 - 5    |
 | XL   | 5 - 10   |
 | XXL  | 10 -     |
-Sum the lower bounds for the lower total and the upper bounds for the upper total.
-
-### Section: Executive Summary
-
-```markdown
-## Executive Summary
-
-<Phase 분류 요약 + 진행 전략 — 2~4문장>
-
-- **Phase 1 (Critical Fixes)**: <n>개 task — <summary>
-- **Phase 2 (Enhancements)**: <n>개 task — <summary>
-- **Phase 3 (Architecture)**: <n>개 task — <summary>
-
-### Effort Sizing 기준
-
-| Size | 기준 | Day(s) |
-|------|------|--------|
-| **S** | 1-2 files, 1 repo, 테스트 수정만, DB 변경 없음 | 0.5 - 1 |
-| **M** | 3-5 files, 1 repo, 신규 테스트 포함, DB 변경 없음 | 2 - 3 |
-| **L** | 5-15 files, 2-3 repos, 순차 배포, 패키지 릴리스 포함 가능 | 3 - 5 |
-| **XL** | 15+ files, 3+ repos + infra, frontend 동시 변경, 아키텍처 전환 | 5 - 10 |
-| **XXL** | 작업 더 세분화 필요 | 10 - |
-
----
-```
-
-### Section: Task Dependency Graph
-
-This section MUST follow ONE of two exact shapes — free-form ASCII art, mermaid, PlantUML, or Graphviz are all forbidden.
-
-**Shape A — no dependency data.** Single italicized blockquote-line under the heading, literal Korean:
-
-```
-_의존 정보 없음_
-```
-
-**Shape B — adjacency-list inside a plain fence.** When dependency edges are extracted from per-task reports, emit them as a fenced block with NO language tag. Each non-empty line is one of:
-
-- An adjacency line: `<TASK-ID> -> <TASK-ID>[, <TASK-ID>]*`
-- A comment line starting with `#` (free prose, max one per group)
-- A blank line (group separator)
-
-```
-DEV-1 -> DEV-2, DEV-3
-DEV-2 -> DEV-4
-# Phase 3 fan-out
-DEV-5 -> DEV-6
-```
-
-Rules:
-- Use ASCII arrow `->` only. Unicode `→` is rejected so downstream tooling does not have to handle both.
-- Both endpoints MUST be `TASK-ID` literals (the same identifiers used in the At a Glance table). Free text is forbidden.
-- Fence MUST be plain ` ``` ` with no language tag. ` ```mermaid `, ` ```plantuml `, ` ```graphviz `, ` ```dot ` are all rejected.
-- If only one task is in scope (no dependencies), use Shape A — do NOT emit an empty fence.
-
-### Section: Phase 1 / Phase 2 / Phase 3
-
-For each phase, repeat the per-task block:
-
-````markdown
-## Phase <N>: <Name>
-
-### <N>-<i>. <TASK-ID> — <Title>
-
-| Item | Detail |
-|------|--------|
-| **Category** | <category> |
-| **Priority** | <P0~P3> |
-| **Effort** | **<S/M/L/XL>** (<scope summary>) |
-| **Status** | <workStatus + currentPhase summary> |
-| **Risk** | <risk> |
-| **Scope** | <files / repos summary> |
-| **Repo** | <repos> |
-
-**Problem**: <…>
-
-**Solution**: <…>
-
-**Work Breakdown**:
-
-| Step | File | Action | Detail |
-|------|------|--------|--------|
-| 1 | <path> | CREATE/MODIFY/VERIFY | <detail> |
-| ... |
-
-**Verification Commands**:
-```bash
-<commands>
-```
-
-**Rollback**: <…>
-
----
-````
-
-If a task entry is `[NEEDS-OKSTRA-RUN]` or `[PARSE-ERROR: <section>]`, place the marker immediately under the task heading and fill only the available fields.
-
-### Section: Execution Priority Matrix
-
-```markdown
-## Execution Priority Matrix
-
-| Priority | Task | Effort | Risk | Next Action |
-|----------|------|--------|------|-------------|
-```
-
-Each row summarizes the next concrete engineering action per task in priority order. No `Done` / `Ready?` / `Blocking Decisions` columns — schedule is a client-facing plan, not an internal todo board.
-
-### Section: Cross-Task Dependencies & Shared Concerns
-
-Free-form prose listing inter-task overlaps, shared packages, release order, etc.
-
-### Section: Risk Mitigation Strategy
 
-Enumerate phase-level risk strategies as numbered list.
+Sum the lower bounds across all in-scope tasks for the lower total, and the upper bounds for the upper total. The same table is rendered as descriptive reference under `### Effort Sizing 기준`; this copy is the source-of-truth for the At a Glance computation.
 
-### Section: Recommended Immediate Actions
+### `[NEEDS-OKSTRA-RUN]` / `[PARSE-ERROR: <section>]` placement
 
-Markdown bullet list of next concrete engineering actions, one item per line: `- <action>`. Numbered lists (`1. …`) and checkbox lists (`- [ ] …`) are both forbidden — the schedule is a client-facing plan, not an internal todo.
+When a task entry is tagged with one of these markers, place the marker immediately under the per-task heading inside the corresponding Phase section and fill only the available fields. Do NOT relocate it to a sibling section.
 
 ## Edge Cases
 
 | Case | Handling |
 |------|----------|
-| `workStatus` field absent or empty | Resolve via the okstra-status inference table; include unless the resolved value is `done` |
+| `workStatus` field absent or empty | Resolve via the `okstra-inspect status.4` inference table; include unless the resolved value is `done` |
 | Filtered task count is 0 | Emit "모든 task가 done" message; do NOT create a file |
 | `latestReportPath` missing or unreadable | Tag entry with `[NEEDS-OKSTRA-RUN]`; include manifest metadata only |
 | Report parsing fails for a specific section | Tag with `[PARSE-ERROR: <section>]`; continue with the rest |

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

@@ -17,7 +17,7 @@ machine, or when adopting okstra in a new project.
 ## When NOT to use
 
 - A task is already in flight → use [`okstra-run`](../okstra-run/SKILL.md) or
-  [`okstra-status`](../okstra-status/SKILL.md).
+  [`okstra-inspect status`](../okstra-inspect/SKILL.md).
 - Day-to-day usage in a project that already has `project.json` — skip this skill.
 
 ## Prerequisites

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

@@ -70,8 +70,11 @@ Every worker prompt MUST start with the following anchor headers, in this exact
 
 1. `**Project Root:** <absolute-path>` — absolute target project root (from `{{PROJECT_ROOT}}` in the lead's prompt). Required so the worker can self-anchor without relying on inherited cwd.
 2. `**Prompt History Path:** <project-relative-path>`
-3. `**Result Path:** <project-relative-path>` — canonical destination for the worker's result file. Workers resolve it to absolute against `**Project Root:**` and use it for the post-completion existence check (see codex-worker / gemini-worker step 8c, and Lead's redispatch policy below). The path identifies a single file; do NOT deliver a directory.
+3. `**Result Path:** <project-relative-path>` — canonical destination for the worker's result file. Workers resolve it to absolute against `**Project Root:**` and use it for the post-completion existence check (see CLI wrapper agents' step 8c, and Lead's redispatch policy below). The path identifies a single file; do NOT deliver a directory.
 4. `Assigned worker prompt history path: <absolute-path>` — same as the prompt-history path but resolved against `Project Root`. Codex/Gemini wrapper subagents extract this exact line.
+5. `**Worker Preamble Path:** <absolute-path>` — points to `~/.okstra/templates/worker-prompt-preamble.md` (canonical SSOT for Required Reading + Error Reporting + Anchor / Output sections). Workers Read this file end-to-end before producing any output. This anchor replaces the ~80 lines of inlined `[Required reading]` / `[Error reporting]` boilerplate that earlier versions injected into every dispatch.
+6. `**Errors log path:** <absolute-path>` — run-level errors JSONL.
+7. `**Errors sidecar path:** <absolute-path>` — this worker's per-run sidecar JSON.
 
 The body must include: role name, task type, task key, required bundle paths, assigned model, output contract, evidence handling rules, and any relevant config/deployment expectations from `reference-expectations.md`.
 
@@ -83,120 +86,26 @@ Before dispatching any required worker, lead persists the exact worker prompt to
 
 Send byte-identical dispatch prompts to every analysis worker (Claude / Codex / Gemini), modulo the role label and the wrapper-specific path headers enumerated in the "Dispatch-prompt invariant" rule of the Role Definitions section. The prior "role-specific emphasis" guidance is retired — emphasis in the body biases each worker toward its lens and silently kills convergence (see Role Definitions for the failure mode). Specialization lives in Section 6 of the worker output, not in the dispatch prompt body.
 
-### Required reading clause (analysis workers + report-writer worker)
+### Required Reading + Error Reporting via Worker Preamble (SSOT)
 
-Inject the following clause verbatim into every analysis worker's prompt and into the report-writer worker's prompt. Workers tend to skim long input documents — especially when the carry-in clarification response is structurally similar to the file they will write into next. This clause is the single biggest lever against that failure mode; do not paraphrase it, do not move it lower in the prompt, and do not omit any input file path.
+The lead does NOT inline `[Required reading]` or `[Error reporting]` blocks into worker prompts. Both contracts live in a single canonical file at `~/.okstra/templates/worker-prompt-preamble.md` (source: `templates/worker-prompt-preamble.md`). The lead injects the path via the `**Worker Preamble Path:**` anchor header (header #5 above) and each worker Reads that file end-to-end before producing output.
 
-Replace placeholder file paths in the `[Required reading]` block with the actual project-relative paths derived from the run's `instruction-set/` and (if applicable) the carry-in clarification response.
+What the lead MUST still do per dispatch:
+- Inject the input file enumeration into the dispatch prompt body via an `## Inputs` section (or any heading the recipient agent expects), listing the actual project-relative paths derived from the run's `instruction-set/` and the carry-in clarification response if any. The preamble describes the rules; the lead provides the specific paths for THIS run.
+- Inject the absolute `**Errors log path:**` and `**Errors sidecar path:**` headers (#6 and #7 above) — workers cannot synthesize these paths.
+- Omit the preamble pointer for reverify dispatches (Phase 5.5 lightweight mode) — see [okstra-convergence](../okstra-convergence/SKILL.md) "Reverify prompt: required-reading suppression".
 
-**Audience-scoped enumeration (BLOCKING — performance optimization):**
+Audience-scoped file enumeration (BLOCKING — performance optimization):
 
-Different recipients need different files. Do NOT include `final-report-template.md` in analysis worker prompts: analysis workers produce findings (not the final report), and forcing them to read the template inflates token usage without changing finding quality.
-
-| Recipient | Files included in `[Required reading]` |
+| Recipient | Files the lead lists under `## Inputs` |
 |---|---|
 | Claude / Codex / Gemini analysis workers | task-brief, analysis-profile, analysis-material (if present), reference-expectations, clarification-response (if carry-in) |
 | Report writer worker (Phase 6) | all of the above **plus** `final-report-template.md` |
-| Reverify dispatches (Phase 5.5, lightweight mode) | **do NOT inject the `[Required reading]` clause at all** — see [okstra-convergence](../okstra-convergence/SKILL.md) "Reverify prompt: required-reading suppression". |
-
-**Asymmetry between claude-worker and codex/gemini-worker prompts (NOT a bug):**
-
-The dispatch prompt the lead constructs for `claude-worker` is intentionally shorter than for `codex-worker` / `gemini-worker`. Do NOT "fix" this by re-injecting `[Required reading]` / `[Error reporting]` / `[Output Contract]` blocks into the claude-worker prompt:
-
-- `claude-worker` is an in-process Claude subagent. The Agent SDK auto-loads `agents/claude-worker.md`, which already contains `## Required Reading Before Any Analysis`, `## Worker Output Structure`, and `## Error reporting`. Re-injecting them is redundant and wastes tokens.
-- `codex-worker` / `gemini-worker` shell out to a CLI. The CLI never sees the agent definition file — it only sees the prompt body passed via stdin. Therefore the lead MUST inject those three blocks into the dispatch prompt for those two workers.
-
-Worker definition file size (claude-worker ~106 lines vs codex/gemini ~175–179 lines) is NOT evidence of incompleteness — it reflects the in-process vs CLI-wrapper distinction.
-
-```
-[Required reading]
-You are required to read every input file listed below from the very first
-character to the very last character before you produce any analysis output.
-Skimming, partial reads, jumping to a single section, or relying on prior
-knowledge of a similar file's structure is not acceptable. Each file may
-contain decisive context that is not surfaced in its summary or first page.
-
-Required files for this run (read in this order, end-to-end, no exceptions):
-
-  1. <Project Root>/<instruction-set>/task-brief.md
-  2. <Project Root>/<instruction-set>/analysis-profile.md
-  3. <Project Root>/<instruction-set>/analysis-material.md   (only if present)
-  4. <Project Root>/<instruction-set>/reference-expectations.md
-  5. <Project Root>/<instruction-set>/clarification-response.md   (only if a carry-in was provided for this run)
-  6. <Project Root>/<instruction-set>/final-report-template.md   (REPORT WRITER ONLY — omit for analysis workers and reverify dispatches)
-
-Reading rules:
-
-  - Use a single Read tool call per file with no offset and no limit. Do not
-    page through the file with offset/limit unless the file is genuinely too
-    large for one read; if you must page, you MUST cover the entire file
-    before moving on, and you MUST state the page boundaries you used in your
-    Findings section.
-  - For the carry-in clarification response, read the conditional
-    `## 0. Clarification Response Carried In From Previous Run` section
-    (rendered only when carry-in is non-empty) and every row of
-    `## 5. Clarification Items` (`C-001`, `C-002`, ...) in full,
-    including rows whose `User input` cell is blank. The fact that you
-    will write your output into a file with a structurally similar
-    section 5 is NOT an excuse to skim — the prior `C-*` rows carry
-    context you cannot reconstruct from the new run alone.
-  - Write the Reading Confirmation block to your **audit sidecar** at
-    `runs/<task-type>/worker-results/<worker>-audit-<task-type>-<seq>.md`
-    (sibling to the main worker-results file). One short line per input
-    file confirming end-to-end reading, e.g. "Read task-brief.md
-    end-to-end (147 lines)." Do NOT include a `## 0. Reading Confirmation`
-    heading in the main worker-results file — the validator now fails
-    worker-results that contain one. If you cannot truthfully confirm a
-    file end-to-end, record a `tool-failure` in the errors sidecar
-    instead of fabricating Findings.
-  - Do not collapse multiple input files into a single mental summary before
-    reading them all individually. Each file has its own canonical role
-    (brief = the user's request, profile = the lead's rules for this phase,
-    reference-expectations = ground-truth config/deployment values,
-    clarification-response = prior run's open questions and the user's
-    answers, final-report-template = the structure your eventual writeup
-    must conform to). Conflating them loses signal.
-```
-
-### Error reporting clause (analysis workers)
+| Reverify dispatches | none — the lead provides only the items to reverify |
 
-Inject the following clause verbatim into every analysis worker's prompt
-(Claude / Codex / Gemini). All three workers' subagent definitions already
-include the same contract — the prompt clause exists as a redundant safety
-net so any worker dispatched without its custom definition still receives
-identical instructions.
-
-```
-[Error reporting]
-If any tool call you make (Bash, Read, Edit, MCP, etc.) returns a non-zero
-exit code, raises an exception, or otherwise fails its intended effect,
-append a single entry to your worker errors sidecar at:
-
-  runs/<task-type>/worker-results/<role-slug>-errors-<task-type>-<seq>.json
-
-Schema (create the file with {"schemaVersion": 1, "errors": []} if absent):
-
-  {
-    "ts": "<ISO 8601 UTC>",
-    "phase": "<current okstra phase>",
-    "errorType": "tool-failure",
-    "command": "<failed command/tool signature>",
-    "commandKind": "bash | tool:Read | tool:Edit | mcp | ...",
-    "exitCode": <int or null>,
-    "durationMs": <int or null>,
-    "message": "<one-line human summary>",
-    "stderrExcerpt": "<first ~2KB of stderr, or null>",
-    "context": { ... or null }
-  }
-
-Do NOT include source / recordedAt / agent / agentRole / model / taskKey —
-Lead will fill those in. Do NOT use errorType values other than
-"tool-failure" in the sidecar. Continue your task after recording; do not
-abort unless the failure makes the task impossible.
-```
+Asymmetry note: `claude-worker` runs in-process and the Agent SDK auto-loads its agent definition; lead's dispatch prompt body for claude-worker can therefore be shorter than for codex/gemini. The Worker Preamble pointer is still emitted for all three so the contract source is identical regardless of dispatch path.
 
-The substituted `<role-slug>` is `claude-worker`, `codex-worker`, or
-`gemini-worker` matching the receiving role.
+Send byte-identical dispatch prompts to every analysis worker (Claude / Codex / Gemini), modulo the role label and the wrapper-specific path headers. The prior "role-specific emphasis" guidance is retired — specialization lives in Section 6 of the worker output, not in the dispatch prompt body.
 
 ## Terminal Statuses
 

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

@@ -0,0 +1,204 @@
+---
+type: brief
+brief-id: <ticket-id>-<file-title>          # equals the filename stem
+parent-id: self                              # always `self` at root; child briefs use parent's brief-id
+ticket-id: <LIN-1234 | PROJ-42 | gh-repo-123 | notion-abcdef12 | "">
+source-type: <file | linear | jira | github | notion | url | user-input>
+task-group: <task-group>
+depth: 0                                     # 0=parent/single, 1=child, 2=grandchild, ...
+created: <YYYY-MM-DD>
+generator: okstra-brief
+reporter-confirmations: <complete | partial | pending | skipped>  # set by Step 6.5
+# codebase-scan variant frontmatter (omit for reporter-input briefs):
+scope: <reporter-input | codebase>              # 'codebase' for codebase-scan variant; omit for reporter-input variant
+priority-lenses: []                              # codebase-scan only: lens enum subset, size 1..4
+scan-scope: []                                   # codebase-scan only: 1+ paths
+out-of-scope: []                                 # codebase-scan only: optional
+candidate-cap: 8                                 # codebase-scan only: 1..12, default 8
+---
+
+# Task Brief: <task_group>/<filename-without-ext>
+
+> Generated: okstra-brief · <YYYY-MM-DD>
+> Source type: <file | linear | jira | github | notion | url | user-input>
+> Tracker key (if any): <LIN-1234 | PROJ-42 | gh-repo-123 | notion-abcdef12>
+> Parent brief (child briefs only): <relative path>
+> Recommended next phase: <requirements-discovery | error-analysis>  ← from Step 6
+> Handoff contract: see `prompts/profiles/_common-contract.md` § "Brief handoff contract"
+
+## Source Material
+
+<!-- author guidance — strip out at fill-in time:
+Paste each source separately and as-is. No paraphrasing, summarizing, or
+restructuring. Format conversion (e.g. Jira ADF → Markdown) is allowed and
+must be annotated in the header meta. Heading was originally
+"Source Material (verbatim — do not modify)" — the parenthetical is a
+reviewer note, not body text.
+-->
+
+### Source 1 — <type: file | linear | jira | github | notion | url | user-input>
+
+- ref: <abs file path | LIN-1234 | https://... | "conversation synthesis">
+- fetched-via: <Read | mcp__linear__getIssue | mcp__notion__... | gh issue view | WebFetch | user-paste>
+- fetched-at: <YYYY-MM-DD HH:MM>
+- format: <as-is | "Jira ADF → Markdown (semantics preserved)" | "tool-truncated — missing body requested from reporter">
+
+```
+<Paste the raw source here without changing a single character.>
+```
+
+<!-- Repeat `### Source N — …` blocks as needed. -->
+
+## Context
+
+<Background / scope / why now. If self-evident from Source Material, quote
+it briefly and stop. Use the blockquote below when augmentation is needed.>
+
+> augmented: <label> — <Interpretation added by the skill or user.>
+
+<!-- label MUST be one of: `evidence-link` / `format-conversion` /
+`terminology-mapping` / `intent-inference`. Do NOT add any extra
+interpretation outside the `> augmented:` blockquote. -->
+
+## Problem / Symptom
+
+<Current state. For bugs: repro / observed / expected. For greenfield: gap
+between current and desired.>
+
+<!-- Same source-quote + `> augmented:` rule as the Context section. -->
+
+## Desired Outcome
+
+<Shape of success.>
+
+<!-- Do NOT prescribe a solution — that belongs to implementation-planning. -->
+
+## Constraints
+
+<Deadlines, compatibility, technical/operational limits. Use _(none)_ if
+none.>
+
+## Scan Scope
+
+<!-- codebase-scan variant only — omit this section for reporter-input briefs. -->
+<!-- Author guidance: one bullet per `scan-scope` path with a short description of what lives there. -->
+
+- <path>: <one-line description of contents / responsibility>
+
+## Priority Lenses
+
+<!-- codebase-scan variant only — omit this section for reporter-input briefs. -->
+<!-- Author guidance: one bullet per priority lens explaining why it is a priority for THIS scope. -->
+
+- <lens>: <short rationale tying this lens to the scope's risk surface>
+
+## Related Artifacts
+
+- <file path / URL / issue / prior task-key>
+
+## Open Questions
+
+<!-- author guidance — strip out at fill-in time:
+Prefix every row with one of these signals so the next phase knows how to
+handle it. Free-form rows are allowed only as `general:`.
+
+Allowed signals:
+- `general: <unresolved question the user flagged>`
+- `terminology: <reporter word> — needs canonical resolution against
+  <PROJECT_ROOT>/.project-docs/okstra/glossary.md`
+- `intent-check: <restated inference> — confirm with reporter`
+  (auto-paired with every `intent-inference` augmentation)
+- `conversion-block: <reporter statement> — could not be mapped to project
+  vocabulary; reporter query required`
+- `adr-candidate: <topic>` — signal only; `implementation-planning`
+  evaluates and, if accepted, drafts a decision file at
+  `<PROJECT_ROOT>/.project-docs/okstra/decisions/<NNNN>-<slug>.md`.
+
+Use `_(none)_` only if every signal is empty. `intent-check:` and
+`conversion-block:` rows that are answered in Step 6.5 are NOT removed
+from this list — they receive a `[CONFIRMED <YYYY-MM-DD> → RC-N]`
+marker that links to the corresponding entry under
+`## Reporter Confirmations`.
+-->
+
+- <fill in one row per signal, or replace with `_(none)_`>
+
+## Reporter Confirmations
+
+<!-- Populated by Step 6.5. Each subsection records one reporter answer
+verbatim, with a link back to the originating `Open Questions` row. -->
+
+_(none — pending or skipped)_
+
+<!-- when populated, the shape is:
+### RC-1 — <intent-check: or conversion-block: row id / topic>
+- asked: <YYYY-MM-DD HH:MM>
+- linked-row: `<exact Open Questions row text>`
+- answer (verbatim):
+
+  > <reporter's answer, byte-for-byte>
+-->
+
+## Augmentation
+
+<!-- author guidance — strip out at fill-in time:
+Cross-references / interpretation / context added by the user or skill that
+is not in the original source. May be empty. Keep this section visually
+separated from Source Material — never inline it inside Source Material.
+
+Every entry below must start with one of the four labels:
+`evidence-link` / `format-conversion` / `terminology-mapping` /
+`intent-inference`. Unlabelled entries are forbidden.
+-->
+
+### Domain alignment
+
+<!-- author guidance — strip out at fill-in time:
+Observations from Step 3b and the outcome of Step 4.5 (glossary applied
+vs. skipped). The actual glossary edits live in
+`<PROJECT_ROOT>/.project-docs/okstra/glossary.md` when applied; this
+section records what happened. Decision candidates are NOT recorded here —
+they flow through `Open Questions` as `adr-candidate:` rows for
+`implementation-planning` to evaluate (and, if accepted, draft into
+`<PROJECT_ROOT>/.project-docs/okstra/decisions/`).
+
+Allowed entry shapes:
+- `terminology-mapping: <reporter word> → <okstra glossary canonical>` —
+  routine glossary alignment, paired with `terminology:` in Open Questions
+  when unresolved.
+- `terminology-mapping: applied glossary: <term> → <PROJECT_ROOT>/.project-docs/okstra/glossary.md`
+- `terminology-mapping: skipped glossary: <term> = <definition>` —
+  Step 4.5 outcomes.
+Use `_(none)_` if every alignment entry is empty.
+-->
+
+- <fill in one entry per alignment, or replace with `_(none)_`>
+
+### Evidence links (file / symbol resolution)
+
+<!-- Allowed entry shapes:
+`evidence-link: <reporter phrase> → <relative path>:<line>` or
+`evidence-link: <reporter phrase> → <symbol> in <relative path>`.
+Use `_(none)_` if none. -->
+
+- <fill in one entry per link, or replace with `_(none)_`>
+
+### Intent inferences
+
+<!-- Every entry here is an unverified hypothesis. Each one MUST have a
+paired `intent-check:` row under Open Questions.
+
+Allowed entry shape:
+`intent-inference: <reporter phrase> → <qualitative restatement>`
+(qualitative only — never invent numeric thresholds).
+Use `_(none)_` if none. -->
+
+- <fill in one entry per inference, or replace with `_(none)_`>
+
+### Format conversions
+
+<!-- Allowed entry shape:
+`format-conversion: <ref> — <e.g. Jira ADF → Markdown, semantics preserved>`.
+Use `_(none)_` if none. -->
+
+- <fill in one entry per conversion, or replace with `_(none)_`>

package/runtime/templates/reports/schedule.template.md

@@ -55,14 +55,23 @@ taskType: "{{FM_TASK_TYPE}}"
 ## Task Dependency Graph
 
 <!-- Use ONE of:
-     (A) literal `_의존 정보 없음_` when no edges exist;
-     (B) plain ``` fenced adjacency-list block — see SKILL §"Section: Task Dependency Graph".
+     (A) literal `_의존 정보 없음_` when no edges exist (single-task scope or no extracted edges).
+     (B) plain ``` fenced adjacency-list block. Each non-empty line is one of:
+         - adjacency: `<TASK-ID> -> <TASK-ID>[, <TASK-ID>]*`
+         - comment: `# <free prose>` (max one per group)
+         - blank: group separator
      Example (B):
      ```
      DEV-1 -> DEV-2, DEV-3
      DEV-2 -> DEV-4
+     # Phase 3 fan-out
+     DEV-5 -> DEV-6
      ```
-     Mermaid / PlantUML / Graphviz / Unicode '→' are all forbidden. -->
+     Rules:
+     - ASCII arrow `->` only; Unicode `→` is rejected so downstream tooling does not handle both.
+     - Both endpoints MUST be `TASK-ID` literals (same identifiers as the At a Glance table). Free text is forbidden.
+     - Fence MUST be plain ``` with NO language tag. ```mermaid / ```plantuml / ```graphviz / ```dot are all rejected.
+     - If only one task is in scope (no dependencies), use Shape A — do NOT emit an empty fence. -->
 _의존 정보 없음_
 
 ---