kendo.dev

Appearance

Projects ​

Projects are the top-level container for all work in kendo. Each project has its own board, sprints, epics, time entries, and team members.

Creating a Project ​

Create a project from the dashboard with a name and code. The project code is a short prefix (2-5 characters) used for issue keys. For example, a project with code KD generates issues KD-1, KD-2, and so on.

TIP

Choose a meaningful project code — it appears in branch names, commit messages, and MCP tool references. It cannot be changed after creation.

Board Configuration ​

Lanes ​

The Kanban board is organized into lanes that represent your workflow stages. Every project starts with default lanes, but you can customize them:

  • Add lanes for extra workflow stages (e.g., "QA", "Staging")
  • Rename lanes to match your team's terminology
  • Reorder lanes by dragging them into position
  • Remove lanes that are no longer needed (you nominate the lane its issues move to)

GitHub Triggers ​

Each lane can have GitHub triggers configured. When a GitHub event fires on a branch linked to an issue — for example, a pull request is opened — kendo moves the issue into the lane that holds that event. Moving an issue into a lane does not send anything to GitHub. See the GitHub integration guide for details.

Sprint Settings ​

Settings → Sprint Settings switches on the automatic sprint cycle, which completes an expired sprint and starts the next planned one every hour, and sets where a completed sprint's unfinished issues go. See Sprints for how it decides.

Teams and Access ​

Projects are assigned to teams. All members of a team have access to the team's projects. User roles (Admin, Developer, Viewer) determine what actions each member can perform.

See the Quick Start for role descriptions.

Epics ​

Epics group related issues into one larger piece of work, and show it on the project's timeline. Each epic has:

  • Name, and a color for the timeline
  • Goal — what the epic delivers, up to 500 characters, shown first on the epic page and in the drawer
  • Description — up to 65,535 characters. A long one folds behind Show more on the epic page and Read the full description in the drawer
  • Start date and end date for the timeline
  • Assignee — the person who owns the epic
  • Issues — the issues that belong to it. Add issues on the epic form opens a searchable picker, and an issue already in another epic says so
  • Done when — the customer's wishes that make the epic done
  • What done looks like — checks to verify the work against

Create an epic from the project's Epics view. A click on an epic's title in the Epics table, or on its bar in the timeline, opens it in a drawer. The epic page shows the content on the left, and a sidebar with Planning and Progress on the right.

Done when ​

List the customer's wishes under Done when, and tick each one when it is delivered. The epic shows who ticked a wish and when. A wish can link issues of the same epic, but a link never ticks it.

What done looks like ​

A second list holds plain-text checks: the things an agent or a reviewer verifies the work against. Checks are never ticked.

Open and Closed ​

kendo decides an epic's status for you; there is no status to set:

  • An epic with Done when wishes is Closed once every wish is ticked, even with issues still open. It stays Open while one wish is open.
  • An epic without wishes is Closed when it has issues and every one is in the project's last lane.

The Epics table, the timeline, the epic page and the drawer count wishes and issues apart, for example "1/4 wishes · 8/11 issues".

Assignee ​

Set the Assignee on Create and Edit, on the epic page or in the drawer. The new assignee gets an in-app notification, and an email when their assignment emails are on. Assigning yourself notifies nobody. An assignee who leaves the project is unassigned. The Epics table has an Assignee column and filter, with Unassigned.

Comments ​

The epic page and the drawer have a Comments section with replies, mentions, likes, pins and attachments, as on issues. A mention notifies the person mentioned, and a reply notifies the author of the comment it answers. Other epic comments notify nobody, because epics have no watchers.

Blocked issues ​

In an epic's issue list, an issue with open blockers shows a red Blocked tag. Hover or tap the tag to see its open blockers.

Archiving a Project ​

When a project is finished, archive it instead of deleting it. Archiving is available from the project list — the archive button sits on each row, next to pin and delete — and requires the Projects: Update permission.

An archived project disappears from the places you browse:

  • the project list and its Archived toggle, where you can bring it back into view
  • the sidebar, including the pinned section
  • every project picker, such as the one on time-entry exports
  • kendo project list in the CLI, unless you pass --include-archived

Nothing is removed. All issues, sprints, epics, lanes and time entries stay exactly as they were, and the project itself stays open and editable — if you have a link to it, it still works, complete with its board and backlog. A banner at the top tells you the project is archived, with a Restore project button for anyone who may update it. Its issues also keep turning up in search, and its hours keep appearing in time-entry exports.

TIP

Archiving is a workspace-wide decision, not a personal view filter. Once you archive a project it is out of the list for everyone in the tenant, and restoring brings it back for everyone — with pins intact.

Restore a project from the Archived view in the project list, or from the banner on the project itself.

WARNING

Archiving is not deleting. Deleting a project permanently removes its issues, sprints, epics, lanes and time entries and cannot be undone; archiving only hides the project from lists and is reversible at any time.

Multi-Tenant Isolation ​

Each tenant in kendo gets a fully isolated database. Projects, issues, users, and all data are separated at the database level — there is no cross-tenant data access.

Audit Logging ​

Changes to projects, issues, users, time entries, two-factor enforcement, GitHub connections and AI keys are recorded in an append-only, hash-chained audit log. Every entry records when the change happened and who made it — or, where a webhook or a scheduled job drove it, which system did. Alongside that sits a snapshot of the affected fields: a create captures the new state, a delete the state that was lost, an edit both sides of the change, and restoring a deleted user the state it came back as. A few system-driven updates record only the new state. Each row folds the previous row's hash into its own, so a later edit to the history is detectable.

An issue's history is readable in the Activity tab on the issue itself, covering its creation and any change to lane, priority, type, assignee, sprint, epic, title, description or estimate. That tab is the only audit surface in your workspace — the other trails are written for forensic use and cannot be browsed.

WARNING

Not every change is recorded. Deletions cascade silently. Deleting a project is itself recorded, but the records it takes with it are not: deleting a project takes its issues, time entries and project AI keys with it, and deleting a single issue takes its time entries with it; none of those removals is recorded, so whatever history the deleted records already had stays in the log but nothing marks them as gone. Deleting an issue or a time entry directly is recorded. Changes an issue inherits from something else are not recorded. Editing an epic's issue set, deleting an epic, a sprint or a lane, unlinking a GitHub repository, or deleting a user all rewrite a field on every issue affected — its epic, its sprint, its lane, its repository or its assignee — with no entry naming who did it. Roles sit outside the two-factor snapshot. Turning enforcement on or off for an existing role is recorded, but creating, renaming or deleting a role changes which roles are enforced without writing one, and deleting a role moves everyone holding it to another role unrecorded. Some accounts are created unaudited: the first administrator of a new workspace, and an administrator invited to one, write no creation entry — and the one-click unsubscribe link in a notification email changes that person's notification preferences without recording anything, since it is followed without signing in. An issue's labels, its blocking relationships, its watchers and its AI prompt all sit outside the snapshot, so changing any of them leaves no trace of who did it. A project's membership, avatar, and lane configuration sit outside its snapshot too. Reassigning a project's teams, adding or removing its direct members, or replacing its avatar records nothing, and neither does creating, renaming, reordering, or deleting a lane — only a project's name, code, description, owner, archived state and sprint settings are captured, so a change of owner is recorded while the people who can reach the project, the image it shows, and the column structure of its board are not. Reordering an issue is recorded only when the move changes something audited: a drag that alters nothing but the issue's position writes no entry, because position is deliberately excluded from the snapshot, so the log cannot say who moved an issue up or down a column. A drag that also moves it between lanes, or in or out of a sprint or epic, is recorded — including one that stays in the same lane.

See Also ​