Projects

Group related issues and track them as one unit — with priority, status, progress, and an owner.

A project in Statica is a container for a set of related issues. Reach for one when the work is too big for a single issue but too small to be a workspace of its own — a launch, a migration, a multi-part feature, an investigation that spawns several threads.

Every project carries a name, an icon, a description, a lead (a member or an agent), a status (planned / in_progress / paused / completed / cancelled), a priority (urgent / high / medium / low / none), and a progress percentage that is derived automatically from the state of its linked issues.

How projects relate to issues

Projects and issues are independent objects in a many-to-one relationship: an issue belongs to at most one project; a project holds any number of issues. Linking and unlinking is fully reversible — drag in the board view, or use the project picker on the issue's right-hand properties panel.

A project's progress bar is computed from its linked issues — the more issues that reach done, the fuller it gets. Cancelled issues are excluded from the count entirely; backlog issues count toward the denominator but not the numerator.

Pinning to the sidebar

The pin icon in the top-right of a project adds it to your sidebar's pinned list. Pinned projects stay one click away no matter where you are in the workspace, and pins are personal — every teammate pins independently.

The sidebar's Workspace → Projects link always shows every project in the workspace; pinning is just a personal shortcut layered on top.

Attaching resources

Each project has a Resources section where you attach GitHub repositories. Once attached, any agent assigned to an issue inside that project can read and write to those repos while executing tasks — Statica passes the repo URLs through to the daemon as context.

Resources are scoped per-project; if two projects need to share a repo, attach it to each one.

Deleting a project

Deleting a project does not delete its issues. The linked issues are simply unlinked and fall back into the workspace's flat issue list. That is intentional — work that was scoped to a project is rarely throwaway, even when the framing of the project itself changes.

If you want to discard the work as well, archive or delete the issues first, then delete the project.

Project lead

The lead is the person — or agent — accountable for the project. It is a soft signal, not an access-control mechanism: any workspace member can edit a project regardless of who leads it. A lead can be:

  • A workspace member (a human teammate)
  • An agent — useful when the project's work is mostly delegated to one (for example, "Weekly bug triage" led by a triage agent)

Next