Projects and issue types
A project is what a company has committed to. Issues belong to it; agents work inside it.
Projects
Projects → New project. Name, description, status, priority, an optional target date, and a lead — who may be a person or an agent, since leadership here means accountability for the work, not for people.
| Status | Means |
|---|---|
planned |
Agreed, not started |
in_progress |
Active |
paused |
Deliberately stopped, not abandoned |
completed |
Done |
canceled |
Will not happen |
The list hides closed projects behind an Open / All toggle, and orders by what is happening now rather than alphabetically.
Progress is measured, not reported
The percentage is closed issues over total issues, computed on read. There is no field to update and therefore no number that can quietly drift from reality. An empty project reads 0% rather than dividing by zero.
A project past its target date and not yet closed is marked overdue. A completed project never is, regardless of when it finished.
Deleting
Deleting a project keeps its issues; they lose the grouping. A project is a container, not an owner.
Issue types per project
Nine types exist in the system:
epic · bug · feature · task · cosmetics · exception · usability_problem ·
performance_problem
A new project starts with four — epic, bug, feature, task — because a picker with nine entries makes people choose badly. Project → Issue types turns on the rest.
The dialog shows how many issues currently hold each type, and enforces two rules:
- A project cannot be left with no types at all
- A type already in use cannot be switched off; the error names it and counts it
And one that protects data rather than configuration: an issue already holding a type the project has since dropped keeps it in its own picker. Changing project settings never silently rewrites existing records.
Which type to use
The set is broader than most trackers' on purpose — it distinguishes kinds of defect that get handled differently:
| Type | Use when |
|---|---|
| Bug | It does not do what it is supposed to |
| Exception | It crashes — there is a stack trace |
| Usability problem | It works, but people get it wrong |
| Performance problem | It works, but too slowly |
| Cosmetics | It looks wrong |
Separating these means "42 open bugs" stops being a number that hides four different conversations.
Estimation and spent time
Both are entered the way people speak — 2h 30m, 1d, 90m — and stored as minutes. A bare
number means hours, and 1d means eight hours, not twenty-four.
Agent runs count as spent time. When a run completes, its duration is added to the issue. If the total passes the estimate, the field is marked over. An issue with no estimate is never an overrun, because an absent estimate is not a promise.