rails-security
Boundaries
Review Rails application code as it runs in development: the repository plus commands you can run locally — bin/rails routes, bundle exec brakeman, bundle audit, the test suite. Server, cloud, container, CI, and network configuration are out of scope; when a finding depends on them, note the dependency and move on.
The whole workflow inspects and reports. No agent edits reviewed files, applies patches, commits, or begins remediation. Reproduce claims only with non-mutating commands. Review only code the user owns or is authorized to audit.
Confirm agents
Run every lens as a blind agent: fresh context, no prior conclusions, no lens passes in the delegator context. Use the runtime's native subagent abstraction. When no mechanism can create blind agents, stop and return an execution-unavailable response naming the missing capability.
Complete this step when one mechanism can create a blind agent per lens.
Resolve scope
Resolve explicit scope first. Otherwise resolve, in order: pending changes against HEAD including staged, unstaged, and relevant untracked files; a branch from its merge-base; an associated pull request; a recent commit. When the user asks to audit the app rather than a change, the scope is the whole application: app/, lib/, config/, db/, routes, and lockfiles.
Complete this step when the exact diff, range, or file set can be stated.