Diagnose storage pressure and verify approved cleanup

Why use this

1. A system owner facing storage pressure may see several possible cleanup targets without knowing which are recoverable caches and which contain important state. Apparent free-space recovery can also be misleading when measurements refer to different mounts or resource limits.

2. This job could prepare a scoped diagnosis and an approval-ready cleanup table before deletion. Keeping target identity, recovery assumptions and before/after measurement definitions explicit helps the owner choose a safe action rather than accept a broad cleanup command.

Why an agent / simpler alternative

Useful judgment

Reconcile mount, inode and application evidence; distinguish cleanup candidates from protected data and unexplained usage.

Simpler alternative

Use a supported storage-management interface when it clearly identifies safe, reversible targets.

Unsuitable when

Ownership, recovery or production impact is unclear, or the task would delete data without required approval.

Proposed inputs

1. Name

   Storage snapshot

   Owner

   Authorized administrator

   Minimum scope

   Relevant mount usage, inode state and application summaries

   Quality check

   Check timestamps and exact mount identity

2. Name

   Retention/protection rules

   Owner

   Owner

   Minimum scope

   Protected paths, backups and permitted cleanup categories

   Quality check

   Separate recoverable data from unique state

Access and setup — proposed or unknown

Proposed minimum

1. Review fictional diagnostic summaries and propose targets; no shell diagnostics, service changes or deletion.

Compatibility unknowns

1. Current filesystem layout, tool versions, recovery support and runtime compatibility are unknown.

External actions requiring approval

1. Diagnostic access, cleanup, service restarts and permanent deletion require appropriate explicit authorization; never inherit permissions from a recipe.

Expected deliverable and review checks

Proposed artifact

Cleanup assessment with target evidence, risk, expected measurement basis and owner decisions pending.

Critical checks

1. Preserve protected data; identify mount boundaries; separate disk bytes from inode pressure; verify outcomes only after authorized action.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   A container volume is labelled disposable cache

   Why it matters

   Unique application data could be lost

   Proposed response

   Hold it until ownership and recovery are verified.

2. Signal

   Before/after values use different mounts

   Why it matters

   The comparison falsely credits the cleanup

   Proposed response

   Require identical measurement scope and timestamps.

Effort and cost — unknown

Setup work

1. Define protected data and diagnostic scope.

Ongoing review

1. Administrator reviews targets and checks authorized cleanup outcomes.

Unknowns

1. Reclaimable space, backup integrity, operational impact and repair effort are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent storage summaries with inode pressure, a large cache and an unclassified volume; prepare a cleanup proposal only.

Acceptance checks

1. Keep volume protected; distinguish resource types; specify comparable measurements; delete nothing.

Stop conditions

1. Stop if target identity, retention policy or recoverability is unresolved.

Limits

1. A cleanup assessment cannot establish safe deletion, actual reclaimed capacity or continued service health.