Found while reviewing the #1603 fix (carrying a real reason on an error outcome).
#1603 made a Template/Capture failure honest for a CLI or interactive caller. Success
stayed ambiguous, and there is one shape where that matters.
When a capture's formatted payload is empty or whitespace-only,
src/engine/CaptureChoiceEngine.ts deliberately does not touch the file - inserting
would add a blank line or, on currentLine, DELETE the active selection - and shows a
"Nothing to capture" notice instead of a false "Captured to …". Good. But the run still
records {status:"success", file}, so:
quickadd:run … verify answers {"ok":true,"verified":true,"file":"Inbox.md"}quickadd:interactive finishes {"kind":"done","result":{"ok":true,"verified":true,…}}
The canvas path (handleCanvasTextCapture) does the same when nextText === existingText.
Concretely: an interactive Capture whose {{VALUE}} prompt is answered with whitespace.
The desktop says "Nothing to capture"; the client records a capture that never happened,
and an automation counting captures, or writing an idempotency marker, believes it landed.
The verified: true flag makes this worse than a plain ok:true - it is documented as
meaning "the engine actually completed (a file was created / capture written)", which is
exactly the claim that is false here.
Shape of a fix: distinguish it on the success variant rather than turning it into an
error - nothing failed, and the run should not read as one. Something like
{status:"success", file, committed:false} in ChoiceOutcome, surfaced by the CLI as
verified: false plus a note (the notice text is already the right words), and ignored by
the URI x-callback handler like every other detail.
Out of scope for #1603, which was about failures; filed rather than folded in.
Found while reviewing the #1603 fix (carrying a real
reasonon an error outcome).#1603 made a Template/Capture failure honest for a CLI or interactive caller. Success
stayed ambiguous, and there is one shape where that matters.
When a capture's formatted payload is empty or whitespace-only,
src/engine/CaptureChoiceEngine.tsdeliberately does not touch the file - insertingwould add a blank line or, on
currentLine, DELETE the active selection - and shows a"Nothing to capture" notice instead of a false "Captured to …". Good. But the run still
records
{status:"success", file}, so:quickadd:run … verifyanswers{"ok":true,"verified":true,"file":"Inbox.md"}quickadd:interactivefinishes{"kind":"done","result":{"ok":true,"verified":true,…}}The canvas path (
handleCanvasTextCapture) does the same whennextText === existingText.Concretely: an interactive Capture whose
{{VALUE}}prompt is answered with whitespace.The desktop says "Nothing to capture"; the client records a capture that never happened,
and an automation counting captures, or writing an idempotency marker, believes it landed.
The
verified: trueflag makes this worse than a plainok:true- it is documented asmeaning "the engine actually completed (a file was created / capture written)", which is
exactly the claim that is false here.
Shape of a fix: distinguish it on the success variant rather than turning it into an
error - nothing failed, and the run should not read as one. Something like
{status:"success", file, committed:false}inChoiceOutcome, surfaced by the CLI asverified: falseplus a note (the notice text is already the right words), and ignored bythe URI x-callback handler like every other detail.
Out of scope for #1603, which was about failures; filed rather than folded in.