Skip to main content
Choose the SDK path when the app needs a differentiated layout, workflow, or interaction model that should remain owned by the host application.

​
Suggested request

Add a social feed to this app using the social.plus SDK. Keep the UI consistent with the existing design system and ask me for any missing scope, target, route, region, or identity decisions before editing.

​
Governed loop

vise inspect .
vise plan . --request "Add a social feed to this app using the social.plus SDK" --summary
Review the plan, then repeat the full vise plan and vise init commands with one explicit --answer id=value flag for every blocking question. Do not place API keys or server-issued tokens in command history or AI chat; use the app’s ignored local environment/configuration pattern. After the agent implements the agreed surface: 
vise check .
vise validate .
vise run-sensors .
For a user-visible handoff, launch the real target and capture runtime-smoke evidence. Static green and passing sensors do not prove that the screen mounted, authenticated, or populated with tenant data.

​
Review checklist

  • The selected SDK path is explicit.
  • Read and write targets come from route, app state, user selection, SDK discovery, or a create flow—not invented IDs.
  • Loading, empty, error, and data states are implemented.
  • Live collections, cleanup, pagination, session renewal, and user switching follow the platform SDK lifecycle.
  • Scope decisions for post types, composer types, comments, reactions, and moderation are recorded.
  • The final handoff includes remaining advisory findings and unresolved non-blocking decisions.

How Vise works

Understand the contract, evidence, runtime-proof boundary, and CI behavior.