🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

if (
  flow.syncMode === "managed" &&
  (flow.status === "running" || flow.status === "waiting" || flow.status === "blocked") &&
  ageMs >=
    (flow.status === "running"
      ? staleRunningMs
      : flow.status === "waiting"
        ? staleWaitingMs
        : staleBlockedMs) &&
  linkedTasks.length === 0 &&
  !hasBlockingMetadata(flow)
) {
  ​// ... createFinding({ code: "missing_linked_tasks", ... })
}

if (
  flow.syncMode === "managed" &&
  (flow.status === "running" || flow.status === "waiting" || flow.status === "blocked") &&
  linkedTasks.length === 0 &&
  !hasBlockingMetadata(flow)
) {
  const threshold = flow.status === "running" ? staleRunningMs
                  : flow.status === "waiting" ? staleWaitingMs
                  : staleBlockedMs;

  findings.push(createFinding({
    severity: ageMs >= threshold ? (flow.status === "running" ? "error" : "warn") : "warn",
    code: "missing_linked_tasks",
    flow,
    ageMs,
    detail: "managed TaskFlow has no linked tasks or wait state",
  }));
}

Analyzed PR: #59672 at commit e1c85f9

_{Last updated on: 2026-04-02T13:57:35Z}

Greptile Summary

This PR hardens the task-flow registry by catching restore failures and degrading them into audit findings, and adds new listTaskFlowAuditFindings / maintenance helpers that are folded into the existing openclaw tasks audit and openclaw tasks maintenance commands. The implementation is well-structured and the new test files cover the primary scenarios (restore failure, stale/stuck flows, cancel reconciliation, pruning).

Two minor points worth noting:

• The missing_linked_tasks audit check has no minimum-age gate (unlike stale_running's 30-minute threshold), which could emit spurious error findings for brand-new managed flows before their first child task is linked.
• The --json output shape for both audit and maintenance changed structurally (summary.byCode is now nested under summary.tasks.byCode; auditBefore/auditAfter gained a tasks/taskFlows wrapper), which is a breaking change for any external JSON consumers.

Confidence Score: 5/5

• Safe to merge; all findings are P2 style suggestions with no blocking defects.
• No P0 or P1 issues found. The restore-failure hardening, audit logic, and maintenance reconciliation are all correct. The retry loop in finalizeCancelledFlow handles concurrent-update conflicts gracefully. The two P2 notes (no stale gate on missing_linked_tasks, JSON schema change) are informational and do not affect correctness or reliability of the primary runtime path.
• No files require special attention beyond the two P2 notes on task-flow-registry.audit.ts and commands/tasks.ts.

This is a comment left during a code review.
Path: src/tasks/task-flow-registry.audit.ts
Line: 225-240

Comment:
**`missing_linked_tasks` has no minimum-age gate**

Unlike `stale_running` (which requires `ageMs >= 30 min`), the `missing_linked_tasks` check fires immediately — including for a managed flow that was just created in `"running"` status before its first child task is linked. If task linkage can lag flow-status promotion by even one tick, this will emit a spurious error-severity finding. Consider guarding with a small minimum threshold (e.g. the same `staleRunningMs`) or restricting to the already-stale case:

```ts
if (
  flow.syncMode === "managed" &&
  (flow.status === "running" || flow.status === "waiting" || flow.status === "blocked") &&
  ageMs >= (flow.status === "running" ? staleRunningMs : staleWaitingMs) &&
  linkedTasks.length === 0 &&
  !hasBlockingMetadata(flow)
) {
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/commands/tasks.ts
Line: 231-238

Comment:
**Breaking change to `--json` audit summary shape**

The `summary` object previously returned `{ total, errors, warnings, byCode }` (from `summarizeTaskAuditFindings`). It now returns `{ total, errors, warnings, tasks: {…byCode…}, taskFlows: {…} }`, so `summary.byCode` is gone. Any downstream consumers (scripts, integrations) reading `summary.byCode` directly will silently break. Similarly, the maintenance `--json` output's `auditBefore`/`auditAfter` moved from a flat `TaskAuditSummary` to `{ tasks, taskFlows }`, which is also a structural break. Worth a note in the PR or a changelog entry if external consumers exist.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "Merge branch 'main' into vk/taskflow-har..." | Re-trigger Greptile}

Addressed the three review points in b6887a1010.

• missing_linked_tasks now waits until the flow is already stale for its current status before emitting a finding, so a freshly-promoted managed flow does not false-positive before its first child task is linked.
• tasks audit --json and tasks maintenance --json keep the existing task summary shape for compatibility and add TaskFlow data as additive fields instead of replacing the structure.
• Combined task + TaskFlow audit findings are now globally sorted before --limit is applied, so limited output still surfaces the highest-priority findings first.

Verification:

• pnpm test -- src/tasks/task-flow-registry.audit.test.ts src/tasks/task-flow-registry.maintenance.test.ts
• pnpm check