claudetools/.claude/memory/feedback_verify_live_before_acting.md at 994885b2aadbea2edfb907287dc95d8c5145e4c8

Files

Howard Enos be2ae8b07e sync: auto-sync from HOWARD-HOME at 2026-06-24 12:49:35

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-24 12:49:35

2026-06-24 12:50:03 -07:00

2.1 KiB

Raw Blame History

name, description, metadata

name

description

metadata

feedback_verify_live_before_acting

Always pull LIVE current data before acting on (or alarming about) a hardware/infra finding — wiki/session-logs are point-in-time snapshots that go stale

type
feedback

Before acting on, or raising alarm about, any hardware/infrastructure state — pull live current data first and lead with THAT, not the wiki or a recalled fact. The wiki, session logs, and memory are point-in-time snapshots; a "broken/degraded/failing" flag may have changed by the time you read it. This matters most for hard-to-reverse or money-spending actions (drive swaps, hardware pulls, parts purchases, "it's down" escalations).

Why: 2026-06-24 — the Cascades CS-SERVER wiki carried a [CRITICAL] RAID degraded / failing drive flag from 2026-06-15. Acting on it, SSDs were purchased and Howard went onsite ready to hot-swap the "failing" drive. A live Dell OMSA omreport query (via the RMM agent) then showed the OS mirror had self-recovered (the flaky drive dropped out and re-synced after a power cycle): all 5 disks Online/Ok, all LEDs green, and the "5th unused drive" was actually the global hot spare. Acting on the 9-day-stale flag nearly pulled a healthy drive and wasted a drive purchase. Howard's directive: "always go with live current data to make sure our findings are real."

How to apply:

For Dell servers: omreport storage controller|vdisk|pdisk controller=0 + omreport system esmlog via the RMM agent (OMSA reads the controller directly — authoritative). iDRAC/Redfish is the out-of-band equivalent (no iDRAC skill yet; creds not vaulted as of 2026-06-24).
Windows Get-PhysicalDisk/Get-Disk shows only the VIRTUAL disks as "Healthy" even when a member is degraded — it CANNOT see the array; never conclude RAID health from the OS view alone.
For any infra claim sourced from the wiki/a recalled fact: re-verify the specific file/flag/host is still true before recommending action. State the data's timestamp and source.
See reference_rmm_drive_map_explorer_refresh for the OMSA-via-RMM pattern context.

2.1 KiB Raw Blame History

2.1 KiB

Raw Blame History