root/fusion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(FN-4595): implement cumulative execution timing semantics

Browse Source 
Fusion-Task-Id: FN-4595
Fusion-Task-Lineage: 73a3d0ad-5c10-4560-aec5-f9d138deeefd
This commit is contained in:
Fusion
2026-05-15 07:28:34 -07:00
committed by gsxdsm
parent b1f70a20d4
commit 3648d1e1df
18 changed files with 355 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/task-management.md
View File

@@ -402,7 +402,10 @@ The task detail modal exposes multiple tabs:
- **Workflow** — workflow step results (pass/fail/skip)
- **Review** — actionable feedback surface (PR reviews/threads or reviewer-agent findings), manual refresh controls, and same-task revision actions for selected items
- **Stats** — execution timing + token usage breakdown
- `Total execution time` prefers durable wall-clock execution window (`executionStartedAt` → `executionCompletedAt`)
- `Total execution time` prefers cumulative active runtime (`cumulativeActiveMs` + live in-progress segment)
- `executionStartedAt` is a current-attempt anchor and may reset on reopen bounces; cards no longer rely on it alone for lifetime runtime
- `firstExecutionAt` is the immutable first-dispatch wall-clock anchor; `executionCompletedAt` remains first-time-reaching-done
- Task Detail also shows `Wall-clock since first execution` when it differs from active runtime (for bounced/reopened tasks)
- Fallback order for legacy tasks: `timedExecutionMs` when present, otherwise `[timing]` log sum + workflow runtime
- Workflow runtime is shown as a separate metric and is not double-counted into totals when `timedExecutionMs` is already available
- **Comments** — collaboration thread + steering controls