Bug Report Guideline
Department
Summary
How Kiluth reports and tracks bugs in Kiluth Tasks: one task per bug, chained to a batch task for the round (e.g. one UAT round). Required fields: evidence, steps to reproduce, expected vs actual. Consistent format for UAT, QA, and production bugs.
Table of Contents
| Section | |
|---|---|
| 1 | Summary |
| 2 | Purpose |
| 3 | Scope |
| 4 | How Bugs Are Filed |
| 5 | Who Creates the Batch |
| 6 | What the AE Does Before Handing Over |
| 7 | Required Content of a Bug Task |
| 8 | Example: A Full UAT Round |
| 9 | Closing a Round |
| 10 | Related |
Purpose
This guideline defines how Kiluth reports and tracks bugs using Kiluth Tasks. Each bug is its own task. Bugs found together are grouped by chaining them to a batch task for that round.
| Outcome |
|---|
| Consistent, actionable bug reports that include context, evidence, and reproduction steps so Technology can fix issues efficiently. |
Scope
| Included | |
|---|---|
| 1 | How a bug task and its batch task are structured |
| 2 | Required content: evidence, steps to reproduce, expected vs actual, notes |
| 3 | Who works a bug up before it reaches Development |
This guideline applies to bugs found during UAT, QA, or production. For UAT workflow and acceptance sign-off, see Client Acceptance (UAT) & Go-Live Guideline.
How Bugs Are Filed
One bug is one task. Bugs found in the same round are grouped by a batch task that they all chain to.
| Rule | |
|---|---|
| 1 | One task per bug, dept: technology |
| 2 | One batch task per round (one UAT round, one release, one incident sweep) |
| 3 | Each bug task Blocks the batch task |
| 4 | The batch task Blocks the project |
## Chain
Blocks: [[2026-09-24T09-00-technology-uat-round-2-bug-batch]]And in the batch task:
## Chain
Blocks: [[PROJ-0000]]The batch is not a container. Nothing lives inside it. It is an ordinary task that the bug tasks point at, which is what makes the round visible as one thing on the dependency graph and gives it a single place to sign off.
Why one task per bug
Each bug needs to be owned, moved and finished independently. A separate task gives every bug its own assignee, its own section, its own priority, and its own automatic hygiene check. A single task holding a list of bugs has one assignee and one status, so the work cannot be split across people and nobody can see which bug is with whom.
This matters more as Kiluth grows, not less. The structure is the same whether one person or twenty are fixing the round.
Who Creates the Batch
The PM creates the batch task and the bug tasks under it. That holds however the bug was found. It keeps one owner and one place bugs land, instead of bugs living in a chat message.
| Where the bug came from | Path | |
|---|---|---|
| 1 | The client, during UAT or after go-live | Client reports it to the AE. AE reproduces and works it up (below), then hands the worked-up report to the PM. PM creates the batch and the bug tasks, and assigns them to Development. |
| 2 | Inside Kiluth, from QA, a developer, or a review | The person who found it works it up to the same standard and gives it to the PM. PM creates the batch and the bug tasks, and assigns them to Development. |
What the AE Does Before Handing Over
A client’s report is rarely a usable bug report. The AE does the first pass, not a forward. Hand over only once you can answer these:
| Before it reaches the PM | |
|---|---|
| 1 | Reproduce it. Confirm it actually happens, and on what: device, browser, screen size, which environment. |
| 2 | Write the three required lines: steps to reproduce, expected result, actual result. |
| 3 | Attach evidence, a screenshot or recording, annotated where it helps. |
| 4 | Check it is a bug. Not user error, not already reported, not something that was never in scope. |
| 5 | Group it. Several findings from one UAT round travel together as one batch, not as separate messages. |
If the AE cannot reproduce it, that goes to the PM too. “Reported, not reproducible, here is what I tried” is a useful report. Guessing is not.
| # | Note |
|---|---|
| 1 | The AE is the client’s point of contact and does the first pass. Forwarding a raw client message to the PM is not a handover, it moves the work rather than doing it. |
| 2 | Development fixes what is in the task. If a reported item turns out to be new scope rather than a defect, it stops being a bug and follows the Change Request Workflow Guideline. |
Required Content of a Bug Task
A bug task follows the Task Usage Guideline like any other task, so the title names the fix and implies when it is done. The body must carry four things.
| Required | |
|---|---|
| 1 | Evidence, a screenshot or recording, annotated where it helps |
| 2 | Steps to reproduce, numbered |
| 3 | Expected result |
| 4 | Actual result |
Add Notes for anything that narrows it down: device, browser, screen width, whether it reproduces every time.
Context that is the same for every bug in the round — environment, build version, URLs — goes on the batch task, not repeated in each bug.
No personal data. Do not paste a client contact’s name, email or phone into a bug task, including inside a screenshot or a console log. Rule 3 of the Task Usage Guideline applies here in full.
Example: A Full UAT Round
The batch task
| Field | Content |
|---|---|
| Title | Fix the UAT round 2 bugs for [Client Name] |
| dept | technology |
| section | In Progress |
| project | PROJ-0000 |
| Description | Context • Project/Module: [Client] Web / Checkout + Footer • Environment: UAT (client-facing) • Build/version: v1.8.3 Links • Staging/UAT URL: https://uat.example.com/checkout • Figma: https://figma.com/file/XXXX (Checkout flow) Done when every bug chained to this task is fixed and the client has re-tested. |
| Chain | Blocks: [[PROJ-0000]] |
Bug task 1
| Field | Content |
|---|---|
| Title | Stop the checkout CTA button overlapping the footer on mobile |
| assignee | firstname.lastname@kiluth.com |
| Description | Evidence • checkout-footer-overlap.png (boxed in red) • Recording: https://loom.com/share/XXXX Steps to reproduce 1) Go to https://uat.example.com/checkout 2) Scroll to bottom 3) Observe the “Pay now” button area Expected • CTA sits above the footer with 16px spacing and is fully clickable Actual • CTA overlaps the footer; bottom 20% is not clickable Notes • iPhone 13 / iOS 17 / Safari • Only at mobile width below 390px |
| Chain | Blocks: [[2026-09-24T09-00-technology-uat-round-2-bug-batch]] |
Bug task 2
| Field | Content |
|---|---|
| Title | Fix the double-applied coupon discount on the checkout total |
| assignee | firstname.lastname@kiluth.com |
| Description | Evidence • coupon-total-mismatch.png (totals highlighted) • Console log screenshot (no personal data) Steps to reproduce 1) Add item A (฿100) and item B (฿200) 2) Apply coupon “SAVE10” 3) Observe the total Expected • Total = (100 + 200) − 10% = ฿270 Actual • Total shows ฿260, discount applied twice Notes • Desktop Chrome • Possibly recalculation on re-render |
| Chain | Blocks: [[2026-09-24T09-00-technology-uat-round-2-bug-batch]] |
Bug task 3
| Field | Content |
|---|---|
| Title | Reposition the login error toast so it does not cover the email label |
| assignee | firstname.lastname@kiluth.com |
| Description | Evidence • login-toast-cover-label.png (arrow and note) Steps to reproduce 1) Go to /login 2) Submit the empty form 3) Observe the toast position Expected • Toast appears below the header and does not cover form labels Actual • Toast overlays the email label Notes • Desktop Chrome 122 • Reproduces every time |
| Chain | Blocks: [[2026-09-24T09-00-technology-uat-round-2-bug-batch]] |
On the graph, the three bugs fan into the batch and the batch points at the project. The round is one shape you can look at.
Closing a Round
| Each bug | Moves to tasks/done/ as it is fixed, independently of the others |
| The batch | Stays open until the last bug is done and the client has re-tested, then moves to tasks/done/ |
| Not fixed this round | A deferred bug is unchained from the batch and chained to the next one, or straight to the project. Do not close a batch with unfinished bugs still pointing at it |
Related
| Document | Purpose |
|---|---|
| Task Usage Guideline | The rules every task follows, including bug tasks |
| Client Acceptance (UAT) & Go-Live Guideline | UAT workflow and acceptance sign-off |
| Kiluth Tasks Usage | How Kiluth Tasks is built, the task file, and the checker |
| Go-Live & Incident Response Guideline | Go-live execution and incident handling |