How destinations get chosen#
Sidekick resolves a destination per role at build time:
- Pinned destination — if you've pinned a connector for that role (e.g. GitHub for
code_host), Sidekick uses it. - Managed default — if nothing is pinned, Sidekick falls back to the matching managed default (managed artifacts for files, managed runtime for execution).
- Approval — if the destination is gated by autonomy policy, Sidekick pauses for approval before publishing.
Roles and what they cover#
| Role | Typical destination | Managed fallback |
|---|---|---|
code_host | GitHub | Internal code bundle or manual export; pull requests require a connected code host |
document_store | Notion, OneDrive | Managed artifacts |
artifact_store | OneDrive, GitHub Releases | Managed artifacts |
deployment_host | Your deployment provider or CI/CD pipeline | No public deployment; manual export or PR-ready handoff |
runtime_target | Connected runtime / fleet | Managed runtime |
Pinning a destination#
In Sidekick → Settings → Destination defaults, choose a connector for each role you want to override. Unpinned roles continue to use the managed default.
Publication approval#
For destinations marked as approval-gated by your autonomy policy, Sidekick:
- Drafts the change in its isolated worktree
- Surfaces a publication approval in the Approvals inbox
- Publishes only after the approval resolves
Capability boundary#
Sidekick won't pin a destination on your behalf. The first time it touches a role with no pin and no connector, it uses the managed default and records that decision in the evidence trail so you can opt in to a different destination later.
If there is no deployment host connected, Sidekick may produce a deployable output, export bundle, or pull request, but it should not claim that a public URL exists. Public hosting starts only after a deployment destination is connected and the deployment action is approved.
info See Outputs, artifacts, and destinations for the plain-language boundary between internal outputs and public hosting.