Ramnique Singh 46ad5aa3b6 fix(x): never record a repository failure as a tool's own error result ... executeSyncTool's success-result append sat inside the try whose catch appends an error tool result. A transient repository failure (disk pressure, EMFILE) on that append was therefore durably recorded as the TOOL having failed — after its side effect already happened — inviting the model to retry the side effect on the next call (double-sent email, duplicate issue). This violated §21.4: repository failures must reject the execution, not masquerade as tool outcomes. The try now covers execution and result parsing only (a tool returning garbage is still a tool error). The success append happens outside: a failure there propagates as an infrastructure error, the log keeps the invocation without a result, and the existing §23 recovery closes it honestly on re-advance ("outcome is unknown and it was not retried") without re-executing. Tests: a repo fake failing exactly the success append — asserts no false error is persisted, the outcome rejects, recovery yields the indeterminate result without re-execution, and a committed sibling result survives untouched with correct model-facing ordering; plus a parse-failure case pinning garbage returns as tool errors. Both repo tests fail against the old code. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>		2026-07-11 10:30:08 +05:30
..
core	fix(x): never record a repository failure as a tool's own error result	2026-07-11 10:30:08 +05:30
shared	fix(x): fail-closed tool permissions with per-tool catalog declarations	2026-07-10 23:07:11 +05:30