orcakitlisted

# orcakit [Orca](https://www.onorca.dev/) 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`](#mode-clean), which