KanbanGit Documentation
Current status
KanbanGit currently starts from a fresh Laravel 13 + Inertia starter application. The product-specific Kanban, ticketing, permission, and Git integration features described in this documentation are not implemented yet.
Product summary
KanbanGit is intended to become a self-hostable project management application with Kanban workflows and Git provider integrations. The long-term product direction is comparable to a lightweight Jira-style workflow system with repository awareness, starting with Gitea and leaving room for future providers such as GitHub and GitLab.
The product centers around projects. Each project owns its own board configuration, backlog, ticket metadata, ticket hierarchy, and repository connections. The architecture must support application-wide administration plus project-scoped permissions that can be assigned to users and teams.
First Mockup https://stitch.withgoogle.com/projects/353263382234239260
Documentation map
- Product Spec describes expected product behavior, user-visible rules, and scope boundaries.
- Domain Model defines the canonical domain concepts, relationships, and invariants that future database tables, Eloquent models, policies, and frontend types should follow.
- Architecture Roadmap captures the planned architecture direction, permission strategy, integration boundaries, and staged implementation intent.
- GitHub Integration Plan captures the first planned GitHub-specific integration strategy for release
0.3. - Release Task Breakdown splits the planned work into small ordered implementation tickets grouped by release.
Glossary
| Term | Meaning |
|---|---|
| Project | A workspace with its own settings, board columns, backlog, tickets, and repository connections. |
| Project Key | A project-specific uppercase identifier with a maximum length of 5 characters. It prefixes every ticket key. |
| Ticket Key | The immutable unique ticket identifier in the format PROJECTKEY-INDEX. |
| Board | The Kanban view of a project, using configurable project-specific columns. |
| Backlog | The default intake area where newly created tickets start before they are moved into a board column. |
| Ticket | The core work item with title, description, acceptance criteria, type, priority, status, custom field values, worklog, and links. |
| Parent Ticket | A ticket of the dedicated Parent type that may contain child tickets. |
| Worklog | The audit trail of ticket changes, including what changed and who changed it. |
| Team | A group of users that can receive project permissions and pass those permissions to its members. |
| Permission | A project-scoped action grant such as create, view, edit, or delete, plus application-wide admin access for platform administration. |
| Repository Connection | A project-level configuration that links the project to an external Git provider repository. |
Product principles
- Self-hosting is a core requirement.
- Projects are the primary boundary for workflow configuration.
- Ticket keys are immutable and must remain reliable references across the product and future Git integrations.
- Permissions must be designed for both direct user assignment and team inheritance, even before the full permission system is implemented.
- External Git providers must be introduced behind a provider abstraction, even if Gitea is the first supported provider.