Aster Fix Workflow

Review → fix workflow

aster fix takes findings produced by aster review --json and asks the model for concrete edits. It is dry-run by default and only writes with --apply, subject to the permissions block in aster.yaml.

The pipeline

aster review --json > findings.json        # 1. review, capture findings
aster fix --findings-json findings.json    # 2. dry-run: preview proposed edits
aster fix --findings-json findings.json --apply   # 3. write to the working tree

Or as one stream:

aster review --json | aster fix --findings-json - --apply

Rules

• ALWAYS run the dry-run first and read the preview before --apply. Never jump straight to --apply on findings you have not seen.
• --apply writes to the working tree only; it never commits. Review the diff with git diff afterward and commit yourself.
• Writes are gated by permissions in aster.yaml (mode, plus allow/ask/deny rules). A headless run has no way to answer a prompt, so anything that reaches ask is refused: automation needs mode: edit with explicit allow rules like Edit(src/**).
• --json emits one JSON array of per-finding results (useful to report which fixes applied, failed, or were skipped).
• --model overrides the fix model (else ASTER_MODEL, else aster.yaml); --repo-root <DIR> sets the root the finding paths are relative to.

Curating findings

aster fix fixes whatever is in the array, so filter first. Findings are JSON; drop low-confidence or out-of-scope entries before fixing, e.g.:

aster review --json | jq '[.[] | select(.confidence >= 0.8)]' | aster fix --findings-json - 

After applying

Run the project's tests/build to confirm the fixes hold, then commit. Treat model edits like any other patch: verified, not trusted.