> ## 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.

# Brownfield and day-2 path

> Add another social.plus feature while keeping existing integrations and earlier Vise engagements reviewable.

Vise supports both apps that adopted social.plus before Vise and apps whose earlier features already have a Vise contract.

## Existing integration built without Vise

Initialize the new feature before editing. If Vise reports pre-existing findings, record a baseline immediately:

```sh theme={null}
vise init . --request "Add comments to the existing feed" \
  --answer comment_target=post \
  --answer comment_depth="one level of replies" \
  --answer lifecycle_owner="React component" \
  --answer target_screen="existing feed detail"
vise baseline .
```

Then gate new rule findings with:

```sh theme={null}
vise check . --new-only
```

The baseline excludes legacy rule findings only. The new feature's completeness checklist and selected capabilities still have to pass.

## Existing integration already governed by Vise

Initializing a different outcome records the previous engagement under `sp-vise/engagements/`. Replacing a green engagement requires an explicit acknowledgement:

```sh theme={null}
vise init . --request "Add comments to the existing feed" \
  --supersede-engagement \
  --answer comment_target=post \
  --answer comment_depth="one level of replies" \
  --answer lifecycle_owner="React component" \
  --answer target_screen="existing feed detail"
```

Review prior work at any time:

```sh theme={null}
vise status .
vise check . --engagement <outcome>
vise check . --all-engagements
```

In CI, one command holds the active and recorded engagements green:

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

Exit `11` means the active feature is green but previously completed work drifted.

## Handoff checklist

* State whether a baseline was used and when it was recorded.
* Identify the active outcome and every recorded previous engagement.
* Report unresolved non-blocking intake and any scope-omit decisions.
* Include runtime proof or an explicit waiver for the new user-visible surface.
* Do not describe a green active engagement as sufficient when `--ci` reports previous-engagement drift.

<Card title="Reading a check result" icon="shield-check" href="/ai-mcp/vise/how-it-works#reading-a-check-result">
  Understand active failures, proof waivers, contract drift, and engagement drift.
</Card>