> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pandorian.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Integrations

> Learn how to integrate Pandorian with your development workflow

Pandorian integrates into your existing SDLC to enforce guidelines continuously and automatically. This guide covers PR scanning, CI/CD integration, repository policy, and notifications.

## Source Control & Pull Request Scanning

The fastest way to enforce guidelines is through automatic PR scanning via your source control integration. Pandorian supports **GitHub**, **GitLab**, and **Azure DevOps**.

### How PR Scanning Works

Once you connect your source control manager during initial setup, PR scanning is automatically triggered on every new PR or push to an existing PR.

**What happens during a PR scan:**

1. Developer opens or updates a pull request.
2. Pandorian scans only the modified files against guidelines.
3. Violations appear as inline comments on specific lines and as a summary comment on the PR (if opted in)
4. The PR check appears in your source control's status checks (configurable as required or optional)

### PR Actions

**Rescan:** Re-trigger a scan for an existing PR with the current set of active guidelines applied to it. Useful after updating guidelines or resolving earlier violations.

**Archive:** Archive individual findings that are no longer relevant — archived violations are excluded from future Jira ticket creation and reporting views.

**Skip CI Check:** Manually skip the CI check for a specific PR. The scan will still run, but results will not block the PR build associated with it.

***

### Blocking vs. Monitoring Mode

**Blocking Mode** (recommended for production): Pipeline fails if violations are found, preventing non-compliant code from being deployed. Set exit code 1 when violations > 0.

**Monitoring Mode** (useful for gradual rollout): Pipeline continues regardless of violations. Scan results are logged for visibility. Set exit code 0 and log violations without blocking.

***

## Guidelines as Code

High-velocity teams can manage guidelines directly within their code repositories, treating engineering standards as living documentation that evolves alongside the codebase.

If your team already uses internal markdown files or AI coding assistant skills, you can sync those same files to Pandorian — ensuring the rules your AI uses to write code are the exact same rules Pandorian uses to validate it.

### How It Works

1. Designate a repository and base directory (e.g., `/docs/guidelines`) in the **Integrations** tab
2. Pandorian monitors that directory for `.md` files
3. Any merge to the main branch triggers an update — guidelines are immediately enforced across all associated repositories

### File Structure & Metadata

Each Markdown file must contain a YAML frontmatter block with a `pandorian-metadata` section:

| Attribute      | Type    | Description                                               |
| -------------- | ------- | --------------------------------------------------------- |
| `id`           | string  | Unique identifier (e.g., `scala-expert`)                  |
| `language_ids` | string  | Target languages (e.g., `scala`, `python`)                |
| `title`        | string  | Clear, actionable rule name                               |
| `block`        | boolean | `true` to block on violation; `false` defaults to monitor |
| `category`     | string  | Area of focus (e.g., `security`, `performance`)           |
| `is_active`    | boolean | Whether this guideline is currently enforced              |
| `tags`         | list    | Strings for filtering and organization                    |

### Supported Categories

Architecture, Code Quality & Maintainability, Reliability & Resilience, Performance & Scalability, Security, Data & Storage, Infrastructure & Environments, Observability

### Supported Languages

c, cobol, cpp, csharp, dockerfile, elixir, go, haskell, java, javascript, kotlin, lua, perl, php, python, ruby, rust, scala, swift, terraform, typescript

### Implementation Example

Create a file named `scala-expert.md` in your guidelines directory:

```yaml theme={null}
---
pandorian-metadata:
  id: scala-expert
  language_ids: [scala]
  title: Scala Functional Programming Expert
  block: true
  category: Architecture
  is_active: true
  tags: [scala, functional-programming, cats, fs2]
---

# Scala Functional Programming Standards

You are an elite Scala developer. When writing or reviewing code, ensure:
- **Immutability First**: Always use `val` over `var` and prefer immutable collections.
- **Referential Transparency**: Effects must be properly tracked in the type system using `IO`.
- **Resource Management**: Use `Resource` for anything requiring cleanup.

### Prohibited Patterns
- Never use `null`. Use `Option` instead.
- Avoid `Thread.sleep`; use `IO.sleep` for non-blocking delays.
```

### Configuration Steps

1. Navigate to **Integrations → Connections → Source Control** in the Pandorian platform
2. Select the repository containing your `.md` files
3. Provide the top-level directory path (e.g., `/docs/guidelines`)
4. Save to trigger an initial import

***

## Policy as Code

Policy as Code lets you configure repository-level settings as code, so Pandorian knows which guidelines to run and when to block pull requests — without managing these rules outside your codebase.

The policy is defined in a `.Pandorian/.policy` file inside the repo and is applied on every full and PR scan.

### Repository Policy Schema

```yaml theme={null}
# Guidelines to apply — only guidelines tagged with the specified tag will run
repository_guidelines_tags:
  - guideline_tag: string

# Exclusions — skip files or directories from analysis using glob patterns
# Useful for vendor code, generated files, or any paths that shouldn't be scanned
exclusions:
  - type: glob
    value: string
    case_sensitive: bool

# Inclusions — apply a specific guideline only to a specific path inside the repository
# Uses glob patterns to scope guideline enforcement to relevant directories or file types
inclusions:
  - guideline_tag: string
    path_pattern:
      - type: glob
        value: string
        case_sensitive: bool
```

### Comprehensive Configuration Example

