codex-orchestrator 2.0.3 → 2.0.5

package/internal-workflow/skills/implementation-spec-review/SKILL.md

@@ -5,207 +5,111 @@ description: "Review compact or full implementation specs for deterministic exec
 
 # Implementation Spec Review
 
-Review an implementation spec before execution begins. The spec is an execution contract for a downstream coding agent. Your job is to decide whether it can be executed safely without guessing, not whether the product idea is good.
-
-Use `../../docs/agents/confidence-rubric.md` when classifying blockers, execution risks, and optional improvements. High-confidence blockers need direct evidence from the spec, repo, issue, or trusted contract. Medium-confidence risks must name the one unresolved assumption. Low-confidence concerns are questions or verification gaps, not blockers.
-
-Use `../../docs/agents/contract-test-ledger.md` when reviewing behavior-changing specs with contract risk.
-
-This skill reviews three independent classifications from
-`implementation-spec-maker`: document shape (`spec_mode`), delivery shape
-(`implementation_size`), and consequence/uncertainty (`review_profile`). It
-also checks the declared `expected_repositories`. Never infer one dimension
-from another.
-
-It supports both document shapes:
-
-- **Compact specs:** dense single-agent specs whose exact scope, risk controls, and proof fit clearly. Compact does not mean small; a coherent medium/large or high-risk implementation may stay compact when ownership, sequencing, and validation remain deterministic. They do not need source-of-truth tables, file matrices, multi-agent contracts, or long halt sections unless a concrete ambiguity calls for them.
-- **Full specs:** lean contracts used when compact mode cannot express concrete coordination, contract, ownership, sequencing, or validation ambiguity safely.
-
-Do not punish a compact spec for omitting full-mode ceremony. Do not punish a full spec for using short risk-control bullets instead of large tables when the ownership and safety rules are still unambiguous. Do reject any spec, compact or full, that requires invention, hides risk, or cannot prove the intended behavior.
-
-When used inside the spec-making loop, return blockers and author questions clearly so the parent agent can relay them. Do not contact the user directly. Do not rewrite the spec unless explicitly asked.
-When already running as the assigned `reviewer_fast`, `reviewer_standard`, or
-`reviewer_deep` child, review inline and never spawn a grandchild. Otherwise,
-root must launch the reviewer selected by the shared review profile and must not
-self-review inline.
-
-## Review Posture
-
-- Be strict about determinism and safety.
-- Be proportional about format and ceremony.
-- Prefer concrete defects with repair instructions over broad commentary, but in Full Mode return every visible evidence-backed blocker and execution risk in the assigned lenses as one batch.
-- Treat false precision as a first-class defect: exact-looking claims must be grounded in source material, repo evidence, or trusted external sources.
-- Separate hard blockers from execution risks and optional improvements.
-- If the spec can be fixed by one sentence, name that sentence-level fix instead of expanding the spec.
-
-### Scope Conservation
-
-A review repair must not broaden approved product or operational scope. Prefer
-deleting or narrowing an unsafe proposal before adding a mechanism. Feature
-flags, telemetry systems, dashboards, rollout machinery, compatibility paths,
-and generic fallbacks are scope expansion unless the source requires them or a
-concrete evidenced failure path makes them necessary. Keep optional
-improvements optional; do not convert them into mandatory spec work.
-
-## Artifact Review Protocol
-
-Act as the implementation-spec Adapter for
-`../../docs/agents/artifact-review-loop.md`. The prompt assigns mode and lenses.
-Return actual coverage, reuse supplied IDs, and label new candidates
-`NEW-<LENS>-NN`; do not implement another review flow or lifecycle here.
-
-When invoked directly outside a maker Module, default to `Full` mode, cover all
-mandatory spec lenses, use no ledger unless one is supplied, and return only the
-single Adapter verdict. Do not claim a Module outcome or closure state.
-
-## Size-Aware Rules
-
-### Compact Specs
-
-Approve a compact spec when it has:
-
-- exact enough targets, commands, preconditions, and validation for the current task
-- numbered phases or a clear single phase
-- a simple progress/reconciliation rule
-- explicit blockers or `None`
-- observable behavior proof
-- no unresolved placeholders, pseudo-paths, or alternative commands
-
-Do not require these unless the task risk demands them:
-
-- source-of-truth map
-- file modification matrix
-- long halt checklist
-- defect closure section
-- multi-agent handoff contract
-- mandatory dedicated review at every phase
-
-### Lean Full Specs
-
-Treat these as signals to check whether compact mode leaves a concrete
-ambiguity; none selects full mode by itself:
-
-- multi-agent execution
-- persistence, migrations, schemas, DTOs, API contracts, or external contracts
-- auth, secrets, permissions, payments, caching, concurrency, background jobs, shared state, or destructive operations
-- changes across several runtime surfaces
-- one ticket with multi-agent coordination requirements
-- revision of an existing checklist with completed history
-
-For these specs, the expected shape is:
-
-- a short `Risk Controls` section naming only applicable ownership, safety, contract, concurrency/state, and forbidden-scope rules
-- phase steps with exact targets and validation
-- `Write Scope Summary` only when phases alone do not make the write set obvious, or when there is multi-agent work, broad runtime change, generated artifacts, or 5+ runtime files
-- task-specific `Halt Conditions` only when the compact stop rule is insufficient
-- `Integrator Coordination Contract` only for multi-agent execution
-
-Missing ownership, write-scope, validation, safety, or handoff details are defects. Missing tables are not defects when the lean sections are unambiguous.
-
-## Mandatory Review Lenses
-
-Across a Module full-review wave, cover all of these lenses according to the
-policy assignment, scaled to artifact risk; each reviewer owns only its
-assigned primary lenses. A standalone direct review covers all lenses:
-
-- **Determinism:** exact paths, symbols, commands, payloads, fixtures, and target behavior where execution depends on them.
-- **Evidence:** exact-looking claims are supported by source material, repo context, docs, issues, or external contract proof.
-- **Preconditions:** required services, env vars, fixtures, data state, feature flags, and prerequisites are explicit or intentionally `None`.
-- **Sequencing:** phases are ordered safely and have exit checks.
-- **Scope:** approved scope, out of scope, protected paths, and rejected approaches are clear enough to prevent drift.
-- **Contract Test Ledger:** contract-heavy behavior changes map ordering, precedence, threading, runtime contract, retry/idempotency, determinism, evidence, partial failure, and cardinality risks to first tests/proofs.
-- **Review Checkpoints and Focus:** high-risk specs use an early `$code-review` checkpoint only when the first risky slice becomes stable before later work. Otherwise the spec assigns concrete `Review Focus` lenses, targeted recipes, and bug classes to the final parallel review wave.
-- **Final Handoff Requirements:** medium/high-risk specs require a compact final response packet covering contract implemented, risky checkpoints, invariants proved, review findings/fixes, validation, skipped checks, residual risks, and files by role.
-- **Minimum solution and reuse:** the spec states a direct `Minimum Solution`, records `Added Complexity: None` or ties every added mechanism to a concrete invariant/failure, and removes anything that passes the deletion challenge. Prefer the fewest necessary concepts, owners, states, and integration points; line or file count is not decisive.
-- **Deep-module fit:** using the `$codebase-design` lens, new Modules or Seams pass the deletion test, avoid one-adapter abstraction, and test through the Module Interface.
-- **Risk Controls:** full specs include only applicable risk controls, and each control is specific enough to guide execution.
-- **Ownership:** source-of-truth ownership is explicit when behavior/data can drift across layers. A short `Source of Truth` bullet is enough when there is only one material owner.
-- **Validation:** checks prove observable behavior, not just compilation.
-- **Safety:** auth, secrets, credentials, destructive operations, persistence, concurrency, retries, and shared state have explicit constraints when touched.
-- **Multi-agent handoff:** if multi-agent, write scopes are disjoint and one integrator owns merge order and final reconciliation.
-- **Revision integrity:** if revising, still-valid completed items are preserved and stale completed items are reopened with a note.
-- **Completion clarity:** another agent could know when to stop, what passed, and what remains blocked.
-
-## What To Reject Immediately
-
-- The spec asks the executor to guess file names, symbol names, DTOs, schema details, API contracts, fixtures, or behavior.
-- The spec contains unresolved placeholders, pseudo-paths, example rows, bracket instructions, or alternative commands presented as executable.
-- The validation cannot prove the intended behavior.
-- The spec changes a contract-heavy behavior but has no Contract Test Ledger, or the ledger lists invariants without a first RED test/proof or a concrete blocked reason.
-- A high-risk spec neither defines a stable early checkpoint nor assigns the risky slice's concrete review focus to the final parallel wave.
-- A medium/high-risk spec has no final handoff requirement, leaving the user to manually reconstruct contract proof, review status, skipped checks, or residual risk from the diff.
-- Code changes are planned, the repo has an architecture check, and the spec omits it without a reason.
-- Exact-looking paths, commands, or symbols are not grounded in evidence and would force the executor to trust invented precision.
-- A multi-agent topology has overlapping write scopes, unclear integration ownership, or no merge/handoff contract.
-- A full spec touches a real safety/contract/state risk but has no applicable `Risk Controls` entry.
-- The spec says or implies the executor should continue despite a mismatch instead of stopping.
-- Security-sensitive or destructive work lacks explicit safe sources, guards, or stop-before-damage constraints.
-- The spec requires an added mechanism outside approved scope, or safe execution would depend on inventing that mechanism's need or contract.
-
-## Common Defects
-
-- Vague instructions like “update logic”, “handle edge cases”, “refactor if needed”, or “reuse existing code where possible” without exact targets.
-- Validation that checks only lint/build and misses the behavior changed by the spec.
-- A contract-heavy spec covers only a happy path and omits ordering, precedence, retry/idempotency, persistence/evidence, serialization, deterministic ordering, or cardinality invariants that are material to the touched flow.
-- A high-risk spec defers all review to the final diff even though the first risky state/contract slice becomes stable, is independently reviewable, and will not be invalidated by lower-risk work.
-- A medium/high-risk spec updates checklists and review gates but does not say what proof summary the executor must give the user at completion.
-- Required env vars, fixtures, payloads, services, or app state are absent.
-- Acceptance criteria are subjective, non-observable, or not tied to proof.
-- Ticket specs lose issue-only requirements such as `Implementation preparation`, `External contracts`, `Verification`, `Blocked by`, live prerequisites, or rejected approaches, or absorb sibling-ticket scope.
-- Evidence sections repeat a file inventory instead of proving determinism.
-- `Minimum Solution` is a slogan rather than a direct path, `Added Complexity` is absent or vague, or a smaller evidence-backed path satisfies the same approved behavior, invariants, and proof.
-- Full specs add large tables where 2-4 exact `Risk Controls` bullets would be clearer.
-- Full specs include generic halt checklists instead of task-specific stop conditions.
-- Full specs spread one rule across multiple files without a declared owner.
-- Compact specs expand into a large document without added safety value.
-
-## Defect Taxonomy
-
-- **Blocker:** The spec is unsafe or impossible to execute as written.
-- **Execution Risk:** The spec is executable but likely to cause drift, rework, or inconsistent implementation.
-- **Improvement:** The spec is usable, and the suggestion would materially sharpen it.
-
-Report blockers first. Mention improvements only when they matter.
-
-## Decision Rules
-
-- **Approved:** Deterministic, bounded, proportionate, and executable without guesswork.
-- **Needs Work:** Directionally usable but has ambiguities, missing proof, weak validation, or scope/control gaps.
-- **Rejected:** Unsafe to execute because it depends on invention, broad interpretation, overlapping ownership, missing validation, or missing safety controls.
-
-Scores:
-
-- `0`: missing or unsafe
-- `1`: partially specified or weakly proven
-- `2`: explicit and well-grounded
-
-## Output Format
-
-Always answer in Russian, keeping technical terms in English where appropriate. Use this exact structure:
-
-1. `Вердикт: Approved / Needs Work / Rejected` plus one sentence with the main reason.
-2. `Режим и покрытие: Full / Closure` with assigned lenses and evidence actually checked.
-3. `Оценка` with short scores `Determinism / Evidence / Validation / Safety` on a 0-2 scale.
-4. `Что уже исполнимо` with 2-4 bullets about what is concrete and safe.
-5. `Критические дефекты спецификации` with concrete blockers, ambiguity points, and failure mechanics. Quote the exact vague phrase, missing step, or unsafe instruction when justifying a defect. If there are no blockers, say `Нет`.
-6. `Defect Records` with the supplied stable ID or `NEW-<LENS>-NN`, class, confidence, invariant, failure, evidence, repair, affected sections, and status. If there are no defects, say `Нет`.
-7. `Что исправить перед исполнением` with exact changes needed in the spec. If nothing is needed, say `Ничего`.
-8. `Жесткие уточняющие вопросы` with 3-5 specific questions only if the spec cannot become deterministic without answers. If none, say `Нет`.
-
-Keep the output short, severe, and execution-oriented.
-
-## Anti-Overengineering Heuristic
-
-- If a compact direct flow is enough, flag unnecessary full-mode ceremony as an improvement or execution risk.
-- Run the whole-solution deletion challenge: if a mechanism can be removed while preserving every approved behavior, material invariant, and proof, require its removal. Do not remove a necessary mechanism merely because it adds a file, type, schema object, or boundary.
-- If a lean full spec gives exact risk controls without tables, do not ask for tables unless prose leaves ambiguity.
-- If a full spec has enough phase-level targets, do not ask for `Write Scope Summary` unless the write set or ownership is hard to audit.
-- If a full spec introduces an indirect flow where a direct one satisfies all constraints, treat that as a defect.
-- If a new abstraction exists only for cleanliness or future flexibility, return `Needs Work` and require its removal. Treat it as a blocker only when execution would be unsafe, broaden approved scope, or require invention.
-- Treat missing or unsupported `Minimum Solution` / `Added Complexity` evidence as `Needs Work`; escalate to `Rejected` only when the added mechanism is unsafe, unapproved scope, or requires invention.
-- If the review can make the spec safer by deleting ceremony rather than adding it, say so.
-
-## Tone
-
-Be direct, strict, and operational. No fluff, no architecture theater.
+Decide whether a saved implementation spec can be executed safely without
+guessing. Review execution quality, not the product idea. Do not rewrite the
+spec unless explicitly asked.
+
+Read:
+
+- `references/review-loop.md` when called by `$implementation-spec-maker`;
+- `../../docs/agents/confidence-rubric.md` for defect confidence;
+- `../../docs/agents/contract-test-ledger.md` only when the spec changes a
+  material behavior contract.
+
+## Independent Dimensions
+
+Keep these classifications independent:
+
+- `spec_mode: compact | full` — document/coordination density;
+- `implementation_size: small | medium | large` — delivery shape;
+- `review_profile: simple | medium | high` — consequence and uncertainty;
+- `expected_repositories` — approved repository count.
+
+Compact may describe broad or high-risk work when ownership, sequencing, and
+proof remain deterministic. Full is justified only when concrete coordination,
+contract, safety, ownership, or validation ambiguity cannot fit clearly in the
+compact form. Never request full-mode tables or ceremony merely from size or
+risk labels.
+
+## Adapter Contract
+
+When called by the maker, use the mode and lenses supplied by
+`references/review-loop.md`, reuse supplied defect IDs, and return actual
+coverage. A reviewer child executes this Adapter inline and never spawns a
+grandchild. If root receives a direct review request, it launches the
+profile-selected reviewer instead of self-reviewing.
+
+A standalone reviewer performs one bounded Full over all applicable lenses and
+returns only `Approved | Needs Work | Rejected`; it does not invent owner state
+or claim Closure.
+
+## Review Lenses
+
+Scale depth to the profile and inspect only applicable lenses:
+
+- **Determinism and evidence:** execution-critical paths, symbols, commands,
+  contracts, fixtures, and claims are confirmed rather than invented.
+- **Scope and minimum solution:** the spec preserves approved scope, uses
+  existing owners/seams, and ties every added mechanism to a requirement or
+  concrete failure path.
+- **Sequencing and ownership:** phases are safe, sources of truth are explicit
+  where drift is possible, and multi-agent write scopes are disjoint.
+- **Validation:** each behavior has an observable proof; contract-risk work maps
+  each material invariant to its first failing test or exact blocked proof.
+- **Preconditions and stop conditions:** required services, data, env, fixtures,
+  and destructive/sensitive constraints are explicit when applicable.
+- **Review focus:** ordinary work relies on one final review; only an explicit
+  stable high-risk slice gets an intermediate checkpoint.
+- **Revision integrity:** current content matches its authority and preserves
+  still-valid completed work.
+- **Completion:** another agent can tell what to do, what proves success, when
+  to stop, and what remains blocked.
+
+## Proportional Expectations
+
+Approve a compact spec when targets, ordered work, observable proof, and stop
+conditions are exact enough for the task. Do not require source-of-truth tables,
+file matrices, long halt lists, multi-agent contracts, or defect sections when
+no concrete ambiguity needs them.
+
+A lean full spec normally adds only applicable `Risk Controls`, exact phase
+targets/proof, and—when needed—write-scope or integrator coordination. Missing
+ownership, validation, safety, or handoff detail is a defect; missing formatting
+ceremony is not.
+
+Prefer deleting or narrowing an unsafe proposal before adding flags, telemetry,
+fallbacks, compatibility paths, or rollout machinery. Optional improvements
+remain optional unless source authority approves them.
+
+## Defects And Decision
+
+- **Blocker:** unsafe or impossible to execute as written.
+- **Execution risk:** executable but likely to drift or require rework.
+- **Improvement:** useful but not required for safe execution.
+
+Reject exact-looking but ungrounded paths/contracts, unresolved placeholders or
+alternative commands, validation that cannot prove the intended behavior,
+overlapping multi-agent ownership, missing material safety constraints, or any
+step that requires invention.
+
+Use:
+
+- `Approved` when the current spec is deterministic, bounded, proportional, and
+  executable without guessing;
+- `Needs Work` for repairable ambiguity, weak proof, or excess ceremony;
+- `Rejected` when execution would be unsafe or depend on invented decisions.
+
+## Output
+
+Answer in Russian and keep technical terms in English. Return:
+
+1. `Вердикт` and one-sentence reason.
+2. `Режим и покрытие` with Full/Closure and actual lenses.
+3. Short `Determinism / Evidence / Validation / Safety` scores from 0 to 2.
+4. Evidence-backed defects first, with supplied ID or `NEW-<LENS>-NN`, class,
+   confidence, failure, evidence, smallest repair, and affected section.
+5. Exact changes needed before execution, or `Ничего`.
+6. Only genuinely blocking questions, or `Нет`.
+
+Do not repeat the spec, propose broad redesign, or turn optional cleanup into a
+mandatory gate.

