[freeqaz]

Problem

The controller ends an older version's deployment work with REVISION_SUPERSEDED (or REPOSITORY_REVISION_SUPERSEDED) when a newer version took over before it became current. The deployment status API reports that as failed, and the console had no case for it. A member who can read only older versions of a busy Agent saw "Latest visible deployment v2 · Failed", a red "Deployment work failed; check the recorded error and current version" stage, a warning banner "v2 deployment is recorded as failed … Live serving is unverified", and the code in red as an error, while the Agent was serving a newer version fine (dogfood finding 1353).

Change

• console/agents/list.mjs: supersededDeployment(record) (status failed with one of the two superseded codes) and deploymentOutcome(record) (superseded for those, the API status otherwise). The Agents list shows vN · superseded with "Superseded by a newer version." instead of the stored error.
• console/agents/detail.mjs:
  • Summary: vN · Superseded, note "Superseded by a newer version." No "Probably down" and no status-line banner from a superseded result alone. A hidden requested version still gets its own line.
  • Deployment activity and the version's deployment record: Recorded status/outcome: superseded, neutral grey "Deployment work" and "Completion recorded" stages, and a muted note naming the code ("This version did not fail; no action is needed.") instead of a red error and Logs link.
  • The diagnostics hint no longer tells the reader to "resolve" a superseded record first.
• console.css: a neutral marker for the superseded stage.
• Nothing names the newer version. The record does not carry it, and the console only shows what the Current version card already showed.
• Real failures are unchanged. The API is unchanged.
• Storybook: new story Pages/Agent detail → Deployment superseded by a newer version (deploymentSuperseded): v7 superseded while an unreadable v8 is selected. The console guide says a superseded result is neutral.

Verification

