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

# Keep integrations verified in CI

> Make the same Vise contract and evidence that guided implementation protect current and previously completed social.plus features in CI.

After the first integration is green, keep it verifiable after the coding-agent conversation ends. Commit the `sp-vise/` folder with the application, then run Vise as a read-only CI gate.

## What the CI gate protects

The gate checks more than the feature currently being edited:

* the active integration still matches its recorded scope
* deterministic SDK and platform requirements still pass
* required evidence and project sensors are present and current, including any retained runtime receipt
* accepted organization policy remains current, authentic, and inside its lifecycle and trust boundaries
* every previously completed Vise feature still holds against the current code

This matters when a later change passes for one surface but quietly breaks an earlier feed, comments, community, or chat experience.

## Add the gate

Install the same Vise version your team uses for local work, then run:

```sh theme={null}
vise check . --ci
```

Keep the command read-only in CI. Changes to contracts, attestations, baselines, runtime waivers, or policy selections should be deliberate reviewable changes made before the pipeline runs.

For a more diagnostic pipeline, verify retained runtime evidence or the repository policy source in separate read-only steps before the composed gate:

```sh theme={null}
vise smoke verify . \
  --evidence sp-vise/evidence/runtime-smoke/<surface>.json
vise policy status . --ci
vise check . --ci
```

## Read the outcome

* **Green:** the active work and all recorded completed features still hold.
* **Active failure:** the current integration, required evidence, or project validation needs attention.
* **Earlier-feature drift:** the active work passes, but a previously completed surface no longer does.
* **Release review required:** when Passport comparison is enabled, the compliance checks pass but a person still needs to review the candidate's release evidence.
* **Policy review required or blocked:** the accepted policy source changed or crossed a lifecycle, signing-key, or rotation boundary; Vise returns the exact owner instead of accepting a successor automatically.

Link the CI output to the changed application code and committed `sp-vise/` evidence so reviewers can reproduce the result locally.

<Info>
  MCP `check_compliance` returns the same compliance result and exit code with an additive `customerOperations` summary for build, Day-2, and release routing. The summary does not run sensors, write files, or turn advisory findings into a gate.
</Info>

<Accordion title="Advanced: compare an approved and candidate release" icon="terminal">
  Teams using Integration Passports can add the same release comparison used during human review:

  ```sh theme={null}
  vise check . --ci \
    --from-passport <approved-passport.json> \
    --to-passport <candidate-passport.json>
  ```

  A `ready` result supports human release review; it does not record approval. See the [command reference](/ai-mcp/vise/cli-reference) for exact exit codes and trust-policy options.
</Accordion>

## Related

<CardGroup cols={2}>
  <Card title="How Vise works" icon="gears" href="/ai-mcp/vise/how-it-works">
    Understand result states and which ones need human input.
  </Card>

  <Card title="Review and release" icon="clipboard-check" href="/ai-mcp/vise/release-assurance">
    Review the candidate evidence without confusing readiness with approval.
  </Card>
</CardGroup>