Audit Backlog
Последнее обновление: 24 мая 2026Отдельный практический артефакт к AI Project Hardening Protocol.

AUDIT_BACKLOG.md

Готовый шаблон backlog для управляемых исправлений после AI-аудита.

Используйте этот шаблон, когда находок уже много и их нужно превратить в понятный roadmap, а не в хаотичный список замечаний. Все critical и high находки должны получить задачу, статус и владельца.

Шаблон

AUDIT_BACKLOG.md

Открыть rawСкачать .md
# Audit Backlog

Практический шаблон для фиксации находок после AI Project Hardening Protocol.

## Как использовать

- Не просите AI "починить все" сразу.
- Сначала перенесите все находки в backlog.
- Отдельно выделите Critical и High.
- У каждой задачи должен быть владелец, статус и evidence.
- Accepted risks фиксируйте явно, а не в переписке.

## Статусы

- Todo
- In progress
- Waiting review
- Fixed
- Verified
- Deferred
- Accepted risk

## Critical

| ID | Category | Task | Risk | Evidence | Status | Owner |
|---|---|---|---|---|---|---|
| SEC-001 | Security |  |  |  | Todo |  |
| PAY-001 | Payments |  |  |  | Todo |  |

## High

| ID | Category | Task | Risk | Evidence | Status | Owner |
|---|---|---|---|---|---|---|
| DEP-001 | Supply Chain |  |  |  | Todo |  |
| LEGAL-001 | Legal |  |  |  | Todo |  |

## Medium

| ID | Category | Task | Risk | Evidence | Status | Owner |
|---|---|---|---|---|---|---|
| QA-001 | Device QA |  |  |  | Todo |  |
| TEST-001 | Tests |  |  |  | Todo |  |

## Low

| ID | Category | Task | Risk | Evidence | Status | Owner |
|---|---|---|---|---|---|---|
| DOC-001 | Documentation |  |  |  | Todo |  |

## Accepted risks

| ID | Risk | Why accepted | Review date | Owner |
|---|---|---|---|---|
| RISK-001 |  |  |  |  |

## Категории

- Security
- Supply Chain
- Architecture
- Tests
- Monitoring
- DevOps
- Documentation
- UX
- Performance
- Data / Privacy
- AI / Cost
- Legal
- Compliance
- Payments
- Fiscalization
- Device QA
- Browser QA
- Accessibility
- Analytics / Cookies
- Marketing consent

## Мини-правила

- Critical блокируют merge или deploy до явного решения.
- High должны иметь план исправления до production.
- Medium и Low можно планировать, но не терять.
- Если риск принят, это должно быть осознанное решение с датой пересмотра.
Связанные материалы

Сначала протокол. Потом шаблон. Потом проверяемые исправления.

Если нужен полный контекст — вернитесь к AI Project Hardening Protocol. Если вы еще только начинаете проект, сначала откройте стартовый протокол для vibe coding.