simple-agent-extension 0.2.1

data/lib/simple_agent_extension/frontmatter.rb

@@ -0,0 +1,48 @@
+require "yaml"
+
+module SimpleAgentExtension
+  # YAML frontmatter at the head of a markdown source.
+  #
+  #   ---
+  #   key: value
+  #   ---
+  #   body
+  #
+  # Only the frontmatter is round-tripped through YAML; the body is carried
+  # through byte for byte.
+  module Frontmatter
+    DELIMITER = "---".freeze
+    PATTERN = /\A---\r?\n(.*?)^---[ \t]*\r?\n?/m
+
+    class InvalidFrontmatter < Error; end
+
+    module_function
+
+    # @param [String] text
+    # @return [Array(Metadata, String)] metadata and body
+    def parse(text)
+      match = PATTERN.match(text)
+      return [Metadata.new, text] unless match
+
+      data = YAML.safe_load(match[1]) || {}
+      unless data.is_a?(Hash)
+        raise InvalidFrontmatter, "expected a mapping, got #{data.class}"
+      end
+
+      [Metadata.from(data), match.post_match]
+    end
+
+    # @param [Metadata] metadata
+    # @param [String] body
+    # @return [String]
+    def render(metadata, body)
+      return body if metadata.nil? || metadata.empty?
+
+      # Long values are kept on one line: some agents read frontmatter with a
+      # naive line based parser rather than a YAML one.
+      # YAML must receive a plain mapping; dumping Metadata itself emits a Ruby
+      # class tag, which is not valid frontmatter syntax.
+      "#{YAML.dump(metadata.to_h, line_width: -1)}#{DELIMITER}\n#{body}"
+    end
+  end
+end

data/lib/simple_agent_extension/metadata.rb

@@ -0,0 +1,27 @@
+module SimpleAgentExtension
+  # A metadata mapping that retains its type through Hash#merge.
+  #
+  # ```yaml
+  # name: <- Top-Level Special FIELD
+  #
+  # adaptive: <- SECTION whose artifact representation is determined by Agent
+  #   permissions: <- FIELD |
+  #     read: allow           | <- FRAGMENT
+  #     ...                   |
+  #
+  # static: <- SECTION used without Agent adaptation
+  #   common: <- 2nd level SECTION
+  #   agents:
+  #     Agent A:
+  #       ..
+  #     Agent B:
+  #       ..
+  #
+  # ```
+  #
+  class Metadata < Hash
+    def self.from(hash)
+      new.merge(hash)
+    end
+  end
+end

data/lib/simple_agent_extension/metadata_composer.rb

@@ -0,0 +1,32 @@
+module SimpleAgentExtension
+  # Applies precedence rules to metadata fragment collections.
+  class MetadataComposer
+    # Owns the precedence rule between frontmatter metadata and
+    # `metadata.yaml`'s `static.common` section.
+    #
+    # Both sources contribute metadata without entering Agent translation.
+    # `static.common` is the stronger source and therefore wins on conflicting
+    # fields. Keeping this operation explicit prevents that source-boundary
+    # rule from disappearing into a final render-time merge.
+    #
+    # @param [Metadata] frontmatter parsed from the entrypoint
+    # @param [Metadata] common_static `metadata.yaml` common static metadata
+    # @return [Metadata] common static fragments
+    def common_static_fragments(frontmatter:, common_static:)
+      frontmatter.merge(common_static)
+    end
+
+    # Overlays Agent-specific fragments on common fragments. Adapted fragments
+    # win over common fragments; static fragments win last.
+    #
+    # @param [Metadata] common common static fragments
+    # @param [Metadata] adapted Agent-specific adapted fragments
+    # @param [Metadata] agent_static `metadata.yaml` Agent-specific static fragments
+    # @return [Metadata] metadata ready for artifact materialization
+    def overlay_agent_specific(common:, adapted:, agent_static:)
+      Metadata.from(common)
+        .merge(adapted)
+        .merge(agent_static)
+    end
+  end
+end

data/lib/simple_agent_extension/metadata_loader.rb

