sensor-false-positive-remediation

name	sensor-false-positive-remediation
version	1.0.0
category	devops
description	Handle false positives from the auto-remediation sensor pipeline. Covers the trace-before-create workflow for sensor-reported missing scripts and distinguishing stale sensor entries from genuine issues.
author	Hermes Cortex
license	MIT
metadata	{"hermes":{"tags":["remediation","sensor","false-positive","cron","maintenance"]}}

Sensor False Positive Remediation

When this applies

The agent-remediation-sensor.py (every 5m, no_agent) reports issues via JSON. Not all reports indicate real problems — some are stale entries in the sensor's hardcoded check lists.

Known false positive patterns

Sensor report	Likely cause	Action
script_missing for a script	Stale entry in required_scripts array	Trace references; remove if never deployed
mycortex_health_check_failed	Skills missing resolver triggers (content/marketing skills)	Pre-existing; no action unless service-level failure
git_issue — uncommitted changes	Sensor's own fix not committed yet	Commit and push the sensor fix
nginx config invalid (from nginx -t as non-root)	open() "/run/nginx.pid" failed (13: Permission denied) — pid-file permission artifact, NOT a config error	Validate with sudo nginx -t; don't report/revert anything (2026-08-05)
Authorization: Basic *** literal in a script (auth header "computed but never used")	Tool-output redaction, NOT a bug. Hermes masks any Authorization: Basic <token> pattern to Authorization: Basic *** in displayed output (canary-verified 2026-08-13). The file usually contains f'-H "Authorization: Basic {encoded}"' — the var IS used.	Byte-check before reporting: python3 -c "print(open('<file>').read().count('*'))" — 0 asterisks in the line = redacted display, code is fine. Don't re-report (Gisu FP 2026-08-13)

Reading the sensor's own output

The sensor cron's output lives at ~/.hermes/cron/output/922670b04cba/*.md (job id for agent-remediation-sensor). An empty issue array prints as [] in the file — that is the healthy state, not an error. On hosts with IS_SERVER=false in ~/hermes-cortex/.env the sensor always prints [] by design (host gating); don't expect sensor issues from them.

Workflow: Handling script_missing from the sensor

1. Trace references

search_files(pattern="<script-name>", path="~/hermes-cortex")

Check: does the script exist in any ops/scripts/ directory?

ls ~/hermes-cortex/ops/scripts/*<script-name>* 2>/dev/null

2. Check session lessons

session_search(query="<script-name>")

Lessons may confirm the script was deliberately never deployed — e.g. "only appeared in uninstall arrays for cleanup, never a create_cron block".

3. Check install scripts

Search for the script name in:

• ops/scripts/install-crons.sh (create_cron blocks and uninstall arrays)
• ops/scripts/install/install-orch-crons.sh (orchestration crons)

If it only appears in the uninstall array (cleanup legacy) and never in a create_cron block, the entry is stale.

4. Fix

If stale: Remove the entry from required_scripts in ops/scripts/health/agent-remediation-sensor.py, commit, push, deploy.

If genuinely missing: Copy from repo source to both runtime paths.

5. Deploy

cp ~/hermes-cortex/ops/scripts/health/agent-remediation-sensor.py ~/.hermes-cortex/scripts/
cp ~/hermes-cortex/ops/scripts/health/agent-remediation-sensor.py ~/.hermes/scripts/

6. Verify

python3 ~/.hermes-cortex/scripts/agent-remediation-sensor.py

Confirm the script_missing issue no longer appears in output.

Workflow: Handling mycortex_health_check_failed

The sensor runs mycortex doctor --fast. Exit code != 0 triggers this report.

Expected non-critical issues:

• resolver_health — skills without trigger rows in RESOLVER.md (content/ marketing skills not relevant to brain ops). This is pre-existing and non-actionable.
• skill_conformance — manifest.json not found. Known/expected warning.
• connection — Skipping DB checks in --fast mode. Not a real failure.

Only escalate if: Postgres is unreachable, the autopilot service is down, or the health score drops below 50 without a known pattern.

Real example (2026-07-21)

orch-team-messages.sh appeared in sensor's required_scripts but:

• Never existed in any ops/scripts/ directory
• Only appeared in uninstall arrays as cleanup legacy (from bare-name rename)
• Lesson search confirmed: "never actively created"
• Fix: removed from sensor list → commit 3f56914 → push → deploy