Tasks, Automations, and Provider Identity Under One Host Model
+
+ The project-first migration gives Orca the durable shape
+ Project -> ProjectHostSetup -> Workspace. The remaining product gap is
+ that Tasks, Automations, and provider integrations still route through different
+ ownership rules. This plan makes Host the user-facing concept across
+ Local Mac, SSH machines, Remote Servers, and future Orca cloud VMs.
+
Short Answer
++ We should keep the model simple for users: a project can be available on one or more + hosts, and every host can have its own filesystem, terminals, provider CLIs, auth, and + runtime capabilities. Tasks and Automations should stop relying on ambient global state + where the host matters. +
++ The big change is not “make SSH and Remote Server the same internally.” It is “present + both as hosts, then route each workflow through the selected host’s capabilities.” +
+Host Boundaries
+Task Source vs Run Host
++ A logical project can exist on multiple hosts, but provider data still has to be fetched + through one credential context. That source context must be explicit or at least visible. + “Project: orca” is not enough information when Local Mac has GitHub account A and + openclaw 2 has GitHub account B. +
+Where issues/PRs are fetched from
++ This answers: which host's GitHub/GitLab/Linear/Jira credentials serve the list? It + affects private repo access, rate limits, viewer-specific filters like “assigned to + me,” review requests, notifications, and mutation permissions. +
+Where the workspace is created
++ This answers: when the user starts work from a task, which project-host setup creates + the workspace? It may default to the task source host, but the user can choose another + ready setup when the project exists there. +
+What Needs To Change
+{ provider, hostId, projectHostSetupId? }.
+ projectId as a repo id. New automations
+ should target a logical project and either an existing workspace or a
+ projectHostSetupId for fresh workspaces.
+ --project plus --host or
+ --project-host-setup for workflows that create workspaces or automations.
+ Keep repo selectors as compatibility aliases.
+ Model
+One user-facing bucket
++ Local Mac, SSH target, Remote Server/runtime, and future Cloud VM all appear as + hosts. The user chooses where work runs; Orca chooses the transport. +
+Project on a host
++ A logical project may have setup rows on multiple hosts. Each row owns path, + readiness, default worktree location, and setup method. +
+Account where the request runs
++ GitHub/GitLab/Linear/Jira identity should be explicit: local desktop account, + SSH-host CLI/token, or Remote Server account. +
+Tasks Mock
++ Interaction: click GitHub / Linear / GitLab above. The important UI addition is the + visible Host + provider identity pair, not a separate “remote task” mode. +
+Automations Mock
+Daily issue triage
+Settings Mock
+Implementation Breakdown
+ExecutionHostId. Keep
+ existing ProjectHostSetup as the project-on-host record.
+ projectId, hostId, and optional
+ projectHostSetupId. Migrate old repo-id automations by mapping the repo
+ to its project-host setup.
+ --project, --host, old --repo.Other Explicitness Gaps
+--project, --host, and/or
+ --task-source-host options. Existing --repo selectors can
+ remain compatibility aliases.
+ Subagent Audit Confirmation
+
+ A second codebase pass split across Tasks/provider routing, Automations,
+ Composer/PR launch, and Settings/cache/CLI agreed on the same core gap:
+ Orca needs an explicit TaskSourceContext separate from the
+ ProjectHostSetup used to run work.
+
Tasks/provider routing
+
+ GitHub is partly host-scoped already, but Linear/Jira still route through active
+ runtime, GitLab is mostly repo-path/local-IPC based, and drawer mutations can lose the
+ source account. Report: notes/subagent-tasks-provider-hosts-audit.md.
+
Automations
+
+ Automations still treat projectId as a repo id and do not snapshot
+ hostId, projectHostSetupId, provider source context, or
+ runtime capability/version on runs. Report:
+ notes/subagent-automations-host-model-audit.md.
+
Composer / PR launch
+
+ Start-from flows use one repoId as both source item and run target.
+ Pending worktree creation stores linked numbers but not source host/account context.
+ Report: notes/subagent-composer-pr-launch-hosts-audit.md.
+
Settings / cache / CLI
+
+ Some host foundations are strong, but GitLab selectors are repo-path-only, provider
+ diagnostics are still client-global, agent launch overrides are global, and CLI
+ automation selectors remain repo-first. Report:
+ notes/subagent-settings-cache-cli-hosts-audit.md.
+
Open Product Decisions
+Do Tasks allow multi-host aggregation?
++ Recommendation: yes for GitHub/GitLab rows when each row can show its serving host, + but default to one selected host for Linear/Jira until cross-host grouping is useful. +
+Should SSH provider auth run on the SSH machine?
++ Recommendation: eventually yes. In the interim, label desktop-served SSH provider + calls explicitly to avoid misleading users with different accounts. +
+Are Remote Servers “better SSH”?
++ Recommendation: explain them as richer hosts. SSH gives filesystem/terminal access to + a machine you already manage. Remote Server adds Orca runtime services, durable RPC, + web/mobile handoff, capability/version negotiation, and richer background behavior. +
+Do we need host onboarding now?
++ Recommendation: no. Existing SSH/server settings can remain the entry point. This work + should make configured hosts behave correctly once present. +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+