Workflow
These rules apply equally to Zeta Flutter and Zeta Web.
Jira tickets
Every piece of work — new component, bug fix, enhancement — must have a Jira ticket before any code is written. The ticket is where scope is agreed, the design link is recorded, and acceptance criteria are defined.
- Create or pick up a ticket before branching.
- Keep the ticket status updated: To Do → In Progress → In Review → Done.
- If you discover scope creep during implementation, create a new ticket rather than silently expanding the current one.
Branch naming
Branch from main. The branch name should be the Jira ticket ID, e.g. UX-1234.
Conventional commits
All commit messages and PR titles must follow Conventional Commits. This drives automated changelog generation and version bumps.
Format: <type>(<scope>): <short description>
| Type | When to use |
|---|---|
feat | New component or new user-visible capability |
fix | Bug fix |
revert | Reverts a previous commit |
docs | Documentation only |
deps | Dependency updates |
test | Adding or correcting tests |
chore | Build process, dependencies, tooling |
perf | Performance improvement |
refactor | Code change with no feature or fix |
style | Code style changes (whitespace, formatting, etc.) |
build | Build-related changes |
ci | Continuous integration related changes |
feat(UX-1234): add trailingIcon property
fix(UX-4321): correct disabled focus behaviour
chore(deps): bump lit from 3.1.0 to 3.2.0
- Breaking changes: append
!after the type/scope (feat(select)!: remove multi-select prop) or addBREAKING CHANGE:in the commit footer