* feat(cloud): ENTERPRISE-SSO Settings › Enterprise single sign-on and directory sync, driven by server state
* feat(cloud): key icon on the single sign-on group title (TEAM-DIALOG-2)
* fix(cloud): Contact us in the SSO block is a plain button; Copy link is for sign-in surfaces
* test(cloud): the copied SSO setup link is minted like the opened one and never logged
* fix(cloud): design-squad review of the SSO blocks (sentence-case chips, directory sync icon, grace and last-change wording)
* fix(cloud): sentence-case success badge variant for the SSO chips; catalog matches the new copy
* fix(cloud): register the Enterprise IPC handlers with the team handlers (file line limit)
* feat(cloud): every setup notice line has plain words and a real action, or doesn't show (ENV-NOTICE-ACTIONS)
- Doctor checks that reached the bare 'check' line now classify: low disk ('disk')
and a missing repo tool ('tool') get their own plain words; disk.free without a
code and any check this desktop doesn't know are hidden, never a bare label.
- The push notice reads repo access plus the person's own gh rights on the repo
(new gitHubInstallRights IPC): Install on {owner} only where installing can
work, 'Copy request for an owner' once an owner was asked, Check again where
the App already reaches the repo, plain words for someone else's public repo
(octocat/Hello-World). Install no longer carries a Copy link.
* copy(cloud): a push nobody here can install offers Copy request for an owner (design-squad, ENV-NOTICE-ACTIONS)
* fix(cloud): ENV-NOTICE-ACTIONS rebase onto AUTH-ONLY-COPY-LINK: the owner request takes the install page from the repo-access answer
A GitHub App user token generally can't read orgs the App isn't installed on, which is
exactly when canInstall is asked. Read the owner type anonymously first (GET /users/{owner}):
another user's account is false; an org is true only for active admin, false for another
role/state, and null for 403/404/errors/timeouts. Owner-type lookup failures are null.
Present while the Orca GitHub App isn't installed for the repo owner ('missing', or
'public' with no installation). true: the caller's connected GitHub login is the owner,
or their membership in the owner org is active admin. false: member, non-member (403/404),
or another user's account. null: no connected GitHub user token, the token can't be read
or refreshed, or GitHub errored / timed out (3 s). Never fails the answer.
The token comes from memberGitIdentity (decrypt + refresh near expiry).
design-squad: a clone GitHub refused marks Start sandbox done and the clone step failed; missing
or requested access reads as a warning (amber, triangle; new InlineError 'warning' tone), the
reachable-now case stays an error; 'Copy request for an owner' reads 'Copied' for 1.5 s.
'Couldn't clone owner/repo' with only Try again becomes 'Orca can't access owner/repo' with Give
Orca access (the App's install page for the owner, repository preselected; no Copy link) and
Choose another repository (back to the draft with the Project picker open). After the handoff the
card re-checks access on focus and on a backing-off timer, and starts the create again once
GitHub grants it. An install GitHub turned into a request says who to ask, with a request to copy;
a repository Orca can reach now offers Try again.
* feat(cloud): COPY-LINK-FIRST-CLICK Copy link on the first Sign in and setup's first Continue in browser starts the same flow without opening the browser
* feat(cloud): COPY-LINK-FIRST-CLICK loopback sign-in links say they open in any browser on this computer (menu line and copied toast)
* fix(cloud): COPY-LINK-FIRST-CLICK Copy link stays on sign-in only; the choose-plan Continue in browser has no copy link
NO-ROW: a create with no project here yet (GitHub-only Orca Cloud) now has its pending row
atop the list when grouped by project too (it got a blank 'repo:' section before). While it
opens, openCloudWorkspace reports the server it pairs to (onHost); the sidebar hides that
server's rows until the hand-off removes the pending row, both in one store update, so the
workspace never shows twice.
CANCEL: createSandboxWithProgress (owned and GitHub-only creates) deletes what a cancel
leaves: cancelled in flight, it replays the create by its Idempotency-Key and deletes the
sandbox the control plane hands back (reclaimCancelledCreate, retrying while the first is
still in progress); cancelled just as it answered, it deletes it. A cancelled clone already
deleted itself. The GitHub runner deletes the sandbox when Cancel lands before or during
Open workspace (which also drops this computer's pairing), and cancel's 'Deleting the
sandbox…' waits for it. Copy link moves to cloud-workspace-share-link.ts (re-exported) to
keep open-cloud-workspace.ts within max-lines.
n40b: a paired Archive never reached the server; its Sleep's host-side step (terminals over the
paired connection) hung, so neither the control-plane suspend nor the archive ran. With a paired
target in the batch, that step now times out after 30s: paired targets get no outcome (their
sandbox is still slept by the control plane, and an Archive waiting on this Sleep proceeds), other
targets report the timeout as a failure. Batches without a paired target are unchanged.
Neil
Neil
