OpenCode in Relpin works against the actual app project. It can help edit files, but it does not replace Relpin governance for data, credentials, release promotion, or audit.
Start from the project
Open the app in Studio and inspect the files before asking OpenCode for changes. Good prompts reference the route, component, SDK call, or behavior you want changed.
Keep edits reviewable
Prefer small edits with visible diffs. For sensitive changes, review the generated file changes before previewing or publishing.
Provider credentials
Relpin can route OpenCode through organization-level or app-level provider settings depending on the workspace configuration. Provider token costs belong to the connected provider account.
Relpin governs the app runtime and project write path. It should not ship provider secrets into generated app code.
Use preview as the boundary
After an OpenCode edit, restart or refresh the preview and verify the behavior in the app. Preview failures should be fixed at the source file or binding layer, not hidden with browser-only fallbacks.
Publish only reviewed work
When the edit is ready, publish a pinned release through the normal Relpin release path.