scanaislop/aislop

Summary aislop agent (the local repair-session runner) currently supports three providers: codex, claude, and opencode (see src/agents/providers.ts). pi (@earendil-works/pi-coding-agent) is already wired into aislop fix --pi and aislop hook install --pi (via #144/#145, closing #142), but it is not selectable as an agent provider. It would be nice for parity to also drive pi from aislop agent --provider pi, aislop agent connect pi, and aislop agent use pi. Details pi supports the required headless surfaces: pi -p "<prompt>" print mode for non-interactive runs --mode json JSON-lines event stream output for usage/tool-call parsing pi /login (or API keys) for auth; no obvious non-interactive auth status check exists, so auth detection may need to stay null (treated as OK, like opencode) Touches at least: AgentProviderId union + PROVIDERS in src/agents/providers.ts, --provider help text / telemetry allowlist in src/cli/agent-command-options.ts, connect/use/provider listing copy, PROVIDER_

Problem The fixer currently reruns its detectors after each step and performs a final aislop scan. That proves whether targeted findings were reduced, but it does not prove that the repository still builds, typechecks, or passes its own tests. A mechanical fix can reduce aislop findings while breaking project behaviour. Verification commands must be opt-in because project scripts can execute repository-controlled code. Expected outcome Allow the user to configure or explicitly pass post-fix verification commands. When an opted-in check fails, aislop should: report the failed command and exit status; restore only the changes produced by the current fix run; preserve every pre-existing tracked and untracked user change; exit non-zero. Starting points src/commands/fix.ts src/commands/fix-steps.ts src/commands/fix-pipeline.ts src/config/schema.ts src/config/defaults.ts src/utils/subprocess.ts tests/fix-verification.test.ts tests/fix-safe-mode.test.ts Acceptance criteria No project co

Problem The published [email protected] prints an error for an invalid fix target but exits successfully: AISLOP_NO_TELEMETRY=1 CI=1 npx --yes [email protected] fix /tmp/aislop-path-that-does-not-exist echo $? # 0 The message is correct, but exit code 0 tells shell scripts, CI jobs, and agent callers that the command succeeded. The early validation in fixCommand logs the error and returns before the command lifecycle can produce a failure result. Expected outcome Invalid fix targets must return a non-zero process exit code. Starting points src/commands/fix.ts src/cli.ts src/telemetry/lifecycle.ts existing CLI ergonomics and command lifecycle tests Acceptance criteria A missing target path exits non-zero. A target that exists but is not a directory exits non-zero. The terminal error remains concise and names the invalid target. Successful fix runs retain exit code 0. Failure passes through the normal command lifecycle when possible so aggregate failure telemetry is consistent. Tests as

Problem aislop already excludes generated output, vendored dependencies, third-party directories, tests from production-only rules, .gitignore entries, .aislopignore entries, and user-provided include/exclude patterns. That policy is mostly invisible. A CLI user cannot easily answer: Which files will be scanned? Why was a file excluded? Which paths were treated as tests, generated code, or vendor code? Which base ref and changed-file scope were resolved? Which supported and unsupported languages were discovered? This has already caused direct user confusion in Discussion #229. Expected outcome Add a non-mutating scope explanation mode, preferably aislop scan --explain-scope, that resolves the same file policy as a real scan and exits before running detection engines. The report should summarize included files and exclusion reasons without dumping thousands of paths by default. Starting points src/cli.ts src/commands/scan-file-scope.ts src/utils/source-file-policy.ts src/utils/source