Local-first AI agent runtime with approval gates, auditable events, and resumable multi-surface workflows.
Aura defines 4 tools with mixed quality. Two patch tools (project__apply_patch, project__patch) have detailed parameter schemas and descriptions but lack critical error handling guidance. One session search tool is well-described with sensible constraints. One export tool lacks output documentation. All tools have descriptions above 20 chars and input schemas with types, but error recovery patterns and output structure documentation are largely absent. Tool naming is clear (verb_noun pattern), but composition could be tighter.
Apply a multi-file patch in Codex apply_patch format to UTF-8 text files under the project root. The patch MUST be raw text (no ``` fences) and MUST start with '*** Begin Patch' and end with '*** End Patch'. This is NOT unified diff: do not use '---'/'+++', and do not use range headers like '@@ -10,6 +11,7 @@'. Hunk headers must be one of: '*** Add File: <path>', '*** Delete File: <path>', '*** Update File: <path>'. Inside an update hunk, every change line must start with ' ' (context), '+' (add), or '-' (remove).
Apply a patch to UTF-8 text files under the project root. Input format: unified diff (starts with '---'/'+++', with '@@' hunks) as produced by `git diff`. Do NOT include markdown ``` fences; pass raw diff text. Notes: - This tool converts unified diff into Aura's internal apply_patch format. - Prefer this tool over `project__apply_patch` (which expects a special DSL).
Export a session into a portable bundle directory under the project root (events + session meta + artifacts). This is a high-risk write operation and typically requires user approval.
Search recorded chat sessions in this project for a keyword by scanning session events and referenced artifacts.
session__export lacks output schema documentation. No documented return type, fields, or structure for the exported bundle. LLMs cannot plan post-export operations or understand what data is included.
Error handling is absent from all tools. No recovery guidance provided. E.g., project__patch does not document what happens on merge conflicts, encoding errors, or invalid diff format. How should the LLM retry or recover?
Destructive tools (project__apply_patch, project__patch, session__export) lack error classification or confirmation patterns. dry_run flags exist but no confirmation request or explicit error codes for policy violations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
project__patch and project__apply_patch are nearly identical in purpose (both apply patches to UTF-8 files). The tool descriptions state 'Prefer project__patch over project__apply_patch', but LLMs may conflate them or choose wrong one. Should consolidate or make distinction sharper.
session__export parameter 'out_dir' defaults to 'out' but no validation or error documented if directory already exists or write fails. What happens on collision? Can it overwrite?
project__patch and project__apply_patch both reference 'max_diff_chars' and 'max_diffs' parameters with generic descriptions. No guidance on what happens when limits are exceeded, are results truncated? Should the LLM retry with smaller limits?