[BUG]: Planning artifacts are overwritten by every retry and by the post-execute call, destroying the iteration's plan record #592

Summary

ExecutionPersistence::write_planning_phase writes to fixed filenames inside the iteration directory:

// crates/aura/src/orchestration/persistence.rs:522-534
fs::write(iter_path.join("planning.prompt.txt"), prompt).await?;
fs::write(iter_path.join("planning.response.txt"), response).await?;

Every planning call for that iteration writes the same two paths — each correction retry inside plan_with_routing, and the post-execute continuation call, which reuses the same iteration number. The last write wins, so the persisted record of how the iteration was actually planned is destroyed.

In the run that motivated this report, iteration-1/planning.prompt.txt ended up holding the 139-byte routing-correction string and iteration-1/planning.response.txt was 0 bytes — the original planning prompt and the plan the coordinator produced were both gone, even though plan.json shows a full two-task plan was created.

Expected: planning artifacts should be attempt-scoped and phase-scoped, the way worker artifacts already are (task-1.attempt-2.prompt.txt, task-1.attempt-2.response.txt, ...).

Reproduction

Pre-requisites

• AURA 0.2.3 (bb9748b1), orchestration enabled with memory_dir set (execution persistence on)

Steps

1. Run any orchestrated query that reaches the post-execute decision point (any plan with at least one task).
2. Ensure at least one planning correction retry occurs — i.e. the coordinator replies with text instead of calling a routing tool. (Deterministically: point the config at a model that does not reliably call routing tools, or lower max_tokens so the reply is truncated before the tool call.)
3. Inspect <memory_dir>/<session>/<run>/iteration-1/.
4. [BUG] planning.prompt.txt contains the last correction prompt, not the iteration's planning prompt, and planning.response.txt contains the last (possibly empty) response, not the plan. The original planning prompt/response are unrecoverable.

Relevant log output

$ ls -la /tmp/aura-rule-prod-memory/8c85d542-.../01a035a4-.../iteration-1
-rw-r--r--  18640  Aug 24 17:27  plan.json
-rw-r--r--    139  Aug 24 17:31  planning.prompt.txt
-rw-r--r--      0  Aug 24 17:31  planning.response.txt

$ cat .../iteration-1/planning.prompt.txt
You must call one of the routing tools (respond_directly, create_plan, or request_clarification). Do not respond with text — call a tool.

plan.json (17:27) proves a real plan existed; the planning prompt/response (17:31) were clobbered by the post-execute correction attempt four minutes later.

Additional Context

This actively hampers debugging: the artifacts are the primary post-mortem record for orchestration runs, and the failure modes that most need investigation (retry loops, routing failures, empty or truncated coordinator responses) are exactly the ones that overwrite the record.

Suggested fix

Adopt the worker naming convention for planning artifacts, distinguishing both the attempt and the call phase, e.g.:

• planning.attempt-1.prompt.txt / planning.attempt-1.response.txt
• continuation.attempt-1.prompt.txt / continuation.attempt-1.response.txt

plan_with_routing already knows its attempt number and whether it was called with a previous IterationContext (initial planning vs. post-execute continuation), so both discriminators are available at the call site.

Searched Issues

• No similar issues found

Code of Conduct

• I agree to follow this project's Code of Conduct