> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/inspect/overview.md).

# Inspect

Inspect is codev's quality gate — it validates your changes before they reach production. Every pull request can be automatically analyzed for code issues and validated by deploying to a real Salesforce org, so problems are caught early, not after merge.

Inspect has four capabilities:

* **Change Analysis** — automated code review that checks every PR for duplicates, compliance violations, code quality issues, and architectural concerns
* **Change Validation** — deploys your changed packages to a real Salesforce org and runs Apex tests, so you know the deployment will work before you merge
* **Scheduled Runs** — recurring Apex test runs and code analysis across your environments, so you can track test health and code quality over time
* **Review Environments** — automatic assignment of pool environments to pull requests, so every PR gets its own org for validation

All four run automatically when enabled. codev's workflow engine triggers analysis and validation on every PR event, runs scheduled jobs on a recurring cadence, and manages review environment assignment — no external CI/CD configuration needed.

## How the pieces fit together

When a contributor loper opens or updates a pull request:

1. **Change Analysis** runs first — it examines the PR diff and checks for duplicates, compliance rules, code analyzer issues, and architectural concerns. Results appear as linter badges on the PR row and as detailed reports when you drill in.
2. **Change Validation** runs in parallel — it detects which domains are impacted by the PR, allocates a review environment from the appropriate pool, deploys the changed packages, and runs Apex tests. Results show deployment success/failure, test pass rates, and coverage.

Both produce check runs on your PR in GitHub, so the team can see results without leaving their normal workflow.

**Scheduled Runs** operate independently — they run Apex tests and code analysis on a recurring schedule across your environments, giving you a continuous view of test health and code quality trends.

**Review Environments** tie it all together by ensuring validation always has an org to deploy to. Assignment rules map branch patterns and domains to specific pools, so the right type of environment is used for each validation.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.flxbl.io/flxbl/codev/inspect/overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.