fix(ui): collapse non-terminal internal tool errors by harjothkhara · Pull Request #90122 · openclaw/openclaw

harjothkhara · 2026-06-04T02:25:34Z

Summary

Fixes #89683. In Control UI / WebChat, a failed internal tool call was promoted to a prominent red "Tool error" banner in the chat timeline even when the turn produced a clean final assistant reply, for example a hidden shell search that exits 1 for no matches (toolResult { isError:true, status:"failed", exitCode:1 }). The banner competed with the real answer and leaked internal tool activity as a product failure.

Codex marks any non-zero exec exit as failed and cannot distinguish a benign no-match from a fatal error (verified in the @openai/codex runtime: codex-rs/core/src/tools/events.rs:341-345 returns Err for exit_code != 0, and :474-478 sets ExecCommandStatus::Failed). So the fix is OpenClaw/UI-side and runtime-agnostic: it normalizes the chat projection boundary so a failed internal tool that is not the turn's outcome is not surfaced as primary error content, while keeping full detail in the existing expand/activity view.

What it does

buildChatItems now stamps each tool MessageGroup with a turnSucceeded signal (a single backward pass: a failed tool group whose turn still produced an assistant reply with text, before the next user message, is non-terminal).
grouped-render gates the error promotion (hasError / toolMessageHasError, which drive the red --error styling, the "Tool error" label, the error badge, and auto-expand) on turnSucceeded !== true.
Non-terminal internal tool failures render as a normal collapsed tool summary; the failed output stays available on expand. Genuinely terminal tool failures (no assistant reply follows, such as aborted/in-progress turns) still surface as before, and showToolCalls: false still hides tool activity entirely.

Collision check

No direct competing PR currently claims or closes [Bug]: Control UI chat surfaces failed internal tool calls as visible red error banners #89683; this PR is the only direct fix found for the reported Control UI / WebChat rendering issue.
fix(reply): suppress direct tool-error progress leaks #89975 is related but complementary: it covers the outbound auto-reply / direct-chat dispatch surface, while this PR covers the Control UI / WebChat render path. There is no file overlap.

Boundary choice

The Codex runtime correctly reports non-zero internal tool exits as failed. The UI renderer has the additional turn-completion context needed to decide whether that failed internal tool should be the primary visible outcome. This keeps terminal failures prominent while collapsing non-terminal internal failures after a clean assistant reply.

Verification

Local, Node 22, real main base:

ui/src/ui/chat/grouped-render.test.ts + build-chat-items.test.ts - 98 passed (9 new cases)
tsgo (test/tsconfig/tsconfig.test.ui.json), oxfmt, oxlint, git diff --check - clean

Real behavior proof

