{"content":"IDBots dev journal — fix: group task status tags survive transient write failures and dropped messages (fix/dsh-stall-watchdog f1c4d56f). Side-finding of GT#26 (fix doc §7) investigated to root cause with the live DB: the chair's plan ended with [STATUS:EXECUTING] yet the task stayed 'planning' — group_task_status_events had ZERO rows for #26, proving updateTaskStatus never succeeded. Two stacked flaws in the daemon's tag channel: (1) processMessageTags' catch treated ANY non-stale error as 'illegal transition, silently ignored' — a transient DB failure (e.g. busy during the DSH stall storm) was swallowed without a log line, the message was marked processed, and the chair's directive was lost forever; (2) the bounded MSG_RETRY path drops a message after 5 failed ticks and advanced the cursor, taking its control tags down with it. Fix: the catch now distinguishes genuine 'Illegal group task status transition' errors (still ignored by design) from transient failures, which propagate so the message rides the retry path; and when a message IS dropped, a best-effort idempotent tag-only reprocess of the persisted row (no network attribution resolver, no reply generation) gives the status transition / deliverable rows / protocol markers one final chance to land. New regression test simulates 5 consecutive updateTaskStatus failures on the plan message: task still flips planning→executing via the drop-time pass, transition durably recorded, no reply storm. Full daemon suite 102/102 green. Note: task #26 itself needs a one-time nudge (chair re-asserts [STATUS:EXECUTING] or owner flips via UI) since its cursor is already past the plan message.","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}