# User Correction Tracking — Spec

## Record Schema

```typescript
interface UserCorrectionRecord {
  record_type: "conversation";
  action_type: "user_correction";
  priority: "critical_for_recovery";
  timestamp: string;        // ISO 8601
  original_claim: string;   // what the agent said that was wrong
  correction: string;       // what the user corrected it to
  principle_extracted: string;  // general principle derived from this correction
  persisted_to: string[];   // files where this correction was documented
}
```

## Storage

User correction records are stored inline in `audit_trail.jsonl` as regular entries. They are extracted during `/end` and surfaced during `/recover` L2 loading.

## Detection

During `/end`, scan the session's `audit_trail.jsonl` for entries matching:
- `action_type === "user_correction"`

Also scan `audit_pending.jsonl` for any pending correction records not yet flushed.

## persisted_to Field

When a correction is written to CLAUDE.md, coding standards, or other documentation, the file paths are recorded in `persisted_to[]`. This is populated manually by the agent when it persists the correction.

## Correction-as-Precedent

When an agent considers an action that contradicts a known `user_correction` record, it is flagged with a warning. The agent should:

1. Identify the contradiction (which rule is being violated)
2. Surface the relevant correction record (with timestamp and original context)
3. Propose an alternative that respects the correction
4. If the contradiction is intentional, document why as a new correction

Detection logic: before each significant action, the agent scans loaded user_correction records from the current recovery context and checks if the proposed action matches any known `original_claim` pattern.
