feat(node): project truthful capability readiness

[clawsweeper]

Summary

• add one inspectable capability-truth projection for camera, browser proxy, and system.run
• expose Settings, Windows permission, Gateway declaration/approval/path, local MCP exposure, runtime readiness, and repairs through Command Center and app.connection.status
• preserve independent local-MCP and Gateway truth, including retained effective declarations during pending reapproval
• update agent guidance, architecture ledger, and MCP/tool coverage

Closes #1155.

Stacked on #1157 because browser-proxy runtime readiness uses that PR's preflight contract.

Validation

• git diff --check - passed at c2e36178
• rubber-duck source review - passed after fixes for disconnected retained declarations, independent MCP/Gateway paths, stale browser readiness, pending reapproval, and prefixed Gateway permission keys
• ./build.ps1 - not run: current Linux host has no .NET SDK or PowerShell
• shared/tray tests - not run locally for the same host prerequisite blocker; exact-head Windows CI is required

Real behavior proof

Not verified / blocked on the current host:

• isolated Windows Hub Command Center capability-diagnostics output
• local MCP tools/list and app.connection.status tools/call
• live Gateway declaration, pending-reapproval, and policy transition proof

Keep this PR draft until Windows CI and current-head MCP/Gateway proof are attached.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed August 13, 2026, 6:59 PM ET / 22:59 UTC.

ClawSweeper review

What this changes

The PR adds a shared readiness projection for camera, browser proxy, and system-run, exposing it through Windows Hub diagnostics, local MCP status, agent guidance, documentation, and tests.

Merge readiness

⛔ Blocked until real behavior proof is added - 6 items remain

Keep this draft PR open. It is the candidate implementation for the still-open capability-truth work, but it is stacked on an unmerged readiness PR and lacks required Windows, MCP, and Gateway behavior proof.

Priority: P2
Reviewed head: c2e361780b42eec196ca0d00374f8147d6d038a6
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The design and focused tests are useful, but the draft lacks required real Windows, MCP, and Gateway behavior proof.
Proof confidence	🧂 unranked krab (1/6)	Needs real behavior proof before merge: The PR body explicitly says after-fix Windows Hub, local MCP, and live Gateway transition proof is blocked and not attached. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs real behavior proof before merge: The PR body explicitly says after-fix Windows Hub, local MCP, and live Gateway transition proof is blocked and not attached. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	5 items	Candidate implementation: The provided PR body explicitly identifies this PR as closing the open capability-truth issue, whose definition of done requests a unified state across settings, Gateway declaration, approval, runtime readiness, Command Center, and agent context. Stacked dependency: The PR body says browser-proxy runtime readiness depends on the still-open browser preflight PR, so this branch has not yet been validated against its final main-branch dependency state. Missing real behavior proof: The PR body explicitly records that isolated Windows Hub diagnostics, local MCP tools/list and app.connection.status tools/call, and live Gateway transition proof were not verified.
Findings	1 actionable finding	[P2] Prove the changed MCP contract through winnode
Security	None	None.

How this fits together

Windows node capabilities pass through tray settings, OS permissions, local MCP registration, and Gateway declaration and approval before an agent can use them. This projection combines those facts for Command Center diagnostics and the agent-facing app.connection.status response.

flowchart LR
  A[Tray settings] --> D[Capability truth projection]
  B[Windows permissions and runtime probes] --> D
  C[Gateway declaration and approval] --> D
  D --> E[Command Center diagnostics]
  D --> F[Local MCP status]
  F --> G[Agent guidance]

Loading

Decision needed

Question	Recommendation
Should app.connection.status version 2 become the supported public diagnostic contract for capability readiness across local MCP and Gateway paths?	Adopt the unified diagnostic contract: Sponsor the public schema after the stacked dependency lands and current-head Windows, MCP, and Gateway proof demonstrates truthful state transitions.

Why: The linked issue carries maintainer-review and product-decision signals, while this PR adds a new agent-facing schema and repair model rather than a narrowly established compatibility fix.

Before merge

• Add real behavior proof - Needs real behavior proof before merge: The PR body explicitly says after-fix Windows Hub, local MCP, and live Gateway transition proof is blocked and not attached. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Prove the changed MCP contract through winnode (P2) - This expands the documented app.connection.status MCP response, but the PR records no WinNode CLI validation or real tools/list and tools/call invocation. The applicable repository policy requires that proof when MCP output or command documentation changes; run it on Windows and attach redacted current-head output before merge.
• Resolve merge risk (P1) - The public app.connection.status response changes to schema version 2 and adds readiness semantics that callers may consume before Windows and CLI proof confirms the serialized contract.
• Resolve merge risk (P1) - Browser-proxy truth depends on the unmerged stacked preflight branch, so a final rebase may alter runtime input behavior or diagnostics.
• Complete next step (P2) - This draft needs maintainer direction on the public diagnostic contract and contributor-provided Windows proof; no narrow reviewer-side repair can establish those conditions.

Findings

• [P2] Prove the changed MCP contract through winnode — src/OpenClaw.WinNode.Cli/skill.md:429-444

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Implementation and coverage	production +413, tests +326, docs +16 across 20 files	The feature introduces a cross-layer diagnostic contract with substantial focused test coverage, but its real Windows and Gateway behavior remains unproven.