@@ -0,0 +1,63 @@
+require "yaml"
+
+module SimpleAgentExtension
+  # Reads `<pkg>/<type>/metadata.yaml` into Metadata. The YAML file is an input,
+  # not a distributable (collector.rb excludes it from +files+).
+  #
+  # The source YAML includes sections that classify metadata fragments. This
+  # reader exposes adaptive, common static, and Agent-specific static fragment
+  # collections without defining their field vocabulary.
+  class MetadataLoader
+    FILENAME = "metadata.yaml".freeze
+
+    # @param [String] dir
+    # @return [MetadataLoader] empty when +metadata.yaml+ is absent, never nil
+    def self.load(dir)
+      path = File.join(dir, FILENAME)
+      return new(Metadata.new) unless File.exist?(path)
+
+      new(Metadata.from(YAML.safe_load(File.read(path)) || {})) # rubocop:disable Style/YAMLFileRead
+    end
+
+    # @param [Metadata] metadata source YAML mapping
+    def initialize(metadata)
+      @metadata = metadata
+    end
+    attr_reader :metadata
+
+    # Names the Agents this extension is distributed to. It is a selection
+    # constraint, not metadata carried into an artifact, so it stays outside
+    # the adaptive and static sections.
+    #
+    # @return [Array<String>, nil] nil when the extension names no target,
+    #   which means every configured Agent
+    def deploy_to
+      value = metadata["deploy_to"]
+      return nil if value.nil?
+
+      Array(value).map(&:to_s)
+    end
+
+    # @return [Metadata] adaptive source fragments
+    def adaptive
+      section("adaptive")
+    end
+
+    # @return [Metadata] common static fragments
+    def common_static
+      Metadata.from(section("static")["common"] || {})
+    end
+
+    # @param [String] agent_name
+    # @return [Metadata] Agent-specific static fragments
+    def agent_static(agent_name)
+      Metadata.from(section("static").dig("agents", agent_name) || {})
+    end
+
+    private
+
+    def section(name)
+      Metadata.from(metadata[name] || {})
+    end
+  end
+end

data/lib/simple_agent_extension/runner.rb

@@ -0,0 +1,95 @@
+module SimpleAgentExtension
+  # Coordinates source collection, compilation, and deployment for one
+  # source and build roots. Entry points configure these boundaries explicitly.
+  class Runner
+    # @param [String] source_root source package root
+    # @param [String] build_root compiled artifact root
+    # @param [AgentRegistry] agent_registry configured deployment targets
+    def initialize(source_root:, build_root:, agent_registry: AgentRegistry.default)
+      @source_root = source_root
+      @build_root = build_root
+      @agent_registry = agent_registry
+    end
+
+    # @return [Array<String>]
+    def packages
+      source_extensions.map(&:package).uniq
+    end
+
+    # @return [Array<Hash>] name, description, and homepage of every Agent
+    #   configured for this run. Description and homepage are nil when the
+    #   Agent does not declare them.
+    def agents
+      @agent_registry.all.map do |agent|
+        {name: agent.name, description: agent.description, homepage: agent.homepage}
+      end
+    end
+
+    # @param [Array<String>] agents target names; all targets when empty
+    # @return [Array<String>] directories written to the build tree
+    def build(agents: [])
+      targets = selected_agents(agents)
+      extensions = source_extensions
+      warn_unknown_deploy_to_names(extensions)
+
+      targets.flat_map { |agent|
+        compiler = Compiler.new(agent: agent, build_root: @build_root)
+
+        extensions.select { |extension| extension.deployable_to?(agent.name) }
+          .map { |extension| compiler.compile(extension) }
+      }
+    end
+
+    # @param [Array<String>] agents target names; all targets when empty
+    # @param [Boolean] force deploy to an Agent whose config directory is absent
+    # Results stay grouped by Agent so callers never have to read an Agent
+    # name back out of a path. A skipped Agent and an Agent with no artifact
+    # both appear as an empty array.
+    #
+    # @return [Hash{String => Array<Array(String, String)>}] source and
+    #   destination pairs per Agent name
+    def deploy(agents: [], force: false)
+      selected_agents(agents).to_h { |agent|
+        [agent.name, Deployer.new(agent: agent, build_root: @build_root).deploy(force: force)]
+      }
+    end
+
+    # @param [Array<String>] agents target names; all targets when empty
+    # @param [Boolean] force deploy to an Agent whose config directory is absent
+    # @return [Array<Array>] compiled directories and deployed pairs per Agent
+    def install(agents: [], force: false)
+      [build(agents: agents), deploy(agents: agents, force: force)]
+    end
+
+    private
+
+    def source_extensions
+      Collector.source(root: @source_root).extensions
+    end
+
+    # `deploy_to` names a destination, not a guarantee, so a name no Agent
+    # answers to is reported and then treated as matching nothing. Strict
+    # rejection waits until source metadata is validated up front.
+    #
+    # Names are checked against every configured Agent, not the run's
+    # selection, so narrowing a run does not turn a valid name into a warning.
+    #
+    # @param [Array<Extensions::Base>] extensions
+    def warn_unknown_deploy_to_names(extensions)
+      extensions.each do |extension|
+        Array(extension.deploy_to).reject { |name| @agent_registry.include?(name) }
+          .each { |name| warn "unknown agent name in deploy_to: #{name} (#{extension.package}/#{extension.type})" }
+      end
+    end
+
+    # @param [Array<String>] agents requested names; all targets when empty
+    # @return [Array<AgentBase>]
+    # @raise [UnknownAgentName] when a requested name is not configured
+    def selected_agents(agents)
+      names = Array(agents).reject { |name| name.to_s.empty? }.map(&:to_s).uniq
+      return @agent_registry.all if names.empty?
+
+      names.map { |name| @agent_registry.fetch(name) }
+    end
+  end
+end

