Repository navigation
fix: allow assistive tools to invoke onboarding actions - #1797
paulcam206 wants to merge 3 commits into
Conversation
Extract the independently reviewed reliability seam without the held native timeout consumer. No change to executor releases, package pins or sandbox enforcement.
|
🦞👀 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 real behavior proof before merge. What this changesAdds native UI Automation invocation to onboarding provider, model, API-key, recommended-install, and completion cards. Example: An assistive tool invokes the visible “Talk to my agent” completion card.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness⛔ Blocked before merge - 1 item remains Keep this PR open: current main still lacks the repaired accessibility contract, and the focused adapter preserves existing action owners and resolves both earlier coverage concerns. Priority: P2 Before merge
FindingsNone. Tests
Agent review detailsHow this fits togetherSetupEngine UI renders onboarding choices and forwards user clicks or automation requests to the existing AI setup controller and verified completion coordinator. flowchart LR
A[Assistive tool] --> B[Native UI Automation]
B --> C[SetupActionCard]
D[User click] --> C
C --> E[Guarded page action]
E --> F[Existing setup coordinator]
Technical reviewBest possible solution: Retain the focused Invoke adapter and behavioral coverage while preserving existing setup, consent, ownership, and completion guards. Do we have a high-confidence way to reproduce the issue? Current-main cards, the existing test-helper workaround, and the directly inherited Toolkit peer identify the failing Invoke path; this read-only review did not execute it or independently verify the exact package binary. Is this the best way to solve the issue? The small SettingsCard-derived adapter repairs the native invocation boundary while retaining Toolkit presentation and existing action owners. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 2dfb4c78ef05. Provenance checked
TestingProof path: in-process harness. SecurityNone. EvidenceWhat I checked:
Likely related people:
LabelsLabel 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 HistoryReview history (2 earlier review cycles)
Reviewed October 22, 2026, 12:19 AM ET / 04:19 UTC (Revision 3). |
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
clawsweeper
Bot
added
the
proof: 📸 screenshot
What Problem This Solves
Fixes: assistive tools cannot invoke some visible onboarding action cards through their native automation contract.
User Impact
User impact: Accessible automation can invoke the same visible onboarding choices as a user, without private completion flags or bypassing normal consent.
DRAFT. Final standalone source passed full build, Shared/private Tray closeout and 24/24 mounted/native-UIA behavior cases. These use synthetic provider/native-runtime dependencies, not live model/package operations or native pixels. Genuine installed onboarding in combined integration63a remains separately attributed historical evidence.
Why This Change Was Made
Expose the existing action-card invocation through the native UI Automation peer and keep normal busy, ownership, verification and completion gates. Preserve the existing setup and composition owners.
The two lost coverage contracts are now protected behaviorally: mounted Local AI/hosted-provider grouping, manual-input placement, selection versus activation and bound-candidate invocation; and verified completion re-verification, all three destinations, no footer bypass and error-only recovery through the owning AI page. Normal Gateway review also hides competing Local AI setup. The compound Local AI card is unchanged; API-key and recommended-template cards reuse the guarded action adapter.
Typed test friend access replaces implementation reflection. A named test-project reference alias resolves the existing linked FluentIconCatalog ambiguity without a production namespace change.
Landing coordination: the independent onboarding drafts share the canonical
MountedControlCapture.cshelper path. Neither requires the other to build; whichever lands second must rebase and retain the other split's reviewed helper changes, including requested-capture geometry diagnostics.Continuity and onboarding automation remove different, non-overlapping old cases in
NativeCompletionPresentationTests.cs. Rebase whichever lands second before final review.Evidence
Actual running-Companion attempt and remaining credential constraint
The published branch is independent and remains DRAFT. No real provider/model or completion-card invocation pass is claimed. The existing mounted/native-UIA tests and the additional running-app evidence below are distinct.
Private-desktop dependency: the independent current head cannot reach its normal app entrypoint on the private desktop without #1783 (fix: open the Hub when private desktop shell services are unavailable). Exact current-head startup output:
No Default-desktop slot was available. The explicitly approved proof-only composition is COMBINED #1797 + #1783:
09fb0621a56f864717ff714e1b3cd547fa8e3ba1.e16d2f9f4070f91aa1da4958c712c0c0ab80436b.d02d3bd3b7b7d1cdf1d285b4cd7ae3f6ecb9cd7c, never pushed.The COMBINED tree passed
./build.ps1, Shared4,635passed/25configuredskips, private-desktop Tray4,440passed/zero skipped, and focused mounted/native-UIA plus startup28/28passed. An earlier runtime-only composition had4,440Traypasses/one obsolete source-inspection assertion failure. That failure is preserved; the complete composition includes #1783's already-published deletion and real native startup tests, not a patched marker assertion or relaxed budget.The real normal COMBINED Companion executable, using the normal installed profile and credential-owning app/CLI paths, then reached authenticated schema2Ready. It was not a preview or synthetic Gateway. The installed packaged Gateway remained OpenClaw2026.10.5 at its existing endpoint; hosting SDK1.0.1 is distinct from this branch's Windows-node SDK1.0.0.
Two normal UI entry paths were actually exercised and stopped before the changed action-card behavior:
Cached device-token reconnect Ready is not fresh credential validation. The verified installed packaging owner has only
clawctl companion prepare; even--checkreturns credential-bearing data. There is no supported opaque Companion connect/open/pipe handoff in that owner.clawctl opentargets the authenticated browser Control UI and was not repurposed. Normal app/CLI owners performed authentication; the automation did not manually read or copy credentials, print token values, put them in arguments or use the clipboard.The noncredential native-draft descriptor was checked against redacted saved-gateway metadata: its port is the existing18789 and its logical ID is already the active published record. Re-entering the Native Gateway install/setup choice would make this source's
CreateDraftAsyncselect another available port, so that route was deliberately not run. No second Gateway, reset, install, model change or port change was used to bypass this constraint.After each actual run, the exact source process was cleaned up and installed Hub403 was restored through its normal packaged activation. Redacted excerpt from the actual lifecycle receipt (not an illustrative MCP response schema):
{ "ProofKind": "COMBINED #1797 + #1783. Not standalone private-desktop entrypoint proof.", "TargetHead": "09fb0621a56f864717ff714e1b3cd547fa8e3ba1", "StartupHead": "e16d2f9f4070f91aa1da4958c712c0c0ab80436b", "RuntimeProofHead": "d02d3bd3b7b7d1cdf1d285b4cd7ae3f6ecb9cd7c", "Before": { "Schema": 2, "State": "Ready", "McpRunning": true, "Node": "Connected", "Operator": "Connected", "Paired": true }, "After": { "Schema": 2, "State": "Ready", "McpRunning": true, "Node": "Connected", "Operator": "Connected", "Paired": true }, "GatewayIdAndEndpointUnchanged": true, "ProviderAndModelUnchanged": true, "GatewayRestartOrInstallRequested": false, "ManualSecretReads": false, "ClipboardUsed": false, "CleanupIssues": [] }Still required: a permitted normal entry/credential-delivery route to this running Companion's AI setup, followed by real provider/model and completion Invoke plus disabled/busy rejection. The present constraints do not permit manual setup-secret handling, a new credential transport or changing the shared Gateway's port. No screenshots were fabricated and the28testcases or Ready readback are not presented as that missing runtime behavior.
Current independent head:
09fb0621a56f864717ff714e1b3cd547fa8e3ba1, based on public main2b7cfce17bb496ec5d8f0c563fb71ebb46e015fa. Published SDK1.0.0 pins unchanged. No unpublished native dependency.Current-head CI: 17 successful checks, UI and its gate red. Actual failed UI job: unchanged
NativeFallback_GatewayMoreRejectsAnOverlappingContinuetimes out waiting for Gateway More IsLoaded. Identical failure occurs on independent 1665 and 1750, neither changing the implicated wizard/fixture owners. Exact main2b passes the case in841ms. This is a confirmed pre-existing cross-PR failure; no exact red-main case or identical underlying timing cause is asserted. Authorized rerun was denied for missing repository-admin permission; attempt1unchanged.The lost LocalAI/provider-group/manual-input and completion-recovery/footer coverage was replaced behaviorally, not restored as source markers. Actual mounted cases invoke native UIA/disabled controls, bind repeated choices to their own candidate, distinguish selection from activation, reverify completion for all three destinations and keep error-only recovery through the owning AI page. API/recommended cards reuse the guarded adapter; compound LocalAI is unchanged. Typed friend access and an explicit test assembly alias avoid production namespace changes.
Actual focused standalone mounted/nativeUIA24/24passed with synthetic provider/native-runtime replies. Final local review snapshotbbd1f5e787c79380f296bc5dd6b11ebac9d5bda7found no blocking code finding. That is local review, not hosted current-head review. Genuine installed combined63a UIA onboarding is historical supporting evidence only.
Change Type
Scope
winnodeRequired proof pools
windows-winui-interactive: mounted action-card UIA invocation, disabled/busy behavior and visible normal onboarding completion.Validation
Source frozen before commit, exact changed bytes verified unchanged afterward. Tray/native tests used owned private desktops and isolated state; quiet/WER/original-native-handle completion checks passed.
.\build.ps1dotnet test .\tests\OpenClaw.Shared.Tests\OpenClaw.Shared.Tests.csproj --no-restoredotnet test .\tests\OpenClaw.Tray.Tests\OpenClaw.Tray.Tests.csproj --no-restore.\scripts\validate-docs.ps1;.\scripts\validate-agent-skills.ps1;git diff --checkAfter UI build with
-r win-x64 -p:Platform=x64 -p:DevBuild=false, the following actual private native/mounted selection passed24/24with zero skips:Earlier duplicate-catalog compilation, stale exact-type expectations and unrelated cancellation-fixture failures remain retained. They were repaired at the actual owner/seam, not by deleting coverage or loosening assertions. Pixel proof was not requested in this functional invocation.
Real Behavior Proof
09fb0621a56f864717ff714e1b3cd547fa8e3ba1.{"Total":24,"Executed":24,"Passed":24,"Failed":0,"Unexecuted":0,"ExitCode":0,"DesktopCreatorRetainedUntilNativeExit":true,"NativeExitReceiptVerified":true}N/Afor local private TRX/ownership receipts; public current-head CI and independent failure links above. No private capture is represented as public visual proof.Security Impact
NoNoNoNoNoYes, explain the risk and mitigation: No new permissions, credential handling, remote endpoint or product execution surface. UIA invokes the same existing visible action; busy/disabled, ownership and verification checks still govern it.Compatibility and Migration
Yes. Existing authenticated connection, consent and ownership contracts remain authoritative.Nopersistent source-contract change.NoReview Conversations
This remains DRAFT pending current-head hosted review and required proof. No merge is authorized.