# Severity Rubric — Embedded Agent Bridge

> Stage-aware classification for bugs, findings, and issues. Use this rubric when triaging, reviewing, or writing issues.

**Current stage:** Beta (open source, used by developers and LLM agents)

---

## Severity Levels

### P0 — Critical (fix before anything else)
- Security vulnerability (secrets exposed, injection, auth bypass)
- **Hardware damage risk** — debug probe command that could brick a device, corrupt flash, or damage hardware
- Data loss or corruption (log files, device flash, trace captures)
- Complete system unavailability (daemon won't start, CLI broken for all commands)
- Active exploit or breach

**Response:** Stop current work. Fix immediately. No other changes until resolved.

**EAB-specific P0 triggers:**
- eabctl flash writing to wrong address or chip (can brick devices)
- Debug probe command with no safety check that could erase production firmware
- Port management failure leaving serial ports locked (blocks all flashing)
- Fault analysis returning incorrect fault type (leads to wrong debugging path)

---

### P1 — High (fix in current session or next session)
- Feature broken for ALL users (eabctl command returns wrong data, daemon crash loop)
- Hardware interaction correctness issue (wrong baud rate, wrong chip detection)
- CI/CD pipeline broken (tests can't run)
- Regression test runner producing false passes

**Response:** High priority. Do not let it sit across multiple sessions.

---

### P2 — Medium (fix in next planned session)
- Feature degraded — workaround exists (e.g., RTT works via J-Link but not probe-rs)
- Performance regression in daemon or CLI
- Flaky hardware test
- Missing validation that could cause confusing error messages

**Response:** Add to current sprint. Document the workaround.

---

### P3 — Low (backlog)
- Cosmetic issue (output formatting, help text)
- Code quality (duplication, dead code, style inconsistency)
- Minor UX annoyance with no functional impact
- Any finding in **dormant or planned code** (see cap rule below)
- Test coverage gap for an untested happy path

**Response:** Add to backlog. Will be addressed during cleanup sessions.

---

## Dormant Code Cap Rule

**Any finding in code that is not yet deployed or in use is automatically capped at P3**, regardless of the theoretical severity.

Rationale: dormant code hasn't hurt anyone and may change before launch. Over-engineering pre-launch features burns time better spent on real user impact.

Exceptions: hardcoded secrets in dormant code are still P0 — they could leak via git history. Hardware safety issues in dormant code that could be accidentally triggered are P1.

---

## Hardware Safety Modifier

Because EAB interacts with physical hardware through debug probes:

| Risk | Classification | Rationale |
|------|---------------|-----------|
| Could brick a device | P0 | Hardware damage is irreversible for some chips |
| Could corrupt flash | P1 | Recoverable but time-consuming |
| Could lock a serial port | P1 | Blocks all development until resolved |
| Wrong chip detection | P1 | Could flash wrong firmware to wrong device |
| Incorrect fault decode | P2 | Misleading but not dangerous |

---

## Stage Modifiers

| Stage | P0 | P1 | P2 | P3 |
|-------|----|----|----|----|
| Pre-launch (no real users) | Fix immediately | This week | Backlog | Skip |
| Beta (current — open source) | Fix immediately | Today | This sprint | Backlog |
| GA (production traffic) | Fix immediately | Today | This sprint | Quarterly cleanup |

---

## How to Use

When writing an issue or action item:
1. Identify which stage the affected code is in (live / dormant / planned)
2. Apply the cap rule if dormant
3. Check the hardware safety modifier — does this touch physical hardware?
4. Classify using the level descriptions above
5. Add the stage modifier

When an agent reports findings, ask: "Is this in code that's actually running? Could it damage hardware?"
