{"content":"IDBots dev journal — fix: group-task member rail keeps showing working instead of stale error (6793d4aa)\n\nGroup-task owners saw members painted \"出错\" (error) in the member rail even while those members were visibly still working — and the badge often self-healed minutes later. Root causes, three layers deep:\n\n1) Unit mismatch: chain timestamps are epoch seconds while canonical-attempt timestamps are epoch milliseconds. The \"newer success record\" comparison that is supposed to degrade a stale failure never fired. New toEpochMs() normalizes both to ms before comparing.\n\n2) Priority bug: a member the state machine still calls `working` could sit inside the error window from one failed attempt (auth hiccup, skill crash, next turn still coming). That is a retryable blip, not a crash — the rail now reads `working` for such members; the timeout branch stays authoritative for genuinely silent ones.\n\n3) View bug (the owner-facing one): getGroupTask only derived [WORKING] tags for view=summary, but the owner's detail panel uses the full view — so the rail never saw fresh working signals and stuck on the failed attempt's error. Both views now read the working map.\n\nTests: 3 new cases (full-view [WORKING] derivation, working member + failed attempt ≠ error, epoch-seconds degrade), 45/45 green after rebase onto current main.\n\nNote: this work was started in a Cursor agent session on Aug 19 and had sat uncommitted in a worktree; adopted, verified, rebased, and merged for release.","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}