@dev-loops/core 1.0.0-rc.2 → 1.0.0-rc.4

package/src/config/extension-defaults.yaml

@@ -4,93 +4,258 @@ version: 1
 # Precedence: built-in defaults < extension defaults < repo .pi/dev-loop/defaults.* < repo .devloops
 
 # Default strategy: extension intends local-first; consumers can still override via repo defaults.
-strategy:
-  default: local-first
+strategy: local-first
 
 # Local-first input source: tracker issues vs phase docs.
-inputSource:
-  default: tracker
+inputSource: tracker
 
 # Refinement fan-out defaults.
 refinement:
   fanOut: 3
   mode: parallel
   maxCopilotRounds: 5
-  stopOnLowSignal: false
-  lowSignalRoundThreshold: 3
-  lowSignalMaxComments: 2
   roles:
     - scope
     - coverage
     - dry
     - kiss
 
-# Gate review angle definitions for all consumers.
+# Gate review angle definitions for all consumers. A bare string angle is
+# sugar for `{ name }`; `mandatory: true` marks an angle that always runs
+# (was gates.<gate>.mandatoryAngles), and `persona`/`prompt`/`model`/`tier`
+# override the built-in reviewer registry for that angle (was the top-level
+# `personas` map + angle-keyed `models.roles`/`models.roleTiers`).
 gates:
   draft:
     angles:
