# Delivery Specialist Review Gate

Use this shared gate from end-to-end delivery workflows before final PR or MR
merge. The gate gives provider delivery skills one consistent review contract
without making low-level close skills mandatory review orchestrators.

## Ownership

- `deliver-github-pr` and `deliver-gitlab-mr` own this mandatory gate for
  end-to-end delivery.
- `close-github-pr` and `close-gitlab-mr` keep their optional user-requested
  review gate for direct close or merge requests.
- `deliver-tracking-issue` relies on this delivery gate for each PR, then adds
  issue-visible evidence, runtime-finding disposition, lifecycle completion, and
  closeout requirements.
- `code-review-specialists` remains read-only. It supplies scope detection,
  specialist findings, and reports; it does not fix code, post PR or MR
  comments, mark draft reviewables ready, merge, close issues, or clean branches.

## Mandatory Gate

For every end-to-end delivery PR or MR:

1. Resolve reviewable metadata and diff base:
   - GitHub PR: use `gh pr view <pr> --json number,url,baseRefName,headRefName,isDraft,state,statusCheckRollup,closingIssuesReferences`.
   - GitLab MR: use `glab mr view <iid>` and resolve the target branch.
   - Use the PR base branch or MR target branch as the `code-review-specialists`
     diff base.
2. Run deterministic scope detection with forced minimum lenses:

   ```bash
   $AGENT_HOME/skills/workflows/code-review/code-review-specialists/scripts/review_specialists.py \
     scope --base <base-ref> --testing --maintainability
   ```

3. Run the selected specialist lenses. The forced minimum means a small diff is
   still reviewed; do not skip only because `diff_lines < 50`.
4. Add risk lenses when the scope warrants them:
   - `--security` for auth, permission, secrets, dependency, supply-chain, or
     backend changes over 100 diff lines.
   - `--api-contract` for route, controller, API schema, OpenAPI, GraphQL,
     event, protocol, CLI, or other external contract changes.
   - `--data-migration` for schema, migration, data transform, fixture
     migration, or persistence changes.
   - `--performance` for runtime hot paths, build/runtime loops, query behavior,
     concurrency, rendering, or deployment-time execution.
   - `--red-team` when `diff_lines > 200`, a previous specialist pass found a
     critical issue, or the reviewable changes safety/security-sensitive
     behavior.
5. For doc-only, generated-only, formatting-only, or mechanical metadata
   reviewables, the review may be a short testing/maintainability pass that
   records "no concrete findings" plus why broader lenses were not selected.

## Findings And Repair Loop

- Treat evidence-backed concrete findings as blocking before merge.
- Repair concrete findings on the same delivery branch when they are inside the
  accepted delivery scope.
- After repairs, rerun focused validation, provider checks or pipelines, and the
  affected specialist lenses.
- Repeat review and repair until no concrete unresolved findings remain, or
  stop with an exact blocker and unblock action.
- Do not treat user-authorized review fixes as a successful stopping point; they
  are part of the delivery repair loop.
- Weakly evidenced concerns, accepted tradeoffs, cleanup notes, and residual
  risks must be reported by the owning delivery workflow. Issue-backed delivery
  must also record their issue-visible disposition before closeout.
- The owning delivery workflow must post the final or blocked outcome using
  `skills/workflows/_shared/references/DELIVERY_REVIEW_OUTCOME_COMMENT.md`
  before final merge/close.
