Issue Lifecycle & Types
Not all work is the same. Here's how different types of work enter and flow through the system.
| Type | Origin | Entry Point | Lifecycle |
|---|---|---|---|
| Feature | Sales, customer, or internal idea | Stage 1 (Opportunity) | Full 6-stage cycle |
| Bug | Customer report, monitoring alert, QA | Stage 2 (Spec — abbreviated) | Spec → Build → Review → Ship |
| Enhancement | Customer request, internal improvement | Stage 2 (Spec) | Spec → Build → Review → Ship |
| Tech Debt | Developer, code review, tech lead audit | Stage 3 (Build) | Build → Review → Ship |
Bug Report Template
Bugs use a streamlined spec template focused on reproduction:
markdown
## Bug Summary
{What's broken? One sentence.}
## Steps to Reproduce
1. Go to {page/endpoint}
2. Perform {action}
3. Observe {unexpected behavior}
## Expected Behavior
{What should happen instead}
## Actual Behavior
{What actually happens — include screenshots, error logs, HTTP status codes}
## Environment
- App version / commit: {hash}
- BTP subaccount: {name}
- Browser / client: {details}
- User role: {role}
## Impact
{Who is affected? How many users? Is there a workaround?}Feature Requests from Customers
When a customer requests a feature, the flow is: Sales captures it → Functional qualifies it → Tech Lead prioritizes it. All in GitLab. The sales person creates the issue with the type::enhancement and stage::opportunity labels. The functional consultant evaluates feasibility and writes the spec. The tech lead assigns it to a milestone based on priority and capacity.