4043e9915f
Previous version reported `status: 'applied'` whenever at least one root landed, with a partial-failure note in `message`. But the orchestrator's retry / minimal-skills / batch_design-fallback chain checks `status === 'applied'` to decide whether to bypass retry — a partial insert (e.g. 1/5 roots landed because `defaultParentId` was stale) would short-circuit retry and leave the user with a degraded design that the system never tried to fix. Now any failed root flips the dispatch to `status: 'failed'` so the orchestrator's retry path can take over. The successful partial inserts are still surfaced in `insertedNodes` so the surrounding history-batch wrapper can roll them back / clean up — `failed` with non-empty `insertedNodes` is a legitimate combination meaning "side effects happened but the dispatch did not complete its contract". Three outcomes now: - All N roots land → `applied` with full count. - 1..N-1 land → `failed` with partial-success `insertedNodes` and a message naming the parent id + failed root ids. - 0 land → `failed` with empty `insertedNodes` and the same diagnostic. |
||
|---|---|---|
| .. | ||
| cli | ||
| desktop | ||
| web | ||