thoth-agents 0.2.11 → 0.3.1

package/src/skills/_shared/thoth-mem-convention.md

@@ -1,123 +0,0 @@
-# thoth-mem Convention
-
-## Harness Scope
-
-This convention defines harness-neutral thoth-mem semantics for SDD artifacts.
-Use the thoth-mem MCP surface as the portable vocabulary:
-`mem_recall`, `mem_save`, `mem_context`, `mem_get`, `mem_project`, and
-`mem_session`.
-
-If a needed operation is unavailable in the active runtime, report the
-unsupported capability and do not pretend persistence/recovery succeeded.
-
-Governance that a harness cannot hard-enforce remains instruction-level:
-role ownership, parent session/project scoping, prompt-save prohibitions, and
-SDD namespace protection.
-
-Root-owned delegation handoffs follow the same rule: handoff bodies stay in
-root-owned summary/checkpoint memory when available; subagent prompts carry only
-task instructions plus parent-scoped recovery instructions.
-
-## Mode Scope
-
-This convention applies only when the artifact store mode includes thoth-mem:
-`thoth-mem` and `hybrid`.
-
-- In `openspec` mode, skip thoth-mem saves.
-- In `openspec` mode, skip thoth-mem recovery and use filesystem artifacts.
-
-## Tool Names
-
-Use callable names exposed by the active runtime, mapped to the six-tool MCP
-surface above.
-
-## Topic Key Format
-
-All SDD artifacts use this deterministic pattern:
-
-```text
-sdd/{change-name}/{artifact}
-```
-
-Supported artifact names:
-
-- `proposal`
-- `spec`
-- `design`
-- `design-brief`
-- `tasks`
-- `plan-review`
-- `apply-progress`
-- `verify-report`
-- `archive-report`
-- `state`
-
-Use the same value for `title` and `topic_key` unless there is a strong reason
-not to.
-
-## State Artifact Format
-
-The orchestrator semantic role persists a lightweight state checkpoint after
-each SDD phase transition to enable recovery:
-
-```yaml
-change: {change-name}
-phase: {last-completed-phase}
-mode: {thoth-mem|openspec|hybrid|none}
-pipeline: {accelerated|full}
-artifacts:
-  proposal: true
-  spec: false       # always false in accelerated pipeline
-  design: false     # always false in accelerated pipeline
-  tasks: false
-  plan-review: false
-  apply-progress: false
-  verify-report: false
-  archive-report: false
-last_updated: {ISO 8601 timestamp}
-```
-
-Persist with `mem_save` using canonical SDD topic keys and required metadata:
-`title`, `topic_key`, `type`, `project`, `scope`, and `content`.
-
-Recovery path for state artifacts:
-`mem_recall(mode="compact", query="topic_key:sdd/{change-name}/state")` ->
-`mem_recall(mode="context", query="topic_key:sdd/{change-name}/state")` when needed ->
-`mem_get(id=...)` (or `mem_get(include_timeline=true)` when chronology matters) ->
-parse YAML -> restore phase state.
-
-## Recall Funnel Protocol
-
-For delegated handoffs, subagents may use recall only when dispatch includes
-both parent `session_id` and `project`.
-
-1. `mem_recall(mode="compact")` with exact topic-key query for token-efficient
-   IDs and ranking.
-2. `mem_recall(mode="context")` to expand strongest hits into retrieved text.
-3. `mem_get(id=...)` to retrieve full artifact content; use
-   `mem_get(include_timeline=true)` when chronology matters.
-
-Use HyDE/fused hybrid recall (sentence + chunk vectors, FTS, KG enrichment) for
-semantic or ambiguous searches; set `mem_recall` `limit` from 1 to 20; narrow
-with `topic_key`, `type`, `time_from`, `time_to`, `scope`, `project`, and
-`session_id` filters. Use `mem_get` with `kind="observation"|"prompt"`,
-`include_timeline=true` plus `before`/`after`, and `offset`/`max_length` for
-large content. Use `mem_context(recall_query=...)` or bounded
-`mem_project(action="graph"|"topics"|"topic")` for supplemental project
-context; `mem_project(action="graph")` relations are `HAS_TYPE`, `IN_PROJECT`,
-`HAS_TOPIC_KEY`, `HAS_WHAT`, `HAS_WHY`, `HAS_WHERE`, and `HAS_LEARNED`.
-Supplemental context does not replace the recall funnel.
-
-## Save Contract
-
-**CRITICAL:** The orchestrator must persist the `state` artifact after each SDD
-phase transition for recovery.
-
-Persist SDD artifacts with stable deterministic topic keys so repeated saves
-upsert instead of duplicating. For `sdd-apply`, save `apply-progress` and
-re-save updated `tasks` after checkbox changes.
-
-Write-capable subagents may call `mem_save` only when dispatch explicitly
-permits delegated durable implementation observations or deterministic SDD
-artifact writes under parent session/project. General observations stay outside
-`sdd/*`; deterministic SDD artifacts keep `sdd/{change-name}/{artifact}`.

