You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dsh-fs-observation-policy rejects edits without a prior read via FS_NOT_OBSERVED / FS_STALE_VERSION, and dsh-tool-fs already appends a text remedy ("— read the file, then retry"). That covers what the model should do, but the recovery instruction is still embedded in the message text only. Tool UIs and frontends cannot tell a "recoverable guard failure" from a real error, so the user experience is a red Error box with no actionable affordance.
提议 Proposal
One or any combination of:
Structured remediation metadata: add a remediation field to FsError (or export a public code → remedy map from dsh-tool-fs), instead of / in addition to message string concatenation. Consumers then route on the field, not by parsing text.
recoverable: true marker on tool results: allow UIs to render a friendly, actionable notice (e.g. "file changed on disk — re-reading it") instead of a plain error, without losing the error code for retry/permission layers.
(Optional) automatic re-read: on FS_NOT_OBSERVED / FS_STALE_VERSION, the tool layer could transparently perform one re-read + retry, preserving the existing CAS semantics, rather than forcing the model through an extra read+retry round.
动机 Motivation
Observed in practice: editing a file twice in one session triggers FS_NOT_OBSERVED on the second edit (the first edit invalidated the observed version). The remedy text works for the model but is invisible to UI layers; a structured, machine-readable marker would let tool UIs surface "recoverable — auto re-read" feedback and keep the error-code routing intact.
期望行为 Expected behavior
Error codes and their routing semantics stay unchanged.
The remedy becomes machine-readable metadata on the error / tool result.
UIs can distinguish recoverable guard failures from unrecoverable errors.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
摘要 Summary
dsh-fs-observation-policyrejects edits without a prior read viaFS_NOT_OBSERVED/FS_STALE_VERSION, anddsh-tool-fsalready appends a text remedy ("— read the file, then retry"). That covers what the model should do, but the recovery instruction is still embedded in the message text only. Tool UIs and frontends cannot tell a "recoverable guard failure" from a real error, so the user experience is a red Error box with no actionable affordance.提议 Proposal
One or any combination of:
remediationfield toFsError(or export a publiccode → remedymap fromdsh-tool-fs), instead of / in addition to message string concatenation. Consumers then route on the field, not by parsing text.recoverable: truemarker on tool results: allow UIs to render a friendly, actionable notice (e.g. "file changed on disk — re-reading it") instead of a plain error, without losing the error code for retry/permission layers.FS_NOT_OBSERVED/FS_STALE_VERSION, the tool layer could transparently perform one re-read + retry, preserving the existing CAS semantics, rather than forcing the model through an extra read+retry round.动机 Motivation
Observed in practice: editing a file twice in one session triggers
FS_NOT_OBSERVEDon the second edit (the first edit invalidated the observed version). The remedy text works for the model but is invisible to UI layers; a structured, machine-readable marker would let tool UIs surface "recoverable — auto re-read" feedback and keep the error-code routing intact.期望行为 Expected behavior
环境 Environment
@deepseek-ai/dsh-fs-observation-policy,@deepseek-ai/dsh-tool-fsAll reactions