Repository navigation
Conversation
… banner The failed-deployment recovery becomes a full-width danger status block (UX spec 3.4, plan A1): the label names the failed version, the code ends the message's first sentence, the title is one --text-lg line, and the actions are buttons with one primary (Deploy again where the message says to deploy again, else the failed version's Logs). At phone width a status block's actions stack full width. Deployment step tiles become hairline inner cards; only a failed step keeps its tone's wash.
…e native admin line
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
clawsweeper
Bot
added
clawsweeper:intake:bug
|
Codex review: needs maintainer review before merge. What this changesThis PR presents failed deployments as danger status blocks with the failed version, inline error code, and responsive recovery buttons. Example: Version v7 fails with CONVERGENCE_DEADLINE_EXCEEDED while v6 remains selected.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep open: this collaborator-authored PR delivers a distinct presentation improvement, and the reviewed diff introduces no actionable correctness or security defect. Priority: P3 Before mergeNone. FindingsNone. Agent review detailsHow this fits togetherThe console renders authorized deployment records and caller permissions into Agent status and recovery navigation; the existing API continues to authorize the destination operations. flowchart TD
A[Deployment API] --> B[Agent detail renderer]
B --> C[Failure status block]
D[Shared status and button styles] --> C
C --> E[Logs or version draft]
Technical reviewBest possible solution: Use the shared status and button styles while retaining the existing recovery decisions, permission gates, and quiet polling behavior. Do we have a high-confidence way to reproduce the issue? The pinned main source renders the older recovery card without the inline error code; supplied before/after screenshots independently show that presentation difference. Is this the best way to solve the issue? The change uses existing presentation owners, removes card-local button styling, and preserves recovery behavior without adding a parallel implementation. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 384fe535f69b. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Likely related people:
LabelsLabel changes: No label changes. Label justifications:
Rating scale6/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. WorkflowClawSweeper edits this one comment on every review. Comment HistoryReviewed October 19, 2026, 10:43 PM ET / October 20, 2026, 02:43 UTC (Revision 3). |
The New version failed stories and the status block workflow now describe the danger block's label, inline code, single primary, phone stacking and the step tiles.
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
clawsweeper
Bot
added
clawsweeper:intake:bug
clawsweeper
Bot
removed
clawsweeper:intake:needs-environment
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
clawsweeper
Bot
added
clawsweeper:intake:bug
Problem
UX spec P4 (plan A1, spec 3.4, finding 1898). #2866 already put the API's own next step and Deploy again into the failed-deployment banner, but the banner was still the old beige "Deployment needs attention" card: a warning-coloured label that said nothing about which version failed, a 23-28 px title, no failure code (only in Deployment details further down), plain links styled by card-local rules, and step tiles that all carried a tone wash. The spec makes it the page's one status block: danger tone, the failed version in the label, the code in the message, one primary action.
Change
agents/detail.mjs: the recovery section is now a full-width.status[data-tone=danger]block. Its.status-labelreads "Deployment failed · vN", the title stays one line, and the body ends its first sentence with the failure code in<code>, for example "v7 did not deploy successfully (DEPENDENCY_UNAVAILABLE)." The rest of the message is unchanged from fix(console): show the error's own next step in the failed-deployment banner #2866. Each part is its own node, so a poll that reads back the same failure still writes nothing. The first action isbutton button--primaryand the others arebutton(secondary). Which actions appear, and in what order, is fix(console): show the error's own next step in the failed-deployment banner #2866's logic: Deploy again only when the API's message says to deploy again (never forRUNTIME_AUTHENTICATION_FAILEDor other credential failures), else Open vN Logs, then Open Credentials/Configuration. The region keeps its accessible name, "Deployment needs attention". The mockup shows Deploy again forCONVERGENCE_DEADLINE_EXCEEDED, but that is sample data: that code's message says to check the logs, then deploy a new version, so Logs stays the primary there.console.css: the block uses the.statusstripe and wash,--space-5/--space-6padding (--space-4under 520), a--text-lgsemibold title with a--space-2gap, and mono--text-mdfor the code. The card-local link chrome is gone because the actions use the C2 button classes. The muted edge on secondary actions stays (finding 1958, 3:1 on the wash). Under 520 px a status block's actions stack full width with a 44 px touch height (spec 4). Deployment step tiles become hairline inner cards on the surface (--radius-md), the marker carries the tone, and only a failed step keeps its wash.status-block-workflow.mdsteps 14-15, describe the new block, its single primary, the phone stacking and the tiles.Verification
Mockup:
agent-failed-1440.png/agent-failed-390.png(ux-design-1019 gist). Storybook stories: Pages/Agent detail "Deployment failed" and "New version failed, deploy again".Before: main before #2977. After: this head, which includes #2977's header.
Walkthroughs at 390 (head, Storybook frames): Deploy again opens the draft with Deploy new version focused, Open v7 Logs selects v7 and focuses its Logs tab.
Mockup (alignment target; its CONVERGENCE_DEADLINE_EXCEEDED message and Deploy again are sample data, see Change):
Acceptance (spec 5, P4), measured with the shots script on the Storybook frames:
.button--primaryon the page.overview-primary)The shots script's
primaryCountcounts all three class aliases and reads 2 both before and after. The second is native admin's "Open admin console" link, which stayshiddenon this page. The danger count rises by one: the block's stripe and its label each count, while the failed tile's red edge is gone. Its remaining items are the lowerCODE: messagerecord and Stop/Delete, which belong to P5 and P8 (spec 3.3 target 3).Tests:
console-agent-overview.test.mjs: the per-code above-the-fold test (RUNTIME_AUTHENTICATION_FAILED, DEPENDENCY_UNAVAILABLE, CONVERGENCE_DEADLINE_EXCEEDED at 1440x900 and 390x844) now also asserts the danger tone, the "Deployment failed · v1" label, the code in<code>, each action's class (onebutton button--primary: Deploy again or Open v1 Logs), that the page's only accent-filled control is that primary, and the full-width stack at 390 only. Against main's sources all 6 fail. With only main'sconsole.css, the three 390 cases fail on the stacking check.console-agent-overview,-deploy-again,-detailand-state. No assertion was dropped.--space-2). Its other nits are a 32 px gap below the block, which P5 reshapes, and console-wide button height, which is P12.Open-PR merge map (conflict hunks in the touched files, main vs this head): #2977 0/0, #2988 0/0, #2986 0/0, #2982 0/0, #2980 0/0, #2971 0/0, #2596 2/2, #2524 0/0, #2518 0/0, #2445 3/3, #1619 1/1, #906 0/0. No new conflict hunks.
Risks
Low. Console presentation only: no API change, and the action logic is #2866's. The phone-width stacking rule applies to every
.status-actions, as spec 4 asks, so other status blocks with actions also stack under 520. The step tiles lose the green and amber washes on complete and in-progress steps, but the markers keep those tones.