gentle-pi 0.1.0

package/skills/chained-pr/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: chained-pr
+description: "Trigger: PRs over 400 lines, stacked PRs, review slices. Split oversized changes into chained PRs that protect review focus."
+license: Apache-2.0
+metadata:
+  author: gentleman-programming
+  version: "1.0"
+---
+
+## Activation Contract
+
+Load this skill when a planned PR may exceed **400 changed lines**, SDD forecasts `400-line budget risk: High` or `Chained PRs recommended: Yes`, or the user asks for chained/stacked PRs, review slices, or reviewer-load control.
+
+## Hard Rules
+
+- Split PRs over **400 changed lines** unless a maintainer explicitly accepts `size:exception`.
+- Keep each PR reviewable in about **≤60 minutes**.
+- Use one deliverable work unit per PR; keep tests/docs with the unit they verify.
+- State start, end, prior dependencies, follow-up work, and out-of-scope items in every chained PR.
+- Every child PR must include a dependency diagram marking the current PR with `📍`.
+- In Feature Branch Chain, create a draft/no-merge tracker PR; child PR #1 targets the tracker branch, later children target the immediate parent branch.
+- Treat polluted diffs as base bugs: retarget or rebase until only the current work unit appears.
+- Do not mix chain strategies after the user chooses one.
+
+## Decision Gates
+
+| Condition | Action |
+|---|---|
+| PR ≤400 changed lines and focused | Keep single PR. |
+| PR >400, each slice can land independently | Use Stacked PRs to main. |
+| PR >400, feature must integrate before main | Use Feature Branch Chain with tracker. |
+| Generated/vendor/migration diff cannot split cleanly | Ask maintainer for `size:exception`. |
+| SDD provides `delivery_strategy` | Follow it before apply/PR creation. |
+
+## Execution Steps
+
+1. Estimate changed lines and identify independent work units.
+2. Ask for a chain strategy when none is cached and the budget is exceeded.
+3. Create branches/PRs using the chosen strategy only.
+4. Add Chain Context to each PR without replacing the repo PR template.
+5. Verify each PR independently: CI/tests/docs/manual checks, rollback scope, and clean diff.
+6. Keep tracker PR draft/no-merge until all child PRs are reviewed and integrated.
+
+## Output Contract
+
+Return the chosen strategy, PR order, current PR boundary, dependency diagram, review budget (`additions + deletions`), verification plan, and any `size:exception` rationale.
+
+## References
+
+- [references/chaining-details.md](references/chaining-details.md) — strategy diagrams, PR body section, branch commands, and reviewer guidance.

package/skills/chained-pr/references/chaining-details.md

