Maintain an existing integration

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

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.

Add or change a feature
Fix a problem
Upgrade the SDK

Ask for the new behavior and name what must keep working:

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.

Describe what the user sees, where it happens, and what should happen instead:

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.

Ask for the version and feature impact before changing dependencies:

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.

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

Under the hood: commands used by the agent

# 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 for baseline, evidence, and per-feature options.

Keep integrations verified in CI

Protect current and earlier social.plus features after the handoff.

Review and release

Turn the completed change into a reviewable release candidate.

​Protect what already works

​What “done” looks like

​Related

Keep integrations verified in CI

Review and release

Protect what already works

What “done” looks like

Related