Merge-risk options

Maintainer options:

1. Prove the stacked runtime path before merge (recommended)
   Rebase onto the finalized browser-readiness dependency and attach current-head Windows MCP, Gateway, and Command Center evidence for the advertised capability states.
2. Defer the public MCP schema
   Keep the projection out of app.connection.status if maintainers do not want to commit to this versioned agent-facing contract yet.

Technical review

Best possible solution:

Land the browser-readiness dependency first, then validate this unified projection on current main with Windows Hub output, local MCP invocation, and a live Gateway approval or declaration transition before accepting the schema expansion.

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

Not applicable: this PR proposes a new diagnostic projection rather than supplying a self-contained reproduction of an existing behavior defect.

Is this the best way to solve the issue?

Unclear: one shared projection is a maintainable direction, but its public MCP contract and stacked runtime inputs need maintainer approval and real current-head validation.

Full review comments:

• [P2] Prove the changed MCP contract through winnode — src/OpenClaw.WinNode.Cli/skill.md:429-444
  This expands the documented app.connection.status MCP response, but the PR records no WinNode CLI validation or real tools/list and tools/call invocation. The applicable repository policy requires that proof when MCP output or command documentation changes; run it on Windows and attach redacted current-head output before merge.
  Confidence: 0.95

Overall correctness: patch is incorrect
Overall confidence: 0.8

AGENTS.md: found and applied where relevant.

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

Labels

Label changes:

• add P2: This is a bounded Windows-node diagnostics feature with meaningful operator impact but no confirmed urgent production regression.
• add merge-risk: 🚨 compatibility: The PR changes the versioned app.connection.status contract and documents new agent-facing readiness semantics.
• add merge-risk: 🚨 availability: Readiness values can suppress use of node capabilities and rely on an unmerged browser-proxy preflight dependency.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body explicitly says after-fix Windows Hub, local MCP, and live Gateway transition proof is blocked and not attached. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P2: This is a bounded Windows-node diagnostics feature with meaningful operator impact but no confirmed urgent production regression.
• merge-risk: 🚨 compatibility: The PR changes the versioned app.connection.status contract and documents new agent-facing readiness semantics.
• merge-risk: 🚨 availability: Readiness values can suppress use of node capabilities and rely on an unmerged browser-proxy preflight dependency.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body explicitly says after-fix Windows Hub, local MCP, and live Gateway transition proof is blocked and not attached. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

What I checked:

• Candidate implementation: The provided PR body explicitly identifies this PR as closing the open capability-truth issue, whose definition of done requests a unified state across settings, Gateway declaration, approval, runtime readiness, Command Center, and agent context. (c2e361780b42)
• Stacked dependency: The PR body says browser-proxy runtime readiness depends on the still-open browser preflight PR, so this branch has not yet been validated against its final main-branch dependency state. (src/OpenClaw.Tray.WinUI/Services/NodeCapabilityTruthSource.cs, c2e361780b42)
• Missing real behavior proof: The PR body explicitly records that isolated Windows Hub diagnostics, local MCP tools/list and app.connection.status tools/call, and live Gateway transition proof were not verified. (c2e361780b42)
• Review environment limitation: Local repository inspection could not run because the read-only sandbox failed before executing git with “bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted”; no local source or history claims are based on that failed command.
• Repository policy: The target AGENTS.md supplied with this review requires the Windows build and shared/tray tests after code changes, plus WinNode CLI validation and MCP invocation proof when MCP output or command documentation changes. (AGENTS.md)

Likely related people:

• RomneyDa: Authored the open, member-associated issue defining the capability-truth outcome that this PR claims to implement; current-main feature history could not be inspected because the read-only sandbox failed before running git. (role: linked issue author; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Attach redacted current-head Windows Hub capability-diagnostics output.
• Attach local MCP tools/list and app.connection.status tools/call output, plus a live Gateway declaration or pending-approval transition.
• Run and report the required Windows build, shared/tray tests, and WinNode CLI validation.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
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.

Workflow

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

[clawsweeper]

ClawSweeper feedback follow-up (current head c2e361780b42eec196ca0d00374f8147d6d038a6):

• The requested winnode --list-tools plus live app.connection.status invocation has not been obtained.
• A 2026-08-15 Crabbox AWS Windows desktop attempt on lease cbx_129687b80dc6 (violet-crab) synced the dependency head, but the stock image lacks .NET 10, Node LTS, Windows SDK 26100, WebView2, and App Installer / winget, so repository setup and MCP invocation could not run.
• Azure provisioning failed before lease creation because the available low-priority core quota is 3 and the Windows class requires 16. No operator-connected Windows node was available through this session.
• This PR is still stacked on fix: preflight browser proxy readiness #1157 and still requires maintainer acceptance of app.connection.status schema version 2 as the supported public diagnostic contract.

Accordingly, Windows Hub, local MCP, and live Gateway transition proof remain not verified. This PR stays draft and blocked on both real behavior proof and the explicit maintainer schema decision.