@@ -0,0 +1,99 @@
+# Chained PR Details
+
+## Strategy Notes
+
+| | Stacked PRs to main | Feature Branch Chain |
+|---|---|---|
+| Speed | Each slice can ship in order | Full feature waits for tracker merge |
+| Rollback | Revert individual main PRs | Revert/hold the whole feature branch |
+| Risk | Partial behavior may land | Nothing lands until the chain completes |
+| Complexity | Simpler retarget/rebase flow | Requires tracker and strict diff hygiene |
+
+## Feature Branch Chain
+
+Use when the feature branch accumulates the final integration while child PRs are reviewed as focused slices.
+
+```text
+main
+ └── feat/my-feature              ← tracker/final integration branch
+      ↑ PR #1 base: feat/my-feature
+      └── feat/my-feature-01-core
+           ↑ PR #2 base: feat/my-feature-01-core
+           └── feat/my-feature-02-shared
+                ↑ PR #3 base: feat/my-feature-02-shared
+                └── feat/my-feature-03-slice
+```
+
+Steps:
+
+1. Create the feature/tracker branch from `main`.
+2. Open the tracker PR to `main`; mark it draft/no-merge.
+3. Create PR #1 from a child branch and target it to the tracker branch.
+4. Create each later child branch from the previous PR branch and target it to that parent branch.
+5. Merge/integrate children in order; merge the tracker only after the chain is complete.
+
+## Stacked PRs to Main
+
+Use when each slice can land on `main` in order.
+
+```text
+main <- PR 1: foundation
+          └── PR 2: feature slice built on PR 1
+                └── PR 3: docs/tests built on PR 2
+```
+
+After a parent PR merges, rebase/retarget the next PR so GitHub shows only the current slice.
+
+## Chain Context Section
+
+Append this section to the repo PR template; do not replace required issue/checklist sections.
+
+```markdown
+## Chain Context
+
+| Field | Value |
+|-------|-------|
+| Chain | <feature or stack name> |
+| Tracker PR | <#NNN or "Not needed"> |
+| Position | <N of total> |
+| Base | `<target branch>` |
+| Depends on | <PR/issue/link or "None"> |
+| Follow-up | <next PR or "None"> |
+| Review budget | <changed lines> / 400 |
+| Starts at | <branch, PR, or state this builds on> |
+| Ends with | <standalone result delivered by this PR> |
+
+### Chain Overview
+
+```text
+main
+ └── #NNN Previous PR
+      └── 📍 #NNN This PR
+           └── #NNN Next PR
+```
+
+### Scope
+- Includes: <focused unit>
+- Excludes: <deferred work>
+
+### Autonomy
+- [ ] CI is expected to pass for this PR branch
+- [ ] This PR has one deliverable scope
+- [ ] This PR can be rolled back without unrelated changes
+- [ ] Tests, docs, or manual verification cover this unit
+```
+
+## Commands
+
+```bash
+gh pr view <PR_NUMBER> --json additions,deletions,changedFiles,title,url
+gh pr create --base feat/my-feature --title "feat(scope): focused slice" --body-file pr-body.md
+gh pr create --base feat/my-feature-01-core --title "feat(scope): next focused slice" --body-file pr-body.md
+```
+
+## Reviewer Guidance
+
+- Ask for a split when a PR exceeds 400 changed lines without `size:exception`.
+- Recommend Feature Branch Chain when work must integrate before `main`.
+- Recommend stacked PRs when each slice can merge independently.
+- Review child PRs against immediate parent branches; a polluted diff is a branching bug.

package/skills/cognitive-doc-design/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: cognitive-doc-design
+description: "Design docs that reduce cognitive load. Trigger: writing guides, READMEs, RFCs, onboarding, architecture, or review-facing docs."
+license: Apache-2.0
+metadata:
+  author: gentleman-programming
+  version: "1.0"
+---
+
+## When to Use
+
+Load this skill when creating or editing documentation that people need to understand quickly, retain, or use during review.
+
+Use it especially for:
+
+- PR descriptions and review notes.
+- Contributor or maintainer guides.
+- Architecture, workflow, or onboarding docs.
+- Any doc that currently feels long, dense, or hard to scan.
+
+## Critical Patterns
+
+| Pattern | Rule |
+|---------|------|
+| Lead with the answer | Put the decision, action, or outcome first. Context comes after. |
+| Progressive disclosure | Start with the happy path, then add details, edge cases, and references. |
+| Chunking | Group related information into small sections. Keep flat lists short. |
+| Signposting | Use headings, labels, callouts, and summaries so readers know where they are. |
+| Recognition over recall | Prefer tables, checklists, examples, and templates over prose that must be remembered. |
+| Review empathy | Design docs so reviewers can verify intent without reconstructing the whole story. |
+
+## Documentation Shape
+
+Use this default structure unless the repo already provides a stronger template:
+
+```markdown
+# <Outcome-oriented title>
+
+<One paragraph: what changed, who it helps, and why it matters.>
+
+## Quick path
+
+1. <First action>
+2. <Second action>
+3. <Verification or expected result>
+
+## Details
+
+| Topic | Decision |
+|-------|----------|
+| <area> | <concise explanation> |
+
+## Checklist
+
+- [ ] <Reader can confirm this>
+- [ ] <Reader can confirm that>
+
+## Next step
+
+<Link or action that continues the workflow.>
+```
+
+## PR and Review Docs
+
+When documenting a PR, reduce reviewer burnout by making the review path explicit:
+
+- State what to review first.
+- State what is intentionally out of scope.
+- Link the previous and next PR when work is chained.
+- Keep each section focused on one decision or unit of work.
+- Use checklists for acceptance criteria and verification.
+
+## Commands
+
+```bash
+# Check markdown files changed in the current branch
+git diff --name-only -- '*.md'
+
+# Inspect PR changed-line count for cognitive load
+gh pr view <PR_NUMBER> --json additions,deletions,changedFiles
+```

