Clarify Local AI managed-model probe naming and verification documentation

[joelagnel]

Cleanup

Address the two Local AI API clarity nits from the PR #1178 review.

Rename the managed-model probe

Rename ProbeRouterAsync to ProbeManagedModelAsync across the interface, implementation, runtime-service callers, fakes, and tests.

The operation checks both router health and the evidence for one configured model alias and expected path. The proposed name communicates that contract more precisely than the generic router-oriented name.

Review thread:
#1178 (comment)

Coordinate this rename with #1192, which tightens the same probe's readiness contract.

Document inference verification at the method boundary

Add method-level XML documentation to LlamaServerInferenceClient.VerifyAsync explaining that it:

• Sends one bounded OpenAI-compatible request to the managed endpoint
• Intentionally triggers lazy model loading during setup
• Verifies the response and token/timing evidence
• Does not return or log prompt and response content

Retain the useful existing class-level documentation while making the public method contract clear to callers and generated documentation.

Review thread:
#1178 (comment)

Acceptance criteria

• ProbeRouterAsync is fully renamed to ProbeManagedModelAsync with no stale references.
• Method-level XML documentation is present on the interface and implementation where appropriate.
• Existing behavior remains unchanged except for any separately reviewed readiness correction from Require verified managed-model evidence before publishing Local AI #1192.
• Focused Local AI client and runtime-service tests pass.

Reported by @larroy

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 21, 2026, 4:21 PM ET / 20:21 UTC.

Summary
Keep open. This is a small, still-needed follow-up for the unmerged Local AI implementation, and its API cleanup should be coordinated with the adjacent readiness correction rather than treated as implemented on current main.

Reproducibility: not applicable. This issue requests a refactor and XML documentation rather than reporting a runtime failure to reproduce.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
The implementation surface is on an actively landing related pull request, so a competing repair lane would add coordination churn.

Review details

Best possible solution:

After the managed-model readiness predicate is finalized, make one focused refactor that names that contract consistently, documents the verification boundary, and adds focused client and runtime-service coverage without changing behavior beyond the separately reviewed readiness fix.

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

Not applicable. This issue requests a refactor and XML documentation rather than reporting a runtime failure to reproduce.

Is this the best way to solve the issue?

Yes. A small coordinated refactor after the readiness contract is settled is the narrowest maintainable solution and avoids competing terminology for the same probe.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Applying the rename independently before the readiness contract in Require verified managed-model evidence before publishing Local AI #1192 is settled could create avoidable churn across the same interface, callers, fakes, and tests.

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

Label changes

Label changes:

• add P3: This is a bounded naming and API-documentation cleanup with no standalone runtime behavior change.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.

Label justifications:

• P3: This is a bounded naming and API-documentation cleanup with no standalone runtime behavior change.

Evidence reviewed

What I checked:

• Current main does not contain the requested Local AI surface: A current-main symbol and path search found no ProbeRouterAsync, ProbeManagedModelAsync, LlamaServerInferenceClient, LlamaServerClient, or Local AI paths, so the requested rename and XML documentation are not already implemented on the default branch. (d3ed6c78bf14)
• Related implementation remains open: The supplied context identifies the open Local AI pull request as the branch that introduces the client and runtime-service surface; its body says the branch is code-focused and does not add documentation, so it does not demonstrate this cleanup is complete. (src/OpenClaw.Connection/LocalAi/LlamaServerClient.cs:167, 31dffdb0dbd9)
• Readiness work is adjacent, not a duplicate: The supplied report for Require verified managed-model evidence before publishing Local AI #1192 changes the same probe’s readiness predicate and runtime publication checks, while this issue requests naming and API documentation. Both need to agree on the final probe contract. (src/OpenClaw.Connection/LocalAi/LlamaServerRuntimeService.cs:243, 31dffdb0dbd9)
• Release and branch position checked: v2026.7.1 points at 4206611, which is an ancestor of current main; the absent-symbol check therefore covers code newer than the latest release as well as the release baseline. (4206611f2b2e)

Likely related people:

• larroy: The issue body attributes both requested review nits and the adjacent readiness concern to larroy’s review of the pending Local AI implementation. (role: reviewer and contract reporter; confidence: medium; files: src/OpenClaw.Connection/LocalAi/LlamaServerClient.cs, src/OpenClaw.Connection/LocalAi/LlamaServerRuntimeService.cs)
• joelagnel: The pending Local AI branch is the identified source of the client and runtime-service surface this cleanup clarifies. (role: related Local AI branch author; confidence: medium; commits: 31dffdb0dbd9; files: src/OpenClaw.Connection/LocalAi/LlamaServerClient.cs, src/OpenClaw.Connection/LocalAi/LlamaServerRuntimeService.cs)

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.