{"version":"2.1.269","anchor":"new-structure-after-turn-outcome-for-spliced-bash-task","canonical_anchor":"new-structure-after-turn-outcome-for-spliced-bash-task","heading":"Queued-command task delivery gains richer turn\/position tracking","tier":"internal","area":"Bash Tool","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269\/e\/new-structure-after-turn-outcome-for-spliced-bash-task","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269","markdown":"### Queued-command task delivery gains richer turn\/position tracking\n\nMessages delivering queued command results now carry explicit turn\/position context used for dedup, telemetry, and history\n\n**What**\n\n- The dedup\/merge helper that delivers queued-command notifications into the transcript now takes a structured options object (`{startsTurn, inDrainPosition, inHumanTurn}`) instead of positional booleans, used for both `taskDelivery` on user messages and `queued_command` attachments.\n\n- The bash-task-delivery splicing logic now distinguishes a third structural outcome, `after_turn`, in addition to the existing `append`\/`new_turn`, based on new position parameters; it's recorded in the `tengu_bash_task_delivered` telemetry event.\n\n- The logic that decides whether a message counts as a completed tool-result turn (for grouping\/rendering) now also treats user messages carrying a `taskDelivery` field as qualifying, not just ones with `tool_result` content.\n\n- The check for whether a message counts toward rewind\/history segmentation likewise now treats messages with a `taskDelivery` field as eligible, not just `tool_result`-bearing ones.\n\n**Why** These changes make messages that deliver queued command results behave consistently with normal tool-result messages for turn grouping, rewind\/history, and telemetry, instead of being treated as a special case that could be miscounted or misplaced.\n\n- Area: Bash Tool\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}