Guru Approve Task Plan

---
name: guru-approve-task-plan
description: Approve current task planning through one AI-owned semantic review, compact private evidence, and four minimal typed exits.
---

# Guru Approve Task Plan

Use this Skill after the current planning wording review has passed and before
task activation. Load [references/contract.md](references/contract.md) before
acting.

Read the live requirement authority, `prd.md`, `design.md`, `implement.md`, and
the Docs SSOT plan directly. Review requirement
authority, scope, design, implementation planning, acceptance verifiability,
Docs SSOT, provenance, and supported unusual scenarios. The AI owns findings,
revision actions, scope proposals, the final route, and delta classification.
For delete, replace, merge, or compatibility-impacting work, also apply
`.trellis/spec/workflow/subtraction-first-compatibility.md`: review direct
deletion/modification/reuse first, identify affected deprecated assets and
consumers, and require the concrete compatibility dialogue before coding,
compatibility tests, or self-fixing. Do not treat `public` or `stable` naming as
an exemption, and do not persist authorization.
Reject incidental task-local fields, persistence, retries, locks, fallbacks, or
other complexity without a named direct consumer. Treat the 3000-line limit for
every touched non-generated code file as a mandatory mechanical-split or small-
decoupling review trigger.

Before that review may return `approved`, consume a fresh
`guru-maintain-architecture-baseline:task_impact_sync(stage=planning)`
`baseline_current` result from the adjacent upstream invocation and reread its project-owned Architecture Baseline,
design-constitution authority, and Architecture change-contract authority.
That current result proves the contract-selected Architecture AI owner already
completed its semantic authoring and formal invocation. Do not search for a
second external owner, reconstruct the Architecture private result, or repeat
its impact/path/contribution/ADR judgment inside Planning approval.
Planning cannot approve a missing or stale Architecture result, a missing
constitution or change contract, or an unresolved conflict, incomplete
contract, regression, or sync route. Bind the current impact/change-path result
inside the existing design-adequacy and provenance judgments; do not copy the
Architecture owner's reasoning or turn constitution principles into a second
checklist. A current `no_architecture_impact` result creates no contribution or
ADR burden.

Before an acceptance scenario, negative test, behavior constraint, or planning
finding participates in that review, form only the profile-specific candidate
set and invoke `guru-qualify-normal-scenario` with `planning_scenario_set`.
Assign no severity or revision action before `classified` returns. Rejected
candidates cannot become scope clarification, acceptance, tests, or
implementation work. Mechanism revision removes/replaces the task-introduced
mechanism and reruns qualification; blocked stops. No qualification state is
written to planning runtime or task files.

Before a proposed mechanism participates in planning acceptance, tests,
findings, or revision actions, invoke `guru-qualify-solution-mechanism` with
`planning_scenario_set`. A `mechanism_revision_required` result removes or
replaces only the task-introduced mechanism and returns here for fresh
qualification; it never becomes scope clarification.

The checked `approved` exit establishes semantic adequacy only. Its stable
consumer is the workflow target `phase-1-task-activation`, which separately
presents the current plan and owns the dialogue-local review pause before task
activation. This Skill neither satisfies, evaluates, records, nor persists that
workflow-owned acceptance. Within this Skill, interact only when unresolved
scope or a material plan choice requires current dialogue input. Never write
authorization, its wording, time, source, reference, or digest into an input,
checkpoint, gate, handoff, archive, schema, or public DTO. Mapped exits and
same-scope re-entry continue automatically.

After the semantic result exists, record and validate only the compact 3.0
owner-private projection. Its one composite planning-content token serves only
the adjacent freshness checker; it is not semantic or workflow authority.
Return exactly one of `approved`,
`revision_required`, `clarify_scope`, or `blocked`. The public input only routes
the owner entry; it never supplies findings, approval status, or a preselected
exit. Missing, stale, multiple, unknown, or consumer-mismatched results fail
closed. This package requires the complete compatible Guru Team preset runtime
and is not self-contained or portable.