List Issues
Present code issues as a table using the representation supported by the active agent or interface. Use exactly these columns in order: Issue ID, Type, Description, and Status.
Build the Table
- Assign IDs in discovery order as
I1,I2,I3, and so on. - Keep each ID bound to the same underlying issue across every table update. Match by the concern and location, not by exact wording or row position.
- Never renumber or reuse an ID. Assign each new issue the number after the highest ID already used in the conversation.
- Keep addressed issues in full-table updates and change only their status. If the user requests a filtered view, omit excluded rows but reserve their IDs.
- Order rows by the numeric part of the issue ID to minimize churn between updates.
Fill the Columns
- Issue ID: Use the issue's stable
I<number>identifier. - Type: Use
Critical,Important,Minor, orSuggestion.Critical: Security, data loss, severe correctness, or release-blocking risk.Important: A meaningful defect or risk that should be addressed.Minor: A limited-impact problem or maintainability concern.Suggestion: An optional improvement with no current defect.
- Description: Write one short, clear sentence that explains the problem and its impact. Include a known source location as
`path/to/file.ext:line`; omit the location rather than guessing it. Keep the description on one line. - Status: Use
Open,Fixed,Won't Fix, orFalse Positive. Default new issues toOpen, and preserve an explicit status supplied by the user.
Update Existing Issues
- Update the existing row when its wording, type, location, or status changes without changing the underlying issue.
- Create a new ID when a finding has a materially different cause or impact, even if it is near an existing issue.
- Keep the earliest ID when duplicate findings are consolidated, and mark the later duplicate as
False Positiverather than removing or reusing its ID. - Do not add a separate file or line column; keep source references in the description.