Verify that the system is safe when users do messy, real-world things. Real users accidentally click delete, upload wrong files, retry operations too early, use confusing UI controls, and panic when something looks broken. This audit ensures that human mistakes cause minimal damage and are recoverable.

## Key Points

1. Enumerate every delete action in the UI:
- Delete project
- Delete asset
- Delete scene
- Remove collaborator
- Delete account
- Clear history
- Remove API key
2. For each, test the delete flow.
- [ ] Every destructive action has a confirmation dialog.
- [ ] High-impact deletions (project, account) require type-to-confirm.
- [ ] Soft delete is used where possible (30-day trash).

## Quick Example

```
TOUCH-SPECIFIC CHECKS:
[ ] Destructive actions require tap (not swipe-to-delete without confirm)
[ ] Touch targets for destructive buttons are not adjacent to safe buttons
[ ] No destructive action triggered by long-press without secondary confirm
[ ] Pull-to-refresh does not trigger re-generation or re-processing
```

Human Error & Operator Safety Audit

Purpose

Verify that the system is safe when users do messy, real-world things. Real users accidentally click delete, upload wrong files, retry operations too early, use confusing UI controls, and panic when something looks broken. This audit ensures that human mistakes cause minimal damage and are recoverable.

This is not a UX polish audit. This is a safety audit: when a user makes a mistake, does the system protect them or punish them?

---

Scope

Error Type	What We Test
Accidental destructive action	Can the user accidentally destroy important data?
Wrong file/data uploaded	Does bad input cause corruption or just rejection?
Premature retry	Does retrying while a job is still running cause problems?
Confusing UI leading to wrong action	Are destructive actions distinguishable from safe ones?
Copy-paste errors	Do malformed inputs crash the system or degrade gracefully?
Abandoned workflow	Does starting and not finishing leave broken state?
Simultaneous conflicting actions	Does the UI prevent or handle contradictory user intents?

---

Risk Pattern Table

Pattern	What It Hits	Risk	Symptom
Delete without confirmation	Data loss	CRITICAL	Single click permanently destroys project/assets
No undo/soft-delete	Data loss	HIGH	Deleted data is irrecoverable; no trash/archive
No input validation on upload	Data integrity	HIGH	Wrong file type silently processed; garbage output
Retry button during active processing	Data integrity	HIGH	Duplicate work, wasted API calls, conflicting results
Destructive button looks like safe button	UX, Data loss	HIGH	"Delete All" styled same as "Save"; user clicks wrong one
No "are you sure?" for bulk operations	Data loss	HIGH	"Delete selected" on 500 items with no confirmation
Error message doesn't explain what to do	UX	MEDIUM	"Error occurred" with no guidance on recovery
Form loses data on navigation	UX	MEDIUM	Back button or accidental navigation discards unsaved work
No rate limit on expensive user action	Cost	HIGH	User clicks "Generate" 50 times out of frustration
Silent failure looks like success	Data integrity	HIGH	No error shown; user assumes action worked

---

Concrete Test Cases

TEST-HE-001: Accidental Delete Path Analysis

Objective: Map every delete path in the system and verify safeguards exist.

Steps:

1. Enumerate every delete action in the UI:
   • Delete project
   • Delete asset
   • Delete scene
   • Remove collaborator
   • Delete account
   • Clear history
   • Remove API key
2. For each, test the delete flow.

Safeguard Checklist Per Delete Action:

| Delete Action | Confirmation Dialog? | Type-to-Confirm? | Soft Delete? | Undo Available? | Recovery Path? |
|--------------|--------------------|--------------------|-------------|-----------------|----------------|
| Delete project | [ ] | [ ] (for > 5 assets) | [ ] | [ ] | [ ] |
| Delete asset | [ ] | [ ] | [ ] | [ ] | [ ] |
| Delete scene | [ ] | [ ] | [ ] | [ ] | [ ] |
| Remove collaborator | [ ] | [ ] | N/A | [ ] (re-invite) | [ ] |
| Delete account | [ ] | [ ] (type email) | [ ] | [ ] (grace period) | [ ] |
| Clear all data | [ ] | [ ] (type "DELETE") | [ ] | [ ] | [ ] |

Pass Criteria:

