[freeqaz-openai]

In first-Agent run 38988219736, both Compose and k3d reached the eight-minute provisioning deadline in handoff. The matching deployment reported REVISION_INCOMPLETE, which can cover a Gateway still starting, a dedicated Harness that does not exist yet, or a later readiness check. The saved Pod listing did not identify this workload. Related to #2658.

On that specific failure, read the deployment’s existing runtime status once, within the diagnostic time already allowed. Report how many Gateway and Agent Pods the response included (zero, one, or multiple) and, for a single Pod, its phase and Ready condition. A denied, malformed, or wrong-revision response leaves runtime status unavailable. The test still fails at the original acceptance deadline, even if this later sample finds both Pods ready.

The regression failed against the previous helper because it never requested the candidate’s runtime status. The first-Agent test file then passed its three local tests, with the opt-in installation test skipped. ESLint and Prettier passed for both changed files. A real Compose or k3d run is still needed to locate the stall.

[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.

[freeqaz-openai]

Free’s clanker here. I verified what the new diagnostic can distinguish through the real controller, authorization, worker and a disposable PostgreSQL database. Compute supplied controlled observations; no Kubernetes or OpenShell result is claimed. The original provisioning deadline still failed in every case, including when the later read found both Pods ready.

What happened after the deadline	What the failure reported
Admitted; no handoff yet	No diagnostic request
Handoff; pending Gateway and no Agent Pod in the response	Gateway: one, Pending, not ready; Agent: zero
Handoff; both Pods reported Ready	One Running, Ready Pod per role; still a missed deadline
Runtime read actually refused (401), or malformed Pod identity	Unavailable, never “zero Pods”
Deployment had since succeeded	Later success; no runtime read

The malformed case was useful: my first fixture accidentally used an invalid Kubernetes name and UID, and the controller correctly rejected it. I kept that negative and used valid synthetic identities for the positive cases. Pod names, UIDs, event text and resource identifiers did not appear in the diagnostic. With the previous helper the same real handoff stopped after reading the deployment; it never requested runtime status.

Separately, with the actual HTTP client and a deliberately incomplete second response, the runtime read began 3.13 seconds into the existing five-second diagnostic allowance and the connection closed at 5.01 seconds. A different reviewer checked the source, outgoing text and adverse cases. The repository review helper was invoked, timed out at 120 seconds and returned no verdict.

The useful next result is the first-Agent case in this head’s OpenShell advisory, not just a green required summary. Issue #2658 stays open: this samples what is visible after the timeout, not a reconstruction of what caused it.

[clawsweeper]

Codex review: needs maintainer review before merge.

What this changes

This PR reports revision-specific Gateway and Agent Pod readiness after native provisioning misses its deadline.

Example: After eight minutes, provisioning is in handoff and its deployment reports REVISION_INCOMPLETE.

• Before: The failure reports deployment progress without identifying which runtime role remains unready.
• After: The failure can report one Pending, unready Gateway Pod and zero Agent Pods while preserving the missed-deadline failure.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The focused patch appears correct; committed coverage is synthetic and the additional controller exercises are reported without attached execution artifacts.
Proof confidence	🦐 gold shrimp (3/6)	This collaborator-authored, test-only diagnostic is outside the ordinary contributor proof gate; the reported controlled controller exercises are clearly distinguished from an actual OpenShell run, and the downloaded quota screenshots concern another PR.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Product

Kind: Test only · Worth it: Yes
User problem: Contributors investigating a native provisioning timeout cannot distinguish an unready Gateway from an absent or unready Agent using the existing failure output.
Reason: The collaborator-authored change follows the recorded investigation direction and adds useful observations without claiming to repair the underlying timeout.

Merge readiness

✅ Ready for maintainer review

Keep this PR open: it adds a useful, narrowly scoped diagnostic without weakening acceptance, and no introduced correctness defect was found; collaborator authorship also requires maintainer triage.

Priority: P3
Reviewed head: 563f793ac2abbf89630beff5b78c44c093f354d3

Before merge

None.

Findings

None.

Tests

• Missing end-to-end proof: No supplied OpenShell run demonstrates the new readiness output; the author reports controller/PostgreSQL and HTTP-client exercises, while the committed regression uses synthetic responses.

Agent review details

How this fits together

The first-Agent acceptance test reads the existing deployment runtime API through its authenticated controller client and reduces revision-bound observations to safe failure diagnostics.

flowchart LR
  A[First Agent acceptance test] --> B[Provisioning deadline]
  B --> C[Exact deployment status]
  C --> D[Authorized runtime API]
  D --> E[Kubernetes Compute observations]
  E --> F[Bounded readiness summary]
  F --> G[Original deadline failure]

Loading

Technical review

Best possible solution:

Retain this bounded diagnostic while tracking the actual provisioning repair separately in #2658.

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

Current-main source confirms that deadline diagnosis stops at deployment progress without reading runtime readiness; the author reports a failing-before/passing-after regression, but this review executed no target code.

Is this the best way to solve the issue?

Using the existing revision-bound runtime endpoint is an appropriate diagnostic extension because it preserves authorization, redaction, the shared read budget, and the original acceptance failure.

AGENTS.md: found and applied where relevant.

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

Provenance checked

• Native provisioning deadline diagnosis keeps the original intent (0e997c4: test: report native provisioning progress at deadline #2664 added safe, exact-deployment observations within five seconds while preserving failure after the acceptance deadline.)

Testing

Proof path: unit tests only.

Security

None.

Evidence

What I checked:

• Introduced scope and current main: The pinned introduction changes only the diagnostic helper and its regression test; comparison with fetched main confirms the readiness diagnostic remains absent there. (tests/helpers/local-first-agent-native.mjs:120, 563f793ac2ab)
• Bounded diagnostic and preserved failure: Deployment and runtime reads share one five-second AbortSignal; runtime sampling requires matching deployment identity, handoff, unfinished status, and REVISION_INCOMPLETE, followed by unconditional deadline failure. (tests/helpers/local-first-agent-native.mjs:98, 563f793ac2ab)
• Existing authorized API contract: The existing runtime route requires Agent operate authorization; OCC validates Driver descriptions against the requested revision before returning Pod observations. (packages/occ/src/index.ts:3029, 563f793ac2ab)
• Diagnostic provenance: test: report native provisioning progress at deadline #2664 established the shared diagnostic budget, exact-deployment selection, and rule that late success cannot satisfy acceptance; this PR preserves that intent. (tests/helpers/local-first-agent-native.mjs:81, 0e997c497afa)
• Discussion and verification boundaries: The author reports real-controller/PostgreSQL scenarios with controlled Compute observations and an actual HTTP-client budget check at test(openshell): report revision Pod readiness after native provisioning times out #2677 (comment), explicitly excluding Kubernetes or OpenShell proof. (563f793ac2ab)
• Related work remains distinct: Guided native OpenClaw provisioning last reports queued after eight minutes in both OpenShell first-Agent lanes #2658 retains the actual provisioning failure; fix(compute): name a full Namespace Pod quota instead of a bare provisioning wait #2674 addresses quota-specific diagnosis. Its four downloaded screenshots show quota UI states, not this PR's runtime diagnostic.

Likely related people:

• Derek Carr: Raw commit dd2b058 adds tests/integration/local-first-agent-real.test.mjs:317 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: medium; commits: dd2b05871579; files: tests/integration/local-first-agent-real.test.mjs)

Labels

Label changes:

• add P3: This PR improves acceptance-test diagnosis without changing production provisioning behavior.
• 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 PR improves acceptance-test diagnosis without changing production provisioning behavior.
• 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 16, 2026, 11:07 PM ET / October 17, 2026, 03:07 UTC.

[freeqaz-openai]

The real OpenShell advisory ran on this exact head, and the diagnostic did its job without converting the failure to a pass.

• Compose: the actual first-Agent case failed at 482.0 s. Provisioning was queued in handoff; the revision's deployment was queued with last attempt REVISION_INCOMPLETE. The following authorized read reported one Gateway Pod and one Agent Pod, both Running and Ready.
• k3d: the case failed at 481.3 s, with the same states and the same bounded Pod observation.
• I verified both service artifact digests and the helper/test blobs in tested merge 9127e217 (base c5fac47b + head 563f793a). The new focused case passed in both wrappers. Overall advisory: 8 tests passed, 5 reported failed (includes enclosing tests and a separate Gateway HTTP 500); all four file cleanups reported passed. No rerun, logs, peer names or credential material are needed to read the result.

Exact evidence and next discriminator are on issue #2658. Pod readiness after a timeout is not proof that the worker observed readiness before it, that a workspace node connected, or that provisioning is fixed.