Best possible solution:

Close this stale branch and let any revived dashboard work come back as smaller, current-base PRs with current-head real behavior proof and clean protocol/release-owned-file handling.

Do we have a high-confidence way to reproduce the issue?

Yes for the patch blockers: source inspection on the PR head shows the changelog rollback and task-flow schema/handler mismatches. The user-visible dashboard/chat behavior itself is not reproduced or proven by inspectable current-head artifacts.

Is this the best way to solve the issue?

No; the dashboard direction may be useful, but this broad conflicting branch is not the best landing shape after the proof ask expired. A smaller staged implementation with clean protocol contracts and current-head proof is the safer path.

Security review:

Security review cleared: No concrete malicious or supply-chain defect was identified, but workflow and approval/proof boundary changes remain merge-sensitive risks if the work is revived.

AGENTS.md: found and applied where relevant.

What I checked:

• Live PR state and stale proof gate: Live GitHub shows the PR is open, external, unassigned, not draft, mergeable=CONFLICTING, mergeStateStatus=DIRTY, current head 63216a7, with labels including status: needs proof and rating: unranked krab. (63216a766d7b)
• No recent head or check activity: The latest PR commit is 63216a7 at 2026-06-20T17:32:33Z and the latest status-check completion in the live rollup is 2026-06-20T19:55:17Z, both more than 14 days before this review on 2026-07-07. (63216a766d7b)
• Proof ask age: The current status: needs proof label was re-applied at 2026-06-20T17:32:38Z after the final force-push cycle, and no current maintainer review, assignee, or requested reviewer is visible. (63216a766d7b)
• Prior proof request remains unanswered: The existing ClawSweeper review says the PR lacks inspectable current-head screenshots, recordings, terminal output, logs, or artifacts showing the dashboard/chat changes running after the fix. (63216a766d7b)
• Task-flow list contract still mismatches handler output: The PR head still maps taskFlows.list entries through mapTaskFlowDetail, so list responses include detail fields even though the list schema declares TaskFlowSummary entries. (src/gateway/server-methods/tasks.ts:292, 63216a766d7b)
• Task-flow detail schema still uses closed intersect branches: The PR head defines TaskFlowDetailSchema as an intersection of two additionalProperties:false object schemas, keeping the prior generated-client/schema-validator compatibility concern live. (packages/gateway-protocol/src/schema/tasks.ts:145, 63216a766d7b)

Likely related people:

• steipete: Authored and merged recent Control UI direction and plugin-tab seam work that the related modular-dashboard proposal explicitly builds on. (role: recent area contributor; confidence: medium; commits: bb724436150e, c730d8f1f1bb; files: ui/, src/gateway/methods/core-descriptors.ts)
• xingzhou: Local blame on the current checked-out main attributes the central task/protocol/workflow/changelog files sampled in this sparse checkout to the recent Codex runtime commit, making this a useful routing hint but not a full ownership conclusion. (role: recent adjacent contributor; confidence: low; commits: f14eb97ae7c5; files: src/gateway/server-methods/tasks.ts, packages/gateway-protocol/src/schema/tasks.ts, .github/workflows/workflow-sanity.yml)
• Peter Steinberger: Current main history and blame show recent top-of-changelog and repository-head work, relevant to the release-owned changelog rollback risk. (role: recent release/changelog contributor; confidence: medium; commits: b95b9e448794; files: CHANGELOG.md)

Codex review notes: model internal, reasoning high; reviewed against b95b9e448794.