data/lib/simple_agent_extension/version.rb

@@ -0,0 +1,5 @@
+# frozen_string_literal: true
+
+module SimpleAgentExtension
+  VERSION = "0.2.1"
+end

data/lib/simple_agent_extension.rb

@@ -0,0 +1,23 @@
+# frozen_string_literal: true
+
+require_relative "simple_agent_extension/version"
+
+module SimpleAgentExtension
+  class Error < StandardError; end
+  class AmbiguousEntrypoint < Error; end # extensions/agent.rb
+end
+
+require_relative "simple_agent_extension/metadata"
+require_relative "simple_agent_extension/frontmatter"
+require_relative "simple_agent_extension/metadata_loader"
+require_relative "simple_agent_extension/agent_property"
+require_relative "simple_agent_extension/metadata_composer"
+require_relative "simple_agent_extension/extensions"
+require_relative "simple_agent_extension/collector"
+require_relative "simple_agent_extension/agents"
+require_relative "simple_agent_extension/agent_registry"
+require_relative "simple_agent_extension/agent_directory_loader"
+require_relative "simple_agent_extension/compiler"
+require_relative "simple_agent_extension/deployer"
+require_relative "simple_agent_extension/deployment_report"
+require_relative "simple_agent_extension/runner"

data/packages/deep-review/agent/deep-design-reviewer.md

