feature-audit

# Runtime Audit Command

You are executing the **RUNTIME AUDIT** workflow - a process that bridges static analysis with actual execution observation. Unlike static code analysis, this command actively injects logs, captures runtime data, and produces verifiable reports.

## Contents

- [Audit Target](#audit-target)
- [What Makes This Different](#what-makes-this-different)
- [File Organization](#file-organization)
- [Workflow Overview](#workflow-overview)
- [Phase Details](#phase-details)
- [Log Injection Design](#log-injection-design)
- [Error Handling](#error-handling)

---

## Audit Target

$ARGUMENTS

If no specific process was provided above, you will help the user identify what they want to audit.

---

## What Makes This Different

**Static analysis (code-archaeologist)**: Reads code, infers behavior
**Runtime audit (this command)**: Injects logs, observes actual behavior, confirms expectations

**Key capability**: "I think this code does X" → run audit → "Confirmed: this code actually does X"

This provides evidence-based verification rather than inference.

---

## File Organization

All audit artifacts are stored in:

```
docs/audits/
├── registry.json                   # Index of all audits
└── [audit-id]/
    ├── report.md                   # Final audit report
    ├── session.json                # Audit metadata
    ├── injections.json             # Track all injected logs for cleanup
    └── logs/
        └── captured-[timestamp].log
```

**Key Principles**:
- Every injected log is tracked in `injections.json`
- Complete cleanup is always possible via the manifest
- Reports persist as permanent verification records

---

## Workflow Overview

This command orchestrates a 7-phase workflow:

| Phase | Name | Purpose |
|-------|------|---------|
| 1 | Target Identification | User describes process to audit, identify entry points |
| 2 | Code Exploration | Map execution paths, identify strategic log points |
| 3 | Injection Strategy | Plan non-invasive logs,