S3
S3SuiteDocs
Docs/Bug Reports

Bug Reports

Engineering-side bug tracker tied to a project, with severity, status, and attachments

Last updated: 2026-05-26

Bug Reports is the engineering-side defect tracker built into S3Suite. It's the place to log defects found in design, firmware, hardware revisions, or test runs - distinct from customer-facing Support tickets (which are public-side issues that may or may not turn into a real bug).

Open it from any project: sidebar -> Engineering -> Bug Reports, or visit /projects//engineering/bug-reports.

When to use it (vs Support, vs RMA, vs Risk)

Use thisWhen
Bug ReportInternal engineering defect. "Schematic rev B has a missing pull-up on GPIO 12." "Firmware v1.4 crashes after 6 hours of uptime." Reproducible. Owned by the engineering team.
Support TicketA customer hit a problem in the field. May or may not be a real bug yet. See Support & Ticketing.
RMAA physical device came back. Use RMA, 5-Why & Knowledge Base.
RiskA possible future failure mode. Use Risk Management.
If a customer ticket reveals a real bug, file a Bug Report and link the two in the description.

Concepts

FieldDescription
Bug numberAuto-assigned at creation (e.g. BUG-2026-014). Stable, never reused.
TitleShort label. Treat it as the chat-channel summary - one sentence.
DescriptionMarkdown. The detail: repro steps, expected vs actual, screenshots, log lines.
SeverityLow / Medium / High / Critical. The impact if the bug ships.
StatusOpen / Investigating / In progress / Fixed / Won't fix / Duplicate / Cannot reproduce.
Affected versionThe product or firmware version the bug was found in.
EnvironmentFree-text - hardware revision, firmware build, OS, vendor, test fixture.
AttachmentsFiles (logs, screenshots, scope traces, oscilloscope captures).
ReporterAuto-filled with whoever created the bug.
Assigned toThe engineer responsible for fixing it.

Quick start (2 minutes)

1. Open the tracker

  1. Open your project
  2. Sidebar -> Engineering -> Bug Reports

2. File your first bug

  1. Click New Bug Report
  2. Fill in:
- Title - the one-sentence summary - Description - repro steps, expected vs actual - Severity - Affected version (e.g. "PCB Rev B" or "Firmware v1.4.2") - Environment (e.g. "Lot L-2026-042, FW build #1473, vendor: ACME")
  1. Optionally attach files (drop them on the upload area)
  2. Click Create
The bug appears in the list with its auto-assigned bug number.

3. Triage during a sync

  1. Open Bug Reports
  2. Sort by Severity descending; filter status to Open
  3. For each: assign an owner, change status to Investigating or In progress, or close as Duplicate / Won't fix with a note

4. Close the bug

  1. Open the bug detail
  2. Move status to Fixed, Won't fix, Duplicate, or Cannot reproduce
  3. Add a closing note in the description (or a comment on the bug) explaining what shipped or why the bug is being parked

Workflow: bug found in a test report

  1. The tester sees a failed step in a device test report (Manufacturing -> Devices -> device -> Test reports)
  2. They copy the relevant context (variant, lot, firmware version, the failed step's actual value)
  3. Open Bug Reports -> New Bug Report
  4. Paste the context into the description; attach the test report's log file
  5. Set severity based on whether this blocks the lot
  6. Submit; ping the firmware lead in the bug's assigned-to

Workflow: bug fix tied to a commit

  1. Engineer fixes the bug in the Revision Control commit
  2. In the commit message, reference the bug number (Fixes BUG-2026-014)
  3. In the bug report, paste the commit URL into a comment or the resolution note
  4. Move bug status to Fixed
The audit trail (bug -> commit -> release -> lot) makes it possible to answer "which lots shipped with this fix?" three years later. See Hardware Revision Control for the release flow.

Reference

Severity definitions (default)

  • Low - cosmetic, easily worked around, no production impact.
  • Medium - noticeable, has a workaround, may affect customer satisfaction.
  • High - significant impact, blocks a meaningful use case, no easy workaround.
  • Critical - blocks shipping, customer safety concern, or data integrity issue.

Status flow

  • New bugs default to Open.
  • Once an engineer picks it up: Investigating (still reproducing / diagnosing) -> In progress (fix being written) -> Fixed (shipped or merged).
  • Terminal "we won't fix this" states: Won't fix (intentional), Duplicate (link to the original), Cannot reproduce (re-open if a fresh repro arrives).

Common pitfalls

  • "The same bug got filed three times." Use the duplicate status. Link the duplicates to the master so the count is honest.
  • "The bug list is full of stale Open items." Schedule a weekly triage. Drop low-severity open bugs to Won't fix if they've been open more than three months without a customer report.
  • "I marked it Fixed but the customer is still seeing it." The fix may not have shipped yet. Open the bug, link the Revision Control commit, and check which release / lot included the fix. The customer's device may be on an older firmware.

Related docs

ChecklistsProvisioning Profiles