Problem
Issue #1004 fixed the hard-floor registry function name mismatch. During that work, the security-auditor surfaced an honest gap: the aspirational rm -rf with unresolved variables semantic was listed in hard_floor_hooks.json registry as a protected pattern, but no implementation exists anywhere that detects this specific class of dangerous commands.
The hard-floor registry now honestly reflects reality (post-#1004), but the gap itself remains open: a rm -rf $UNSET_VAR command passes through the hook layer unchallenged.
Evidence
From issue #1004's security-auditor output:
"1 LOW pre-existing rm-rf-vars semantic gap — the aspirational 'rm -rf with unresolved variables' detection is NOT implemented anywhere. Registry now honestly reflects this."
The hard_floor.py likely contains a _check_dangerous_bash() stub or similar placeholder that was never implemented.
Suggested Fix
Option A — Implement the detection (preferred):
- In
plugins/autonomous-dev/lib/hard_floor.py, add a function _check_rm_rf_unresolved_vars(command: str) -> bool that detects patterns like:
rm -rf $VARNAME where $VARNAME is not quotedrm -rf ${VARNAME} with potentially empty expansionrm -rf "$VARNAME" is SAFE (quoted, empty → removes nothing at that path)
- Use regex:
r'rm\s+-rf?\s+\$\{?[A-Z_][A-Z0-9_]*\}?(?!\s*["\'])' as a starting point
- Add unit tests in
tests/unit/lib/test_hard_floor.py
- Update registry entry with
implemented: true
Option B — Accept the gap formally:
- Add a
KNOWN-GAPS.md doc entry explaining why this detection is out of scope (e.g., requires shell expansion context that's unavailable at hook time)
- Remove or mark the registry entry as
aspirational: true with an explicit rationale
Why This Matters
The rm-rf-vars class of bugs is a high-impact footgun in automation scripts. If the pipeline ever passes an unset variable through a bash command (e.g., from a failed env lookup), the result could be catastrophic directory deletion. Hook-level detection at HARD GATE priority is the correct defense layer.
Context
Plugin Version: 3.50.0 (995ee2d)
Filed automatically by continuous-improvement-analyst
Problem
Issue #1004 fixed the hard-floor registry function name mismatch. During that work, the security-auditor surfaced an honest gap: the aspirational
rm -rf with unresolved variablessemantic was listed inhard_floor_hooks.jsonregistry as a protected pattern, but no implementation exists anywhere that detects this specific class of dangerous commands.The hard-floor registry now honestly reflects reality (post-#1004), but the gap itself remains open: a
rm -rf $UNSET_VARcommand passes through the hook layer unchallenged.Evidence
From issue #1004's security-auditor output:
The
hard_floor.pylikely contains a_check_dangerous_bash()stub or similar placeholder that was never implemented.Suggested Fix
Option A — Implement the detection (preferred):
plugins/autonomous-dev/lib/hard_floor.py, add a function_check_rm_rf_unresolved_vars(command: str) -> boolthat detects patterns like:rm -rf $VARNAMEwhere$VARNAMEis not quotedrm -rf ${VARNAME}with potentially empty expansionrm -rf "$VARNAME"is SAFE (quoted, empty → removes nothing at that path)r'rm\s+-rf?\s+\$\{?[A-Z_][A-Z0-9_]*\}?(?!\s*["\'])'as a starting pointtests/unit/lib/test_hard_floor.pyimplemented: trueOption B — Accept the gap formally:
KNOWN-GAPS.mddoc entry explaining why this detection is out of scope (e.g., requires shell expansion context that's unavailable at hook time)aspirational: truewith an explicit rationaleWhy This Matters
The rm-rf-vars class of bugs is a high-impact footgun in automation scripts. If the pipeline ever passes an unset variable through a bash command (e.g., from a failed env lookup), the result could be catastrophic directory deletion. Hook-level detection at HARD GATE priority is the correct defense layer.
Context
plugins/autonomous-dev/config/hard_floor_hooks.jsonplugins/autonomous-dev/lib/hard_floor.pyPlugin Version: 3.50.0 (995ee2d)
Filed automatically by continuous-improvement-analyst