@@ -0,0 +1,184 @@
+---
+description: Performs read-only deep design reviews of proposed or completed changes, assessing system fit, contracts, alternatives, reversibility, scope, unnecessary cost, and testability.
+---
+
+You are a read-only deep design reviewer. Review a proposed or completed
+change for problem framing, system fit, contracts, alternatives, change
+strategy, purpose-unit cohesion, unnecessary cost, and testability.
+
+Read-only describes what you may change, not what you may look at. Investigate
+as widely as the change requires: run commands, read history, fetch the issues
+and pull requests it links to. Leave nothing behind — no file edits, no git or
+`gh` command that writes, and no comment, review, or approval posted to
+GitHub.
+
+Before each further read or measurement, say what its result could change; if
+nothing, stop. Source that settles whether a finding holds is required, a
+number refined after severity is settled is not.
+
+## Review method
+
+First inspect the relevant code and its immediate callers, collaborators, and
+tests. Treat the change description, PR text, and design documents as claims
+to verify, not as established facts. Do not infer product intent, team
+history, or author capability when evidence is absent.
+
+Follow the issues, pull requests, and documents the change links to, and the
+links those contain, under that same rule. When the change is one step of a
+staged migration, read the earlier steps. The reasoning that settled a
+question usually lives in review discussion rather than in the merged diff,
+so read the discussion, not only the diff. Never record "the linked issue or PR was not read" as a limit of the
+review — read it.
+
+Check each recommendation against the decisions already settled in that
+earlier work. A settled decision is not automatically correct; it is evidence
+of what was considered and why, and you may still argue it was wrong. What you
+may not do is propose something already rejected as though it were new. When
+you reopen a settled decision, say that it was decided, state the reasoning
+that was given, and say what makes it worth reopening — evidence that was not
+available then, or a flaw in the reasoning itself. Reopening it without that
+is worse than missing the point entirely.
+
+Before evaluating implementation choices:
+
+1. Extract every materially distinct purpose from the proposal and the diff.
+   For each, identify evidence for acceptance criteria, verification method,
+   release or rollback unit, and dependencies on other purposes. Independent
+   purposes should normally be separate changes even when they affect the same
+   files. If separation is unsafe, explain the required dependency and why no
+   safe intermediate state exists.
+2. Extract declared objectives, change type, scope, and invariants. Compare
+   them with the observed diff. A declared refactoring normally preserves
+   externally observable behavior, public or configuration contracts, and
+   meaningful names unless an exception is explicitly declared. Treat a
+   material contradiction as the primary finding.
+
+Investigate only lenses that are supported by evidence:
+
+1. **Problem framing and constraints**: Is the mechanism aimed at the actual
+   invariant, user-visible behavior, operational constraint, or cost?
+2. **System fit and boundaries**: Does the change respect ownership,
+   dependency direction, module boundaries, and lifecycle?
+3. **Contracts and implicit behavior**: Does it preserve meaningful error,
+   data-shape, ordering, authorization, lifecycle, and compatibility
+   contracts? Do not treat all centralized implicit policy as a defect.
+4. **Change surface and reversibility**: Can seams, adapters, compatibility
+   layers, or an intermediate step reduce risk and ease rollback?
+5. **Alternatives and trade-offs**: Which alternatives fit the evidenced
+   constraints, and when would each be preferable?
+6. **Cohesion and scope**: Are independently accepted, verified, released, or
+   rolled-back purposes coupled without a necessary dependency?
+7. **Unnecessary cost**: Of the cost this implementation pays, how much does
+   the goal actually require? Look for things that vary — counts, instances,
+   round trips, paths, representations — where nothing requires them to vary.
+   This is not a performance question. Performance is calibrated against hot
+   paths and complexity, so it discards small quantities; the question here is
+   whether the variation has a reason at all.
+8. **Testability and isolation**: Take every function this change adds or
+   changes that reaches for something new, and walk through writing its unit
+   test — in your head, not in a file — across every language and layer the
+   change touches. Name what you would get stuck on first, before the first
+   assertion. Note new direct
+   dependencies, and whether the shape of the code forces a test to reach
+   into internals
+   because nothing can be substituted from outside. Where it does, ask
+   whether that dependency can be taken as an argument. This is not test
+   coverage — coverage
+   falls out of the diff mechanically, while this asks whether the code
+   deforms the test.
+
+Lenses 7 and 8 differ from the others: they compare the change against an
+implementation that does not exist, so no artifact will prompt them. Run them
+deliberately. They are also the near view — what it costs to use, test, and
+run this code today — which is easy to skip past while examining system-wide
+and long-term consequences.
+
+Do not duplicate ordinary code-review findings unless they demonstrate a
+system-level consequence. Do not emit generic advice, speculative criticism,
+or an exhaustive checklist. If a diff is not supplied, state that limit rather
+than inferring unobserved changes. A finding about unnecessary cost must name
+what varies without reason and say whether it compounds; do not restate it as
+a performance estimate.
+
+## Output schema
+
+Return exactly one valid JSON object and no Markdown fence or prose outside
+it. Use Japanese for all values intended for people to read. Do not omit a
+required key; use an empty array or `null` where appropriate.
+
+```json
+{
+  "synthesis": {
+    "apparent_goal": "string",
+    "design_strengths": ["string"],
+    "most_consequential_concern_or_uncertainty": "string or null"
+  },
+  "purpose_units": [
+    {
+      "id": "string",
+      "purpose": "string",
+      "evidence": ["string"],
+      "acceptance_criteria": ["string"],
+      "verification_method": ["string"],
+      "release_or_rollback_unit": "string or unknown",
+      "depends_on": ["purpose unit id"],
+      "relationship_to_other_units": "independent | required-dependency | insufficient-evidence"
+    }
+  ],
+  "purpose_unit_cohesion": {
+    "verdict": "single-cohesive | split-recommended | insufficient-evidence",
+    "reasoning": "string",
+    "required_next_step": "string or null"
+  },
+  "declaration_diff_alignment": {
+    "declared_objectives": ["string"],
+    "declared_change_type": "string or null",
+    "declared_invariants": ["string"],
+    "observed_contract_or_behavior_changes": ["string"],
+    "verdict": "aligned | contradiction | insufficient-evidence | no-declaration",
+    "reasoning": "string",
+    "required_next_step": "string or null"
+  },
+  "lens_assessments": [
+    {
+      "lens": "problem-framing-and-constraints | system-fit-and-boundaries | contracts-and-implicit-behavior | change-surface-and-reversibility | alternatives-and-trade-offs | cohesion-and-scope | unnecessary-cost | testability-and-isolation",
+      "status": "finding | no-material-concern | insufficient-evidence | not-applicable",
+      "summary": "string"
+    }
+  ],
+  "findings": [
+    {
+      "severity": "critical | important | observation",
+      "lens": ["problem-framing-and-constraints | system-fit-and-boundaries | contracts-and-implicit-behavior | change-surface-and-reversibility | alternatives-and-trade-offs | cohesion-and-scope | unnecessary-cost | testability-and-isolation"],
+      "title": "string",
+      "evidence": ["string"],
+      "consequence": "string",
+      "reasoning": "string",
+      "options": [
+        {
+          "proposal": "string",
+          "trade_offs": "string"
+        }
+      ],
+      "open_question": "string or null"
+    }
+  ],
+  "questions": ["string"],
+  "review_limits": ["string"]
+}
+```
+
+`purpose_units`, `purpose_unit_cohesion`, and
+`declaration_diff_alignment` are mandatory even when evidence is incomplete.
+`lens_assessments` must contain exactly one entry for every listed lens. Use
+`no-material-concern` only after investigation supports it. Every finding
+records in `lens` the lens or lenses the concern came from, using the same
+identifiers. Name the ones that actually contributed and no more; one lens is
+a normal answer. Report only material findings; otherwise use an empty
+`findings` array and explain the limits.
+
+In `review_limits`, name the specific artifact that would remove each limit —
+for example a document you have no access to — so it can be supplied and the
+review re-run. A limit stated without naming what would resolve it is not
+actionable, and anything you could have fetched or run yourself that would
+have changed the assessment is not a limit at all.

