# Quality Grades
<!-- Purpose: Track code quality across domains and layers.
     Review and update grades quarterly (or after major changes).
     This gives agents context about which areas need extra care
     and which areas are solid enough for faster iteration.

     Grading Scale:
       A  = Excellent: well-tested, clean, documented, few bugs
       B  = Good: solid tests, minor tech debt, occasional issues
       C  = Adequate: works but has known gaps, moderate debt
       D  = Poor: fragile, undertested, frequent bugs
       F  = Critical: actively broken or dangerous, needs immediate attention

     Usage:
       - Agents should exercise extra caution in D/F areas
       - Agents can move faster in A/B areas
       - Use this to prioritize refactoring and testing efforts
-->

## Last Reviewed: [YYYY-MM-DD]

## Overall Score: [GRADE]

## By Domain

| Domain              | Grade | Test Coverage | Tech Debt | Notes                       |
|---------------------|-------|---------------|-----------|------------------------------|
| [DOMAIN_1 -- e.g., Authentication] | [A-F] | [e.g., 92%] | [Low/Med/High] | [e.g., "Well-tested, stable"] |
| [DOMAIN_2 -- e.g., Billing]        | [A-F] | [e.g., 78%] | [Low/Med/High] | [e.g., "Azure Service Bus retry policy needs error handling work"] |
| [DOMAIN_3 -- e.g., Notifications]  | [A-F] | [e.g., 45%] | [Low/Med/High] | [e.g., "Added quickly, needs test coverage"] |
| [DOMAIN_4]          | [A-F] | [%]          | [Level]    | [Notes]                      |
| [DOMAIN_5]          | [A-F] | [%]          | [Level]    | [Notes]                      |

## By Layer

| Layer               | Grade | Notes                                          |
|---------------------|-------|-------------------------------------------------|
| [LAYER_1 -- e.g., UI Components]    | [A-F] | [e.g., "Storybook coverage good, a11y needs work"] |
| [LAYER_2 -- e.g., API Routes]       | [A-F] | [e.g., "Well-structured, good error handling"]     |
| [LAYER_3 -- e.g., Business Logic]   | [A-F] | [e.g., "Core is solid, edge cases undertested"]    |
| [LAYER_4 -- e.g., Data Access]      | [A-F] | [e.g., "N+1 queries in reports module"]            |
| [LAYER_5 -- e.g., Infrastructure]   | [A-F] | [e.g., "CI/CD reliable, monitoring gaps"]          |

## By Quality Dimension

| Dimension           | Grade | Notes                                          |
|---------------------|-------|-------------------------------------------------|
| Test Coverage       | [A-F] | [e.g., "82% overall, but critical paths at 95%"]  |
| Type Safety         | [A-F] | [e.g., "Strict mode enabled, 3 remaining `any` types"] |
| Error Handling      | [A-F] | [e.g., "Inconsistent -- some areas use Result, others throw"] |
| Documentation       | [A-F] | [e.g., "API docs current, internal docs stale"]   |
| Performance         | [A-F] | [e.g., "P99 within targets, reports page is slow"] |
| Security            | [A-F] | [e.g., "Last audit clean, dependency scanning active"] |
| Accessibility       | [A-F] | [e.g., "WCAG 2.1 AA partial compliance"]          |
| Observability       | [A-F] | [e.g., "Good logging, missing distributed tracing"] |

## Known Issues by Priority

### Critical (Fix Immediately)
- [ ] [ISSUE -- e.g., "Race condition in concurrent invoice generation (#1234)"]

### High (Fix This Quarter)
- [ ] [ISSUE -- e.g., "Reports module has N+1 queries under load (#1189)"]
- [ ] [ISSUE]

### Medium (Fix When Touching Related Code)
- [ ] [ISSUE -- e.g., "Notification templates use string concatenation, not template engine (#998)"]
- [ ] [ISSUE]

### Low (Backlog)
- [ ] [ISSUE -- e.g., "Rename `usr` table to `users` (#456)"]
- [ ] [ISSUE]

## Agent Instructions by Grade

<!-- Give agents explicit guidance based on quality grades. -->

**Working in A/B areas:**
- Standard development pace
- Trust existing patterns -- follow them
- [CUSTOM_INSTRUCTION]

**Working in C areas:**
- Add tests for any code you touch (boy scout rule)
- Check for existing test gaps before adding features
- [CUSTOM_INSTRUCTION]

**Working in D/F areas:**
- Write tests BEFORE making changes
- Keep changes minimal and focused
- Flag any surprises in the PR description
- Consider whether refactoring should precede the feature
- [CUSTOM_INSTRUCTION]

## Changelog

| Date       | Change                                             |
|------------|-----------------------------------------------------|
| [DATE]     | [e.g., "Initial grading"]                           |
| [DATE]     | [e.g., "Upgraded Billing from C to B after test push"] |
| [DATE]     | [e.g., "Downgraded Notifications to D after outage"]  |