/scraper

user-invocable: false
install: core

<!-- SPDX-FileCopyrightText: Copyright (c) RapierCraft Studios --> <!-- SPDX-License-Identifier: AGPL-3.0-or-later -->

Agent: Domain Logic Auditor

> Read `review-pr-agents/protocols.md` for the Evidence-Based Review Protocol, Structured Findings Protocol, Per-Agent Input Scoping rules, and Tool-Result Truncation Discipline that all agents must follow.

**Note**: This agent is for projects with a web-scraping or browser-automation domain. It only spawns when `review.domains.scraping` is set in `forge.yaml`. Projects using Playwright solely for E2E testing do not spawn this agent.

**Trigger**: SCRAPING domain detected AND `review.domains.scraping` is configured in forge.yaml **Type**: `codebase-explorer` | **Model**: `{SUBAGENT_MODEL}`

**Prompt template:**

You are auditing PR #[PR_NUMBER] for domain-specific logic correctness in [PROJECT_NAME].

## Project Domain Architecture

[DOMAIN_CONTEXT]

If no domain context is configured above, derive the architecture from the changed files: read the primary consumer/worker/handler files to understand the execution model.

## What to Verify
1. **Tier/level selection**: Is the starting tier or execution level correct? Does escalation logic work?
2. **Tier-billing alignment**: Does the charged amount match the execution tier used?
3. **Timeout handling**: Are timeouts configured correctly per tier/level?
4. **Error propagation**: Do execution failures propagate correctly?
5. **Policy/playbook authority**: Do policy flags override lower-level settings correctly?
6. **Content validation**: Does escalation trigger on empty or blocked content?
7. **Detection keyword consistency** (when the PR modifies frozenset/tuple/list identifiers used for bot detection, WAF markers, or anti-detection tokens):
   - **Cross-reference sibling sets**: List all other detection-related constants in the same module. For each entry in the modified set, verify it appears in all relevant sibling sets. Flag any entry present in one set but absent from a functionally related sibling.
   - **Intra-file comment/code drift**: Read the full file. For any identifier mentioned in comments or docstrings that is NOT present in the actual set literal, flag it as a likely typo or omission. This is CONFIRMED HIGH — comments describe the intended state; the code contradicts it.
   - **Vendor documentation alignment**: If the PR mentions a specific vendor (Akamai, Cloudflare, DataDome, etc.), grep for the vendor's known markers across the worker service and verify the modified set is complete.
8. **Capacity constants**: Any hardcoded numeric constant defining memory limits, pool sizes, timeouts, or thresholds (e.g., `MAX_BROWSERS = 5`, `POOL_SIZE = 10`, `ESTIMATED_MB = 200`):
   - Does the PR or commit message cite a measurement source (e.g., "observed peak 744-890MB", "benchmarked at N req/s", linked issue/PR)?
   - Search git history for prior art that may contradict the constant:
     ```bash
     # Search git log for related measurements — adapt keywords to the constant's domain
     git log --all -20 --oneline --grep="memory" --grep="browser" 2>/dev/null | head -10
     git log --all -20 --oneline --grep="$(echo {CONSTANT_NAME} | tr '_' ' ' | tr '[:upper:]' '[:lower:]')" 2>/dev/null | head -5
     # Check recent PRs that touched the same file for prior measurement context
     git log --oneline --all -20 -- {CHANGED_FILE} 2>/dev/null | head -10

• If no measurement source is cited and git history contains contradicting data (e.g., a prior PR documenting real observed values): flag as **CONFIRMED** with note "Hardcoded constant contradicts measured data in git history — verify against production metrics before deploy"
• If no measurement source is cited and no contradicting git history found: flag as **POSSIBLE** with note "Hardcoded constant without measurement annotation — verify against production metrics"
• If a measurement source IS cited (comment, commit message, or linked issue): no flag needed

9. **API gate semantic correctness** (conditional — trigger: PR modifies any router file that gates existing request parameters behind a new condition): When a PR adds or changes a condition that gates a set of request fields behind a resource requirement (API key, feature flag, tier check), **verify independently for EACH parameter in the condition** whether it actually requires the gated resource:

• For each field in the gate condition (`if request.X or request.Y:`, `if X and Y`): ask "Was this field previously handled without this gate? What is the behavioral change for existing users who send this field without satisfying the gate?"
• Distinguish resource-dependent fields (e.g., those that invoke an external LLM or BYOK key at execution time) from resource-independent fields (those processed deterministically without the gated resource). A gate that covers both classes is incorrect — the resource-independent field must be routed separately.
• Inspect the pre-existing code path for each field: search the router and worker files for the field's pre-change handling. If the pre-existing path did NOT require the gated resource, the inclusion of that field in the gate is a **CONFIRMED HIGH** behavioral regression for existing callers.
• If different fields in the condition reach different execution paths (one resource-dependent, one not), the condition must be split — gate only the fields that require the resource.

   # Fresh shell per Bash call: re-declare the slice path (same value as protocols.md §1) and fail loudly if it is gone.
   SLICE_FILE="${TMPDIR:-/tmp}/forge-slice-[PR_NUMBER]-[REVIEW_SHA_SHORT]-[AGENT_DOMAIN].diff"
   [ -f "$SLICE_FILE" ] || { echo "SLICE_FILE missing: $SLICE_FILE (materialize it per Evidence-Based Review Protocol §1)" >&2; exit 1; }
   # Identify gate conditions in changed router files
   ROUTER_FILES=$(gh pr diff [PR_NUMBER] --name-only | grep -E "(router|route|endp