• Every destructive action has a confirmation dialog.
• High-impact deletions (project, account) require type-to-confirm.
• Soft delete is used where possible (30-day trash).
• Undo is available for at least 30 seconds after deletion.
• Recovery path is documented for hard deletes (backups, support contact).
• Bulk delete has a count confirmation ("Delete 47 assets? Type '47' to confirm").

Fail Criteria:

• Any destructive action happens on single click with no confirmation.
• No soft delete or undo for any data.
• Bulk delete has the same confirmation as single delete (no count check).

---

TEST-HE-002: Malformed Data Upload Handling

Objective: Verify that uploading wrong/malformed data is handled gracefully.

Steps:

1. For every upload endpoint, attempt:
   • Wrong file type (e.g., .exe instead of .png)
   • Corrupted file (valid extension, invalid content)
   • Oversized file (2x the limit)
   • Empty file (0 bytes)
   • File with special characters in name
   • File with extremely long name (255+ characters)

Pass Criteria Per Upload:

| Input | Expected Behavior | Status |
|-------|-------------------|--------|
| Wrong type (.exe for image) | Rejected with "Unsupported file type. Allowed: .png, .jpg, .webp" | [ ] |
| Corrupted file | Rejected with "File appears corrupted. Please try a different file." | [ ] |
| Oversized file | Rejected BEFORE upload completes. "File exceeds 50MB limit." | [ ] |
| Empty file | Rejected with "File is empty." | [ ] |
| Special chars in name | Sanitized filename; upload succeeds | [ ] |
| Long filename | Truncated to safe length; upload succeeds | [ ] |
| Double upload (same file) | Deduplicated or clearly labeled (not silent duplicate) | [ ] |

Fail Criteria:

• Wrong file type is silently accepted and causes downstream errors.
• Corrupted file causes server crash or unhandled exception.
• Oversized file is uploaded completely before rejection (wasted bandwidth).
• Any upload input causes 500 Internal Server Error.

Validation Implementation Check:

[ ] File type validated by content (magic bytes), not just extension
[ ] File size checked at upload start (Content-Length header), not just at end
[ ] Filename sanitized (special characters removed, length limited)
[ ] Upload to temporary location first, then validate, then move to permanent
[ ] Failed uploads cleaned up (temp files removed)
[ ] Client-side validation for immediate feedback (in addition to server-side)

---

TEST-HE-003: Retry Before Prior Job Resolves

Objective: Verify that retrying an operation while the original is still running is handled safely.

Steps:

1. Trigger a long-running operation (generation, processing).
2. Before it completes, click the retry/regenerate button.
3. Observe behavior.

Pass Criteria (one of):

• Block: "Operation already in progress. Please wait." (retry disabled).
• Cancel + restart: Previous operation cancelled, new one started.
• Queue: New operation queued to run after current one completes.

Fail Criteria:

• Two operations run simultaneously for the same resource.
• Results conflict or overwrite each other.
• No feedback to user about existing in-progress operation.
• Double billing on external API.

UI Guard Implementation:

[ ] Button disabled while operation is in-progress
[ ] Polling/websocket keeps button state accurate
[ ] If button is somehow clicked (race condition), server rejects duplicate
[ ] Clear visual indicator of in-progress state
[ ] Estimated time remaining shown (if possible)
[ ] Cancel button available (instead of retry)

---

TEST-HE-004: Asset Replacement Messaging

Objective: Verify that replacing/overwriting an existing asset is clearly communicated.

Steps:

1. Generate or upload Asset A.
2. Regenerate or re-upload (replacing Asset A).
3. Check: what does the user see?

Pass Criteria:

• User is warned: "This will replace the existing asset. Continue?"
• Previous version is preserved (versioning).
• If no versioning, user is told: "This action cannot be undone."
• After replacement, UI clearly shows the new version.
• Thumbnail/preview updates to reflect new content.

---

TEST-HE-005: Undo, Soft-Delete, and Versioning Verification

Objective: Verify that the system provides recovery mechanisms for user mistakes.

Steps:

1. Delete an asset. Can it be undone?
2. Delete a project. Can it be recovered?
3. Edit settings. Can previous settings be restored?
4. Regenerate an asset. Can the previous version be accessed?

Recovery Mechanism Matrix:

