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 a GitHub trigger configured. When an issue moves into that lane, kendo can automatically perform GitHub actions. See the GitHub integration guide for details.

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 on a timeline. Each epic has:

  • Name and description
  • Start date and end date for timeline visualization
  • Status — Open, In Progress, or Completed
  • Color for visual identification on the timeline

Create epics from the project's epic view, then assign issues to them. Epics help plan larger features that span multiple sprints.

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 issues, users, time entries, two-factor enforcement, GitHub connections, AI keys and Hand to Claude sessions 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 — a Hand to Claude session ticking through its statuses, for instance — and two of that session's status changes, one made by the cleanup job and one by a webhook, record nothing at all. 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. Projects themselves are not audited: creating, renaming, archiving, restoring or deleting a project writes no audit entry. Deletions cascade silently. 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 Hand to Claude prompt all sit outside the snapshot, so changing any of them leaves no trace of who did it. 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 ​