Slice 2 prerequisite: enable trusted hosted-provider smoke qualification #12955

Problem Statement

Testing prerequisite for Slice 2 #12589 and PR #12886. Rebecca's review requires hosted-provider API-key qualification. The trusted planner on main cannot select the targets currently defined only in the candidate. Candidate-authored workflows must not supply their own authority to receive protected credentials.

This issue plans one focused infrastructure PR. It does not reopen Slice 2 product implementation. Implementation and draft publication are now authorized by the issue owner. Merge remains a separate maintainer action.

Desired Behavior

The existing trusted E2E workflow can explicitly select a hosted-provider smoke against the verified latest commit of #12886, using the approved key/model for that provider. Results identify the tested commit, trusted workflow revision, scenario, outcome, and cleanup result.

The five existing selectors are hosted-inference-openai, hosted-inference-anthropic, hosted-inference-gemini, hosted-inference-openrouter, and hosted-inference-hermes. The first four use OpenClaw; the fifth uses Hermes with NOUS_API_KEY.

Scope and Exclusions

Extract only the required existing changes from #12886 into current canonical main:

• Target definitions and integration with the existing catalogue/planner.
• Hosted execution profile and selected-provider credential/model routing through the existing trusted workflow.
• Existing provider smoke harness and indispensable fixture helpers.
• Focused selection, trust-boundary, credential-scan, and reporting tests; directly affected execution guidance.

Initial selection is proposed to be explicit dispatch only, subject to maintainer confirmation. Do not automatically run native-provider assertions against main before Slice 2's product behavior exists. Do not weaken existing unrelated selection or qualification requirements.

Excluded: provider lifecycle/onboarding/restart product changes; OAuth automation; new providers, models, agent combinations, platforms, or test frameworks; Brev provisioning; image/Dockerfile changes; dependency upgrades; broad CI cleanup; expanded default suites; altered branch protections or bypassed trust checks. Keep Slice 2's Pi image-input ownership changes out of this extraction.

Every changed file must implement or verify the outcome above. An additional helper requires a demonstrated dependency; a new product or infrastructure capability requires re-planning.

Ongoing Ownership

Proposed implementation owner: @deepujain. Accountable Slice 2 maintainer: @rsliter. Existing CODEOWNERS retain review ownership: NVIDIA/nemoclaw-maintainer for CI/tooling and NVIDIA/nemoclaw-engineer for E2E tests. A named credential/model configuration owner remains to be confirmed.

Placement and Support Expectations

Extend core NemoClaw's existing E2E owners. This is a thin qualification integration for the existing Slice 2 consumer, not a new supported product surface. Preserve one canonical smoke-test owner and the current trusted dispatch contract. The implementation follows this extraction scope and initial explicit-only selection. Maintainer review must verify both before merge.

Prerequisites and Evidence Already Collected

A temporary extraction from candidate 892770dd9b1219e5cdd73cab4d74175cc01d5826 applied cleanly to main fcbbab088ad89dc78322b79d6b4e5ecceee8f1b0. After including the existing Hermes API-command fixture, 72 focused deterministic tests passed across three files, without copying product code. This is preliminary feasibility evidence, not full build, hosted CI, or live qualification.

The raw extraction is not the final scope: it contains automatic hosted-test selection on workflow edits and Slice 2 image-input tracking entries. Both need the narrowing described above.

The five expected repository-level API-key secrets and model variables were absent from metadata checks. Organization-secret inspection was denied, so inherited availability is unknown. Before live dispatch, a configuration owner must confirm approved sources, repository access, model entitlement/quota, and authorization for candidate execution, or provision missing configuration. Draft code review proceeds in parallel with that confirmation; publishing infrastructure does not establish live readiness:

• OPENAI_API_KEY / NEMOCLAW_OPENAI_MODEL
• ANTHROPIC_API_KEY / NEMOCLAW_ANTHROPIC_MODEL
• GEMINI_API_KEY / NEMOCLAW_GEMINI_MODEL
• OPENROUTER_API_KEY / NEMOCLAW_OPENROUTER_MODEL
• NOUS_API_KEY / NEMOCLAW_HERMES_MODEL

Do not include secret values in this issue or test evidence. Configuration existence does not prove that a live request succeeds.

Delivery and Validation Plan

Three checkpoints within one PR; they are not separate features or PRs:

• 1. Confirm readiness and finalize the extraction. Track the configuration owner separately as a live-dispatch prerequisite and obtain maintainer scope review before merge. Extract the minimum code into an isolated checkout from canonical main. Prove the helper/import closure without pulling in Slice 2 product code. Retain the existing smoke owner, and make initial dispatch explicit.
• 2. Validate and publish one complete candidate. Run focused selector/trust/credential/reporting tests, applicable builds and workflow checks, and scope review before pushing. Use normal hooks and required CI/reviews. Collect complete findings before one repair batch; use the persistent bounded-retry policy. Do not push each checkpoint, chase unrelated main changes, duplicate successful validation, or change test requirements to obtain green checks. Maintainer approval and merge remain independent requirements.
• 3. Verify the consumer after the prerequisite lands. Integrate the merged prerequisite into feat(inference): [slice 2] use native hosted providers #12886 once, reconcile overlapping infrastructure without duplication, and complete checks affected by the resulting commit. Dispatch the five supported API-key scenarios against that commit after credential authorization and absence of equivalent active jobs are verified. Attach sanitized, commit-bound results and cleanup outcomes to feat(inference): [slice 2] use native hosted providers #12886. Refresh image receipts only if their actual inputs changed.

Acceptance evidence

• Each explicit selector runs only its intended existing provider smoke.
• Only the selected provider key/model is forwarded; missing prerequisites fail clearly, and a skip is not a pass.
• Existing PR, repository, candidate-commit, and trusted-workflow identity validation remains enforced. Candidate-authored workflow sources receive no hosted keys.
• Default and unrelated runs do not launch these new hosted scenarios. Focused tests establish the approved initial selection behavior.
• The infrastructure candidate builds and passes applicable checks independently of Slice 2 product changes.
• After landing, all five live scenarios execute against the resulting Slice 2 commit and produce inspectable, sanitized results. No historical result substitutes for that commit.

Live evidence belongs to test/e2e/live/inference-routing-provider-smoke.test.ts: native endpoint/adapter and credential-placeholder configuration, a fresh request with the selected response model and nonempty answer, and the existing bounded credential-leak checks with a synthetic positive control. Deterministic fixtures and support tests own selection, secret routing, and workflow trust logic. Do not broaden this into a provider-by-agent-by-platform matrix.

Compatibility Requirements

Use the existing Docker/CPU execution profile, repository runtime/tool pins, OpenClaw for four API-key cases, and Hermes for the Nous API-key case. No GPU or Brev dependency is introduced by this prerequisite. Preserve existing E2E consumers and supported dispatch behavior.

Security or Privacy Impact

Forward approved credentials through the existing trusted workflow boundary. Candidate-controlled host processes can access the selected key. Redaction and sandbox credential checks do not isolate the key from those processes. Provider keys can outlive a CI job; the credential owner controls rotation/revocation. Cleanup must report its outcome and must not claim to revoke a key. Preserve existing artifact redaction, resource ownership, and cleanup behavior; do not expand credential scope.

Completion Boundary and Stop Conditions

This issue enables and verifies API-key qualification only. Hermes OAuth remains tracked in #12589: an authorized account operator and approved disposable interactive environment must complete device authorization, a fresh native-endpoint request, restart, and another fresh request with evidence tied to the tested commit. Neither the infrastructure merge nor API-key success closes that gap or grants Slice 2 approval.

Re-plan before expanding if extraction requires product changes, a new credential trust model, a new runner platform, or unrelated test work. Report unavailable credentials/configuration explicitly rather than publishing infrastructure as if it guarantees live readiness. Missing evidence remains missing; merge and approval are not implied.

Category

Testing

Current implementation checkpoint

Draft PR #12958 is at 0f87c97ac9bddead7cb43d16d6b0c78fb38d90a9. The reporting, mixed-result handling, documentation, and model-ownership repairs are published. Normal isolated hooks passed and all published commits are GitHub Verified.

Full CI passes on this commit, including all 12 CLI shards. CodeRabbit reviewed all six latest changed files with zero actionable findings; its preceding full review covered all 25 files. Advisor run 38039606784 completed all nine specialists, and all nine findings ledgers are clear with zero P0/P1 defects. The complete specialist reports and failing gate log were inspected.

The gate still fails for five recommendation records that overlap the same five after-landing API-key qualifications. These runs remain unexecuted. This is the staged external qualification dependency, not an unresolved code defect or a failed unit test. No unchanged Advisor rerun or additional source patch is justified by this result.

Independent maintainer disposition of the non-success prerequisite gate and maintainer merge remain outstanding. After landing, integrate the prerequisite into Slice 2 once and execute checkpoint 3 with confirmed provider credential/model configuration. This issue stays open until the five cases have matching live evidence and cleanup outcomes. Hermes OAuth remains separate under #12589. No qualification or gate waiver is claimed.