[freeqaz-openai]

Fixes #3707.

An operator could lose Stop on the Agents list when the last deployment they could read had failed, even though the Agent could still be stopped. The list now uses the Agent's state and the member's operate permission to offer Stop. A readable deployment can still explain what confirmation will do. Delete permissions are unchanged.

The browser regression uses the same member throughout: failed v1 is readable and queued v2 is not. The list sends no Stop before confirmation, sends one after confirmation, and the Controller returns 202. Reading the Agent back shows that its desired state is stopped. The browser never requests v2, and Delete stays disabled.

The regression failed on the upstream base and passed with the fix. All 12 selected browser cases passed against the Controller with native IAM and in-memory state; the test supplies the failed v1 deployment response. The rebuilt Storybook preview covers the list and detail controls with simulated data.

Verification

Controller-backed browser, with in-memory state and a supplied failed-v1 response:

stop-walkthrough.webm

Storybook: Components / Stop Agent / Failed first deployment (simulated).

[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

The Agents list keeps Stop available based on Agent state and operate permission rather than a failed deployment from filtered revision history.

Example: Mixed Agent has readable failed v1, unreadable queued v2, and no selected version; mixed-operator has Agent operate permission.

• Before: The list hides Stop after reading v1's failure.
• After: Stop remains available and confirmation sends the existing authorized request without exposing v2.

Review scores

Measure	Result	What it means
Overall readiness	🦞 diamond lobster (5/6)	A focused repair with directly relevant visual evidence, meaningful Controller-backed regression coverage, and no actionable findings.
Proof confidence	🦞 diamond lobster (5/6)	The ordinary contributor proof gate does not apply to this collaborator-authored PR; inspected screenshots exercise the changed Console list through confirmation and accepted-stop feedback, supported by the Controller-backed same-member case with simulated v1 failure and no deployment worker.
Patch quality	🦞 diamond lobster (5/6)	No actionable review findings were identified.

Product

Kind: Bug fix · Worth it: Yes · Fix scope: Complete
User problem: An authorized operator cannot stop queued Agent work from the list when an older readable failure masks the newer revision.
Reason: The maintainer-authored repair restores an existing authorized action without new permissions, APIs, configuration, or revision disclosure.

Merge readiness

✅ Ready for maintainer review

This PR fixes a current-main defect in authorized Stop availability; no actionable introduced bugs were found.

Priority: P2
Reviewed head: 3bcba8dc3b0743f713e5769704ce47a58cdcad09

Before merge

None.

Findings

None.

Agent review details

How this fits together

The browser Console combines Agent state, filtered revision history, and advisory permissions into row controls; the Controller independently authorizes Stop and records the requested stopped state.

flowchart TB
A[Operator] --> B[Agents list]
C[Filtered revision history] --> B
D[Agent state and permission advice] --> B
B -->|Confirmed Stop| E[Controller API]
E --> F[Exact Agent authorization]
F --> G[Stopped state and reconciliation work]

Loading

Technical review

Best possible solution:

Keep Stop availability tied to Agent state and exact operate permission while using readable deployment history only to explain confirmation.

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

Current-main source establishes the failed-v1/hidden-v2 path, and the supplied before/after screenshots support the reported regression; no target code was executed during this review.

Is this the best way to solve the issue?

Removing the filtered-history suppression is the smallest complete repair for the linked issue and reuses existing confirmation, authorization, and lifecycle owners.

AGENTS.md: found and applied where relevant.

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

Provenance checked

• Failed-deployment suppression in list actions and its regression expectations changes intended behavior with a stated reason (0a17e75: fix(console): disabled reasons name the grant and who gives it #3695 hid Stop after an observed failed first deployment to match Agent detail and avoid offering an apparently ineffective action.)
• Readable deployment outcomes, confirmation wording, flow, and Storybook description changes intended behavior with a stated reason (84108ce: fix(console): say stop cancels a first deployment only when one is in progress #3715 distinguished cancellation from gateway interruption; this PR retains that wording logic and explains why filtered failure history cannot suppress list Stop.)

Testing

Proof path: shipped entry point.

Security

None.

Evidence

What I checked:

• Introduced repair: The pinned introduction diff removes failedFirst and its action refresh, retaining deployment outcomes for confirmation wording and preserving stopped, deleting, unsettled, and permission gates. (apps/controller/src/console/agents/collection.mts:678, 3bcba8dc3b07)
• Current-main defect remains: Fetched main still hides Stop when the newest readable deployment failed and no version is selected, even though a newer revision may be hidden. (apps/controller/src/console/agents/collection.mts:688, 1258c43f75fb)
• Independent permission contracts: listRevisions filters each revision by read permission; stopAgent checks operate on the exact Agent before cancelling provisioning, changing desired state, and recording reconciliation work. The HTTP handler returns 202 and appends audit evidence. (packages/occ/src/index.ts:10784, 3bcba8dc3b07)
• Focused Controller-backed regression: The new browser case uses production Console, Fastify, Controller, and Native IAM code with in-memory state. It verifies filtered v1-only history, no v2 requests, disabled Delete, confirmation before one Stop request, 202, and stopped-state readback; only v1's failed deployment response is supplied. (tests/browser/console-agent-overview.test.mjs:478, 3bcba8dc3b07)
• Discussion and original intent: Keep Stop available when an operator cannot read the newest queued revision #3707 specifies this same-member scenario. The discussion at fix(console): disabled reasons name the grant and who gives it #3695 (comment) identified the filtered-history defect. fix(console): say stop cancels a first deployment only when one is in progress #3715 explains the earlier failed-first-deployment suppression and confirmation wording.
• Visual evidence inspected: The four prepared screenshots show the missing Stop before the fix, restored Stop with Delete disabled, confirmation, and accepted-stop feedback. Both linked Storybook images were also inspected and show the retained detail-page behavior. The linked recording could not be inspected: it was absent from the prepared manifest, scratch downloads failed to write, ffmpeg was unavailable, and no browser playback tool was available; this is a reviewer infrastructure limit. (3bcba8dc3b07)

Likely related people:

• Free Wortley: Raw commit 1605e30 adds apps/controller/src/console/agents/collection.mts:522 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 1605e3094366; files: apps/controller/src/console/agents/collection.mts)

Labels

Label changes:

• add P2: This repairs an authorized operator action under partial revision visibility, with a limited Console surface.
• add proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence.
• add rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR.

Label justifications:

• P2: This repairs an authorized operator action under partial revision visibility, with a limited Console surface.
• rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR.
• 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 28, 2026, 7:26 AM ET / 11:26 UTC.