package/src/skills/executing-plans/SKILL.md

@@ -1,288 +0,0 @@
----
-name: executing-plans
-description: Execute SDD task lists with real-time progress tracking, sub-agent dispatch, and verification checkpoints.
-metadata:
-  author: thoth-agents
-  version: '1.0'
----
-
-# Executing Plans Skill
-
-Use this skill to execute an existing SDD task list end to end while keeping
-task progress durable, ordered, and verifiable.
-
-## Shared Conventions
-
-- [../_shared/openspec-convention.md](../_shared/openspec-convention.md)
-- [../_shared/persistence-contract.md](../_shared/persistence-contract.md)
-- [../_shared/thoth-mem-convention.md](../_shared/thoth-mem-convention.md)
-
-## Progress Tracking Invariants
-
-The orchestrator owns task progress tracking.
-
-- The orchestrator marks `- [ ]` to `- [~]` before dispatching execution work.
-- The orchestrator marks `- [~]` to `- [x]` only after successful results are
-  received and verified.
-- The orchestrator marks `- [-]` with a clear reason when a task is skipped or
-  fails after escalation.
-- Sub-agents execute assigned work and return structured results. They do not
-  own checkbox updates.
-- Same-agent execution batches are allowed when consecutive ready tasks share
-  dependencies, scope, and verification context.
-- For a same-agent batch, keep checkbox state per task: mark each batched task
-  `- [~]` before dispatch, and later mark each task `- [x]` or `- [-]` only
-  from task-specific evidence in the returned result.
-- Never proceed without updating the current task state first.
-- Re-read the canonical tasks artifact after each edit to confirm persistence.
-- Persistence mode determines target stores: `openspec` → file only,
-  `thoth-mem` → memory only, `hybrid` → both. Never skip a store that the
-  active mode requires.
-- The artifact governance validator is outside this skill's responsibility.
-  If present, it is a report-only checkpoint after `sdd-tasks` and before a
-  future `sdd-apply` entrypoint; it does not change checkbox state or task
-  ownership.
-- `openspec/` files are coordination artifacts, not source code. The
-  orchestrator may read and edit them directly for progress tracking and state
-  management only when the active mode includes openspec artifacts.
-- Keep visible task state on the active progress tracking surface while
-  preserving the canonical task artifact. Use the visible progress surface
-  when available, plus the same canonical `tasks.md` and/or thoth-mem artifacts.
-- Task state updates are NOT optional and NOT deferred — they happen in
-  real-time as execution proceeds.
-- Every state transition (pending→in-progress, in-progress→completed,
-  in-progress→skipped) MUST be persisted BEFORE moving on.
-- Real-time tracking is a hard invariant, not a best practice. Deferred updates
-  are a protocol violation, and batch dispatches must still record each task's
-  state transition before and after the delegated work.
-
-## When to Use
-
-- Executing an SDD task list
-- Resuming work from a previous session
-- Multi-task implementation with an existing change already defined
-
-## Workflow
-
-### Phase 1: Load
-
-1. Determine the artifact store mode from config before reading or writing any
-   SDD artifacts.
-2. Load task artifacts using mode-aware retrieval:
-   - `openspec`/`hybrid`: scan `openspec/changes/` for active changes and read
-     `tasks.md`.
-   - `thoth-mem`: recover tasks via the recall funnel
-     (`mem_recall(mode="compact")` -> `mem_recall(mode="context")` ->
-     `mem_get(...)`) using topic key `sdd/{change-name}/tasks`; use
-     `mem_get(include_timeline=true)` when task chronology matters.
-3. Find the first unchecked task in state `- [ ]` or `- [~]`.
-4. Build a mental model of the plan: total tasks, remaining work,
-   parallelizable work, and dependency order.
-5. Load remaining SDD context using mode-aware retrieval in
-   [../_shared/persistence-contract.md](../_shared/persistence-contract.md).
-
-### Phase 2: Execute Ready Work
-
-#### A. Mark In-Progress
-
-Before dispatching a task or same-agent batch:
-
-1. Select the next ready task, or the next consecutive ready tasks that target
-   the same execution agent and can safely be handled in one dispatch.
-   - **`[P]` parallel batch (toggle-gated)**: when `rules.tasks.parallel_markers`
-     is enabled, consume contiguous `[P]`-marked tasks WITHIN the same phase that
-     target the same execution role as one explicit parallel batch (an upgrade of
-     the implicit same-agent grouping, not a cross-role scheduler). For
-     `[P]` tasks that touch overlapping files, recommend worktree isolation per
-     concurrent writer (or serialize them) to avoid write conflicts; a harness
-     without concurrent dispatch treats the `[P]` batch as an annotated
-     sequential batch and reports the capability gap.
-   - **Back-compat fallback**: when `parallel_markers` is off OR no `[P]` markers
-     are present, fall back to today's implicit consecutive + same-agent grouping
-     unchanged.
-2. Edit the canonical tasks artifact and change each selected task from
-   `- [ ]` to `- [~]`.
-3. If the mode is `thoth-mem` or `hybrid`, re-persist the updated tasks
-   artifact with topic key `sdd/{change-name}/tasks`.
-4. Re-read `tasks.md` after the edit to confirm the change persisted.
-
-#### B. Dispatch
-
-Choose the semantic execution role based on task type. Preserve the role
-boundary even when the active harness uses different invocation syntax:
-
-| Need | Semantic role |
-| --- | --- |
-| Broad codebase discovery | explorer |
-| External docs or APIs | librarian |
-| Architecture or debugging | oracle |
-| UI or UX work | designer |
-| Simple, precise changes | quick |
-| Complex, multi-file changes | deep |
-
-Prefer one dispatch for consecutive ready tasks assigned to the same execution
-role, especially repeated UI/UX work for designer, repeated narrow edits for
-quick, or related implementation tasks for deep.
-
-Every dispatch prompt MUST include these 6 parts:
-
-1. `TASKS` — exact task number(s) and title(s)
-2. `CONTEXT` — relevant proposal, spec, design, and prior-task state
-3. `REQUIREMENTS` — concrete outcomes and constraints
-4. `BOUNDARIES` — files, scope limits, and non-goals
-5. `VERIFICATION` — checks the sub-agent must run or report
-6. `RETURN ENVELOPE` — the exact structured response contract in this skill
-
-`BOUNDARIES` must not contradict accepted proposal or spec scope. Use it to
-limit the current assigned task, not to redefine the approved change scope.
-
-
-    #### B.1 Traceability Fields (optional, back-compatible)
-    
-    When a task carries the optional `sdd-tasks` traceability fields, SURFACE them
-    during dispatch:
-    
-    - `[USN-<n>]` story id and `Priority:` (P1/P2/P3) — include in the dispatch
-      `CONTEXT`/`TASKS` so the executing agent knows the story grouping and priority.
-    - `Independent Test:` — pass into the dispatch `VERIFICATION` as the in-isolation
-      acceptance check for that task.
-    - `Spec:` trace tag — include as the requirement the task implements.
-    
-    These fields are OPTIONAL. A legacy `tasks.md` whose tasks lack `[USN]`,
-    priority, `Independent Test`, or `Spec:` MUST still execute without error: treat
-    the absent fields as optional and proceed using the task title and
-    `Verification` block alone. Never fail or block a task solely because a
-    traceability field is missing.
-    
-    #### C. Receive and Verify
-
-Read the sub-agent return envelope and respond by status:
-
-- `completed`: inspect the reported file changes, run verification checks, and
-  confirm every task's acceptance criteria were actually met.
-- `failed`: assess the blocker, decide whether to retry with sharper guidance,
-  switch agents, or escalate.
-- `partial`: assess what is already done, preserve that context, and dispatch a
-  focused follow-up for the remainder.
-
-#### D. Mark Complete
-
-After verified completion:
-
-1. Edit the canonical tasks artifact and change each verified task from
-   `- [~]` to `- [x]`. If a batched result only completed some tasks, update
-   only those tasks and keep the rest in progress, skipped, or retryable based
-   on evidence.
-2. If the mode is `thoth-mem` or `hybrid`, re-persist the updated tasks
-   artifact under `sdd/{change-name}/tasks`.
-3. Persist a progress checkpoint under `sdd/{change-name}/apply-progress` when
-   the mode includes thoth-mem.
-4. Re-read `tasks.md` after the edit to confirm the completed state persisted.
-
-#### E. Auto-Continue
-
-Immediately proceed to the next task.
-
-Do not ask the user whether execution should continue unless one of these is
-true:
-
-- the work is truly blocked
-- a critical failure prevents safe continuation
-- the current task or batch has failed 3 consecutive times
-
-### Phase 3: Between Tasks
-
-Between every task or same-agent batch:
-
-1. Re-read `tasks.md` because later tasks may depend on earlier outputs.
-2. Re-check that assumptions still hold.
-3. If a prior task introduced breakage, fix that before starting the next task.
-
-### Phase 4: Escalation Policy
-
-- Attempt 1: re-dispatch the same task with explicit fix instructions and the
-  missing evidence called out.
-- Attempt 2: switch to a different agent or fix directly when appropriate.
-- Attempt 3: make one final targeted attempt with narrowed scope.
-- "Narrowed scope" means a narrower recovery attempt for the assigned task
-  only. It must not redefine accepted proposal or spec scope for the change.
-- After 3 consecutive failures, mark the task `- [-]` with a clear reason and
-  escalate to the user.
-
-### Phase 5: Completion
-
-After the task list is complete:
-
-1. Run final verification using the project's configured instructions and the
-   smallest sufficient checks: typecheck, tests, lint, and build when
-   appropriate.
-2. Report a completion summary with evidence.
-3. If the work is SDD-backed, hand off to the bounded verify-loop rather
-   than a single verify shot: dispatch `sdd-verify` as an iterative gate and
-   branch on its verdict — `fail` triggers a targeted fix scoped by the
-   report's remediation anchors and a re-verify; `pass with warnings` and a
-   bound-exhausting `fail` escalate to the user; a clean `pass` proceeds to
-   archive. The loop is capped by the 3-round bound defined in the
-   orchestrator SDD wording (the canonical source of the round number).
-
-## Return Envelope Contract
-
-Every execution sub-agent MUST return this exact structure:
-
-```markdown
-## Task Result
-
-**Status**: completed | failed | partial
-**Tasks**: {task number(s) and name(s)}
-
-### What was done
-- {concrete change 1}
-- {concrete change 2}
-
-### Per-task outcome
-- `{task number}` — completed | failed | partial: {task-specific evidence}
-
-### Files changed
-- `path/to/file.ts` — {what changed}
-
-### Verification
-- {check 1}: passed | failed
-- {check 2}: passed | failed
-
-### Issues (if any)
-- {issue description} — {severity: critical | important | minor}
-
-### Failure reason (if failed)
-{Why it failed, what was attempted, what blocked progress}
-
-### Skip reason (if skipped)
-{Why it was skipped, what prerequisite is missing}
-```
-
-Treat missing sections or vague summaries as incomplete execution results.
-
-## Recovery Protocol
-
-To resume safely:
-
-1. Determine the artifact store mode from config.
-2. Recover task state using mode-aware retrieval:
-   - `openspec`: read `openspec/changes/{change-name}/tasks.md`.
-   - `thoth-mem`: recover `sdd/{change-name}/tasks` and
-     `sdd/{change-name}/apply-progress` via the recall funnel
-     (`mem_recall(mode="compact")` -> `mem_recall(mode="context")` ->
-     `mem_get(...)`); use `mem_get(include_timeline=true)` when task chronology
-     matters.
-   - `hybrid`: do both recovery paths and prefer thoth-mem as the source of
-     truth if state diverges.
-3. Resume from the first task marked `- [ ]` or `- [~]`.
-
-## Guardrails
-
-- Do not execute tasks out of dependency order.
-- Do not mark a task complete without verification evidence.
-- Do not skip SDD context recovery.
-- Do not modify task-list structure; only update checkbox state and explicit skip
-  reasons.
-- Do not continue past a blocked task without escalation.
-- Do not claim completion without evidence.