| Action | Undo (< 30s)? | Soft Delete? | Trash/Archive? | Versioning? | Backup? |
|--------|-------------|-------------|---------------|------------|---------|
| Delete asset | [ ] | [ ] | [ ] | N/A | [ ] |
| Delete project | [ ] | [ ] | [ ] | N/A | [ ] |
| Edit settings | [ ] | N/A | N/A | [ ] | [ ] |
| Regenerate asset | N/A | N/A | N/A | [ ] | [ ] |
| Remove collaborator | [ ] | N/A | N/A | N/A | [ ] |
| Bulk operation | [ ] | [ ] | [ ] | [ ] | [ ] |

Minimum Acceptable Recovery:

Tier 1 (must have for all systems):
  [ ] Confirmation dialog on all destructive actions
  [ ] Soft delete with 30-day retention for projects and assets
  [ ] Error messages include what to do next

Tier 2 (recommended for production systems):
  [ ] Undo button for recent actions (30-second window)
  [ ] Trash/archive with restore capability
  [ ] Version history for generated assets
  [ ] Unsaved changes warning on navigation

Tier 3 (ideal for premium systems):
  [ ] Full audit trail with point-in-time recovery
  [ ] Diff view for settings changes
  [ ] Batch undo for bulk operations
  [ ] Keyboard shortcut for undo (Ctrl+Z)

---

TEST-HE-006: Destructive Action Distinguishability

Objective: Verify that destructive actions are visually distinct from safe actions.

Steps:

1. Review every page with both safe and destructive buttons.
2. Check visual differentiation.

UI Safety Checklist:

[ ] Delete buttons use red/danger color (not blue/primary)
[ ] Delete buttons are not adjacent to save/confirm buttons
[ ] Destructive actions are in a separate section (e.g., "Danger Zone")
[ ] Bulk destructive actions have higher confirmation bar than single
[ ] Keyboard shortcuts do NOT trigger destructive actions
[ ] Destructive modal has "Cancel" as the default/focused button
[ ] Confirmation text clearly states what will be destroyed
[ ] Confirmation includes count for bulk operations
[ ] No auto-submit forms that could trigger destructive actions

---

TEST-HE-007: Abandoned Workflow Cleanup

Objective: Verify that starting and not finishing a workflow does not leave broken state.

Steps:

1. Start a multi-step wizard/workflow.
2. Complete step 1 and 2 of 5.
3. Close the browser tab.
4. Re-open the application.

Pass Criteria:

• No partial/broken records created (changes not committed until final step).
• OR partial progress is saved and resumable.
• No resources locked/reserved by the abandoned workflow.
• No orphaned temporary files from the abandoned steps.

---

TEST-HE-008: Error Recovery Guidance

Objective: Verify that every error message tells the user what to do next.

Steps:

1. Trigger various error conditions.
2. For each error, evaluate the message.

Error Message Quality:

BAD:  "Error"
BAD:  "Something went wrong"
BAD:  "Request failed"
OK:   "Upload failed. Please try again."
GOOD: "Upload failed: file exceeds 50MB limit. Please resize the image and try again."
BEST: "Upload failed: file exceeds 50MB limit. [Resize Image] [Choose Different File] [Contact Support]"

Error Message Checklist:

[ ] Every error tells the user WHAT happened (specific, not generic)
[ ] Every error tells the user WHAT TO DO (actionable next step)
[ ] Every error is displayed (no swallowed errors that leave user confused)
[ ] Error display persists until dismissed (not auto-hide after 3 seconds)
[ ] Error state is recoverable (user can retry without refreshing)
[ ] Errors do not expose internal details to users (no stack traces)
[ ] Errors include support/help links for complex failures

---

TEST-HE-009: Rate Limiting on User-Triggered Expensive Actions

Objective: Verify that frustrated users cannot cause damage by repeating actions rapidly.

Steps:

1. Click "Generate" 10 times rapidly.
2. Submit a form 10 times rapidly.
3. Click "Delete" and "Cancel" alternately 5 times.

Pass Criteria:

• Only one generation triggered (button disabled after first click).
• Only one form submission processed (subsequent ignored or queued).
• Delete/cancel rapid alternation does not leave inconsistent state.
• Rate limit returns friendly message (not 429 with no explanation).
• User cannot bypass UI rate limits via API (server-side limits exist).