package/internal-workflow/skills/implementation-spec-review/evals/evals.json

@@ -0,0 +1,24 @@
+{
+  "schema_version": 1,
+  "skill": "implementation-spec-review",
+  "cases": [
+    {
+      "id": "artifact-profile-by-consequence",
+      "prompt": "Review one broad but reversible spec and one narrow spec with irreversible data impact and unclear recovery ownership.",
+      "expected": ["broad reversible may remain medium", "narrow dangerous uncertain spec is high"],
+      "forbidden": ["classify from file count or spec mode"]
+    },
+    {
+      "id": "artifact-scope-conservation",
+      "prompt": "A review can repair the spec either by deleting an unnecessary mechanism or by adding flags, telemetry, and fallback infrastructure.",
+      "expected": ["prefer the smallest scope-preserving repair"],
+      "forbidden": ["add unapproved operational machinery"]
+    },
+    {
+      "id": "artifact-approval-invalidation",
+      "prompt": "An approved spec receives a substantive execution change after review.",
+      "expected": ["invalidate approval for the changed revision", "review only invalidated coverage"],
+      "forbidden": ["execute under stale approval", "restart unrelated coverage"]
+    }
+  ]
+}

package/internal-workflow/skills/implementation-spec-review/references/review-loop.md

@@ -0,0 +1,93 @@
+# Implementation Spec Review Loop
+
+This reference owns review orchestration for specs created by
+`implementation-spec-maker`. Read it when the maker requests artifact review.
+The reviewer skill remains the Adapter; the shared review mechanics live in
+`../../../docs/agents/review-protocol.md`.
+
+## Contract
+
+Input:
+
+- saved spec and pinned revision;
+- source authority and approved decisions;
+- evidence needed to verify execution claims;
+- optional user-raised review profile.
+
+Output:
+
+- `outcome: Approved | Blocked | Waived`;
+- `adapter_verdict: Approved | Needs Work | Rejected | Not run`;
+- `review_profile: simple | medium | high` and evidence-backed reasons;
+- mandatory-lens coverage and unresolved defects.
+
+The Adapter returns only its verdict. The root maps preflight, convergence, and
+waiver state to the artifact outcome.
+
+## Preflight And Profile
+
+Before launching a reviewer, confirm source authority, approved scope, current
+spec revision, and mandatory external evidence. Save a useful blocked spec when
+a product or contract decision is missing; do not launch review to discover a
+known authority gap.
+
+`medium` is the default. Use:
+
+- `simple` for one narrow owner with direct proof and no material uncertainty;
+- `medium` for all ordinary specs, including multi-file, API, persistence, or
+  stateful work with clear ownership and bounded proof;
+- `high` only when a sensitive mechanism has both a material failure
+  consequence and an uncertainty amplifier such as unclear ownership,
+  cross-trust effects, non-local recovery, or an unproven external contract.
+
+File count and implementation size never select `high`. The user may raise but
+not lower an evidence-backed profile.
+
+## Scope And Capsule
+
+Review the smallest approved solution. Risk may strengthen proof but does not
+authorize flags, telemetry, compatibility paths, generic fallbacks, or rollout
+machinery unless the source or a concrete failure requires them.
+
+Give each reviewer a bounded capsule containing the current spec, authority,
+approved scope, evidence, review question, assigned lenses, and current defect
+records. For Closure also include the repaired sections and affected contracts.
+Do not pass raw parent history or unrelated inventories.
+
+## Topology
+
+- `simple`: one `reviewer_fast`, one bounded Full.
+- `medium`: one `reviewer_standard`, one bounded Full.
+- `high`: two parallel `reviewer_deep` sessions with disjoint primary lenses:
+  Architecture/Execution and Failure/Contracts.
+
+Root launches and aggregates reviewers. A reviewer child runs the
+`implementation-spec-review` Adapter inline and never spawns another reviewer.
+Reuse valid coverage for the same revision and question.
+
+After one consolidated repair, coordinator verification is enough for ordinary
+medium/low findings. Use shared-protocol Closure only for critical/high defects,
+protected trust/data/concurrency/shared-contract impact, or invalidated
+mandatory coverage. A substantive rewrite gets a new Full only when it
+invalidates existing mandatory lenses.
+
+## Approval
+
+Return `Approved` only when the current saved revision matches source authority,
+mandatory lenses are covered, and every blocking defect is verified. Any
+substantive edit invalidates approval; lifecycle metadata alone does not.
+
+Return `Blocked` when authority/evidence is missing, repair needs a product or
+ownership decision, no substantive repair exists, or shared no-progress rules
+apply. Return `Waived` only after explicit user instruction and keep skipped
+coverage visible; an open blocker still maps the artifact to `Blocked`.
+
+Map outcomes to spec status:
+
+- `Approved` -> `ready`;
+- `Blocked` -> `blocked`;
+- eligible `Waived` -> `ready` with visible waiver metadata.
+
+Report profile, outcome, Adapter verdict, mandatory coverage, verified/open
+defects, and skipped checks. Do not report counters or session history for a
+normal one-review flow.

