feat(audit)!: consolidate audit log JSON entries into command_evaluations

[fohte]

Purpose

• Extract the actual binary from audit logs with a one-line jq. Filtering on the raw command string mismatches on inline env prefixes (FOO=x helmfile ...) and on binary names buried inside argument bodies such as --prompt
• The existing audit JSON places fields differently for single and compound (a && b etc.) commands, so consumers must branch on whether to read top-level matched_rules or sub_evaluations[].matched_rules

Approach

• Drop AuditEntry.matched_rules and sub_evaluations; collapse them into a single command_evaluations: [CommandEvaluation]
• Put command, action, matched_rules, eval_type, env, argv, redirects, pipe flat on CommandEvaluation so the shell-level parse data sits at the same level as the rule evaluation result
• Non-compound input produces one element (eval_type: "primary"); compound input produces one element per branch (eval_type: "compound"); input with no runnable command (comment-only, parse failure) produces an empty array

{
    "command": "FOO=x echo hi && BAR=y cat /tmp/f",
    "command_evaluations": [
        {
            "command": "echo hi",
            "action": { "type": "allow" },
            "eval_type": "compound",
            "env": [{ "name": "FOO", "value": "x" }],
            "argv": ["echo", "hi"]
        },
        {
            "command": "cat /tmp/f",
            "action": { "type": "allow" },
            "eval_type": "compound",
            "env": [{ "name": "BAR", "value": "y" }],
            "argv": ["cat", "/tmp/f"]
        }
    ]
}

Design decisions

Whether single and compound entries share one shape

Decision	Design	Pros	Cons
Chosen	Both single and compound entries use the same command_evaluations: [] shape	A single canonical jq path (.command_evaluations[]) covers both cases, eliminating the single/compound branch	Breaking change for consumers that referenced the old matched_rules / sub_evaluations fields directly
Rejected	Keep top-level parsed for single inputs, scatter per-branch parse data under sub_evaluations[].parsed for compound	Pure additive change, no schema breakage	Consumers still need an OR between top-level and sub_evaluations paths to handle both cases

Whether runok names binary / subcommand

Decision	Design	Pros	Cons
Chosen	Stay at the shell-parse layer; consumers read argv[0] themselves	CLI-agnostic; runok carries no per-CLI knowledge	Consumers must know to read argv[0]
Rejected	Emit dedicated binary / subcommand fields	jq becomes parsed.subcommand	Subcommand position varies per CLI (git -C dir status puts it at argv[3]); runok would need a per-CLI table

Breaking changes

• The top-level matched_rules and sub_evaluations keys on AuditEntry JSON are removed; their contents move into each command_evaluations[] element

[gemini-code-assist]

Code Review

This pull request introduces a structured parsed field to audit log entries, providing shell-level tokenization results—including environment variables, arguments, redirects, and pipeline status—directly in the JSON output. This allows audit consumers to filter by binary or arguments without re-implementing shell parsing. The implementation updates the command extraction logic using tree-sitter, adds new serializable models, and includes comprehensive integration tests and documentation. Feedback was provided to refactor the new roundtrip tests into an existing parameterized test suite to adhere to the repository's style guide regarding test parameterization and naming.

[codecov]

Codecov Report

❌ Patch coverage is 92.10526% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.77%. Comparing base (49f6212) to head (8fa80b8).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
src/audit/model.rs	92.23%	8 Missing ⚠️
src/adapter/mod.rs	94.33%	3 Missing ⚠️
src/rules/command_parser.rs	93.10%	2 Missing ⚠️
src/rules/rule_engine.rs	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #333      +/-   ##
==========================================
+ Coverage   88.74%   88.77%   +0.03%     
==========================================
  Files          53       53              
  Lines       12163    12314     +151     
==========================================
+ Hits        10794    10932     +138     
- Misses       1369     1382      +13     

Flag	Coverage Δ
Linux	88.56% <92.10%> (+0.01%)	⬆️
macOS	89.92% <92.10%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.