---

TEST-HE-010: Navigation Safety

Objective: Verify that unsaved work is not lost on accidental navigation.

Steps:

1. Start editing a form (change a field but don't save).
2. Click back button / navigate away / close tab.

Pass Criteria:

• Browser "unsaved changes" warning appears.
• Back button triggers confirmation if form is dirty.
• Closing tab triggers beforeunload warning.
• If the user confirms navigation, partial data is cleaned up.
• If the user cancels navigation, they return to their form with all changes intact.

---

Post-Audit Checklist

[ ] Every destructive action has a confirmation dialog
[ ] High-impact destructions require type-to-confirm
[ ] Soft delete used for all user-facing delete operations
[ ] Undo available for recent actions (30-second window minimum)
[ ] Malformed file uploads are rejected with helpful error messages
[ ] Retry during in-progress operation is safely handled
[ ] Asset replacement warns user and preserves previous version
[ ] Destructive buttons are visually distinct (red, separated, danger zone)
[ ] Abandoned workflows do not leave broken state
[ ] Every error message is specific and actionable
[ ] Rate limits prevent accidental expensive action spam
[ ] Unsaved changes warning on navigation
[ ] Keyboard shortcuts cannot trigger destructive actions
[ ] Bulk operations show count in confirmation dialog
[ ] Recovery path exists for every destructive action

---

UX Safety Checklist for Dangerous Actions

Per-Page Review Checklist

For every page in the application, verify:

PAGE: _______________

DESTRUCTIVE ACTIONS ON THIS PAGE:
[ ] All delete buttons use red/danger styling
[ ] Delete buttons are separated from primary action buttons by at least 50px
[ ] No destructive action is the default/focused button in any dialog
[ ] Destructive buttons have explicit labels ("Delete Project" not just "Delete")
[ ] Bulk destructive actions show exact count ("Delete 47 assets")

CONFIRMATION PATTERNS:
[ ] Single item delete: confirmation dialog with item name displayed
[ ] Bulk delete (>5 items): type-to-confirm with count
[ ] Account/project delete: type entity name to confirm
[ ] No destructive action executes on Enter key press alone
[ ] Confirmation dialog "Cancel" is visually more prominent than "Confirm"

UNDO/RECOVERY:
[ ] Undo toast appears after deletion (10-30 second window)
[ ] Soft delete sends to trash (recoverable for 30 days)
[ ] Trash/archive section is accessible from navigation
[ ] Version history available for regenerated/replaced content

FEEDBACK:
[ ] Success feedback confirms what was done ("3 assets moved to trash")
[ ] Error feedback explains what went wrong and what to do
[ ] Loading states prevent double-submission
[ ] Progress indicators show on operations > 2 seconds

NAVIGATION SAFETY:
[ ] "Unsaved changes" warning on form pages with dirty state
[ ] Browser back button triggers confirmation if form is dirty
[ ] Tab close triggers beforeunload warning if work is unsaved
[ ] Auto-save drafts for long-form content (> 3 fields)

Admin Panel Safety

ADMIN-SPECIFIC CHECKS:
[ ] Bulk operations on admin panel require elevated confirmation
[ ] "Delete all" / "Reset" buttons require typing "DELETE" or project name
[ ] Admin actions are logged with operator identity
[ ] Admin cannot delete own account through admin panel
[ ] Rate limiting on admin destructive operations (max 10 deletes/minute)
[ ] Admin audit log is immutable (cannot be deleted by admin)
[ ] Dangerous admin operations require 2FA re-verification

Mobile/Touch Safety

TOUCH-SPECIFIC CHECKS:
[ ] Destructive actions require tap (not swipe-to-delete without confirm)
[ ] Touch targets for destructive buttons are not adjacent to safe buttons
[ ] No destructive action triggered by long-press without secondary confirm
[ ] Pull-to-refresh does not trigger re-generation or re-processing

---

What Earlier Audits Miss

Standard QA and UX reviews focus on happy paths and visual consistency. This audit matters because:

• Automated tests verify that delete works, not that it is safe to trigger. They test the API, not the human-API interaction layer.
• UX reviews focus on aesthetics, information architecture, and flow. They rarely audit the damage radius of each button.
• Accessibility audits verify screen reader compatibility and contrast ratios. They do not test whether keyboard shortcuts can trigger destructive actions.
• Security audits verify authorization (can this user delete?) but not intention verification (did this user mean to delete?).
• Load testing verifies the system handles concurrent requests but not concurrent panic-clicks from a frustrated user.

This would be called a Human Error & Operator Safety Audit -- specifically testing whether accidental destructive actions are prevented, recoverable, and clearly communicated under real-world user behavior including mistakes, impatience, and confusion.

---

Automation Opportunities

Test	Automatable?	Method
TEST-HE-001: Delete path analysis	PARTIAL	Crawl UI for delete buttons; manual verification of safeguards
TEST-HE-002: Malformed upload	YES	Automated tests with bad file types, sizes, and content
TEST-HE-003: Retry during active	YES	Script: trigger operation, immediately retry, assert no duplicate
TEST-HE-004: Asset replacement	PARTIAL	Automated API test; manual UI verification
TEST-HE-005: Undo/soft-delete	YES	Integration test: delete, undo, assert data restored
TEST-HE-006: Distinguishability	MANUAL	Visual inspection, accessibility audit tools for contrast
TEST-HE-007: Abandoned workflow	YES	Start wizard, close session, reopen, assert no orphaned state
TEST-HE-008: Error recovery	PARTIAL	Trigger known errors, assert messages match quality standard
TEST-HE-009: Rate limiting	YES	Script: rapid-fire clicks via API, assert rate limit response
TEST-HE-010: Navigation safety	PARTIAL	Selenium test: edit form, navigate away, assert warning

# Automated malformed upload test
for file in wrong_type.exe corrupted.png oversized.png empty.png "special chars!@#.png"; do
  response=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST /api/upload \
    -F "file=@test_files/$file" \
    -H "Authorization: Bearer $TOKEN")
  echo "$file: HTTP $response"
  # All should return 400 (not 500)