```yaml theme={null}
# Guidelines Configuration
repository_guidelines_tags:
  - guideline_tag: v2

# Exclusion Rules
exclusions:
  # Exclude vendor directories
  - type: glob
    value: "vendor/**"
    case_sensitive: true

  # Exclude generated protobuf files
  - type: glob
    value: "**/*.pb.go"
    case_sensitive: true

  # Exclude test files
  - type: glob
    value: "**/*_test.go"
    case_sensitive: true

  # Exclude node_modules
  - type: glob
    value: "node_modules/**"
    case_sensitive: true

# Inclusion Rules
inclusions:
  # Apply security guidelines only to the auth service path
  - guideline_tag: security
    path_pattern:
      - type: glob
        value: "src/auth/**"
        case_sensitive: true

  # Apply data guidelines only to migration files
  - guideline_tag: data-storage
    path_pattern:
      - type: glob
        value: "db/migrations/**"
        case_sensitive: true
```

***

## Scan Policies

Scan Policies let you define exactly where and how guidelines run — which paths to ignore, and which guideline groups to scope to specific files or directories. Repo-level overrides take precedence over org-level defaults.

Navigate to **Scan Policies** in the Pandorian dashboard to configure.

### Organization Policy

Organization-level policy applies across all repositories by default.

**Ignored Paths:** Paths that should never be scanned, applied to all guidelines. Use this to exclude vendor code, generated files, test fixtures, or any directory that shouldn't be subject to enforcement. Click **Ignore a path** to add an exclusion.

**Guideline Scoping:** Restrict a guideline group to specific paths only. Rather than running all guidelines across the entire codebase, scoping rules let you target enforcement by tag — for example, applying security guidelines only to the auth service, or data guidelines only to migration files. Click **Add scoping rule** to configure.

### Repository Overrides

Repository overrides let you customize scan policy for a specific repository, overriding the organization defaults. This is useful when a particular repo has different conventions, third-party code that should be excluded, or guidelines that only apply in that context. Click **Add repository override** to configure.

### Examples

**Ignoring test files across all repositories:**
Test files shouldn't be subject to the same enforcement as production code. Add your test file glob patterns as ignored paths — Pandorian will skip those files across all guidelines without any per-guideline configuration.

**Scoping compliance guidelines to sensitive services:**
Your organization has a set of guidelines tagged `pci-compliance`. Rather than running them across every repository, create a scoping rule that restricts them to repos or paths containing payment processing code. Every other repo is unaffected.

**Scoping security guidelines to the auth layer:**
Security guidelines tagged `auth` should only apply to the `/src/auth` directory. Set a scoping rule so those guidelines run exclusively on that path — reducing noise in unrelated parts of the codebase while enforcing strictly where it matters.

**Overriding org defaults for a legacy repository:**
Your org-wide policy excludes test files from scanning. A legacy repo requires the opposite — tests are the only place certain patterns are enforced. Add a repository override to configure a different ignored paths policy for that repo without affecting the rest of the organization.

***

## Dynamic Context Providers

Dynamic Context Providers connect external data sources directly to your guidelines, ensuring they evaluate code against real-time context — approved libraries, internal API routes, active feature flags — rather than static hardcoded lists.

### Configuring a Provider

When creating or editing a guideline, add a provider with:

* **Title:** Descriptive name (e.g., "Approved Config Flags")
* **Command:** The exact command Pandorian executes to fetch data (e.g., a `curl` to your internal API)
* **Grep:** Optional regex to filter the command output to only the relevant data
* **Timeout:** Maximum seconds to wait for the external source before timing out

***

## Slack Integration

### Setting Up Slack Notifications

1. Navigate to **Settings → Integrations**
2. Click **Connect Slack**
3. Authorize Pandorian to access your Slack workspace
4. Choose the notification channel
5. Configure alerts for scan completed or scan failed events

Each alert includes a direct link to the scan results in the Pandorian dashboard.

***

## Jira Integration

Connect Pandorian to Jira to create issues directly from scan results, turning violations into actionable tickets without leaving the dashboard.

### Setting Up Jira

1. Navigate to **Integrations → Jira** in the Pandorian dashboard
2. Click **Connect** and sign in via Atlassian
3. Once authorized, the integration status shows **Configured**
4. Under **Configuration**, select your default Jira board and click **Save**

### Creating a Jira Issue from a Guideline

From the **Guidelines** page, click the **Violations** badge on any guideline. Click **Create Issue** — Pandorian generates a ticket draft containing all current open violations for that guideline in bulk.

The **Create Jira Issue** form is pre-populated with:

| Field           | Details                                                                                      |
| --------------- | -------------------------------------------------------------------------------------------- |
| **Summary**     | Pre-filled; editable                                                                         |
| **Description** | Auto-generated from guideline details, violation count, category, and repo context; editable |
| **Issue Type**  | Defaults to Task; editable                                                                   |
| **Priority**    | Optional; editable                                                                           |
| **Assignee**    | Optional; editable                                                                           |
| **Labels**      | Optional; comma-separated                                                                    |

A **Ticket Preview** panel shows the rendered output before submission.

> **Tip:** Archive irrelevant violations before creating a ticket — archived violations are excluded from the generated issue.

### Ticket History & Lifecycle

A **Tickets** page in Pandorian shows all issues opened, so you can track escalations without leaving the dashboard. Pandorian does not automatically close, update, or comment on tickets — lifecycle is managed within Jira.