-      - scope
-      - coverage
-      - correctness
-      - ci-guard
-      - contract-surface
-      - link-check
-      - config-drift
-      - gate-evidence
-      - no-op
-      - input-validation
-      - threat-model
-      - packaging-runtime
-      - state-concurrency
-      - renderer-security
-      - determinism
-      - pr-comments
+      - name: scope
+        persona: review
+        prompt: Check whether every changed file belongs in this PR. Flag unrelated or out-of-scope changes. The PR description's scope section is the contract.
+      - name: coverage
+        persona: review
+        prompt: "Check whether tests cover the changed behavior adequately. Look for missing edge cases, untested error paths, and acceptance-criteria gaps. Also flag test-name quality issues: test names that misrepresent what is actually asserted, overly broad names that hide gaps, and names that don't match the behavior under test. Flag missing negative-case coverage: malformed-argument tests, error-contract tests, and edge-case coverage for boundary conditions, empty inputs, and unexpected states. Do not accept happy-path-only test suites."
+      - name: correctness
+        persona: review
+        prompt: Check whether the implementation matches the acceptance criteria and PR description. Flag logic errors, contract violations, and behavior mismatches.
+      - name: ci-guard
+        persona: review
+        prompt: |-
+          Audit CI/workflow semantics for reproducibility and correctness: - Verify CI configuration is deterministic (no floating version ranges
+            in install steps, lockfile is respected).
+          - Check that branch-protection rules and status-check requirements
+            match the stated merge policy.
+          - Flag non-reproducible install steps and missing lockfile enforcement. - Verify that CI failure precedence is correct: a failing required check
+            must block merge regardless of other passing checks.
+          - Flag pending check-run states that could silently hide failures. - Flag Node.js support-floor mismatches between CI matrices,
+            package.json engines, and documented requirements.
+      - name: contract-surface
+        persona: review
+        prompt: Review this change for public contract-surface drift. Check whether documented schema fields, state/sentinel names, runtime values, tests, and CLI output agree. Verify CLI --help usage matches accepted flags. Compare stdout JSON success shape and stderr JSON error shape against documented examples. Flag optional fields documented as always emitted but conditionally omitted, or fields emitted but undocumented. Stay repo-agnostic; cite concrete changed files and give minimal fixes.
+      - name: link-check
+        persona: review
+        prompt: |-
+          Validate link and path correctness: - Check that all Markdown relative links resolve to existing files
+            or sections.
+          - Flag placeholder links (e.g. href targets still using example URLs,
+            404 references, or TODO links).
+          - When the repo provides `scripts/docs/validate-links.mjs`, run it
+            for the mechanical link pass and report any failures.
+          - Flag symlink-backed doc pointers that point to missing targets. - This persona complements mechanical link validation with context-aware
+            judgment for link intent and anchor correctness.
+      - name: config-drift
+        persona: review
+        prompt: |-
+          Cross-check config, schema, and documentation for contract drift: - Verify that configuration files (.pi/dev-loop/settings.yaml,
+            package.json, CI workflows, skill manifests) agree on canonical
+            status tokens, support floors, and required flags.
+          - Flag any instance where two sources of truth disagree about the
+            supported contract (e.g. one doc says a flag is required, another
+            says it's optional).
+          - Check that the engines.node field matches CI matrix and any
+            documented Node.js support floor.
+          - Flag inconsistencies within a single doc that could confuse
+            consumers (e.g. one section says "default: true" and another
+            section implies the opposite).
+      - name: gate-evidence
+        persona: review
+        prompt: |-
+          Verify that required workflow checkpoint evidence is present and valid: - Check that the draft checkpoint verdict comment exists. While the PR is
+            still draft, it must also reference the current head SHA. After the PR
+            leaves draft, the `draft_gate` checkpoint verdict comment is a one-time transition record
+            and head-SHA matching no longer applies.
+          - Check that the pre-approval checkpoint verdict comment exists when the PR
+            is in a ready/merge state.
+          - Flag any PR that transitions to ready/merge states without visible
+            checkpoint evidence for the current head.
+          - When draft-first enforcement is configured, verify that a draft-gate
+            comment was posted before the PR was marked ready.
+          - This persona is opt-in for the draft gate (uncomment to add).
+            On first PR it checks for any checkpoint evidence (not only draft_gate since
+            no prior gate exists).
+      - name: no-op
+        persona: review
+        prompt: |-
+          Flag workflow or tool invocations that are effectively no-ops: - Check that shell commands and tool calls actually affect output,
+            state, or exit behavior rather than discarding their effect.
+          - Flag tool invocations that look successful but pass arguments in
+            a way that produces no meaningful change.
+          - Flag commands whose output is generated but never consumed. - Flag patterns where a tool is called in a loop but only the last
+            iteration's result is used (or none at all).
+      - name: input-validation
+        persona: review
+        prompt: Review this change for input-validation drift. Check repo slug, issue number, host, SHA, whitespace, and sentinel normalization. Prefer shared parsers/helpers over ad hoc validation. Flag malformed inputs that slip through, confusing errors, path traversal-like segments, and inconsistent trimming/normalization across CLI/API entrypoints. Recommend minimal tests for accepted and rejected forms.
+      - name: threat-model
+        persona: review
+        prompt: "Adversarially threat-model this change end to end — you are an attacker with control over every caller-/plan-influenced input (descriptors, paths, URLs, flags, env, fixture data). Do NOT spot-check; return a trust-boundary CHECKLIST and a verdict per item. Enumerate exhaustively for every seam the diff touches: (1) INPUT ALLOWLISTS — are actions/commands/schemes/hosts allowlisted (not denylisted), and enforced BEFORE any dangerous use (browser launch, exec, read)? (2) NAVIGATION/ORIGIN CONFINEMENT — same-origin/scheme enforced both pre-launch AND at runtime after every redirect / click / server-response (a pre-check the runtime can defeat is a hole). (3) RESOURCE/LOOP BOUNDS — step/size/time/recursion caps on attacker-influenced counts. (4) DATA-AT-REST + CLEANUP — sensitive intermediate artifacts minimized and removed on EVERY fail-closed path (not just the happy path); no off-origin/partial artifact left on disk on error. (5) EXPORTED/ENTRY-POINT TRUST — does every exported function / alternate entry self-validate, or can it bypass the parse-time validation the CLI does? (6) ERROR/TEARDOWN SAFETY — a throw in rm/close/teardown must not break the fail-closed envelope or leak state. (7) PATH TRAVERSAL / DESERIALIZATION — reject absolute/`..`/escape-base paths before read; no unsafe deserialization of untrusted data. (8) SHELL/PROCESS — no unescaped interpolation into a shell; prefer argv arrays; no `shell:true` with caller input. For each category that applies, state whether the change is safe and cite the guarding code (file:line) or flag the specific abuse and a failing-input example. If a category does not apply to the touched seam, say so explicitly rather than skipping it."
+      - name: packaging-runtime
+        persona: review
+        prompt: "Review this change for packaging/runtime asset contract gaps. Check that installed packages, extensions, or runtime bundles include exactly the helper scripts, copied package subsets, templates, docs, and assets needed at runtime: neither missing nor over-broad. Compare install docs, fixture assertions, allow-lists, and import paths. Flag runtime-only dependencies not covered by packaging tests."
+      - name: state-concurrency
+        persona: review
+        prompt: Review this change for state concurrency and locking risks. Check state-file read/modify/write paths, lock acquisition/release, stale lock handling, concurrent invocations, atomic writes, managed process cleanup, and stderr/error capture. Flag races that can clobber state or leave orphaned locks/processes. Recommend narrow deterministic concurrency or cleanup tests.
+      - name: renderer-security
+        persona: review
+        prompt: Review this change for renderer security. Check HTML text escaping, URL encoding, attribute encoding, JSON/script embedding, and rendering of user-controlled content. Treat titles, names, URLs, statuses, errors, and external payload fields as untrusted. Flag raw interpolation into HTML or attributes and tests that expect unsafe output.
+      - name: determinism
+        persona: review
+        prompt: Review this change for determinism. Check ordering, tie-breakers, localeCompare use, time/random/environment dependence, polling/count assumptions, and mocks/stubs that allow unexpected extra calls. Require stable sorting, strict stubs, deterministic fixture data, and tests independent of locale, timezone, filesystem order, and network timing.
+      - name: pr-comments
+        persona: review
+        prompt: |-
+          Scan PR comments for unresolved issues before declaring the gate clean. Check all PR comments and review threads for: - Comments from the repository owner or collaborators that point out
+            implementation bugs, logic errors, contract violations, or security
+            issues
+          - Unresolved review threads that raise implementation concerns Flag any unresolved comment that identifies a concrete implementation problem as a blocking finding (severity: high or medium). Do not flag: - Resolved threads - Style nits, formatting suggestions, or cosmetic feedback - Comments from non-collaborators or bots - Outdated comments that were already addressed in a later commit If no unresolved implementation concerns exist, return clean.
       - contradiction-lens
       - code-conformance
       - semantic-drift
-    excludeAngles: []
+      - name: pr-description
+        mandatory: true
+        persona: review
+        prompt: 'Review the PR description for completeness, contract fitness, and checkbox formatting before this PR is marked ready for review. The PR body is the implementation contract — it must have: - A Summary section explaining what changed and why - A Scope and context section defining the boundary of the change - An Acceptance criteria section with the linked issue acceptance criteria - A Definition of done section - A Non-goals section - A Validation command section describing exactly how to verify the change - The "Closes #N" line must match the linked issue; flag changes that alter or remove the operator-intended close target Checkboxes (`- [ ]` / `- [x]`, or `* [ ]` / `* [x]`) must appear inside genuine Markdown list items. Flag any checkbox marker used outside a list item (including table cells) as a medium finding. Flag any checkbox marker wrapped in backticks (e.g. `` `[x]` ``) as a medium finding. Flag PRs where the body is a single sentence or lacks any of these sections. Do not block on formatting preferences other than checkbox correctness.'
     required: true
     requireCi: true
-    mandatoryAngles:
-      - pr-description
-  # Gate findings comments live ON the PR (the local-first spec-of-record /
-  # human-review surface), so they are evidence, not tracker noise — keep them on.
-  postFindingsComments: true
+    # Diff-class angle tiers (opt-in, ordered, first match wins). A matching tier
+    # replaces this gate's resolved angle set with its own for that round's
+    # fan-out (mandatory angles are always kept); it never changes execution
+    # mode. A tiered round is still a normal fanout_fanin round:
+    #   tiers:
+    #     - name: docs-only
+    #       match: { kinds: [docs] }
+    #       angles: [pr-description, link-check, gate-evidence]
+  # The gate round's verdict review already carries every finding, so the
+  # consolidated findings comment is opt-in duplication — keep it off.
+  postFindingsComments: false
+  # Grouped fan-out dispatch (AC6, default mode — see resolveFanoutGroups):
+  # angles that read the same surface batch onto one reviewer. Angles not
+  # named below join the auto-chunked leftover pool. Set `mode: per-angle`
+  # to restore full one-reviewer-per-angle fan-out repo-wide (bypasses
+  # maxAnglesPerGroup: 1 honors configured groups; the two match in unit size only when no configured multi-angle group matches). `gate:full` forces the full angle set but no
+  # longer restores per-angle dispatch (ADR 0047 superseded by 0048) — it
+  # dispatches grouped.
+  #
+  # Two orthogonal dispatch bounds (#1601):
+  #   maxAnglesPerGroup (N, default 3, min 1) — leftover ungrouped angles
+  #     auto-chunk into dispatch units of ≤N instead of singletons.
+  #   maxConcurrent (M, default 4, min 1) — at most M dispatch units per wave.
+  # Both count dispatch units (groups), not angles.
+  fanout:
+    maxAnglesPerGroup: 3
+    maxConcurrent: 4
+    groups:
+      - name: docs-surface
+        angles: [docs, link-check, config-drift, contract-surface]
+      - name: process
+        angles: [scope, pr-description, gate-evidence, pr-checklist-matrix]
+      - name: correctness-input
+        angles: [correctness, input-validation]
+      - name: determinism-state
+        angles: [determinism, state-concurrency]
   preApproval:
     angles:
-      - dry
-      - kiss
-      - yagni
-      - srp
-      - soc
-      - deep
-      - ocp
-      - lsp
-      - isp
-      - dip
-      - docs
-      - pr-checklist-matrix
+      - name: dry
+        persona: review
+        prompt: Flag duplicated logic, repeated patterns, and copy-pasted code. Prefer one canonical path. Check for restated policies across docs and skills.
+      - name: kiss
+        persona: review
+        prompt: Flag over-engineering and unnecessary complexity. Prefer simple solutions. Question extra layers, abstractions, and indirection that don't earn their keep.
+      - name: yagni
+        persona: review
+        prompt: Flag speculative features, future-proofing, and compatibility shims not required by the current acceptance criteria. YAGNI = You Aren't Gonna Need It.
+      - name: srp
+        persona: review
+        prompt: "Single Responsibility Principle: check that each module, file, class, and function has exactly one reason to change. Flag multi-concern files, god objects, mixed abstractions, and modules that own unrelated responsibilities."
+      - name: soc
+        persona: review
+        prompt: "Separation of Concerns: flag modules that mix distinct concerns (e.g., business logic + I/O, data access + presentation, orchestration + implementation). Each concern should live in its own module with a clear boundary."
+      - name: deep
+        persona: review
+        prompt: |-
+          Perform a structural code quality audit of this PR.
+          Bring the same rigor as a full-codebase deslop audit, scoped to this change: - Question whether every new file, export, layer, or abstraction is
+            genuinely necessary. Prefer deletion over addition.
+          - Flag files crossing 1000 lines without strong justification. - Flag new conditionals bolted onto unrelated paths. Push logic into its
+            own boundary instead of scattering special cases.
+          - Flag thin wrappers, re-export-only files, and identity abstractions
+            that add indirection without buying clarity.
+          - Flag feature logic leaking into shared or general-purpose modules. - Question cast-heavy, optionality-heavy, or any-typed contracts that
+            obscure the real invariant.
+
+          Be ambitious about simplification: - Look for "code judo" moves: restructurings that preserve behavior while
+            deleting whole categories of complexity.
+          - Prefer the simpler model. If the change adds moving parts, ask whether
+            fewer would achieve the same result.
+
+          Do not rubber-stamp working-but-messier code. Approval bar: - no structural regression - no missed simplification opportunity - no unjustified file-size explosion - no spaghetti branching growth - no unnecessary abstraction or indirection
+          This persona complements full-repo deslop audits: same rigor, applied per-PR.
+      - name: ocp
+        persona: review
+        prompt: |-
+          Open/Closed Principle: flag code that requires modifying existing
+            modules to add new behavior. Prefer extension points, plugin
+            architectures, and config-driven dispatch over patching internals.
+      - name: lsp
+        persona: review
+        prompt: "Liskov Substitution Principle: flag subtypes or implementations that weaken base contracts, throw unexpected errors, or require special-casing in callers. Subtypes must be fully substitutable for their base types."
+      - name: isp
+        persona: review
+        prompt: "Interface Segregation Principle: flag fat interfaces and modules that force consumers to depend on methods or exports they never use. Prefer narrow, role-specific interfaces."
+      - name: dip
+        persona: review
+        prompt: "Dependency Inversion Principle: flag high-level modules depending on low-level implementation details. Check that abstractions are owned by the consumer, not the implementation. Flag concrete imports where an interface/contract should exist."
+      - name: docs
+        persona: docs
+        prompt: "Review documentation correctness for the current change. Check that relative markdown links resolve, symlink-backed doc pointers resolve, navigable doc references are actual markdown links rather than bare backtick path mentions, command/script references still exist and use current names, and index/surface references match the current file tree. Also flag stale command references: removed or renamed npm scripts, CLI commands, or tool invocations that no longer match the current codebase. When the repo provides `scripts/docs/validate-links.mjs`, use it for the mechanical link pass; otherwise keep the review scoped to the touched doc surface and current change only."
+      - name: pr-checklist-matrix
+        mandatory: true
+        persona: review
+        prompt: |-
+          Verify before approval that the PR checklist and AC/DoD/non-goals matrix are complete. - Every PR checkbox (`- [ ]`) must be checked. If any box is unchecked, flag it as a blocking finding. - The PR body must contain an AC/DoD/non-goals matrix that maps each acceptance criterion
+            to its definition-of-done item(s) and lists explicit non-goals.
+          - The matrix must have a markdown table with at least a header row and one content row. - Flag the matrix as incomplete if any acceptance criterion, definition-of-done item, or non-goal is missing.
       - contradiction-lens
       - correctness-final
       - ui-validation
-    excludeAngles: []
     required: true
-    mandatoryAngles:
-      - pr-checklist-matrix
   # Relaxed spike gate profile (#965). A spike's deliverable is a findings doc,
   # not production code, so it is intentionally lighter than the production
   # draft -> pre-approval -> Copilot set: a small docs-first angle set, not a
   # required gate, and no CI prerequisite. Resolved through the same
-  # config-merge layering and resolveGateConfig path as draft/preApproval; only
-  # applies to spike-mode work, so production gates are unaffected.
+  # config-merge layering and resolveGateConfig path as draft/preApproval (one
+  # unified GateConfig, D2) — only applies to spike-mode work, so production
+  # gates are unaffected. `blockCleanOnFindingSeverities`/`dynamic.additive`
+  # are accepted but inert for spike (a findings-doc deliverable has no "clean
+  # verdict" escalation path or additive dynamic pool).
   spike:
     angles:
-      - scope
-      - docs
-    excludeAngles: []
+      - name: scope
+        persona: review
+        prompt: Check whether every changed file belongs in this PR. Flag unrelated or out-of-scope changes. The PR description's scope section is the contract.
+      - name: docs
+        persona: docs
+        prompt: "Review documentation correctness for the current change. Check that relative markdown links resolve, symlink-backed doc pointers resolve, navigable doc references are actual markdown links rather than bare backtick path mentions, command/script references still exist and use current names, and index/surface references match the current file tree. Also flag stale command references: removed or renamed npm scripts, CLI commands, or tool invocations that no longer match the current codebase. When the repo provides `scripts/docs/validate-links.mjs`, use it for the mechanical link pass; otherwise keep the review scoped to the touched doc surface and current change only."
     required: false
     requireCi: false
-    mandatoryAngles: []
 
 # Autonomy: only merge requires operator confirmation by default.
 autonomy:
@@ -121,7 +286,7 @@ localImplementation:
     maxFiles: 2
     maxLines: 100
 
-# Queue defaults (repo-specific projectNumber/boardTitle omitted by design).
+# Queue defaults (repo-specific queue.board omitted by design).
 queue:
   maxParallel: 3
   # Local-first is PR-first (issues are skipped, #952), so auto-filing issues is
@@ -129,380 +294,6 @@ queue:
   maxAutoFiledIssues: 1
   reDispatchMaxRetries: 1
 
-# Persona registry used by gate review angle resolution.
-personas:
-  refiner:
-    persona: refiner
-    prompt: |-
-      For every refinement, include an AC/DoD/Non-goal coverage matrix:
-
-      | Item | Type (AC/DoD/Non-goal) | Status (Met/Partial/Unmet/Unverified) | Evidence | Notes |
-      |---|---|---|---|---|
-      | <exact item text> | AC | Unverified | <reference> | |
-
-      Use exact wording from the source issue(s); when the governing input is a phase doc or other spec instead of an issue, use that source wording exactly for every explicit item.
-      Include every explicit acceptance criterion, definition-of-done item, and non-goal; do not skip items.
-      If no explicit definition of done exists, add a `Proposed DoD` subsection before the matrix.
-      Treat any `Partial`, `Unmet`, or `Unverified` row as incomplete refinement.
-      A refinement is complete only when no item has `Partial`, `Unmet`, or `Unverified` status.
-
-      When a bounded audit artifact is supplied, add an `Audit inputs` subsection.
-      Summarize the audited scope, list prioritized findings, include the highest-value follow-up candidates,
-      and add an explicit `Will not rewrite/broaden in this phase` statement.
-      For each prioritized finding, classify it as exactly one of: current-phase scope/AC,
-      DoD expectation, explicit non-goal/defer, or risk/watchpoint.
-      Do not fabricate audit evidence when none was provided.
-    defaultModel: null
-
-  audit:
-    persona: review
-    prompt: >-
-      Run a bounded refinement audit. Audit only the named files/areas.
-      Prefer delete / merge / trim / defer framing over additive rewrite plans.
-      Produce prioritized findings and highest-value follow-up candidates,
-      not a whole-repo essay.
-      Always include a bounded-scope statement and a `not rewriting in this phase`
-      statement. Findings are planning inputs, not automatic rewrite authorization.
-    defaultModel: null
-
-  scope:
-    persona: review
-    prompt: >-
-      Check whether every changed file belongs in this PR.
-      Flag unrelated or out-of-scope changes.
-      The PR description's scope section is the contract.
-    defaultModel: null
-
-  coverage:
-    persona: review
-    prompt: >-
-      Check whether tests cover the changed behavior adequately.
-      Look for missing edge cases, untested error paths,
-      and acceptance-criteria gaps.
-      Also flag test-name quality issues: test names that misrepresent
-      what is actually asserted, overly broad names that hide gaps, and
-      names that don't match the behavior under test.
-      Flag missing negative-case coverage: malformed-argument tests,
-      error-contract tests, and edge-case coverage for boundary
-      conditions, empty inputs, and unexpected states.
-      Do not accept happy-path-only test suites.
-    defaultModel: null
-
-  correctness:
-    persona: review
-    prompt: >-
-      Check whether the implementation matches the acceptance criteria
-      and PR description. Flag logic errors, contract violations,
-      and behavior mismatches.
-    defaultModel: null
-
-  docs:
-    persona: docs
-    prompt: >-
-      Review documentation correctness for the current change. Check that
-      relative markdown links resolve, symlink-backed doc pointers resolve,
-      navigable doc references are actual markdown links rather than bare
-      backtick path mentions, command/script references still exist and use
-      current names, and index/surface references match the current file tree.
-      Also flag stale command references: removed or renamed npm scripts,
-      CLI commands, or tool invocations that no longer match the current
-      codebase. When the repo provides `scripts/docs/validate-links.mjs`,
-      use it for the mechanical link pass; otherwise keep the review scoped
-      to the touched doc surface and current change only.
-    defaultModel: null
-
-  deep:
-    persona: review
-    prompt: >-
-      Perform a structural code quality audit of this PR.
-
-      Bring the same rigor as a full-codebase deslop audit, scoped to this
-      change:
-      - Question whether every new file, export, layer, or abstraction is
-        genuinely necessary. Prefer deletion over addition.
-      - Flag files crossing 1000 lines without strong justification.
-      - Flag new conditionals bolted onto unrelated paths. Push logic into its
-        own boundary instead of scattering special cases.
-      - Flag thin wrappers, re-export-only files, and identity abstractions
-        that add indirection without buying clarity.
-      - Flag feature logic leaking into shared or general-purpose modules.
-      - Question cast-heavy, optionality-heavy, or any-typed contracts that
-        obscure the real invariant.
-
-      Be ambitious about simplification:
-      - Look for "code judo" moves: restructurings that preserve behavior while
-        deleting whole categories of complexity.
-      - Prefer the simpler model. If the change adds moving parts, ask whether
-        fewer would achieve the same result.
-
-      Do not rubber-stamp working-but-messier code.
-      Approval bar:
-      - no structural regression
-      - no missed simplification opportunity
-      - no unjustified file-size explosion
-      - no spaghetti branching growth
-      - no unnecessary abstraction or indirection
-
-      This persona complements full-repo deslop audits: same rigor,
-      applied per-PR.
-    defaultModel: null
-
-  dry:
-    persona: review
-    prompt: >-
-      Flag duplicated logic, repeated patterns, and copy-pasted code.
-      Prefer one canonical path. Check for restated policies across
-      docs and skills.
-    defaultModel: null
-
-  kiss:
-    persona: review
-    prompt: >-
-      Flag over-engineering and unnecessary complexity.
-      Prefer simple solutions. Question extra layers, abstractions,
-      and indirection that don't earn their keep.
-    defaultModel: null
-
-  srp:
-    persona: review
-    prompt: >-
-      Single Responsibility Principle: check that each module, file,
-      class, and function has exactly one reason to change.
-      Flag multi-concern files, god objects, mixed abstractions,
-      and modules that own unrelated responsibilities.
-    defaultModel: null
-
-  ocp:
-    persona: review
-    prompt: >-
-      Open/Closed Principle: flag code that requires modifying existing
-        modules to add new behavior. Prefer extension points, plugin
-        architectures, and config-driven dispatch over patching internals.
-    defaultModel: null
-
-  lsp:
-    persona: review
-    prompt: >-
-      Liskov Substitution Principle: flag subtypes or implementations
-      that weaken base contracts, throw unexpected errors, or require
-      special-casing in callers. Subtypes must be fully substitutable
-      for their base types.
-    defaultModel: null
-
-  isp:
-    persona: review
-    prompt: >-
-      Interface Segregation Principle: flag fat interfaces and modules
-      that force consumers to depend on methods or exports they never
-      use. Prefer narrow, role-specific interfaces.
-    defaultModel: null
-
-  dip:
-    persona: review
-    prompt: >-
-      Dependency Inversion Principle: flag high-level modules depending
-      on low-level implementation details. Check that abstractions are
-      owned by the consumer, not the implementation. Flag concrete
-      imports where an interface/contract should exist.
-    defaultModel: null
-
-  soc:
-    persona: review
-    prompt: >-
-      Separation of Concerns: flag modules that mix distinct concerns
-      (e.g., business logic + I/O, data access + presentation,
-      orchestration + implementation). Each concern should live in
-      its own module with a clear boundary.
-    defaultModel: null
-
-  yagni:
-    persona: review
-    prompt: >-
-      Flag speculative features, future-proofing, and compatibility shims
-      not required by the current acceptance criteria.
-      YAGNI = You Aren't Gonna Need It.
-    defaultModel: null
-
-  contract-surface:
-    persona: review
-    prompt: >-
-      Review this change for public contract-surface drift. Check whether documented schema fields, state/sentinel names, runtime values, tests, and CLI output agree. Verify CLI --help usage matches accepted flags. Compare stdout JSON success shape and stderr JSON error shape against documented examples. Flag optional fields documented as always emitted but conditionally omitted, or fields emitted but undocumented. Stay repo-agnostic; cite concrete changed files and give minimal fixes.
-    defaultModel: null
-
-  input-validation:
-    persona: review
-    prompt: >-
-      Review this change for input-validation drift. Check repo slug, issue number, host, SHA, whitespace, and sentinel normalization. Prefer shared parsers/helpers over ad hoc validation. Flag malformed inputs that slip through, confusing errors, path traversal-like segments, and inconsistent trimming/normalization across CLI/API entrypoints. Recommend minimal tests for accepted and rejected forms.
-    defaultModel: null
-
-  packaging-runtime:
-    persona: review
-    prompt: >-
-      Review this change for packaging/runtime asset contract gaps. Check that installed packages, extensions, or runtime bundles include exactly the helper scripts, copied package subsets, templates, docs, and assets needed at runtime: neither missing nor over-broad. Compare install docs, fixture assertions, allow-lists, and import paths. Flag runtime-only dependencies not covered by packaging tests.
-    defaultModel: null
-
-  state-concurrency:
-    persona: review
-    prompt: >-
-      Review this change for state concurrency and locking risks. Check state-file read/modify/write paths, lock acquisition/release, stale lock handling, concurrent invocations, atomic writes, managed process cleanup, and stderr/error capture. Flag races that can clobber state or leave orphaned locks/processes. Recommend narrow deterministic concurrency or cleanup tests.
-    defaultModel: null
-
-  renderer-security:
-    persona: review
-    prompt: >-
-      Review this change for renderer security. Check HTML text escaping, URL encoding, attribute encoding, JSON/script embedding, and rendering of user-controlled content. Treat titles, names, URLs, statuses, errors, and external payload fields as untrusted. Flag raw interpolation into HTML or attributes and tests that expect unsafe output.
-    defaultModel: null
-
-  threat-model:
-    persona: review
-    prompt: >-
-      Adversarially threat-model this change end to end — you are an attacker with control over every caller-/plan-influenced input (descriptors, paths, URLs, flags, env, fixture data). Do NOT spot-check; return a trust-boundary CHECKLIST and a verdict per item. Enumerate exhaustively for every seam the diff touches: (1) INPUT ALLOWLISTS — are actions/commands/schemes/hosts allowlisted (not denylisted), and enforced BEFORE any dangerous use (browser launch, exec, read)? (2) NAVIGATION/ORIGIN CONFINEMENT — same-origin/scheme enforced both pre-launch AND at runtime after every redirect / click / server-response (a pre-check the runtime can defeat is a hole). (3) RESOURCE/LOOP BOUNDS — step/size/time/recursion caps on attacker-influenced counts. (4) DATA-AT-REST + CLEANUP — sensitive intermediate artifacts minimized and removed on EVERY fail-closed path (not just the happy path); no off-origin/partial artifact left on disk on error. (5) EXPORTED/ENTRY-POINT TRUST — does every exported function / alternate entry self-validate, or can it bypass the parse-time validation the CLI does? (6) ERROR/TEARDOWN SAFETY — a throw in rm/close/teardown must not break the fail-closed envelope or leak state. (7) PATH TRAVERSAL / DESERIALIZATION — reject absolute/`..`/escape-base paths before read; no unsafe deserialization of untrusted data. (8) SHELL/PROCESS — no unescaped interpolation into a shell; prefer argv arrays; no `shell:true` with caller input. For each category that applies, state whether the change is safe and cite the guarding code (file:line) or flag the specific abuse and a failing-input example. If a category does not apply to the touched seam, say so explicitly rather than skipping it.
-    defaultModel: null
-
-  determinism:
-    persona: review
-    prompt: >-
-      Review this change for determinism. Check ordering, tie-breakers, localeCompare use, time/random/environment dependence, polling/count assumptions, and mocks/stubs that allow unexpected extra calls. Require stable sorting, strict stubs, deterministic fixture data, and tests independent of locale, timezone, filesystem order, and network timing.
-    defaultModel: null
-
-  ci-guard:
-    persona: review
-    prompt: >-
-      Audit CI/workflow semantics for reproducibility and correctness:
-      - Verify CI configuration is deterministic (no floating version ranges
-        in install steps, lockfile is respected).
-      - Check that branch-protection rules and status-check requirements
-        match the stated merge policy.
-      - Flag non-reproducible install steps and missing lockfile enforcement.
-      - Verify that CI failure precedence is correct: a failing required check
-        must block merge regardless of other passing checks.
-      - Flag pending check-run states that could silently hide failures.
-      - Flag Node.js support-floor mismatches between CI matrices,
-        package.json engines, and documented requirements.
-    defaultModel: null
-
-  link-check:
-    persona: review
-    prompt: >-
-      Validate link and path correctness:
-      - Check that all Markdown relative links resolve to existing files
-        or sections.
-      - Flag placeholder links (e.g. href targets still using example URLs,
-        404 references, or TODO links).
-      - When the repo provides `scripts/docs/validate-links.mjs`, run it
-        for the mechanical link pass and report any failures.
-      - Flag symlink-backed doc pointers that point to missing targets.
-      - This persona complements mechanical link validation with context-aware
-        judgment for link intent and anchor correctness.
-    defaultModel: null
-
-  pr-description:
-    persona: review
-    prompt: >-
-      Review the PR description for completeness, contract fitness, and checkbox formatting before this PR is marked ready for review.
-      The PR body is the implementation contract — it must have:
-      - A Summary section explaining what changed and why
-      - A Scope and context section defining the boundary of the change
-      - An Acceptance criteria section with the linked issue acceptance criteria
-      - A Definition of done section
-      - A Non-goals section
-      - A Validation command section describing exactly how to verify the change
-      - The "Closes #N" line must match the linked issue; flag changes that alter or remove the operator-intended close target
-      Checkboxes (`- [ ]` / `- [x]`, or `* [ ]` / `* [x]`) must appear inside genuine Markdown list items. Flag any checkbox marker used outside a list item (including table cells) as a worth-fixing-now finding.
-      Flag any checkbox marker wrapped in backticks (e.g. `` `[x]` ``) as a worth-fixing-now finding.
-      Flag PRs where the body is a single sentence or lacks any of these sections.
-      Do not block on formatting preferences other than checkbox correctness.
-    defaultModel: null
-
-  acceptance-criteria:
-    persona: review
-    prompt: >-
-      Verify that each acceptance criterion and definition-of-done item from the
-      linked issue/PR is actually satisfied by the implementation — not merely
-      listed. For every criterion, cite the concrete code/test/behavior evidence
-      that meets it; flag any criterion that is unmet, only partially met, or
-      unverifiable from the diff as a blocking finding. Confirm definition-of-done
-      items (tests, docs, validation) are done and that declared non-goals are
-      respected (no scope creep).
-    defaultModel: null
-
-  pr-checklist-matrix:
-    persona: review
-    prompt: >-
-      Verify before approval that the PR checklist and AC/DoD/non-goals matrix are complete.
-      - Every PR checkbox (`- [ ]`) must be checked. If any box is unchecked, flag it as a blocking finding.
-      - The PR body must contain an AC/DoD/non-goals matrix that maps each acceptance criterion
-        to its definition-of-done item(s) and lists explicit non-goals.
-      - The matrix must have a markdown table with at least a header row and one content row.
-      - Flag the matrix as incomplete if any acceptance criterion, definition-of-done item, or non-goal is missing.
-    defaultModel: null
-
-  pr-comments:
-    persona: review
-    prompt: >-
-      Scan PR comments for unresolved issues before declaring the gate clean.
-      Check all PR comments and review threads for:
-      - Comments from the repository owner or collaborators that point out
-        implementation bugs, logic errors, contract violations, or security
-        issues
-      - Unresolved review threads that raise implementation concerns
-      Flag any unresolved comment that identifies a concrete implementation
-      problem as a blocking finding (severity: must-fix or worth-fixing-now).
-      Do not flag:
-      - Resolved threads
-      - Style nits, formatting suggestions, or cosmetic feedback
-      - Comments from non-collaborators or bots
-      - Outdated comments that were already addressed in a later commit
-      If no unresolved implementation concerns exist, return clean.
-  config-drift:
-    persona: review
-    prompt: >-
-      Cross-check config, schema, and documentation for contract drift:
-      - Verify that configuration files (.pi/dev-loop/settings.yaml,
-        package.json, CI workflows, skill manifests) agree on canonical
-        status tokens, support floors, and required flags.
-      - Flag any instance where two sources of truth disagree about the
-        supported contract (e.g. one doc says a flag is required, another
-        says it's optional).
-      - Check that the engines.node field matches CI matrix and any
-        documented Node.js support floor.
-      - Flag inconsistencies within a single doc that could confuse
-        consumers (e.g. one section says "default: true" and another
-        section implies the opposite).
-    defaultModel: null
-
-  gate-evidence:
-    persona: review
-    prompt: >-
-      Verify that required workflow checkpoint evidence is present and valid:
-      - Check that the draft checkpoint verdict comment exists. While the PR is
-        still draft, it must also reference the current head SHA. After the PR
-        leaves draft, the `draft_gate` checkpoint verdict comment is a one-time transition record
-        and head-SHA matching no longer applies.
-      - Check that the pre-approval checkpoint verdict comment exists when the PR
-        is in a ready/merge state.
-      - Flag any PR that transitions to ready/merge states without visible
-        checkpoint evidence for the current head.
-      - When draft-first enforcement is configured, verify that a draft-gate
-        comment was posted before the PR was marked ready.
-      - This persona is opt-in for the draft gate (uncomment to add).
-        On first PR it checks for any checkpoint evidence (not only draft_gate since
-        no prior gate exists).
-    defaultModel: null
-
-  no-op:
-    persona: review
-    prompt: >-
-      Flag workflow or tool invocations that are effectively no-ops:
-      - Check that shell commands and tool calls actually affect output,
-        state, or exit behavior rather than discarding their effect.
-      - Flag tool invocations that look successful but pass arguments in
-        a way that produces no meaningful change.
-      - Flag commands whose output is generated but never consumed.
-      - Flag patterns where a tool is called in a loop but only the last
-        iteration's result is used (or none at all).
-    defaultModel: null
-
 # Internal path patterns for internal-only PR detection.
 internalPathPatterns:
   - "^scripts/"