• New browser test Agent detail and list show a superseded deployment as neutral, not failed (tests/browser/console-agent-state.test.mjs). It covers the Agents list row, the summary, the stages, the activity and record outcomes, no banner, no failure text and no v2 for the unreadable newer version. It then turns the same record into RUNTIME_AUTHENTICATION_FAILED and checks that it still renders as failed with the banner. It fails on main (the list row times out on v1 · superseded) and passes on this branch, 20/20 at 2 CPUs (taskset -c 0,1).
• console-agent-state, console-agent-detail, console-agent-detail-2, console-agents, console-repository-dedicated and console.test: 166/166 pass.
• tsc --build, eslint and prettier on the touched files: clean.
• The test also runs diagnostics on the superseded version and checks that the hint no longer says "recorded deployment failed with".
• Open-PR overlap (shared-file rule): every open PR touching these files (feat: assign configured OpenClaw roles to Agent users #906, feat(auth): sign people in to occ with a device code (rfc-0019) #1619, Enable Codex OAuth with OpenShell-owned credentials #1559, fix(console): explain unavailable Agent actions before confirmation #836, fix(worker): settle initial provisioning on a superseding deploy or stop #2268, fix: preserve native plugin permissions across Harness selection and admission #2258, fix(console): grant Agent access to accepted Configuration Secrets #2255, Support custom Installation profiles and readable Preset starters #2253, Enable dedicated OpenClaw from Console with pinned native runtime #1685, feat(iam): grant the deployer exact read of the revision a deploy admits #1605, docs(specs): propose rfc-0019 for repository options without a repository driver #878) has the same conflicted files against this head as against main. For feat(auth): sign people in to occ with a device code (rfc-0019) #1619 the conflict hunks in console.css and fixtures.mjs match too (1 each). No new conflicts.
• Review: an independent review approved with nits. Applied: plainer copy, the guide names both codes, the negative check is scoped to the outcome panels, and diagnostics are covered. Declined: showing "Newer version hidden" for superseded. A superseded record does not prove the current version is newer, because the successor may still be pending or may have failed.
• Media (simulated Storybook fixture UI, deploymentSuperseded story frame served from prepare-assets.mjs output, headless Chromium, 1300×1000; not live backend proof):
  • Before (main console code), Agent detail:
  • After, Agent detail:
  • Before, Agents list:
  • After, Agents list:
  • walkthrough (after): detail page, Refresh deployment, Agents list.

Risks

Low. Display only. Only a failed record with one of the two superseded codes changes. If the controller ever used those codes for a real failure, the console would now understate it, but the worker sets them only when a newer or equal active version (or a successor) has taken over.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs maintainer review before merge.

What this changes

This PR displays superseded deployments as neutral outcomes across the console’s Agent list, detail page, deployment records, and diagnostics.

Example: Readable v7 has REVISION_SUPERSEDED while selected v8 is unreadable.

• Before: The console shows “v7 · Failed,” a red deployment stage, and a failure banner.
• After: The console shows “v7 · Superseded” with neutral stages, without naming v8 or claiming live serving.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	A focused, source-supported presentation fix with useful browser regression coverage and inspected screenshots; the repository’s UI media attachment gate remains unmet.
Proof confidence	🦐 gold shrimp (3/6)	Real behavior proof is not required for maintainer- or bot-authored pull requests.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Product

Kind: Bug fix · Worth it: Yes · Fix scope: Complete
User problem: An older deployment that was superseded appears to have failed and asks the operator to investigate an unnecessary error.
Reason: The correction has clear operator value, stays within the existing console owner, and retains genuine failure behavior.

Merge readiness

✅ Ready for maintainer review

Keep this PR open: current main still presents superseded deployments as failures, and this focused correction preserves genuine failure handling without changing the API or IAM.

Priority: P2
Reviewed head: 9e445cc3cbcb3ddad6b89a9d67612e7d2a343e10

Before merge

None.

Findings

None.

Tests

• Missing end-to-end proof: The supplied evidence demonstrates simulated console rendering rather than live backend supersession; repository-required native screenshot and video attachments remain outstanding.

Agent review details

How this fits together

The controller records deployment results; authorized API reads supply those records to console modules that render deployment history separately from live runtime health.

flowchart LR
Worker[Controller worker] --> Record[Deployment record]
Record --> API[Authorized deployment API]
API --> Outcome[Console outcome mapping]
Outcome --> List[Agent list]
Outcome --> Detail[Agent detail and diagnostics]

Loading

Technical review

Best possible solution:

Keep supersession neutral in the console while preserving raw deployment records, genuine failure guidance, and existing access boundaries.

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

Current-main source maps both superseded codes to failed presentation, and inspected before screenshots show that result; no target code or tests were run during this review.

Is this the best way to solve the issue?

The narrow console mapping fits the reported problem and preserves the API contract, real failure rendering, and the distinction between recorded deployment outcomes and live health.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 3a65e931a305.

Provenance checked

• Deployment summary and progress keeps the original intent (7c3ecbf: Clarify Agent deployment versions and add on-demand diagnostics #482 separates current selection, persisted deployment outcomes, and unverified live serving.)
• Failure banners and failed-version Logs changes intended behavior with a stated reason (b8c472a: fix(console): show hidden versions and a downed dedicated agent #849 explains hidden revisions and potentially down dedicated Agents; fix(agents): point runtime reads at the failed version without an active revision #748 makes real failed-version logs accessible.)
• Recorded-failure diagnostics hint keeps the original intent (d23cdbe: fix(console): explain slack-only diagnostics and keep recorded failures in view #755 keeps genuine recorded failures visible because Slack diagnostics cannot clear model or deployment failures.)

Testing

Proof path: in-process harness.

Security

None.

Evidence

What I checked:

• Introduced change: The pinned introduction diff limits the new outcome to failed records carrying REVISION_SUPERSEDED or REPOSITORY_REVISION_SUPERSEDED; other records retain their API status. (apps/controller/src/console/agents/list.mjs:34, 9e445cc3cbcb)
• Current-main behavior: Current main renders the raw failed status and stored error in the list and detail views; it has no superseded presentation case. (apps/controller/src/console/agents/list.mjs:185, 3a65e931a305)
• Deployment contract: The worker records supersession when a successor owns deployment lifecycle, and controllerWorkDeploymentStatus deliberately maps completion without activation to failed. (packages/occ/src/state/controller-work.ts:561, 9e445cc3cbcb)
• Inspected visual evidence: All four downloaded before/after screenshots were inspected and show the intended list and detail changes. The three changed production UI blobs at the media revision match the reviewed head. (apps/controller/src/console/agents/detail.mjs:291, 9e445cc3cbcb)
• UI evidence policy: Root policy requires screenshots and a short video as native GitHub attachments before merging UI changes; the PR instead links media stored in a historical repository commit. (AGENTS.md:438, 9e445cc3cbcb)
• Related work has a separate consumer: fix(worker): settle initial provisioning on a superseding deploy or stop #2268 addresses initial provisioning handles, whereas this PR addresses deployment presentation after opening an Agent.

Labels

Label changes:

• add P2: False failure indications confuse Agent operators, but the affected presentation does not interrupt deployment or message delivery.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR.

Label justifications:

• P2: False failure indications confuse Agent operators, but the affected presentation does not interrupt deployment or message delivery.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

Reviewed October 14, 2026, 12:46 PM ET / 16:46 UTC.