# Staleness Rules (shared)

Authoritative staleness policy for every PRD Plugin skill. Each skill keeps a
short "Staleness Coverage" section naming its own responsibility and points here
for the full rule, so the detail lives in one place.

## The rule

Before relying on, refreshing, or changing any durable record, check whether the
related state is stale and handle it explicitly — never silently inherit stale
authority.

Records to check, by the thresholds in `.prd_plugin/config.json`:

- `REQ-*` proposed / in_review / needs_info older than `requests.stale_after_days`.
- `REQ-*` accepted but not graduated older than
  `health.accepted_request_stale_after_days`.
- `TRK-*` active work older than `health.stale_tracking_after_days`.
- Open `HLT-*` findings, open `DBR-*` document branches, and `MSG-*` request
  threads with no recent activity.
- Request transport (inbox/outbox/mailbox), automation locks, and scheduler
  state.

## Required handling

For each stale item, do exactly one of:

1. **Refresh** it with current evidence (command output, reviewed artifact,
   verified timestamp) and update its status/timestamp.
2. **Supersede** it explicitly (e.g. a newer `DEC-*` supersedes an older one).
3. **Carry it forward** as an explicit, visible follow-up ID.

Do not mark a stale record fresh from narrative alone, and do not delete a stale
record to make a check pass.

## Tooling

`python scripts/staleness_audit.py` (or `.prd_plugin/scripts/staleness_audit.py`
downstream) reports stale records by these thresholds. It is read-only; it does
not resolve anything for you.