.bashrsignore

# bashrs ignore configuration for aprender
# See: https://github.com/paiml/bashrs

# Ignore rules with documented justifications:

# DET002: Non-deterministic timestamp usage
# Justification: Timestamps are intentionally used for unique baseline filenames
# in benchmark scripts. This is expected behavior, not a bug.
DET002

# SEC010: Path traversal risk in mkdir
# Justification: Paths in our scripts are hardcoded constants, not user input.
# Path traversal is not a risk when the path is a literal string.
SEC010

# SC2032: Variable assigned in script with shebang
# Justification: These are standalone scripts, not meant to be sourced.
# Variables are intentionally local to the script.
SC2032

# SC2117/SC2317: Unreachable code warnings
# Justification: These are false positives in case statements where
# exit/return is followed by ;; and esac - bashrs incorrectly flags
# the closing syntax as unreachable.
SC2117
SC2317

# MAKE010: Command missing error handling
# Justification: Some commands intentionally use || echo for graceful
# fallback messages (e.g., pmat not found). Fixed where appropriate.
# Remaining instances are intentional fallbacks.
MAKE010

# MAKE012: Recursive make invocation
# Justification: Recursive make is used for sub-targets like chaos-test-lite.
# While "Recursive Make Considered Harmful" is valid for large projects,
# our use case is simple delegation to a fallback target.
MAKE012

# SC2006/SC2046/SC2092/SC2099: Backtick-related warnings
# Justification: These are false positives in heredocs with quoted delimiters
# (<< 'EOF'). Backticks inside such heredocs are literal markdown code blocks,
# not command substitutions. bashrs incorrectly parses heredoc content.
SC2006
SC2046
SC2092
SC2099

# SC2140: Word is split between quotes
# Justification: False positive for valid quote nesting like:
# echo '{"json":"content"}' > "$VAR/file.json"
# The single-quoted JSON and double-quoted path are correctly quoted.
SC2140

# SC2035: Use ./* so names with dashes won't become options
# Justification: False positive when patterns are quoted arguments to find -name.
# In `find -name '*.json'`, the pattern is passed to find, not the shell.
SC2035

# SC2062: Quote the grep pattern
# Justification: False positive when regex patterns are already single-quoted.
# In `grep -qE '^[0-9]+\.[0-9]+$'`, the pattern is already quoted.
SC2062

# SC1020 / SC1140: Missing space before ] / unexpected token after ]
# Justification: bashrs parses regex character classes inside quoted grep
# patterns as shell test expressions, reporting false positives on patterns
# like '[a-z0-9]' or '[0-9]+'. The patterns are single-quoted strings
# consumed by grep/awk, not bash test brackets. Applied to
# scripts/check_readme_claims.sh (FALSIFY-README-001..004 bound by
# contracts/readme-claims-v1.yaml).
SC1020
SC1140

# SC1009: Comment here is not a command. Use a no-op `:` if the body is empty
# Justification: False positive when function bodies begin with a comment
# followed by a statement. bashrs doesn't parse multi-line function bodies.
SC1009

# SC2102: Ranges can only match single chars (to match + literally, use \+)
# Justification: False positive when regex `[0-9]+` is inside a grep `-E`
# pattern. bashrs interprets the brackets as glob ranges, but the string
# is consumed by grep as an ERE pattern.
SC2102

# SEC001: Command injection risk via eval
# Justification: False positive on the literal substring "eval" in comments
# and JSON strings. Our ship-discharge scripts (scripts/ship-discharges/*.sh)
# invoke `apr eval` as an apr subcommand (apr-cli HumanEval benchmark), not
# the bash `eval` builtin. The shell never invokes `eval`. This file already
# contains audited use sites; new uses must be reviewed before adding here.
SEC001