Core concepts

The big picture

Work is organized around the workspace — the inbox catches incoming stuff, goals describe the outcomes you're driving across projects, projects group committed work, and cycles run across all of it:

Workspace
├── Inbox       — workspace-level triage queue (bugs, feedback, ideas, ...)
├── Goals       — outcomes you're driving (link issues from any project)
├── Cycles      — time-boxed iterations (sprints) across all projects
└── Project
    ├── Issues      — the atomic unit of work
    └── Milestones  — release-bounded scope

An issue lives in exactly one project. It can additionally be assigned to one cycle (workspace-wide) and one milestone (project-scoped) — those are orthogonal slicings of the backlog, not nested containers.

Workspaces

A workspace is the top-level tenant boundary. Members are invited into a workspace and granted a role; everything inside (projects, issues, etc.) is scoped to the workspace.

Projects

A project groups all the work for a single product line, codebase, or initiative. Each project has:

• A slug (URL-safe) and an identifier (e.g. ENG) used to prefix issue keys like ENG-12
• A lead (an optional workspace member)
• Its own issue states and milestones

Switch between projects via the project switcher inside the dashboard.

Issues

Issues are the atomic unit of execution — one issue, one piece of work. Each issue has:

Field	Values
state	A column in the project's board (e.g. Backlog, In Progress, Done). Issue states have a category (backlog, unstarted, started, completed, cancelled) that drives status semantics.
priority	none, low, medium, high, urgent
assignee	Optional workspace member
cycle	Optional — the sprint it belongs to
milestone	Optional — the release it ships in
due_date	Optional hard date

Issue keys are stable across renames (ENG-12 always refers to the same issue, even if you rename the project).

Cycles

Cycles are time-boxed iterations — sprints, in most terminology. A cycle lives at the workspace level and can hold issues from any project, so one sprint spans the whole team's work. A cycle has a name, start/end dates, and a status:

• draft — being planned, not yet active
• active — currently running
• completed — closed out

An issue belongs to at most one cycle at a time. Use cycles to answer: "What are we working on this week/sprint?"

Milestones

Milestones are release-bounded scope — a group of issues that ship together (v2.0, the public beta, a Q3 launch). Each milestone has:

• A name and optional description
• Optional start and target dates (placed on the Gantt timeline)
• A status: planned, active, completed, cancelled
• Dependencies on other milestones — a milestone is "blocked" when any dependency is not yet completed

The board view shows progress (% of issues done) and which milestones are blocked. The timeline view is a draggable Gantt chart with dependency arrows.

Goals

Goals describe outcomes you're trying to drive, not work items. Goals are workspace-scoped — they typically span multiple projects (a marketing goal pulls in work from marketing + billing + growth). Each goal has:

• A title, optional description, optional target date
• A status: draft, active, completed, cancelled
• Key results — measurable sub-outcomes (each with optional metric + 0-100% progress)
• Linked issues — issues from any project in the workspace that contribute to the goal; the goal's progress aggregates them

Goals answer "why are we doing this?" — issues answer "what are we doing?". The AI breakdown helper proposes issues from a goal description; when you commit, you pick which project they land in.

Dashboard

The Dashboard is the per-user "Today" view — not a planning surface, but a focused execution one. It pulls from every other surface and presents only what's actionable for you, right now:

• A stat bar (Open / In flight / Overdue / Done today / Done 7d) for the user across every project in the workspace
• An active-cycle card with completion progress (one click to the cycle detail)
• A Today calendar — the day grid populated with overdue + due-today + currently-started issues
• A Goals card — active workspace goals so what you're shipping stays anchored to outcomes
• A My tasks list — every open issue you own, sorted overdue → today → this week → undated, then by priority

It's intentionally read-mostly: you triage in the Inbox, plan in Goals / Cycles / Milestones, and execute from the Dashboard. If the Dashboard feels noisy, the fix is usually upstream — too many open issues, missing priorities, stale cycles — not the Dashboard itself.

Inbox

The inbox is the workspace-level triage queue — anything that lands over the day or week, before it's committed to a project. Each inbox item has:

• A title and optional content
• A kind: bug, feedback, idea, feature, or question
• A source (where it came from — manual, ai, email, api)
• A status: new, reviewed, archived, converted

When an inbox item is ready to act on, promote it into an issue under a chosen project — the link is preserved for lineage.

How it all connects

Inbox item ──"promote"──▶ Issue ──"assign cycle"──▶ Cycle
                            │
                            ├──"assign milestone"──▶ Milestone ──"depends on"──▶ Milestone
                            │
                            └──"link to goal"──▶ Goal (workspace) ──"contains"──▶ Key Result

A typical flow:

1. Drop bugs/feedback/ideas into the Inbox
2. Triage by setting kind, then promote keepers into an Issue
3. Slot the issue into a Cycle when you're ready to work on it
4. Tag it with a Milestone if it needs to ship as part of a release
5. Link it to a Goal so progress rolls up to the outcome you care about