Behavior addressed: failed internal tool calls must not render as a primary red error banner once the turn produced a clean assistant reply ([Bug]: Control UI chat surfaces failed internal tool calls as visible red error banners #89683); terminal tool failures must still surface.
Real environment tested: rendered the production chat render path (renderMessageGroup) into a real DOM (jsdom) on Node v22.14.0 off the current main, the same lit render path the Control UI dashboard uses. The transcript mirrors the report: a shell toolResult with { status:"failed", exitCode:1 } (isError:true) whose turn produced a reply, vs. the same failure with no reply.
Exact steps or command run after this patch: rendered the failed tool group through renderMessageGroup twice, once as buildChatItems now annotates it for a turn that replied (turnSucceeded:true) and once as the pre-fix projection emitted it (turnSucceeded unset), then read the .chat-tool-msg-summary node.
Evidence after fix (copied runtime DOM output from the production view):

{
  "before_turnSucceeded_undefined": {
    "summaryClass": "chat-tool-msg-summary chat-tool-msg-summary--error",
    "label": "Tool error",
    "errorBadge": true
  },
  "after_turnSucceeded_true": {
    "summaryClass": "chat-tool-msg-summary",
    "label": "Tool output",
    "errorBadge": false
  }
}

Observed result after fix: when the turn replied, the failed internal tool renders as a neutral collapsed "Tool output" summary (no --error class, no error badge), so the assistant's answer stays the prominent content; the failed status/output is still shown on expand. When no reply follows, the red "Tool error" banner is unchanged.
What was not tested: a live Control UI browser screenshot against a running gateway (no gateway/dashboard session on this host); reproduced via the production renderMessageGroup view in a real DOM instead.

clawsweeper · 2026-06-04T02:27:38Z

Codex review: needs maintainer review before merge. Reviewed June 29, 2026, 8:19 AM ET / 12:19 UTC.

Summary
The branch annotates Control UI tool message groups with whether the turn produced assistant reply text, then uses that signal to de-promote failed non-terminal tool outputs with focused regression tests.

PR surface: Source +48, Tests +149. Total +197 across 5 files.

Reproducibility: yes. source-reproducible. Current main and v2026.6.10 still map failed tool cards directly to visible error UI without checking whether the same turn later produced a normal assistant reply.

Review metrics: none identified.

Stored data model
Persistent data-model change detected: serialized state: ui/src/ui/chat/build-chat-items.test.ts, serialized state: ui/src/ui/chat/grouped-render.test.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #89683
Summary: This PR is the direct candidate fix for the canonical Control UI/WebChat failed internal tool error-banner bug; adjacent direct-chat and broader tool-output visibility items do not replace it.

Members:

canonical: [Bug]: Control UI chat surfaces failed internal tool calls as visible red error banners #89683 - The PR uses closing syntax for this issue and changes the implicated Control UI chat projection/rendering files.
adjacent_distinct: fix(reply): suppress direct tool-error progress leaks #89975 - That open PR handles outbound direct-chat delivery suppression, not Control UI/WebChat transcript rendering.
partial_overlap: [Bug]: WebChat keeps a visible 'Tool output' block after the assistant reply is complete #89781 - That issue tracks generic successful Tool output visibility after final replies; this PR only de-promotes failed non-terminal internal tools from primary error UI.
partial_overlap: [Feature]:Control UI: Collapse tool activity blocks by default, suppress partial answer fragments #95752 - That issue asks for broader default activity collapsing, partial-fragment suppression, and a config option; this PR is a narrower bug fix.
partial_overlap: fix(ui): show failed tool results as errors #85786 - That merged PR introduced the broad failed-tool error rendering behavior this PR narrows, but it is not a remaining implementation candidate.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦞 diamond lobster
Proof: 🦞 diamond lobster
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Mantis proof suggestion
A short visual Control UI capture would help maintainers inspect the user-facing rendering change, even though the DOM proof is sufficient for review. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis visual task: verify Control UI/WebChat shows a non-terminal failed shell tool result as neutral collapsed Tool output while terminal failures still show Tool error.

Risk before merge

[P1] The remaining uncertainty is visual rather than functional: the supplied proof is copied DOM/live output from the production render path, not a live Control UI browser capture against a running gateway.

Maintainer options:

Decide the mitigation before merge
Land this render-boundary fix, or an equivalent maintainer-approved UI projection change, while leaving broader successful tool-output visibility work to [Bug]: WebChat keeps a visible 'Tool output' block after the assistant reply is complete #89781.
Pause or close
Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

[P2] No repair job is needed because the contributor branch is the viable fix candidate; the remaining action is maintainer review and normal merge gating on the exact head.

Security
Cleared: The diff is limited to Control UI rendering, type shape, and tests, with no dependency, workflow, credential, package, or execution-surface changes.

Review details

Best possible solution:

Land this render-boundary fix, or an equivalent maintainer-approved UI projection change, while leaving broader successful tool-output visibility work to #89781.

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

Yes, source-reproducible. Current main and v2026.6.10 still map failed tool cards directly to visible error UI without checking whether the same turn later produced a normal assistant reply.

Is this the best way to solve the issue?

Yes. The Control UI projection/render boundary has the needed turn-completion context and preserves terminal failures; changing Codex exec semantics or the direct-chat dispatch path would be broader or the wrong surface.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against db2488b6e3d6.

Label changes

Label justifications:

P2: The PR fixes a contained but user-visible Control UI/WebChat rendering bug that can expose internal tool activity as a misleading product error.
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. Sufficient (live_output): The PR body includes after-fix copied DOM output from the production renderMessageGroup path showing non-terminal failed tools lose error styling while terminal failures remain covered.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix copied DOM output from the production renderMessageGroup path showing non-terminal failed tools lose error styling while terminal failures remain covered.

Evidence reviewed

PR surface:

Source +48, Tests +149. Total +197 across 5 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	3	51	3	+48
Tests	2	149	0	+149
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	5	200	3	+197

What I checked:

Repository policy read: Root AGENTS.md and ui/AGENTS.md were read; the root review-depth and Codex dependency-inspection requirements affected this review, while the UI-scoped i18n guidance did not change the chat-render verdict. (AGENTS.md:1, db2488b6e3d6)
Current main still promotes multi-tool errors: On current main, multi-tool activity groups compute hasError directly from cards.some(isToolCardError), which drives error styling and default expansion without turn-success context. (ui/src/ui/chat/grouped-render.ts:523, db2488b6e3d6)
Current main still promotes standalone tool errors: Standalone tool-result rendering also computes toolMessageHasError directly from failed tool cards, so failed tool output becomes a Tool error summary even if an assistant reply follows. (ui/src/ui/chat/grouped-render.ts:1733, db2488b6e3d6)
Latest release is still affected: Release v2026.6.10 has the same direct cards.some(isToolCardError) activity-group error promotion and no turn-outcome field on MessageGroup, so the PR is not obsolete or already shipped. (ui/src/ui/chat/grouped-render.ts:521, aa69b12d0086)
PR adds the turn outcome signal at the projection boundary: PR head adds annotateToolTurnOutcome, walking grouped chat items backward and stamping tool groups when a later assistant group in the same user turn has reply text. (ui/src/ui/chat/build-chat-items.ts:353, 13f63a1ce917)
PR gates error promotion in both render paths: PR head gates activity-group hasError and standalone toolMessageHasError on the new turn outcome while keeping failed details available when expanded. (ui/src/ui/chat/grouped-render.ts:526, 13f63a1ce917)

Likely related people:

chengjiew: Authored the merged failed-tool error rendering PR that made failed tool results prominent in the same Control UI rendering/type surfaces. (role: introduced related behavior; confidence: high; commits: 950007dd9ccf, 64f81d5f327b, 8307479142f0; files: ui/src/ui/chat/grouped-render.ts, ui/src/ui/chat/tool-cards.ts, ui/src/ui/types/chat-types.ts)
altaywtf: Merged the failed-tool error rendering PR and authored follow-up commits refining status-only tool-error classification and styling. (role: reviewer and merger of related behavior; confidence: medium; commits: 950007dd9ccf, 2bd496ee8649, c0c4fb59175f; files: ui/src/ui/chat/grouped-render.ts, ui/src/ui/chat/tool-cards.ts)
vincentkoc: Recent live GitHub history shows multiple Control UI chat rendering changes near the affected grouped-render path. (role: recent area contributor; confidence: medium; commits: 45f935887769, b9b057b6d58f, 402e2bb81a73; files: ui/src/ui/chat/grouped-render.ts, ui/src/ui/chat/build-chat-items.ts, ui/src/ui/chat/tool-cards.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

harjothkhara · 2026-06-04T02:31:29Z

For maintainer context: #89975 (fix(reply): suppress direct tool-error progress leaks) addresses the same underlying principle — don't surface a non-terminal internal tool failure when the turn still produced a clean reply — but on a different surface: the outbound auto-reply/dispatch path (src/auto-reply/reply/dispatch-from-config.ts) for direct chats (e.g. Telegram DMs). This PR is the Control UI / WebChat render side (ui/src/ui/chat/grouped-render.ts + build-chat-items.ts) — zero file overlap, so they're complementary rather than duplicate. Flagging in case you'd like the cross-surface behavior kept consistent.

harjothkhara · 2026-06-06T19:38:35Z

Heads-up for reviewers: both red checks here appear to be pre-existing on main, not introduced by this PR. I verified locally against a clean checkout of current main (3f18c71a), with and without this PR's diff:

check-additional-runtime-topology-architecture (pnpm check:architecture): fails on pristine main via check:madge-import-cycles, an SCC through src/plugins/runtime-state.ts → runtime.ts → … → src/security/dm-policy-shared.ts → src/skills/workshop/policy.ts → src/utils/delivery-context.ts. This PR only touches ui/src/ui/chat/* and ui/src/ui/types/chat-types.ts, so it doesn't participate in that cycle. The stricter pnpm check:import-cycles (runtime value cycles) passes both with and without this PR.
build-artifacts (gateway:watch regression): fails on pristine main with the same readyBeforeWindow: false / "duplicate dist-runtime graph regression" output, again with no changes from this PR.

The diff also applies cleanly onto current main, so a rebase wouldn't change these results — they track main's current state, not this change. Flagging so it isn't chased as a problem with the chat-rendering diff. Happy to rebase once main's architecture check is green again.

harjothkhara · 2026-06-07T02:06:38Z

@clawsweeper re-review please, with the context added since your last pass:

Both red checks are pre-existing on main, not introduced here. Verified against pristine main (3f18c71a): check-additional-runtime-topology-architecture fails via a check:madge-import-cycles SCC unrelated to this diff, and build-artifacts fails on the same gateway:watch regression — both with and without this PR's changes. The diff only touches ui/src/ui/chat/*.
Not a duplicate of fix(reply): suppress direct tool-error progress leaks #89975. That addresses the same principle on a different surface (outbound auto-reply/dispatch); this is the Control UI / WebChat render side, zero file overlap.

Could you re-evaluate the merge-readiness shape with that in mind? Happy to rebase once main's architecture check is green again.

clawsweeper · 2026-06-07T02:06:40Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/27079970042
Updated: 2026-06-07T02:15:08.200Z

harjothkhara · 2026-06-12T05:03:29Z

Rebased onto current main — this branch had fallen ~460 commits behind, so I refreshed the base to clear that stale-base friction (CI is re-running now). ClawSweeper's review came back proof-sufficient and this is marked status: 👀 ready for maintainer look.

It's a contained Control-UI fix: collapse non-terminal internal tool errors so a transient internal failure during a turn that still replied doesn't surface to the user as a red error banner. Whenever a maintainer has a window I'd appreciate a look — happy to re-rebase or adjust scope, and "Allow edits by maintainers" is on. @vincentkoc

…ied (openclaw#89683) A non-zero internal tool exit (Codex marks any non-zero exit as failed, e.g. a no-match shell search) was promoted to a primary red "Tool error" banner in Control UI even when the turn produced a clean assistant reply. Compute a per-tool-group turnSucceeded signal at the chat projection boundary and de-promote such non-terminal failures to a collapsed tool summary; detail stays available on expand. Genuinely terminal tool failures still surface. Co-Authored-By: Claude Opus 4.8 <[email protected]>

altaywtf · 2026-06-29T12:23:52Z

Merged via squash.

Prepared head SHA: 13f63a1ce917a7ccb4ca13c34a1f909d368c6538
Landed commit: 355c43fe0c9eb1f9e0980a8e407f6ea8c325f350

…ied (openclaw#89683) (openclaw#90122) A non-zero internal tool exit (Codex marks any non-zero exit as failed, e.g. a no-match shell search) was promoted to a primary red "Tool error" banner in Control UI even when the turn produced a clean assistant reply. Compute a per-tool-group turnSucceeded signal at the chat projection boundary and de-promote such non-terminal failures to a collapsed tool summary; detail stays available on expand. Genuinely terminal tool failures still surface. Co-authored-by: Claude Opus 4.8 <[email protected]>

In openclaw#90122, annotateToolTurnOutcome was added to collapse non-terminal failed tool errors when the turn produced a reply. The backward pass resets sawAssistantReply only at user groups, assuming every turn starts with a user message. Agent-initiated turns (cron/scheduled/autonomous) have no user group between them, so a later turn reply leaks backward and stamps an earlier genuinely-failed turn as turnSucceeded=true, hiding its error banner. Fix: add a terminal-turn-boundary reset for assistant groups without reply text, scope tool errors by terminal turn outcome, and attribute transcript messages to agent runs. Related to openclaw#97849 Co-authored-by: SunnyShu0925 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

In openclaw#90122, annotateToolTurnOutcome was added to collapse non-terminal failed tool errors when the turn produced a reply. The backward pass resets sawAssistantReply only at user groups, assuming every turn starts with a user message. Agent-initiated turns (cron/scheduled/autonomous) have no user group between them, so a later turn reply leaks backward and stamps an earlier genuinely-failed turn as turnSucceeded=true, hiding its error banner. Fix: add assistantMessageTurnSucceeded with stop-reason classification and runId-scoped outcome tracking for accurate cross-turn boundary detection. Related to openclaw#97849 Co-authored-by: SunnyShu0925 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

…ied (openclaw#89683) (openclaw#90122) A non-zero internal tool exit (Codex marks any non-zero exit as failed, e.g. a no-match shell search) was promoted to a primary red "Tool error" banner in Control UI even when the turn produced a clean assistant reply. Compute a per-tool-group turnSucceeded signal at the chat projection boundary and de-promote such non-terminal failures to a collapsed tool summary; detail stays available on expand. Genuinely terminal tool failures still surface. Co-authored-by: Claude Opus 4.8 <[email protected]>

openclaw-barnacle Bot added app: web-ui App: web-ui size: M proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 4, 2026

harjothkhara changed the title ~~fix(ui): collapse failed internal tool calls when the turn still replied (#89683)~~ fix(ui): collapse non-terminal internal tool errors Jun 4, 2026

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 4, 2026

clawsweeper Bot added proof: sufficient ClawSweeper judged the real behavior proof convincing. P2 Normal backlog priority with limited blast radius. labels Jun 4, 2026

harjothkhara closed this Jun 6, 2026

harjothkhara reopened this Jun 6, 2026

clawsweeper Bot added rating: 🦞 diamond lobster Very strong PR readiness with only minor maintainer review expected. and removed rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. labels Jun 7, 2026

harjothkhara mentioned this pull request Jun 7, 2026

fix(config): allow thinkingLevelMap in persisted model schema #91037

Merged

harjothkhara force-pushed the fix/ui-89683-internal-tool-error-banner branch from 5d3720d to cde5df6 Compare June 9, 2026 00:22

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 9, 2026

clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 9, 2026

harjothkhara force-pushed the fix/ui-89683-internal-tool-error-banner branch from cde5df6 to b92deba Compare June 12, 2026 05:03

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 12, 2026

clawsweeper Bot mentioned this pull request Jun 23, 2026

[Feature]:Control UI: Collapse tool activity blocks by default, suppress partial answer fragments #95752

Open

altaywtf force-pushed the fix/ui-89683-internal-tool-error-banner branch from d600187 to 13f63a1 Compare June 29, 2026 12:13

altaywtf merged commit 355c43f into openclaw:main Jun 29, 2026
69 checks passed

yetval mentioned this pull request Jun 29, 2026

Failed cron/autonomous turn shown as succeeded: cross-turn tool-error banner suppression (regression of #90122) #97849

Closed

harjothkhara mentioned this pull request Jun 29, 2026

fix(ui): keep failed agent turns visibly failed [AI-assisted] #97860

Closed

SunnyShu0925 mentioned this pull request Jun 29, 2026

fix(ui): reset sawAssistantReply for assistant groups without reply text to prevent cross-turn tool-error banner suppression #97873

Closed

nankingjing mentioned this pull request Jul 1, 2026

fix(ui): prevent cross-turn tool-error banner suppression (#97849) #98431

Closed

clawsweeper Bot mentioned this pull request Jul 2, 2026

fix(ui): keep failed autonomous tool turns visible #98888

Closed

This was referenced Jul 5, 2026

fix(auto-reply): hide recovered failed tool progress #97135

Open

fix(auto-reply): guard context prompt tool names #89292

Closed

fix(ui): preserve autonomous tool failures #100514

Merged

clawsweeper Bot mentioned this pull request Jul 16, 2026

[7.1 regression] tool-only turn produces empty final text — outbound payload dropped, control UI hides turn #108738

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(ui): collapse non-terminal internal tool errors#90122

fix(ui): collapse non-terminal internal tool errors#90122
altaywtf merged 1 commit into
openclaw:mainfrom
harjothkhara:fix/ui-89683-internal-tool-error-banner

harjothkhara commented Jun 4, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

Uh oh!

harjothkhara commented Jun 4, 2026

Uh oh!

harjothkhara commented Jun 6, 2026

Uh oh!

harjothkhara commented Jun 7, 2026

Uh oh!

clawsweeper Bot commented Jun 7, 2026 •

edited

Loading

Uh oh!

harjothkhara commented Jun 12, 2026

Uh oh!

Uh oh!

altaywtf commented Jun 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

harjothkhara commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What it does

Collision check

Boundary choice

Verification

Real behavior proof

Uh oh!

clawsweeper Bot commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

harjothkhara commented Jun 4, 2026

Uh oh!

harjothkhara commented Jun 6, 2026

Uh oh!

harjothkhara commented Jun 7, 2026

Uh oh!

clawsweeper Bot commented Jun 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

harjothkhara commented Jun 12, 2026

Uh oh!

Uh oh!

altaywtf commented Jun 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

harjothkhara commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 7, 2026 •

edited

Loading