done

# Automated double-click protection test
response1=$(curl -s -X POST /api/projects/123/generate -H "Authorization: Bearer $TOKEN" &)
response2=$(curl -s -X POST /api/projects/123/generate -H "Authorization: Bearer $TOKEN" &)
wait
# Assert: only one job created, second returns 409 or same job ID

---

Reusable Audit Report Template

# Human Error & Operator Safety Audit Report

## System: _______________
## Date: YYYY-MM-DD
## Auditor: _______________

## Delete Path Inventory
| Action | Confirmation? | Type-to-Confirm? | Soft Delete? | Undo? | Verdict |
|--------|-------------|------------------|-------------|-------|---------|
| Delete project | | | | | |
| Delete asset | | | | | |
| Delete account | | | | | |

## Test Results
| Test ID | Description | Result | Evidence |
|---------|-------------|--------|----------|
| TEST-HE-001 | Delete safeguards | PASS/FAIL | ___ actions lack confirmation |
| TEST-HE-002 | Malformed upload | PASS/FAIL | ___ bad inputs cause 500 errors |
| TEST-HE-003 | Retry safety | PASS/FAIL | Duplicate work created: yes/no |
| TEST-HE-004 | Replacement messaging | PASS/FAIL | Warning shown: yes/no |
| TEST-HE-005 | Undo/recovery | PASS/FAIL | ___ actions are unrecoverable |
| TEST-HE-006 | Visual safety | PASS/FAIL | ___ destructive buttons lack distinction |
| TEST-HE-007 | Abandoned workflows | PASS/FAIL | Orphaned state found: yes/no |
| TEST-HE-008 | Error guidance | PASS/FAIL | ___ errors are generic |
| TEST-HE-009 | Rate limiting | PASS/FAIL | Rapid clicks create duplicates: yes/no |
| TEST-HE-010 | Navigation safety | PASS/FAIL | Unsaved warning: yes/no |

## Score: PASS / PARTIAL / FAIL

---

Priority Targeting

Run this audit FIRST if:

• Users report accidental data loss
• Support tickets include "I didn't mean to delete that"
• No undo or trash functionality exists
• Destructive and safe actions look similar in the UI
• File upload accepts any input without validation
• Error messages are generic
• Users retry impatiently because there's no progress indication