[freeqaz]

Problem

Dogfood finding 2368 (a residual of the earlier failed-deploy layout fix): on a failed deploy, the eyebrow "Deployment failed · v1" repeated the heading "v1 deployment failed". On the failed version's Configuration tab, the version's deployment record repeated the same error text below the block.

Change

• The failed-deployment block shows the "Deployment failed · vN" label only above a serving title ("This Agent may be offline"), where it adds the version. A title that already says "vN deployment failed" stands alone.
• While the block leads with the viewed version's failure, that version's deployment record shows "Recorded outcome: Failed" and "The error and its next step are at the top of this page." instead of a second copy of the error. Other versions' records, and records the block does not cover, are unchanged.
• The Versions rail already marks the failed version "Failed" on main (see the screenshots), so this PR does not change it.

Verification

• tests/browser/console-agent-overview.test.mjs: the label is hidden under a "vN deployment failed" title and shown with "This Agent may be offline". With the record in view at 1440x900 and 390x844 the error shows once. tests/browser/console-agent-state.test.mjs: Refresh deployment keeps the record pointing at the block.
• The new assertions fail on main and pinned 20/20 at 2 CPUs. After merging main, console-agent-overview, console-agent-state and console-agent-detail pass (138 tests).

Before (main), 1440 and 390:

After:

Risks

Low, console only. The record's error text is still one click away in Deployment details and on the Logs tab.

[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 removes a redundant failure label and replaces the matching version record’s repeated error with a pointer to the recovery block.

Example: Viewing failed v1 with RUNTIME_AUTHENTICATION_FAILED on its Configuration tab.

• Before: The recovery block repeats the failure heading, and the version record repeats the error.
• After: One heading identifies the failure, and the version record points to the error and next step above.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	A useful, focused patch with convincing static visual evidence, bounded by incomplete repository-required interaction proof and an unclassified failing CI lane.
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: A failed deployment repeats its heading and error, making the Agent page longer and harder to scan.
Reason: The visible duplication is demonstrated, the repair is narrow, and the collaborator-authored PR establishes owner direction.

Merge readiness

✅ Ready for maintainer review

Keep this PR open: it addresses duplicated failure text still present on main, and no introduced runtime defect was found.

Priority: P3
Reviewed head: bb2c54b734e2427d5d2ce2c45ce452f92d19ec4c

Before merge

None.

Findings

None.

Tests

• Missing end-to-end proof: Provide the repository-required walkthrough of the changed failure display and refresh path from rebuilt Storybook; the reported base-fail/head-pass browser runs were not independently executed.

Agent review details

How this fits together

The Console Agent detail page consumes deployment records and permission answers, then renders recovery actions and the viewed version’s recorded outcome.

flowchart TD
  A[Deployment API] --> B[Agent detail page]
  C[Permission answers] --> B
  B --> D[Recovery block]
  B --> E[Version deployment record]
  D --> F[Logs or configuration recovery]
  D -->|Matching failed version| E

Loading

Technical review

Best possible solution:

Keep the existing recovery and evidence owners, with deduplication limited to the failed revision whose recovery block is visible.

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

Current-main source independently renders both copies, and the supplied before screenshots show the duplication on desktop and phone; no target code was run during this review.

Is this the best way to solve the issue?

The focused change is appropriate: it preserves serving-impact version labels, leaves other versions’ records intact, and retains detailed evidence in Deployment details.

AGENTS.md: found and applied where relevant.

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

Provenance checked

• Failed-deployment label changes intended behavior with a stated reason (fix(console): show the error's own next step in the failed-deployment banner #2989: Identify the failed version in a single danger status block while keeping its code and recovery action prominent.)
• Viewed version deployment record changes intended behavior with a stated reason (Clarify Agent deployment versions and add on-demand diagnostics #482: Keep durable deployment results and exact-version evidence separate from current observations; later refactoring preserved that separation.)

Testing

Proof path: shipped entry point.

Security

None.

Evidence

What I checked:

• Introduced change: The pinned introduction changes only three Console modules and two browser test files; the runtime Dockerfile change belongs to base movement. (bb2c54b734e2)
• Current main retains duplication: Main renders deploymentResult unconditionally in the version record, while the recovery block independently renders the latest failed deployment. (apps/controller/src/console/agents/deployment-evidence.mts:684, b7aa56a2ac19)
• Scoped presentation change: The record suppresses repeated failure output only when the recovery block covers the selected revision; hiding recovery clears that state, and newly created records receive it. (apps/controller/src/console/agents/detail.mts:1929, bb2c54b734e2)
• Visual evidence inspected: All four linked desktop and phone images were inspected locally. Before images show duplicate headings and error text; after images show the single heading and record pointer. The displayed Compute is test-memory-lifecycle, so these establish Console presentation rather than live deployment behavior. (bb2c54b734e2)
• Applicable visual proof requirement: AGENTS.md requires changed-source Storybook inspection and uploaded screenshots plus a short walkthrough video; the PR body, comments, and prepared media contain screenshots but no video. (AGENTS.md:459, bb2c54b734e2)
• Feature history and intent: fix(console): show the error's own next step in the failed-deployment banner #2989 established the version label and recovery presentation; fix(console): show a watched deploy failure as a reload does #3008 moved watched failures to the top and folded repeated details. This PR explains its narrower deduplication change. (apps/controller/src/console/agents/deployment-recovery.mts:168, b7aa56a2ac19)

Likely related people:

• Free Wortley: Raw commit 5227270 adds apps/controller/src/console/agents/deployment-recovery.mts:165 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 5227270c886e; files: apps/controller/src/console/agents/deployment-recovery.mts)
• stevenlee-oai: Raw commit 7c3ecbf adds apps/controller/src/console/agents/detail.mjs:814 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: medium; commits: 7c3ecbfce4fa; files: apps/controller/src/console/agents/detail.mjs)

Labels

Label changes:

• add P3: This is bounded Console presentation polish; existing failure guidance and recovery actions remain available.
• 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:

• P3: This is bounded Console presentation polish; existing failure guidance and recovery actions remain available.
• 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.

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Upload the final-revision Console walkthrough required by repository policy.
• Inspect the PostgreSQL Application failure and establish whether it is caused by this diff.

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 24, 2026, 7:17 PM ET / 23:17 UTC.