Skip to content

Recovery audit: explicit-fallback class is too noisy for v1 lint #2

Description

@sridherj

Source: sub-phase 2.4 (correctness sanity + remediation + LinkedOut-coupling spike).

Context

bin/audit-interdependencies --mode=recovery flags every read/unspecified-direction file expectation as red unless the surrounding 5-line window contains explicit fallback / early-exit / user-prompt prose. Today this produces ~464 red findings across the harvested fleet — the vast majority of them are NOT actionable safety bugs.

Examples of the false-positive class:

  • A reference brief like `see `agents/REGISTRY.md` for the canonical list` — it is a citation, not a load-or-die path.
  • A pseudo-code template like `agents/{name}/{name}.md` — no instance is ever read at runtime.
  • A pattern hint like `*.ai.md` — a filename glob, not a load target.

Problem

A 60% budget cap on red-finding remediation (per Phase 2 high-level plan risk register) cannot accommodate ~464 ad-hoc fallback paragraphs, and writing a fallback paragraph for every literal-pattern citation would degrade prompt quality.

Decision (deferred to Phase 3a)

  • Tighten the recovery classifier so it only fires for load-or-die file dependencies (file referenced as the agent's first-read input, or referenced by a hard write target whose absence breaks the agent).
  • Add a per-agent `required_inputs:` list in `config.yaml` that the audit treats as the only paths subject to the explicit-fallback rule.
  • Anything outside that allowlist is downgraded to yellow (advisory).

Action

  • Phase 3a B-extra: rewrite recovery classifier + adopt `required_inputs` in config.yaml.
  • 2.4 records all 464 recovery reds as Deferred to this issue.

Verification

After Phase 3a lands, `bin/audit-interdependencies --mode=recovery` should report ≤10 red findings, and each remaining red is a real load-or-die dependency.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions