> ## Documentation Index
> Fetch the complete documentation index at: https://social-b97141fb-auto-generate-llmstxt.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Maintain an existing integration

> Add a feature, diagnose a problem, or upgrade the SDK without losing confidence in the social.plus experiences that already work.

Use this path when the app already has social.plus. Start with the outcome or symptom; your agent chooses the Vise workflow.

<Info>
  Ask the agent to start with `vise status . --format human`. It reads the current lifecycle state without running project sensors or changing files, then routes unchanged work, a Day-2 change, or a release handoff to the smallest next action.
</Info>

<Tabs>
  <Tab title="Add or change a feature">
    Ask for the new behavior and name what must keep working:

    ```text theme={null}
    We already use social.plus for the feed. Using Vise, add comments to the
    existing post detail screen. Preserve the current feed behavior and show
    me the impact and product questions before changing code.
    ```

    Expect a short assessment of the existing surface, the new scope, affected files and evidence, and any product decisions still missing.
  </Tab>

  <Tab title="Fix a problem">
    Describe what the user sees, where it happens, and what should happen instead:

    ```text theme={null}
    Using Vise, diagnose why the feed is missing from the selected Community
    detail page. Show me the likely gap and the smallest safe repair before
    changing code.
    ```

    The agent should compare the intended route and data target with the current source and evidence, then separate the repair from the checks that need to be refreshed.
  </Tab>

  <Tab title="Upgrade the SDK">
    Ask for the version and feature impact before changing dependencies:

    ```text theme={null}
    Using Vise, assess the social.plus SDK upgrade in this app. Explain the
    current and target version boundary, affected features, and validation
    plan before changing dependencies or source code.
    ```

    Vise checks the declaration and supported lockfile resolution. It reports the assurance boundary honestly rather than treating a version range as proof of compatibility.
  </Tab>
</Tabs>

## Protect what already works

Before editing, the agent should identify the existing feature, route, data target, and evidence that could be affected.

If the integration predates Vise, pre-existing findings can be recorded as a baseline so the new change is judged on its own work. The baseline never excuses the requested outcome or anything the change introduces.

If earlier features were built with Vise, they stay recorded and re-verifiable. Ask the agent to report earlier-feature drift separately from the current work.

If a support incident or dogfood miss reveals a reusable blind spot, a reviewed `incident-protection` learning record can bind a sanitized finding fixture, clean control, and exact verification evidence. It stays local, never uploads customer source, and does not edit rules or change readiness automatically.

## What "done" looks like

The handoff should state:

* what behavior and scope changed
* whether every earlier completed feature still holds
* which project build, lint, typecheck, test, and SDK smoke checks ran
* whether changed user-visible surfaces have fresh runtime proof or an explicit waiver
* which advisory findings or product decisions remain open

<Accordion title="Under the hood: commands used by the agent" icon="terminal">
  ```sh theme={null}
  # Route the current lifecycle job without changing the project
  vise status . --format human

  # Assess a planned change
  vise impact . --format human

  # Attach a reported symptom
  vise impact . --symptom "Feed is missing from Community detail" --format human

  # Inspect the installed SDK boundary
  vise sdk-release . --format human

  # Protect current and previously completed features in CI
  vise check . --ci

  # Preview a reviewed incident-to-protection record without writing
  vise learning record . --kind incident-protection \
    --evidence <repo-relative-input.json> --no-write
  ```

  See the [command reference](/ai-mcp/vise/cli-reference) for baseline, evidence, and per-feature options.
</Accordion>

## Related

<CardGroup cols={2}>
  <Card title="Keep integrations verified in CI" icon="code-branch" href="/ai-mcp/vise/ci-verification">
    Protect current and earlier social.plus features after the handoff.
  </Card>

  <Card title="Review and release" icon="clipboard-check" href="/ai-mcp/vise/release-assurance">
    Turn the completed change into a reviewable release candidate.
  </Card>
</CardGroup>