fix(elicitation): drop the bare-close reason dialog - the caller that closed has the reason; never offload it to the keyboard #167

New issue

Closed

opened 2026-07-16 20:55:06 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-16 20:55:06 +00:00

(Migrated from codeberg.org)

With close_requires_reason=require, an elicitation-capable client that bare-closes an issue currently gets a dialog asking whoever is at the keyboard to type the closing reason, which then lands in the closing comment. Non-elicitation clients get the refusal instead.

That flow inverts accountability. The guard exists so every close carries a discoverable note, and the party best positioned to write it is the caller that decided to close - an agent that just finished the work has the reason in context. The dialog rewards a bare close with someone else's busywork, trains agents that skipping reason= is fine because someone mops up, and produces worse reasons (the person prompted may not even know why the agent closed it).

It also blurs the elicitation design line that holds everywhere else: dialogs are for consent (may this irreversible thing happen - a call that belongs at the keyboard; the delete confirmation is the right kind), never for substance the caller owes.

Change

Under close_requires_reason=require, a bare close is refused with the existing pass-reason= guidance on every client, elicitation-capable or not. The refusal already teaches the fix; one cheap retry with the reason in hand beats an interrupt.
The delete-confirmation elicitation is untouched - consent stays a dialog.
Steering/help text and the reference docs updated where they describe the reason dialog.

Acceptance

With close_requires_reason=require on an elicitation-capable client, a bare close returns the same refusal as on any other client; no dialog appears.
The delete-confirm dialog still appears and decline still aborts.
Tests covering the old elicit-reason path are replaced by refusal-parity tests across client capability.

With `close_requires_reason=require`, an elicitation-capable client that bare-closes an issue currently gets a dialog asking whoever is at the keyboard to type the closing reason, which then lands in the closing comment. Non-elicitation clients get the refusal instead. That flow inverts accountability. The guard exists so every close carries a discoverable note, and the party best positioned to write it is the caller that decided to close - an agent that just finished the work has the reason in context. The dialog rewards a bare close with someone else's busywork, trains agents that skipping `reason=` is fine because someone mops up, and produces worse reasons (the person prompted may not even know why the agent closed it). It also blurs the elicitation design line that holds everywhere else: dialogs are for **consent** (may this irreversible thing happen - a call that belongs at the keyboard; the delete confirmation is the right kind), never for **substance** the caller owes. ## Change - Under `close_requires_reason=require`, a bare close is refused with the existing pass-`reason=` guidance on every client, elicitation-capable or not. The refusal already teaches the fix; one cheap retry with the reason in hand beats an interrupt. - The delete-confirmation elicitation is untouched - consent stays a dialog. - Steering/help text and the reference docs updated where they describe the reason dialog. ## Acceptance - With `close_requires_reason=require` on an elicitation-capable client, a bare close returns the same refusal as on any other client; no dialog appears. - The delete-confirm dialog still appears and decline still aborts. - Tests covering the old elicit-reason path are replaced by refusal-parity tests across client capability.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#167

No description provided.

Rows
Columns