42 lines
4.0 KiB
Markdown
42 lines
4.0 KiB
Markdown
# 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.
|
|
|
|
## Documentation map
|
|
|
|
- [Product Spec](/docs/product-spec.md) describes expected product behavior, user-visible rules, and scope boundaries.
|
|
- [Domain Model](/docs/domain-model.md) defines the canonical domain concepts, relationships, and invariants that future database tables, Eloquent models, policies, and frontend types should follow.
|
|
- [Architecture Roadmap](/docs/architecture-roadmap.md) captures the planned architecture direction, permission strategy, integration boundaries, and staged implementation intent.
|
|
|
|
## 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.
|