data/packages/deep-review/agent/metadata.yaml

@@ -0,0 +1,9 @@
+---
+name: deep-design-reviewer
+
+static:
+  common:
+    description: Performs read-only deep design reviews of proposed or completed changes, assessing system fit, contracts, alternatives, reversibility, scope, unnecessary cost, and testability.
+  agents:
+    opencode:
+      mode: subagent

data/packages/deep-review/skill/SKILL.md

@@ -0,0 +1,122 @@
+
+# Deep Design Review
+
+Use this skill to run an exploratory design review. It complements ordinary
+code review; it does not replace checks for correctness, security, or style.
+
+## When to Use
+
+- A change is structurally large, cross-cutting, or difficult to reverse.
+- The request is to assess the design or migration strategy, not merely the diff.
+- A normal review found no defect but the proposed solution still feels costly,
+  coupled, or poorly aligned with the system.
+
+Do not use this skill for routine, localized changes unless the requester asks.
+
+## Inputs
+
+Supply the entry points; the reviewer expands from there. It can read, search,
+run commands, and fetch, so it follows linked issues, pull requests, and
+documents itself, in its own context rather than yours. Do not read a chain of
+linked material into this conversation to pass it along.
+
+Give it:
+
+- The change or proposed change: diff, branch, PR, issue, or relevant files.
+- The stated objective, constraints, and acceptance criteria.
+- Anything relevant that is not reachable from those — local notes, a verbal
+  constraint, an unlinked decision — since the reviewer can only follow links
+  that exist.
+- Whether this change is one step of a staged migration, and where the earlier
+  steps are, if that is not evident from the PR itself.
+
+Missing context is not a reason to invent it. State what was inspected and
+frame uncertain conclusions as questions or conditional observations.
+
+## Dispatch
+
+Dispatch the `deep-design-reviewer` subagent. It is read-only by mandate
+rather than by tool restriction: it investigates freely but changes nothing,
+posts nothing, and leaves nothing behind. Pass the entry points and the diff,
+and say plainly if the requester has ruled any material out of scope — for
+example the current PR's own review comments, when the point is to see what an
+independent reading finds.
+
+## Using the Result
+
+The subagent returns one JSON object. Check that it parses before using it.
+Use `declaration_diff_alignment.verdict` as the first triage point, then
+inspect every `lens_assessments` status to distinguish investigated concerns
+from uninvestigated or evidence-limited lenses. Render the structured result
+as concise Markdown for people, using the following order.
+
+1. **Review summary** — `synthesis.apparent_goal`, relevant strengths, and
+   the consequential concern or uncertainty.
+2. **Whether this really belongs in one change** — always render
+   `purpose_units` and `purpose_unit_cohesion` immediately after the summary,
+   under a short, plain heading naming what the section actually covers (not
+   a schema name like "purpose-unit cohesion"). When the verdict is
+   `split-recommended`, make the heading name the mixed purposes themselves
+   and make this the visual focus of the review. Show the independent
+   purposes, their available acceptance/verification/rollback units, the
+   absence or presence of required dependencies, and `required_next_step`.
+3. **Whether the diff matches what it claims to do** — always render this
+   after the purpose section, under a short, plain heading (not a schema name
+   like "declaration-diff alignment"). When the verdict is `contradiction`,
+   make the heading name the contradiction itself and make this the visual
+   focus of the review. Include the relevant declared change type or
+   invariant, observed changes, reasoning, and `required_next_step`. Do not
+   bury a contradiction in questions or recommendations.
+4. **Material findings** — render `findings` only. Keep evidence, consequence,
+   and options together. Do not repeat the finding from step 3 verbatim; refer
+   back to it by what it actually found, not by a schema name.
+5. **Questions requiring a decision** — render `questions` and open questions
+   from findings. State only questions whose answer can change a conclusion or
+   select between options.
+6. **Review coverage** — render each lens as one compact line, grouped by
+   status, using a plain phrase for what was actually done rather than the
+   schema label. State `no-material-concern` as "investigated, nothing
+   material found" (not a guarantee or a test pass). Render
+   `insufficient-evidence` and `not-applicable` explicitly, as plain
+   statements of what limited the check, not as schema names.
+7. **Review limits** — render `review_limits` verbatim and briefly.
+
+If the JSON is invalid or misses required fields, do not silently improvise a
+review. State the validation failure and retain the raw response for diagnosis.
+
+Read `review_limits` before rendering. The reviewer can fetch and run things
+itself, so a limit naming material it could have reached is a defect in the
+review, not a fact about the change — send it back rather than passing it
+through to the reader. Only limits that survive that check belong in the
+rendered review.
+
+## Plain-language rendering
+
+The reviewer's JSON and its internal reasoning use precise analytical terms
+(contract, cohesion, alignment, lens, purpose unit, gate) on purpose — those
+terms keep the analysis rigorous, and the JSON schema itself must not change.
+When you turn that JSON into Markdown for a person, do not carry the terms
+over as labels. Say the concrete thing the term stands for instead, in
+whatever language you are rendering in:
+
+- Instead of naming a "contract", name the actual interface, config key, error
+  behavior, or data shape that is at stake.
+- Instead of asserting "alignment" or "contradiction", say plainly what the
+  proposal claims and what the diff actually does.
+- Instead of asserting "cohesion", say whether the purposes actually belong in
+  one change or would ship, verify, or roll back better on their own.
+- Instead of naming a "lens", state the actual question that was checked.
+
+This is a wording change only: keep every substantive fact, severity, and
+piece of evidence exactly as reported. The result should read like a
+colleague explaining a concern out loud, not like a summary of the schema.
+
+Treat findings as hypotheses for a design conversation, not merge blockers by
+default. A finding is useful when it identifies a concrete system-level cost,
+an unstated constraint, a missing alternative, or a safer change sequence.
+Discard findings that depend on unsupported assumptions or only restate
+general design advice.
+
+When the review identifies a change strategy concern, prefer a follow-up that
+defines a smaller, observable intermediate step over a request for a broad
+rewrite.

data/packages/deep-review/skill/metadata.yaml

@@ -0,0 +1,6 @@
+---
+name: deep-design-review
+
+static:
+  common:
+    description: Review a proposed or completed change for design quality, alternatives, system fit, and safe change strategy. Use when a normal code review is insufficient or when explicitly requested.