Skip to main content
Use these terms consistently in documentation, integrations, and reports.
A logical repo or product that work rolls up to for task lists, usage, reconciliation, and reports. A Project is not an individual checkout, worktree, fork, or Agent Session. Git-backed Projects display as owner/repo by default.
The durable internal identity of a Project. It does not change when a repository is renamed or transferred.
The current canonical identity used to recognize a Project across multiple Workspaces. Git-backed work uses the nearest repository owner and name, preferring upstream over origin. Work without a usable GitHub remote falls back to the canonical local path. When a repository is renamed or transferred, the Project keeps its Project ID, adopts the new Project Key, and retains the old key as a Project Alias.
A former Project Key or provider identity that still resolves to the same Project. An alias helps Taskbean recognize repository renames, transfers, and provider records without making provider-specific values canonical.
A user-provided value that identifies a Project by key or display name, or a Workspace when the value clearly looks like a path. A Workspace selector resolves to its owning Project.
A physical checkout, worktree, fork, or folder where work happens for a Project. Multiple Workspaces can belong to the same Project.
A Project that appears in default task, usage, reconciliation, and report rollups because at least one Workspace is tracked.
A Workspace that participates in physical-path behavior such as agent detection, skill installation, cleanup, and diagnostics.
A Workspace observed from Agent Session metadata or task provenance but not explicitly tracked. It can support attribution and rollups, but Taskbean does not mutate it with skill files or cleanup actions.
A pathless Workspace where an Agent Session runs outside the local machine. Taskbean creates it only when repository metadata or a known Project Alias resolves one Project without ambiguity. Otherwise, the session remains Unassigned Work. A Remote Workspace and a local Workspace merge only when stable lineage evidence proves that they are the same execution lineage.
The user-changeable Workspace a Project uses by default for path-dependent actions such as opening folders, installing skills, or diagnostics. It is not inferred only from the most recent Agent Session.
One run of a coding agent, scoped to a Workspace, that can create tasks, usage records, or Chronicle evidence. Agent Sessions roll up through their Workspace to a Project.
A Copilot-created branch of an existing session or workspace lineage. A Copilot Fork belongs to the same Project as its source and does not create a separate Project.
A unit of developer work that can belong to a Project and carry Workspace provenance. A manually created task without project context may be Project-agnostic and Workspace-agnostic.
Tasks, Agent Sessions, or evidence that Taskbean cannot confidently resolve to a Project. Taskbean presents this work for review instead of inventing a Project from a session ID, GUID, or folder basename.
The automatically discovered context Taskbean uses to prepare a Task for agent execution. It includes relevant Project instructions and available agent capabilities, with optional global, Project, or Task overrides.
The environment-aware, optimized instruction Taskbean prepares for an Agent Session to execute a Task. A Kickoff Prompt can be revised, copied, or launched without changing the Task itself.
The link between a canonical Task and the Agent Session that executes it, including the Kickoff Prompt version, execution status, and review evidence.
A session-scoped step in an agent’s plan for completing a Task. Execution Steps can be added, removed, renamed, or reordered during execution and remain subordinate to the canonical Task.
The execution terms define domain concepts, not new CLI commands or desktop controls. Use the CLI reference and desktop guide for supported workflows. The canonical definitions live in CONTEXT.md. Architecture decisions 0001, 0002, and 0003 explain the identity model.
Last modified on September 16, 2026