Abandoning a task needs an explicit exit

What it is

A pizza is on its third topping; the user says “forget it.” If the next line is still “what else to add,” abandon was not treated as a legal dialogue act, and the person is locked inside a ticket they already tore up. An explicit task abort requires that cancel, forget it, stop doing this, can end the current task — pop the stack, halt the chase, produce a hearable close — rather than take the line as one more unfilled slot. The exit has to work on every agenda beat, not only at final confirm.

Why it happens

Task state machines like to sit in “still missing slots,” the only forward path they were trained on. Abort is a negative edge: no new slot value, only “this goal is no longer pursued.” If that edge does not exist, any negation is poured back into the nearest question. When the user aborts, the half-product in common ground should be marked closed, not suspended for resume — suspend means wanting to come back; abort means not coming back. The exit also has to block a half-close: the skill stops, but a timer, a cart, a pending payment stays alive in the back, and the next wake hands the half-product back — no exit. A hearable close (“okay, that pizza is cancelled”) writes the close into both ears, so one side does not think it ended while the other still waits on toppings.

Studying it

From live logs, take cancel phrases and score what follows: does the system still ask the original slot, open a new skill, produce a close, leave a back-end object alive. Independents: agenda position of the cancel (first slot, mid, pre-confirm), strength of wording (“stop” versus “cancel the order”). Dependents: how many chase turns continue, rate of the half-product being submitted later, how often the user repeats the cancel.

Wizard-of-Oz plants one abort on every required slot. If only the confirm beat can leave and mid-task cannot, the exit is not global. Do not dump abort, repair, and switch into one “negation” bucket — the three successor states are different.

Where it stops holding

“No mushrooms” repairs a slot; it does not abort the order. An overly hair-trigger exit will kill a repair as a cancel. High-consequence acts may still need one confirm after abort (“sure you want to cancel the transfer?”); that is matching consequence, not keeping the person in the old fill. Aborting a nested task should close only the current layer; if a parent remains, resume it, rather than wiping the whole stack. “Stop all of this” is what clears the stack. Access users may not use the canonical cancel word; the trigger cannot be bound to “cancel” alone. An exit that requires a wake word plus a hidden “exit skill” grammar is not an exit.

Applying it

• Hang an abort edge on every task state: on a cancel dialogue act, stop asking, close that task object, speak a close.
• After the close, land in idle. Do not immediately pull the person into another task with a generic “anything else”; idle can be short, but the cancel has to be heard first.
• Abort inside a nest closes the current layer by default and takes the parent’s resumption cue; only an explicit whole-stack cancel wipes everything.
• How to check: say “forget it” mid-toppings and again just before confirm. If mid-task is still chased for toppings, or the back end can still submit this pizza, the exit is not through.

Related

• Same group: M1.05.1 People insert new requests in the middle of a task · M1.05.2 After the insert, the original task has to resume · M1.05.3 Nesting depth needs a hard cap · M1.05.4 A topic switch and a correction are different intents · M1.05.5 A suspended task must keep its full mid-state
• Nearby: M2.07 Dialogue Flow and State Design · M1.12 Opening and Closing a Dialogue · M1.06 Repair Strategies
• Search terms: explicit task abort · cancel dialogue act · task exit