package/skills/comment-writer/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: comment-writer
+description: "Write warm, direct collaboration comments. Trigger: PR feedback, issue replies, reviews, Slack messages, or GitHub comments."
+license: Apache-2.0
+metadata:
+  author: gentleman-programming
+  version: "1.0"
+---
+
+## When to Use
+
+Load this skill whenever you write a comment that another human will read.
+
+Use it for:
+
+- GitHub PR or issue comments.
+- Review feedback and requested changes.
+- Maintainer replies.
+- Slack, Discord, or async project updates.
+
+## Voice Rules
+
+| Rule | Requirement |
+|------|-------------|
+| Be useful fast | Start with the actionable point. Do not recap the whole PR before feedback. |
+| Be warm and direct | Sound like a thoughtful teammate, not a corporate bot. |
+| Keep it short | Prefer 1 to 3 short paragraphs or a tight bullet list. |
+| Explain why | Give the technical reason when asking for a change. |
+| Avoid pile-ons | Comment on the highest-value issue, not every tiny preference. |
+| Match thread language | Write in the thread/user language. If writing in Spanish, use Rioplatense Spanish/voseo: `podés`, `tenés`, `fijate`, `dale`. |
+| No em dashes | Use commas, periods, or parentheses instead. |
+
+## Comment Formula
+
+```text
+<Direct observation or request>
+
+<Why it matters, only if needed>
+
+<Concrete next action>
+```
+
+## Examples
+
+### Request change
+
+```markdown
+Buenísimo el enfoque. Acá separaría este cambio en otro commit porque mezcla la validación con el wiring de UI.
+
+Eso le baja carga al reviewer y hace que el rollback sea más claro si falla la integración.
+```
+
+### Approve with a note
+
+```markdown
+Está bien encaminado y el scope se entiende rápido.
+
+Dejo aprobado. Para el próximo PR, agregá el link al anterior y al siguiente así la cadena queda navegable.
+```
+
+### Ask for split
+
+```markdown
+Este PR supera el presupuesto de 400 líneas cambiadas, así que necesitamos dividirlo o justificar `size:exception`.
+
+Mi sugerencia: primero foundation + tests, después integración, después docs. Así cada review tiene inicio y fin claros.
+```
+
+## Commands
+
+```bash
+# Inspect a PR before writing review feedback
+gh pr view <PR_NUMBER> --json title,body,additions,deletions,changedFiles
+```

package/skills/gentle-ai/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: gentle-ai
+description: Use Gentle AI harness discipline for Pi work: clarify first, preserve OpenSpec artifacts, use strict TDD where available, delegate through subagents when useful, and protect review workload.
+---
+
+# Gentle AI Harness
+
+Use this skill when work is non-trivial, risky, multi-step, or likely to benefit from SDD/OpenSpec artifacts.
+
+## Compact Rules
+
+- Clarify scope, constraints, acceptance criteria, and non-goals before implementation.
+- Use OpenSpec-style artifacts for proposal, specs, design, tasks, apply progress, verify report, and archive notes.
+- If tests exist, follow strict TDD: RED, GREEN, TRIANGULATE, REFACTOR, and record evidence.
+- Keep one parent session responsible for orchestration; child subagents should receive concrete phase work and must not spawn more subagents.
+- Prefer fresh-context reviewers for adversarial review and forked workers only after direction is approved.
+- Keep writes single-threaded unless the user explicitly approves isolated parallel worktrees.
+- Forecast review workload before large changes; ask before producing oversized or multi-area diffs.
+- Never claim persistent memory is available because of Gentle AI itself; memory is provided by separate packages/tools.
+
+## Work Routing
+
+Use the smallest safe harness:
+
+```text
+small + known context      → inline direct
+unknown / context-heavy    → simple delegation
+large / ambiguous / risky  → SDD
+```
+
+For substantial changes:
+
+```text
+clarify → explore → proposal → spec → design → tasks → apply → verify → archive
+```
+
+For bounded implementation with subagents:
+
+```text
+clarify → planner/worker → fresh reviewers → worker fixes → verify
+```
+
+The package auto-installs SDD agents and chains into the project when a Pi session starts. Use `/gentle-ai:install-sdd --force` only for recovery or intentional overwrite.