package/src/skills/plan-reviewer/SKILL.md

@@ -1,219 +0,0 @@
----
-name: plan-reviewer
-description: Review SDD task plans for execution blockers and return [OKAY] or [REJECT].
-metadata:
-  author: thoth-agents
-  version: '1.0'
----
-
-# Plan Reviewer Skill
-
-Verify that an SDD task plan is executable, references valid files, and is safe
-to hand to implementation.
-
-## Shared Conventions
-
-- [../_shared/openspec-convention.md](../_shared/openspec-convention.md)
-- [../_shared/persistence-contract.md](../_shared/persistence-contract.md)
-- [../_shared/thoth-mem-convention.md](../_shared/thoth-mem-convention.md)
-
-## Purpose
-
-Review the tasks artifact for true execution blockers. Retrieve it according to
-the persistence mode: read `openspec/changes/{change-name}/tasks.md` for
-openspec/hybrid modes, use the thoth-mem recall funnel
-(`mem_recall(mode="compact")` -> `mem_recall(mode="context")` ->
-`mem_get(...)`) for thoth-mem/hybrid modes, or read from inline context for none
-mode.
-
-The artifact governance validator is not part of this review. Plan-reviewer is
-only the pre-execution approval gate for the task plan; it does not run the
-validator, enforce its findings, or manage the future pre-`sdd-apply` handoff.
-Plan-reviewer remains read-only: it returns the durable review payload, while the
-orchestrator or `quick` persistence helper writes `plan-review.md` and/or
-`sdd/{change-name}/plan-review` when the selected persistence mode requires it.
-Invoke the semantic oracle role through the available role dispatch surface.
-
-Focus on whether the plan can be executed as written, not whether you would have
-designed it differently.
-
-## Inputs
-
-- `change-name`
-- `pipeline-type` (`accelerated` or `full`)
-- `persistence-mode` (`thoth-mem`, `openspec`, `hybrid`, or `none`)
-- Tasks artifact (retrieved per persistence mode: filesystem for openspec/hybrid,
-  thoth-mem for thoth-mem/hybrid, inline for none)
-- **Full pipeline**: related spec and design artifacts when needed for dependency checks
-- **Accelerated pipeline**: proposal artifact when needed for dependency checks
-
-## Task State Awareness
-
-Recognize these checklist states in `tasks.md`:
-
-- `- [ ]` pending
-- `- [~]` in progress
-- `- [x]` completed
-- `- [-]` skipped with reason
-
-Review executability of the remaining work. If a task is marked `- [-]`, ensure
-the skip reason is explicit and does not hide a blocker.
-
-## Review Checklist
-
-Check only what affects executability:
-
-1. Referenced file paths exist when they are supposed to already exist.
-2. New-file tasks use exact intended paths.
-3. Tasks reference exact file paths instead of vague areas.
-4. Each task includes a `Verification` section.
-5. Each `Verification` section includes both:
-   - `Run:`
-   - `Expected:`
-6. Dependency order is valid.
-7. The sequence is workable without hidden prerequisite steps.
-8. In-scope success criteria from the accepted proposal/spec are represented by
-   executable tasks.
-9. Deferred or unresolved affected areas from the accepted proposal/spec have
-   required discovery, coordination, follow-up tasks, or an explicit execution
-   warning.
-10. Task boundaries or non-goals do not contradict accepted proposal/spec
-    scope.
-
-## Cross-Artifact Consistency Analysis
-
-    In addition to the executability review above, perform cross-artifact
-    consistency analysis across proposal <-> spec <-> design <-> tasks. This is NOT
-    a new pipeline phase; it rides inside this plan-review gate. All checks below
-    are gated by the corresponding `openspec/config.yaml rules:` sections; a section
-    that disables enforcement downgrades its block to a report.
-
-    ### Severity model
-
-    Every consistency finding carries one severity:
-
-    - `CRITICAL` — a spec requirement with no mapping in tasks, an orphan task with
-      no spec/proposal basis, scope drift contradicting the accepted proposal, or a
-      direct contradiction between artifacts.
-    - `HIGH` / `MEDIUM` / `LOW` — weaker inconsistencies, ambiguity, or
-      presentation issues that are worth reporting but are not on their own
-      blocking.
-
-    Detect and report at least: requirements present in the spec but absent from
-    design or tasks; tasks with no spec basis; scope drift from the proposal; and
-    contradictory statements between artifacts.
-
-    ### Requirement-coverage percentage
-
-    Compute and REPORT a requirement-coverage percentage in the review output
-    (gated by `rules.consistency.require_coverage_percentage`):
-
-    ```
-    coverage % = (distinct spec requirements named by >=1 task `Spec:` tag)
-                 / (total `### Requirement:` headings across all delta specs)
-    ```
-
-    Parse `Spec:` trace tags from `tasks.md` and `### Requirement:` headings from
-    `openspec/changes/{change}/specs/*/spec.md`. Example: 8 of 10 requirements
-    covered -> report `80%`. When no `Spec:` tags are present (legacy tasks), report
-    coverage against what is present rather than failing.
-
-    ### [NEEDS CLARIFICATION] cap enforcement
-
-    Flag any spec file containing more than `rules.clarification.max_markers_per_spec`
-    (default 3) `[NEEDS CLARIFICATION: ...]` markers. Exactly 3 is within the cap
-    and is NOT flagged; 4 or more is flagged as carrying too much unresolved
-    ambiguity to proceed cleanly.
-
-    ### Constitution Check
-
-    Evaluate the design and plan against EACH principle in
-    `openspec/memory/constitution.md` (delegate-first coordination, read-only role
-    boundaries, governed persistence, multi-harness parity, evidence-led
-    verification). Report the specific violated principle(s). Gated by
-    `rules.constitution.enforce_check`; when disabled, note the skip in the output
-    and do not block.
-
-    ### TDD ordering check
-
-    When `rules.tasks.tdd` is enabled, verify that within each phase every
-    implementation task that has a corresponding test task is PRECEDED by that test
-    task. Report a TDD-ordering finding for any implementation task that precedes
-    its test task. When `tasks.tdd` is disabled, impose no ordering constraint.
-
-    ## Blocking Consistency and Constitution Gate
-
-    - Any `CRITICAL` consistency finding OR any Constitution violation BLOCKS
-      advancement past plan review (gated by `rules.consistency.enforce_block` and
-      `rules.constitution.enforce_check` respectively).
-    - Non-CRITICAL findings are reported but do not block on their own.
-    - The block is overridable ONLY through an explicit user decision delivered via
-      the harness blocking-input surface (the AskUserQuestion-equivalent primitive).
-      The override MUST be logged with the finding identity / violated principle and
-      the user's choice before advancement proceeds. If the harness lacks a
-      blocking-input primitive, report an unsupported-capability limitation rather
-      than silently downgrading the block.
-    - Express a blocking outcome through the existing `[REJECT]` token (or a listed
-      CRITICAL finding); a clean analysis adds no friction and proceeds via `[OKAY]`.
-
-    See `_shared/openspec-convention.md` (Consistency Severity and Coverage Model,
-    Constitution Governance, Clarification Discipline) for the canonical, harness-
-    agnostic definitions these checks implement.
-
-    ## Decision Rules
-
-- Default to `[OKAY]`.
-- Use `[REJECT]` only for true blockers.
-- A rejection may list at most 3 issues.
-- Do not reject for style preferences or optional improvements.
-- Preserve the exact `[OKAY]` and `[REJECT]` tokens across every runtime; they
-  are portable review semantics, not runtime-specific syntax.
-
-## Output Format
-
-Return the status token plus enough structured payload for durable persistence at
-`openspec/changes/{change-name}/plan-review.md` and topic key
-`sdd/{change-name}/plan-review` when the selected store includes those targets.
-The persisted payload must preserve status, reviewer role, timestamp, pipeline,
-persistence mode, comments, non-blocking notes, blockers, user override context
-when applicable, and reviewed artifact freshness data. Use SHA-256 freshness
-digests over reviewed artifact content when the coordinator asks for a concrete
-manifest. Missing, stale, rejected, or unparsable saved evidence fails closed on
-recovery. A fresh `[OKAY]` satisfies only plan-review; it is not implementation
-confirmation.
-
-If the plan is executable:
-
-```text
-[OKAY]
-- Brief confirmation that the plan is executable.
-- Optional note on any non-blocking caution.
-```
-
-If the plan has blockers:
-
-```text
-[REJECT]
-1. <blocking issue>
-2. <blocking issue>
-3. <blocking issue>
-```
-
-For each rejected issue, include:
-
-- why it blocks execution
-- the smallest concrete fix
-
-## Anti-Patterns
-
-- No nitpicking.
-- No style opinions.
-- No design questioning.
-- No architecture redesign.
-- No expanding the scope of review beyond blockers.
-- Do not return more than 3 rejection issues.
-
-## Review Standard
-
-Approve when a competent implementer can execute the plan without guessing about
-critical paths, missing files, or missing verification instructions.