package/internal-workflow/skills/small-task-implementer/SKILL.md

@@ -16,15 +16,21 @@ Proceed only when all are true:
 - There is a narrow validation path: targeted test, lint/typecheck, build check, UI proof, or direct command.
 - The task does not require a new plan, PRD, issue breakdown, implementation spec, migration, rollout, or multi-agent orchestration.
 
-Escalate instead of implementing when the task touches:
-
-- state transitions, queues, retries, idempotency, background jobs, persistence, migrations, schemas, DTO/API contracts, auth, permissions, payments, caching, or shared cross-module behavior;
-- multi-service, multi-repo, multi-agent, production/live-data, or external-contract work;
-- unclear product intent, ambiguous scope, no credible validation path, or likely broad refactoring.
+Escalate out of the tiny-task route when the work has more than one coherent
+behavior, a broad ownership boundary, material rollback/recovery risk, unclear
+product intent, no credible affected validation, or genuine multi-agent/live
+coordination. Statefulness alone does not require escalation into planning or
+orchestration; a clear API, persistence, cache, queue, or DTO change normally
+becomes direct medium implementation.
 
 Escalation rule:
 
-- Escalate into the single canonical delivery flow: optional `$grilling` for unresolved product decisions, then `$spec-to-tickets` for the reviewed Approval Packet, then `$tickets-orchestrator` for approved ticket delivery.
+- For clear authority and one coherent outcome, escalate to direct medium root
+  implementation under `$tdd`, affected validation, and one final review when
+  `review-gates.md` applies.
+- Use optional `$grilling`, then `$spec-to-tickets` and `$tickets-orchestrator`,
+  only for unresolved product decisions or a real approved ticket graph,
+  delivery dependency, or explicit orchestration request.
 - For one risky behavior or technical contract, prefer one approved ticket and mark `compact spec` or `standard spec` only when the ticket plus repository evidence cannot remove execution ambiguity.
 - For several tickets sharing one unresolved contract or validation path, make the contract-defining ticket block its consumers; merge tickets that cannot be specified or verified independently instead of creating a wave-level implementation spec.
 - Escalate if the bug requires Bugfix Quality Gate analysis across multiple paths, states, async events, persistence, auth, cache, retries, workers, or contracts.
@@ -58,7 +64,8 @@ Validation:
    - Do not run full CI unless local policy or the changed surface makes it necessary.
 
 5. Stop and escalate if implementation reveals hidden risk.
-   - Examples: shared contract drift, duplicate source of truth, missing test seam, broad file spread, concurrency, persistence, or product ambiguity.
+   - Examples: shared contract drift, duplicate source of truth, missing test
+     seam, material concurrency/recovery uncertainty, or product ambiguity.
    - Leave a short explanation of what was discovered and which heavier flow should take over.
 
 ## Output
@@ -90,7 +97,7 @@ Reason:
 - ...
 
 Recommended flow:
-- Canonical ticket delivery / direct small task
+- Direct medium implementation / canonical ticket delivery
 
 Evidence:
 - ...