package/skills/issue-creation/SKILL.md

@@ -0,0 +1,223 @@
+---
+name: issue-creation
+description: "Create Gentle AI issues with issue-first checks. Trigger: creating GitHub issues, bug reports, or feature requests."
+license: Apache-2.0
+metadata:
+  author: gentleman-programming
+  version: "1.0"
+---
+
+## When to Use
+
+Use this skill when:
+- Creating a GitHub issue (bug report or feature request)
+- Helping a contributor file an issue
+- Triaging or approving issues as a maintainer
+
+---
+
+## Critical Rules
+
+1. **Blank issues are disabled** — MUST use a template (bug report or feature request)
+2. **Every issue gets `status:needs-review` automatically** on creation
+3. **A maintainer MUST add `status:approved`** before any PR can be opened
+4. **Questions go to [Discussions](https://github.com/Gentleman-Programming/agent-teams-lite/discussions)**, not issues
+
+---
+
+## Workflow
+
+```
+1. Search existing issues for duplicates
+2. Choose the correct template (Bug Report or Feature Request)
+3. Fill in ALL required fields
+4. Check pre-flight checkboxes
+5. Submit → issue gets status:needs-review automatically
+6. Wait for maintainer to add status:approved
+7. Only then open a PR linking this issue
+```
+
+---
+
+## Issue Templates
+
+### Bug Report
+
+Template: `.github/ISSUE_TEMPLATE/bug_report.yml`
+Auto-labels: `bug`, `status:needs-review`
+
+#### Required Fields
+
+| Field | Description |
+|-------|-------------|
+| **Pre-flight Checks** | Checkboxes: no duplicate + understands approval workflow |
+| **Bug Description** | Clear description of the bug |
+| **Steps to Reproduce** | Numbered steps to reproduce |
+| **Expected Behavior** | What should have happened |
+| **Actual Behavior** | What happened instead (include errors/logs) |
+| **Operating System** | Dropdown: macOS, Linux variants, Windows, WSL |
+| **Agent / Client** | Dropdown: Claude Code, OpenCode, Gemini CLI, Cursor, Windsurf, Codex, Other |
+| **Shell** | Dropdown: bash, zsh, fish, Other |
+
+#### Optional Fields
+
+| Field | Description |
+|-------|-------------|
+| **Relevant Logs** | Log output (auto-formatted as code block) |
+| **Additional Context** | Screenshots, workarounds, extra info |
+
+#### Example — Bug Report via CLI
+
+```bash
+gh issue create --template "bug_report.yml" \
+  --title "fix(scripts): setup.sh fails on zsh with glob error" \
+  --body "
+### Pre-flight Checks
+- [x] I have searched existing issues and this is not a duplicate
+- [x] I understand this issue needs status:approved before a PR can be opened
+
+### Bug Description
+Running setup.sh on zsh throws a glob error when no matching files exist.
+
+### Steps to Reproduce
+1. Clone the repo
+2. Run \`./scripts/setup.sh\` in zsh
+3. See error: \`zsh: no matches found: skills/*\`
+
+### Expected Behavior
+The script should handle missing glob matches gracefully.
+
+### Actual Behavior
+Script crashes with glob error.
+
+### Operating System
+macOS
+
+### Agent / Client
+Claude Code
+
+### Shell
+zsh
+
+### Relevant Logs
+\`\`\`
+zsh: no matches found: skills/*
+\`\`\`
+"
+```
+
+---
+
+### Feature Request
+
+Template: `.github/ISSUE_TEMPLATE/feature_request.yml`
+Auto-labels: `enhancement`, `status:needs-review`
+
+#### Required Fields
+
+| Field | Description |
+|-------|-------------|
+| **Pre-flight Checks** | Checkboxes: no duplicate + understands approval workflow |
+| **Problem Description** | The pain point this feature solves |
+| **Proposed Solution** | How it should work from the user's perspective |
+| **Affected Area** | Dropdown: Scripts, Skills, Examples, Documentation, CI/Workflows, Other |
+
+#### Optional Fields
+
+| Field | Description |
+|-------|-------------|
+| **Alternatives Considered** | Other approaches or workarounds |
+| **Additional Context** | Mockups, examples, references |
+
+#### Example — Feature Request via CLI
+
+```bash
+gh issue create --template "feature_request.yml" \
+  --title "feat(scripts): add Codex support to setup.sh" \
+  --body "
+### Pre-flight Checks
+- [x] I have searched existing issues and this is not a duplicate
+- [x] I understand this issue needs status:approved before a PR can be opened
+
+### Problem Description
+The setup script only configures Claude Code, Gemini CLI, and OpenCode. Codex users have to manually copy skills.
+
+### Proposed Solution
+Add a Codex option to setup.sh that links skills to the .codex/ directory.
+
+Example:
+\`\`\`bash
+./scripts/setup.sh --agent codex
+\`\`\`
+
+### Affected Area
+Scripts (setup, installation)
+
+### Alternatives Considered
+Manually symlinking, but that defeats the purpose of the setup script.
+"
+```
+
+---
+
+## Label System
+
+### Applied Automatically on Issue Creation
+
+| Template | Labels added |
+|----------|-------------|
+| Bug Report | `bug`, `status:needs-review` |
+| Feature Request | `enhancement`, `status:needs-review` |
+
+### Applied by Maintainers
+
+| Label | When to apply |
+|-------|--------------|
+| `status:approved` | Issue accepted for implementation — PRs can now be opened |
+| `priority:high` | Critical bug or urgent feature |
+| `priority:medium` | Important but not blocking |
+| `priority:low` | Nice to have |
+
+---
+
+## Maintainer Approval Workflow
+
+```
+1. New issue arrives with status:needs-review
+2. Review the issue — is it valid, clear, and in scope?
+3. If YES → add status:approved label
+4. If NO → comment with reason, close if needed
+5. Contributor can now open a PR linking this issue
+```
+
+---
+
+## Decision Tree
+
+```
+Is it a bug?                    → Use Bug Report template
+Is it a new feature/improvement? → Use Feature Request template
+Is it a question?               → Use Discussions, NOT issues
+Is it a duplicate?              → Link to existing issue, close
+```
+
+---
+
+## Commands
+
+```bash
+# Search existing issues before creating
+gh issue list --search "keyword"
+
+# Create bug report
+gh issue create --template "bug_report.yml" --title "fix(scope): description"
+
+# Create feature request
+gh issue create --template "feature_request.yml" --title "feat(scope): description"
+
+# Maintainer: approve an issue
+gh issue edit <number> --add-label "status:approved"
+
+# Maintainer: add priority
+gh issue edit <number> --add-label "priority:high"
+```

package/skills/judgment-day/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: judgment-day
+description: "Trigger: judgment day, dual review, adversarial review, juzgar. Run blind dual review, fix confirmed issues, then re-judge."
+license: Apache-2.0
+metadata:
+  author: gentleman-programming
+  version: "1.4"
+---
+
+## Activation Contract
+
+Load this skill only when the user explicitly asks for Judgment Day, dual/adversarial review, or equivalent Spanish trigger (`juzgar`, `que lo juzguen`). Review a specific target: files, feature, PR, or architecture slice.
+
+## Hard Rules
+
+- Resolve project skills before launching agents: read skill registry, match compact rules by target files/task, and inject the same `Project Standards` block into both judge prompts and fix prompts.
+- Launch **two blind judges in parallel** with identical target and criteria; never review the code yourself.
+- Wait for both judges before synthesis; never accept a partial verdict.
+- Classify warnings as `WARNING (real)` only if normal intended use can trigger them; otherwise downgrade to INFO as `WARNING (theoretical)`.
+- Ask before fixing Round 1 confirmed issues.
+- After any fix agent runs, immediately re-launch both judges in parallel before commit/push/done/session summary.
+- Terminal states are only `JUDGMENT: APPROVED` or `JUDGMENT: ESCALATED`.
+- After 2 fix iterations with remaining issues, ask the user whether to continue.
+
+## Decision Gates
+
+| Condition | Action |
+|---|---|
+| Target unclear | Ask for scope; do not launch judges. |
+| No skill registry | Warn, proceed with generic criteria, and record `Skill Resolution: none`. |
+| Both judges find same CRITICAL/real WARNING | Confirmed; ask/fix according to round rules. |
+| One judge finds issue | Suspect; report and triage, do not auto-fix. |
+| Judges contradict | Escalate for manual decision. |
+| Round 2+ has only theoretical warnings/suggestions | Report as INFO; do not re-judge. |
+
+## Execution Steps
+
+1. Confirm target and optional custom criteria.
+2. Resolve compact project standards from registry or warn if missing.
+3. Start Judge A and Judge B concurrently via delegation.
+4. Synthesize findings into confirmed, suspect, contradiction, and INFO buckets.
+5. Ask before Round 1 fixes; delegate a separate fix agent for confirmed approved fixes only.
+6. Re-judge in parallel after fixes; repeat until approved, escalated, or user asks to stop.
+7. Before any terminal action, verify every active Judgment Day has a terminal state.
+
+## Output Contract
+
+Return `## Judgment Day — {target}` with round number, verdict table, confirmed/suspect/contradiction counts, fixes applied, re-judgment result, `Skill Resolution`, and final `JUDGMENT: APPROVED ✅` or `JUDGMENT: ESCALATED ⚠️`.
+
+## References
+
+- [references/prompts-and-formats.md](references/prompts-and-formats.md) — judge/fix prompts, warning rubric, verdict tables, and language snippets.

package/skills/judgment-day/references/prompts-and-formats.md

@@ -0,0 +1,75 @@
+# Judgment Day Prompts and Formats
+
+## Judge Prompt
+
+```markdown
+You are an adversarial code reviewer. Your ONLY job is to find problems.
+
+## Target
+{files, feature, architecture, component}
+
+## Project Standards (auto-resolved)
+{matching compact rules, if available}
+
+## Review Criteria
+- Correctness: logical errors and behavior mismatches
+- Edge cases: missing states, inputs, or platform constraints
+- Error handling: propagation, logging, recovery
+- Performance: N+1, wasteful loops, excessive allocations
+- Security: injection, secrets, auth boundaries
+- Naming/conventions: project standards and local patterns
+{custom criteria, if provided}
+
+## Return Format
+Findings only. No praise.
+
+Each finding:
+- Severity: CRITICAL | WARNING (real) | WARNING (theoretical) | SUGGESTION
+- File: path/to/file.ext (line N if applicable)
+- Description: what is wrong and why it matters
+- Suggested fix: one-line intent
+
+WARNING rule: normal intended use can trigger it → `WARNING (real)`; contrived/malicious/impossible path → `WARNING (theoretical)`.
+
+If clean: `VERDICT: CLEAN — No issues found.`
+
+Always end with: `Skill Resolution: {injected|fallback-registry|fallback-path|none} — {details}`.
+```
+
+## Fix Agent Prompt
+
+```markdown
+You are a surgical fix agent. Apply ONLY the confirmed issues listed below.
+
+## Confirmed Issues to Fix
+{confirmed findings table}
+
+## Project Standards (auto-resolved)
+{matching compact rules, if available}
+
+## Instructions
+- Fix only confirmed issues.
+- Do not refactor beyond the required fix.
+- Do not change unflagged code.
+- If fixing a repeated pattern in touched files, fix all occurrences of that same pattern.
+- Return changed file, line, and fix summary.
+
+End with: `Skill Resolution: {injected|fallback-registry|fallback-path|none} — {details}`.
+```
+
+## Verdict Table
+
+```markdown
+| Finding | Judge A | Judge B | Severity | Status |
+|---------|---------|---------|----------|--------|
+| Missing null check in auth.go:42 | ✅ | ✅ | CRITICAL | Confirmed |
+| Windows volume root edge case | ❌ | ✅ | WARNING (theoretical) | INFO |
+| Naming mismatch | ✅ | ❌ | SUGGESTION | Suspect |
+```
+
+Approved criteria after Round 1: zero confirmed CRITICALs and zero confirmed real WARNINGs. Theoretical warnings and suggestions may remain.
+
+## Language Snippets
+
+- Spanish: “Juicio iniciado”, “Los jueces trabajan en paralelo”, “Los jueces coinciden”, “Juicio terminado — Aprobado”, “Escalado — necesita revisión humana”.
+- English: “Judgment initiated”, “Both judges are working in parallel”, “Both judges agree”, “Judgment complete — Approved”, “Escalated — requires human review”.