orcakit
orcakit
Orca shows one workspace per git worktree, with a card carrying the linked issue, a status, and any terminals running in it. Worktrees themselves come from plain git worktree (gitkit's convention, issuekit's start, or your own hands) and Orca discovers them on its own.
What nothing owns is the drift between the two. A worktree named issue-42-add-sso-login sits in the sidebar with no issue attached, so its card says nothing. An issue closes and its PR merges, but the workspace stays forever, and three weeks later the sidebar is mostly finished work. orcakit owns exactly that reconciliation: Orca's view of your worktrees, made to match the tracker.
The line orcakit does not cross
Git is the source of truth for a worktree. orcakit never runs orca worktree create to do real work and never invents a path, because creating a worktree is native git worktree under gitkit's convention, so a headless Linux box with no Orca on it runs identical commands. orcakit works one layer up, on things Orca alone knows:
- metadata, meaning the linked issue, the workspace status, the comment, the display name;
- Orca-side resources git can't express, meaning live terminals bound to a workspace, and a repo's archive/setup hooks.
Removing a worktree with git is enough: Orca notices within seconds and drops the entry by itself. The single exception is a workspace Orca created, covered in Mode: clean, which documents why and confines it there.
orcakit never touches the tracker. It reads issues and PRs to judge state; it never closes an issue, moves a label, or edits a PR. When it finds a merged PR whose issue is still open, that's tracker drift and it says so, routing to issuekit close rather than reaching around it.