Task Types

Overview

Task types are a system-defined, single-select classification on every task — distinct from user-defined tags. A type like Bug, Feature, Campaign, or Incident tells Kanvas AI what kind of work an item represents, so cards can carry a recognisable icon, boards can be filtered by type, and future automations can react to type changes. Every project picks one board template (e.g. Software, Marketing) at creation time; the template determines which types are available for that project’s tasks.

Use it for: classifying work consistently across a workspace, filtering boards by category, and giving connected tools (Kenny, MCP clients) a stable code-friendly handle on each task’s category.

How it works

The system ships 5 board templates — software, marketing, operations, sales, general. Each is a row in board_templates.
Each template owns a fixed set of task types. Types live in the task_types table with template-scoped keys (e.g. software_bug, marketing_campaign) — there is no cross-template mixing, so a “Task” under Software (software_task) is a different row from a “Task” under General (general_task).
Every project stores projects.board_template_id. The available types for that project are derived at runtime: SELECT * FROM task_types WHERE board_template_id = projects.board_template_id ORDER BY name.
Every task stores tasks.task_type_key — a single string FK to task_types.key. The type cannot be multi-select; a task has exactly one type.
Types are system-locked: keys are immutable, the set is fixed at the database level, and only migrations can add or rename rows.

Seed templates and types

Template	Emoji	Task types
`software`	💻	`software_feature` (Feature), `software_enhancement` (Enhancement), `software_bug` (Bug), `software_task` (Task)
`marketing`	📣	`marketing_campaign` (Campaign), `marketing_content` (Content), `marketing_event` (Event), `marketing_asset` (Asset)
`operations`	⚙️	`operations_process` (Process), `operations_request` (Request), `operations_incident` (Incident), `operations_task` (Task)
`sales`	💼	`sales_lead` (Lead), `sales_opportunity` (Opportunity), `sales_follow_up` (Follow-up)
`general`	📋	`general_task` (Task), `general_note` (Note)

Software ships 4 types, Sales ships 3, the rest ship the counts shown above — 17 type rows in total.

API reference

`GET /api/task-types?board_template_id=<uuid>`

Returns every type belonging to the given template, sorted by name.

Response:

[
  {
    "key": "software_bug",
    "board_template_id": "…",
    "name": "Bug",
    "icon": "🐛",
    "color": "#EF4444",
    "created_at": "…",
    "updated_at": "…"
  }
]

Task and project read responses

Task responses include task_type_key: string. When the underlying query selects the join, they also include task_type: { key, name, icon, color, … }.
Project responses include board_template_id: string. When the join is selected, they also include board_template: { key, name, emoji, … }.

Setup

Task types are enabled on every workspace automatically. No configuration is required:

New projects are created with the software board template by default (Phase 1; a template picker arrives in Phase 2).
All existing projects were backfilled to the software template; all existing tasks were backfilled to software_task.
After backfill, projects.board_template_id and tasks.task_type_key are both NOT NULL at the database level.

Usage

See a task’s type. Each type carries an emoji (🐛 Bug, ⚡ Enhancement, 📋 Task, etc.) that renders before the task ID anywhere Kanvas AI shows a task — board cards, the task drawer header, and the project tasks sidebar in chat. Hover the emoji to see the type name. See Where you’ll see the type emoji below for the full list of surfaces.

Change a task’s type. Open the task drawer and pick a type from the type dropdown — only types belonging to the project’s template are listed.

Where you’ll see the type emoji

The same emoji renders in three places so the task’s type is visible everywhere its ID appears.

Board cards. Each kanban card shows the type emoji immediately before the task ID — e.g. 🐛 KANV-1200 for a Bug. Shipped in KANV-1180.

Task drawer header. Opening any task in the side drawer shows the same emoji before the task ID in the header row — matches the board card so the visual stays consistent as you click through. Shipped 2026-05-22 (KANV-1201).

Project tasks sidebar (chat). Inside a channel, the project tasks sidebar lists the channel’s tasks as small cards. Each card carries the same type emoji before its task ID. Shipped 2026-05-22 (KANV-1202).

Tooltip on hover. On every surface, hovering the emoji reveals a tooltip with the type’s human-readable name (Bug, Feature, Enhancement, etc.). The tooltip text and the emoji glyph both come from the same task_types row, so what you see in the UI matches what an API response or MCP tool returns.

Why types matter. The emoji is the user-facing signal today; under the hood, the type is a stable code-friendly handle (software_bug, marketing_campaign, …) that future workflow automations can react to. The same task_type_key is exposed via the API and MCP clients (e.g. Kenny), so connected tools know not just what a task is called but what kind of work it represents.

Default behaviour.

The database guarantees projects.board_template_id is never null via the public.default_software_template_id() function, which returns the UUID of the software template row. This is a safety net for legacy inserts that omit the column.
The database guarantees tasks.task_type_key is never null via the literal column default 'software_task'. Same safety-net intent — application code is expected to supply a valid key for the project’s template on every write.

Edge cases & limits

No cross-template mixing. A project’s template is set at creation and is immutable. Tasks in a Software project cannot be assigned a Marketing type — the FK on tasks.task_type_key plus the application layer rejects keys outside the project’s template.
One type per task. Multi-type is not supported. If a task needs additional dimensions, use tags (multi-select, user-defined) instead.
Keys are stable, names are not. Code can switch on software_bug safely. The display label (e.g. “Bug”) is intended to be renamable in a future enhancement, but the key never changes.
System-locked. There is no UI for creating or deleting types. Adding a new type means shipping a migration.
Sales has 3 types, not 4. Sales does not include a generic “Task” type — leads, opportunities, and follow-ups cover the workflow.

MCP Server — MCP tools surface task_type_key on tasks and board_template_id on projects; list_task_types is documented in specs/mcp-server.md and ships with F1.8 (KANV-1148).
Phase 1 spec in Kanvas Knowledge: @Task Types — Board Templates, System Types & Workflow Spec (covers decisions log, ER diagram, querying patterns, and the full phased rollout).
TypeScript types: TaskType in src/types/tasks.ts, BoardTemplate in src/types/projects.ts.
Migrations: supabase/migrations/20260519063751_create_board_templates_and_task_types.sql, 20260519073315_backfill_and_constrain_task_types.sql, 20260519074502_add_defaults_for_task_types.sql.