[freeqaz]

Problem

When the Agent page's first Deployment activity read outlasts FIRST_ACTIVITY_WAIT_MS (2 s), the page shows with a 128 px "Loading the most recent visible deployment…" card. The panel that replaces it has a different height, so everything below it moves after the page is already on screen (finding 2163). Measured with the read held past the wait (version tabs' top edge, 1440 / 390):

Recorded outcome	Draft view	Version view
Completed	-65 / -69 px	-29 / -32 px
In progress	+227 / +427 px	+263 / +463 px
Failed	+164 / +254 px	+227 / +338 px
Read error	not measured	+89 / +147 px

Three smaller pieces add to it: the summary's "Reading recorded deployment status." note disappears (-20 px at 390), a stat value grows by 3 px when its loading text becomes a badge, and the version's deployment record grows from one loading line to two rows (+36 px).

The browser tests also wait for "Recorded status: X" in about 30 places, each with its own copy of the fold rule (two files even had the same openFoldedDetails helper). Changing the rule meant touching every one of them.

Change

Product (apps/controller/src/console/agents/detail.mjs, console.css):

• The loading stand-in is now the folded panel's single row (63 px), not a card.
• A first record that lands after the page has shown fills that folded row without opening it. The Agent summary above already shows its outcome badge, and a failure's card still leads the page (finding 2094). Cleanup, startup warnings and an overview refresh error still open the details, and every later change opens them as before. A newer version found later (a deploy the reader is watching) is unaffected: its first record opens the details.
• The latest-deployment note keeps its line when the page shows while it is still loading (a note already empty when the page first shows gives the line back, so a fast load looks as before). A stat value is as tall as its badge, and the version record's loading state fills the same two rows a recorded outcome does.
• The page counts as shown only once it actually is (after the loading page's minimum time, finding 1587), so a record landing in that window still opens as before. The loading row stays one line on narrow phones.

Tests:

• New tests/browser/console-deployment-activity-helpers.mjs holds the rule once: expectDeploymentOutcome(page, label, { folded }), openFailureDetails, openDeploymentActivity, deploymentDetailsOpen, expectVersionRecord and deploymentRecordUrl. With folded unset (a page's first record), a folded panel is accepted only when the summary shows the same outcome, and the helper then opens it. folded: true|false asserts the state where the rule fixes it (every change after the first record, a routine completion, a failure under its card).
• 7 browser files now use it (73 call sites, 22 of them the record URL). The duplicated openFoldedDetails (2 files) and nextFrames (2 files; now in console-agents-browser-helpers.mjs) are gone, as is console-agent-overview's local deploymentUrl.
• New regression test a late first deployment read moves nothing above the version tabs (console-agent-overview): one page, fake clock, a control load (a pending record read in time still opens, and the empty note takes no space) plus 8 late loads (4 outcomes x draft/version view), measured at 1440 and 390. It replaces "Deployment activity appears once with its recorded status" (console-agent-state), whose stand-in checks it keeps. It fails on main.
• console-retained-revalidation waited for .deployment-evidence to mean "the panel replaced the placeholder"; the stand-in now has that class, so it waits for the panel's details.

Docs: flow (agent-editing + history), reference (versions-and-channel-drafts) and guide (agent-details) describe the late-first-record rule. Storybook: Pages/Agent detail / Deployment activity loading now uses an in-progress record and describes the still layout.

Verification

Measured after the change, with the read held past the wait (version tabs move, 1440 / 390):

Recorded outcome	Draft view	Version view
Completed	0 / 0	0 / 0
In progress	0 / 0	0 / 0
Read error	0 / 0	+4 / +25 (the version record's error block)
Failed	the recovery card only: +230 / +323, by design (finding 2094)	the card plus the version record's failure evidence: +255 / +371

The regression test asserts exactly that: the overview never changes height; the tabs move only by the card above and the viewed version's record; and they do not move at all for Completed and In progress (both views) or a read error on the draft.

Before / after, In progress on the draft at 1440, page shown with the read held, then after it lands:

	Shown	Landed
Before
After

Completed on the version view at 1440:

	Shown	Landed
Before
After

Video (In progress, draft, 1440; the read lands about 1.5 s after the page shows): before, after. Screenshots and video come from the real controller with a held, contract-shaped deployment record.

Storybook Pages/Agent detail / Deployment activity loading (simulated API, built by this PR's Console Storybook job; record reads take 4 s), page shown and then landed:

	Shown	Landed
1440
390

Storybook video, 1440.

Checks run locally:

• eslint and prettier on the touched files: clean.

• Touched browser files, one run each, main and this head (a2622f8) alternating file by file on a quiet host: all pass. Wall time:

  File	main	this branch
  console-agent-state	26.7 s	23.8 s
  console-agent-overview	37.8 s	45.7 s
  console-agent-detail	39.7 s	38.9 s
  console-agent-detail-2	47.3 s	46.9 s
  console-agents	43.4 s	42.6 s
  console-repository-dedicated	5.8 s	5.7 s
  console-agent-deploy-again	15.6 s	15.6 s
  console-retained-revalidation	40.4 s	40.8 s
  total	256.7 s	260.0 s

  console-agent-overview gains the new regression test (about 9 s: a control load plus eight late loads); console-agent-state loses the test it replaces (about 3 s). The other files are unchanged within noise.

• Pin runs, 20 per touched browser file, each pinned to 2 CPUs, on a2622f8: 20/20 for all eight files (console-agent-state, console-agent-overview, console-agent-detail, console-agent-detail-2, console-agents, console-repository-dedicated, console-agent-deploy-again, console-retained-revalidation). A first console-agent-state pin round went 19/20 while the host's load average spiked past 500: that run took 1047 s instead of about 40 s and timed out in page.goto before any changed code ran. A rerun once the load had settled went 20/20.

• Whole console browser suite (node --test --test-concurrency=6 tests/browser/*.test.mjs) on a2622f8: 856 of 857 pass in 188 s. The one failure, docs-compute-matrix, is local only: github-slugger is not installed in this checkout's docs-site tooling, and main fails the same way here. CI's Console Browser jobs pass it.

• New-conflict check against the 16 open PRs touching these files (git merge-tree against main and against this head): no new conflicted files.

Risks

• Behaviour change: on a slow first read (over 2 s) a pending, failed, neutral or unreadable record now starts folded. The summary's badge (and for a failure, its card) carries the outcome; the details are one click away. Cleanup, warnings and refresh errors still open them.
• Read error on the version view still moves the tabs by 4 px (1440) / 25 px (390): the version record's error block is taller than its loading rows.
• A late failed record moves the tabs by about 65 px more than before (+230 instead of +164 at 1440 on the draft). Before, the taller loading card absorbed part of the recovery card that appears above; now the overview keeps its height and the recovery card, which leads the page on purpose (finding 2094), is the only thing that moves it.
• A late first read error's alert sits in the folded details, so it is not announced; the summary says "Unavailable" and "Recorded deployment status could not be read."
• Tests: expectDeploymentOutcome opens a folded first record for the caller. Sites that assert a specific fold state pass folded; the regression test's control load pins the in-time case.
• An internal review found no blocking issues; its timing, flake, phone-width and coverage notes are applied in the second commit.

[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 stabilizes Agent version controls when the first deployment-status response arrives after the page appears.

Example: At 1440 px, an Agent draft’s first running-deployment response arrives after the 2-second reveal.

• Before: The loading card becomes expanded deployment details, moving the version tabs down by 227 px.
• After: The response fills a folded row and updates the summary badge, leaving the version tabs in place.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused, useful UI repair with inspected browser evidence, meaningful regression coverage, and no identified correctness blocker.
Proof confidence	🐚 platinum hermit (4/6) ✨ media proof bonus	Sufficient (screenshot): Inspected real-controller before/after screenshots show a held first running-deployment response filling the folded row while the version controls retain their position; the response is synthetic and proves UI behavior, not runtime deployment. Phone screenshots and recordings are linked, but additional inspection was blocked by the review environment.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Product

Kind: Bug fix · Worth it: Yes · Fix scope: Complete
User problem: Version controls move after the Agent page is visible when its first deployment-status read is slow.
Reason: The collaborator-authored direction addresses measured interaction instability and explicitly records the disclosure and recovery tradeoffs.

Merge readiness

✅ Ready for maintainer review

Keep open: this PR addresses a layout shift still present on main, and the review found no blocking introduced defect.

Priority: P2
Reviewed head: a2622f83d69ba5b4ca08c42dba9d0a4d8186de68

Before merge

None.

Findings

None.

Agent review details

How this fits together

The controller-served Console reads authorized Agent and deployment records, then renders summary facts, deployment details, and version controls in the browser.

flowchart TB
  A[Agent details browser page] --> B[Controller resource APIs]
  B --> C[Agent and deployment records]
  C --> D[Summary outcome badge]
  C --> E[Deployment disclosure]
  D --> F[Version controls]
  E --> F

Loading

Technical review

Best possible solution:

Keep the repair in the existing deployment panel and preserve explicit expansion for subsequent outcomes, warnings, cleanup, and recovery.

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

Main’s loading-card replacement and initial disclosure expansion explain the reported movement, supported by the supplied before screenshots; no target code was executed during this review.

Is this the best way to solve the issue?

The patch repairs the existing presentation owner, reserves the affected rows, and distinguishes first arrival from later changes without changing API or deployment behavior.

AGENTS.md: found and applied where relevant.

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

Provenance checked

• Initial deployment panel replacement and bounded reveal keeps the original intent (fix(console): show Agent detail without moving it and read its deployment record once #2537: Hold the initial page until deployment facts settle, with a bounded wait so slow reads cannot hide the controls indefinitely.)
• Initial disclosure expansion changes intended behavior with a stated reason (4bf2532: Expose pending work and consequential evidence while folding routine completion; this PR explains its narrow late-first-read exception.)
• Summary stat sizing keeps the original intent (6c5bbd6: Present selected version, latest visible deployment, and unverified live serving as distinct facts with outcome badges.)
• Leading failure recovery keeps the original intent (75ebcc2: Keep failed-version recovery above the overview and fold duplicate failure details.)

Testing

Proof path: shipped entry point.

Security

None.

Evidence

What I checked:

• Introduced behavior: Only the initial panel receives page visibility state; its late first result remains folded, while cleanup, warnings, overview errors, and subsequent evidence changes retain expansion. (apps/controller/src/console/agents/detail.mjs:809, a2622f83d69b)
• Current-main gap: Main retains the older loading card and initial expansion rule; the production files have no base movement since the pinned merge base. (apps/controller/src/console/agents/detail.mjs:794, e5fc76148cf8)
• Browser regression coverage: The replacement test measures four outcomes across draft and version views at desktop and phone widths, includes an in-time control, and preserves the intentional failure-card movement. (tests/browser/console-agent-overview.test.mjs:1253, a2622f83d69b)
• Accepted presentation tradeoffs: The collaborator-authored PR explicitly accepts folding a late first read, including its error alert, while keeping the summary outcome visible; it also preserves the leading recovery card established by fix(console): show a watched deploy failure as a reload does #3008. (75ebcc2a270b)
• Exact-head checks: CI Required, Console Browser, Console Browser 2, and Static Checks passed for the reviewed head; First Agent Smoke remained in progress. (a2622f83d69b)
• Visual evidence inspected: Four downloaded before/after desktop screenshots show the loading-to-running transition and stable after-fix placement. Source media: https://gist.githubusercontent.com/freeqaz/dc9573a8f28412f4b0f955290c66d90c/raw/ee2ae1e50f1a634586f395cb6d510623dfe7a7e4/after-running-draft-1440-landed.png . The prepared manifest contains no video contact sheets; additional downloads were blocked by the sandbox, the Gist API returned 403, and the web fallback reported inaccessible media. (a2622f83d69b)

Review metrics

Metric	Value	Why it matters
Production and test scope	Production +69/-9 lines; browser tests and helpers +517/-372 lines.	The test growth covers the delayed-response layout matrix and consolidates disclosure handling across existing callers.

Labels

Label changes:

• add P2: Delayed initial reads move visible version controls, creating limited Console interaction friction.
• add proof: sufficient: Contributor real behavior proof is sufficient.
• add proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit 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: Delayed initial reads move visible version controls, creating limited Console interaction friction.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR.
• proof: sufficient: Contributor real behavior proof is sufficient.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence.

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 21, 2026, 9:30 PM ET / October 22, 2026, 01:30 UTC.