Repository navigation
Record OpenShell v0.0.101 baselines and release trust #8598
Description
Important
This child is reserved for #8590 integration-owner dispatch.
Do not start implementation without an explicit assignment from that owner.
Problem Statement
Parent epic: #8590.
The upgrade needs trusted baselines before compatibility work begins.
Without fixed identities, later qualification can use stale or mixed OpenShell artifacts.
Proposed Design
Scope
- Record the final commit from fix(openshell): complete v0.0.99 compatibility #8583 as the repository
v0.0.99baseline. - Record the last public NemoClaw tag and its OpenShell
v0.0.85identities. - Verify the published
v0.0.101tag, release, packages, checksums, and assets. - Record immutable CLI, gateway, supervisor, sandbox, and virtual machine driver identities.
- Inventory every production consumer of OpenShell versions and artifacts.
- Add required identities through the base-branch trust model before the selector change.
Owned boundaries
- Own baseline evidence, trust identities, and the artifact consumer inventory.
- Do not change selectors, runtime behavior, policy behavior, or qualification gates.
Dependencies
- fix(openshell): complete v0.0.99 compatibility #8583 must supply its final merged baseline.
- Published
v0.0.101artifacts must remain available.
Required evidence
- Publish one provenance record for every required artifact.
- Show that each checksum matches its published artifact.
- List every production consumer and its selected artifact identity.
- Link all evidence to [Epic] Qualify and pin OpenShell v0.0.101 #8590.
Acceptance criteria
- Record both the repository baseline and the user baseline.
- Verify every required published
v0.0.101artifact. - Add required identities through the approved trust model.
- Confirm that every active consumer uses one trusted identity set.
- Link the completed evidence to [Epic] Qualify and pin OpenShell v0.0.101 #8590.
Handoff
- Report changed files, tests, risks, and unresolved questions.
- Report all verified identities and consumer locations.
- Link the implementation pull request and evidence to [Epic] Qualify and pin OpenShell v0.0.101 #8590.
Implementation starts in a separate Codex thread.
Alternatives Considered
Keep this work inside #8590. This approach would delay independent trust work and block other workstreams.
Category
Platform
Checklist
- I searched existing issues and this is not a duplicate.
- This is a design proposal, not a "please build this" request.
Activity
apurvvkumaria commentedon Aug 8, 2026
Exact-head qualification blocked by trusted-base E2E failures
The final #8598 candidate is stable at
a69b6c9191d1955a15061e7df969566b4956fe65on frozen base/workflowa76e297019c88c74d77ddadd4ffc96089278b8fa. Normal CI, all eight GitHub test shards, managed-runtime activation, CodeQL, DCO, documentation receipt, repository checks, independent security/correctness review, CodeRabbit, and the aggregate PR advisor pass with no actionable finding.check-hashremains red only because a successful exact-head trusted full-E2E receipt is required.I dispatched exact attempt 1 in E2E run 31252685232 from trusted
main, with empty selectors, mock inference, no Launchable/Jetson/DGX opt-ins, PR #8616, exact candidate/base/workflow SHAs, and correlation49068e55-7a36-450f-bbab-596128bb26ff. The controller authenticated those identities and launched the expected matrix.The run cannot qualify the candidate because multiple unchanged trusted-base jobs failed. The clearest deterministic failure is Hermes security posture, which could not import
../../nemoclaw/dist/shared/sandbox-name.cjsafter the base-owned E2E preparation action skipped the shared build. The current-main push E2E run 31243363889, matching Hermes job, failed with the identical missing module. Other failed jobs exposed separate current-base failures, including the cron local-inference timeout and ARM managed-image build.The #8598 diff changes none of
.github/workflows/e2e.yaml,.github/actions/prepare-e2e/action.yaml,src/lib/name-validation.ts,nemoclaw/src/shared/sandbox-name.ts,nemoclaw/tsconfig.shared.json, orpackage.json. This is therefore classified base-wide, not candidate-caused. Per #8590 policy, I did not absorb an unrelated E2E repair or waive required evidence. I stopped the already-doomed remaining jobs to conserve runner capacity and will not rerun attempt 1.Blocker / next action: the trusted-base full-E2E path must be repaired externally and pass on
main; after that lands, the integration owner will refresh the relevant base identity, review overlap, and dispatch one fresh exact-head run. #8598 remains open and unmerged until a valid receipt makescheck-hashgreen.apurvvkumaria commentedon Aug 8, 2026
The one permitted post-repair qualification for frozen PR #8616 is complete: run 31263982343 failed (65 successful, 7 skipped, 25 failed jobs), so no successful trusted receipt exists and the PR is not accepted.
The base repair did fix its target: Hermes security-posture passed after restoring the exact candidate CLI artifact. The remaining failure wave is base-wide/external. OpenClaw security-posture failed with HTTP 429 on #8616, #8617, and the identical-tree repaired-main run; 21 of the 25 failed #8616 job names also fail on repaired main. The four #8616 files do not touch the implicated live runtime paths.
Head 414de88 remains frozen and provisionally ready only. The one-run limit is honored: no rerun, merge, branch movement, or acceptance.
apurvvkumaria commentedon Aug 8, 2026
Fresh trusted qualification is terminal and did not produce an acceptable receipt.
414de88cce8285d928218a8809169ba7bf59a782c6fb802c09adeb20ab365964fc8703a3cca3ad98a816474c2b91e5e01e560326c750324c05571c4a7a9f9c45-ede5-439a-9d20-f431091b5cfdDispatch identity, setup/provenance, the exact candidate/base binding, and the exact CLI artifact all authenticated successfully. Seventeen failed job names recur across the paired #8616/#8617 runs; fourteen have the same or semantically identical terminal signature, including rate limits, inference/service readiness, stale generated-image, websocket-handshake, package-registry DNS, and shared protected-runtime failures. The #8616 delta remains limited to installer trust/hash code and tests and does not touch the failed live runtime paths. This is therefore classified as shared base/external qualification failure, with no candidate-specific failure evidenced.
Success is still mandatory. #8616 remains implementation-complete, frozen, provisionally ready, and not accepted. The run was not rerun or waived; the head was not moved; no dependent child, candidate, or merge is unlocked.
chore(openshell): trust v0.0.101 release identities (NVIDIA#8616)