[Epic] Qualify and pin OpenShell v0.0.101

[apurvvkumaria]

Problem

OpenShell v0.0.101 is the latest published release.

Work in #8497, #8523, and #8583 found compatibility problems with OpenShell v0.0.99. Earlier tests did not find these problems.

The problems affected these functions:

• Supervisor arguments
• Workspace identities
• SSH aliases
• Rootless Podman activation
• Policy validation
• CLI output
• Sandbox lifecycle
• Middleware reconnection

OpenShell v0.0.101 has nine commits more than v0.0.99. The source comparison has 170 changed paths.

OpenShell v0.0.101 includes the HTTP/2 keepalive correction from NVIDIA/OpenShell#2608. This correction applies to the supervisor middleware channel.

The release also changes these areas:

• Credential storage
• The virtual-machine driver
• The SDK
• Dependencies
• The egress adapter

NemoClaw does not enable these new functions by default. The security review must confirm this condition.

The next NemoClaw tag will include both OpenShell upgrades. Users will upgrade from OpenShell v0.0.85 directly to v0.0.101.

The v0.0.99 to v0.0.101 test is necessary. This test does not replace the v0.0.85 to v0.0.101 test.

Objective

Qualify and select OpenShell v0.0.101.

Use these types of evidence:

• Release trust
• Migration review
• Executable contract tests
• Exact-head live end-to-end (E2E) tests
• Final release-candidate tests

Keep the documented behavior for these functions:

• Installation
• Onboarding
• Sandbox operations
• Network policy
• Managed MCP
• Credential substitution
• Inference
• Recovery
• Rebuild
• Backup and restore
• Uninstallation

The middleware channel must continue to operate after idle, suspend, resume, reconnect, and reopen events.

Use the final commit from #8583 as the repository baseline. Use the last public NemoClaw tag as the user baseline.

Mandatory merge and release gates

Do not merge the selector PR until all required live E2E tests pass on its exact head SHA.

Do not create the NemoClaw tag until the final release candidate passes the required release tests.

Use these gate rules:

• A later commit makes earlier evidence stale.
• A base update invalidates all local preflight evidence.
• Run the complete preflight again after a base update.
• Run the applicable tests again after each corrective commit.
• Unit tests do not replace live upgrade E2E tests.
• Integration tests do not replace live upgrade E2E tests.
• Package-contract tests do not replace live upgrade E2E tests.
• E2E-support tests do not replace live upgrade E2E tests.
• Fresh all-agent activation does not replace live upgrade E2E tests.
• Mocked resources do not replace live upgrade E2E tests.
• Synthetic containers do not replace live upgrade E2E tests.
• Automated reviews do not replace live upgrade E2E tests.
• Use the published OpenShell artifacts.
• Let OpenShell create and activate the test resources.
• Do not use hand-created containers as qualification evidence.
• Do not use fixtures that imitate released-runtime output as qualification evidence.
• Treat a missing, canceled, skipped, stale, or failed run as a blocking result.
• Treat an expected compatibility failure as a blocking result.
• Run an infrastructure-failed test again until it passes.
• Use a machine-readable blocking status or a trusted qualification receipt.
• Put the receipt schema version in each receipt.
• Reject an unknown receipt schema.
• Put the exact candidate SHA in each receipt.
• Put the NemoClaw and OpenShell baselines in each receipt.
• Put the OpenShell target, test identifiers, and results in each receipt.
• Put the run links or run identifiers in each receipt.
• Do not use a prose comment or an unchecked item as gate evidence.
• Require the selector gate for a change to an OpenShell selector or runtime identity.
• Require the selector gate for a change to a manifest or installer pin.
• Require the selector gate for a supervisor, gateway, or credential-boundary change.
• Configure repository automation to require the selector receipt for each applicable change.
• Require the final receipt before tag creation.

Implementation method

This method applies only to #8590. It does not make a general rule for other changes.

Use two stable candidate revisions. Use a third revision only for a new blocker or a required base update.

1. Freeze and divide the scope

• Use separate changes for release trust, compatibility preparation, the selector, and qualification enforcement.
• Keep qualification enforcement in its own change.
• Do not add general-purpose qualification infrastructure to the selector or compatibility changes.
• Keep each change limited to one technical purpose.
• Do not add unrelated refactors to the selector PR.
• Update the branch from main before Candidate 1.
• Do not update from main during an active review.
• Update from main again only when a base rule requires the update.

2. Make an invariant table

Before you change code, make one invariant table.

Put this information in the table:

• The changed OpenShell contract
• The upstream evidence
• All affected files and callers
• The positive tests
• The negative tests
• The required live evidence
• The completion status

Read all applicable path instructions. Search for every consumer of each changed contract.

Include these paths in the search:

• Docker and Podman implementations
• Success and failure paths
• Timeout and cleanup paths
• Backup and restore paths
• Status and lifecycle operations
• E2E logs and artifacts

When a review finds one problem, inspect all related consumers. Do not correct only the reported line.

Record the producer and consumer search for each changed shared contract.

A shared contract is complete only when all listed consumers have passing tests.

Parallel work

Use maximum safe parallelism after the invariant table is complete.

Use all available agent slots when independent work exists.

Assign one integration owner before agents change files.

This owner controls shared contracts, release-candidate assembly, candidate commits, candidate pushes, and qualification evidence.

Assign each agent one bounded workstream.

Use these workstreams when applicable:

• Release trust and artifact identities
• Upstream source and security review
• Docker compatibility
• Rootless Podman compatibility
• Runtime identity and SSH
• Gateway, supervisor, and middleware lifecycle
• Credential and policy boundaries
• Test consumer inventory
• E2E qualification design
• Documentation review

Run independent reviews and test design while implementation work continues.

Do not assign overlapping file ownership without integration-owner approval.

Do not let separate agents change the same shared contract concurrently.

Only the integration owner assembles release candidates, pushes candidate branches, and starts qualification evidence runs.

Each agent must report changed files, tests, risks, and unresolved questions.

If an agent finds a new shared contract, return that decision to the integration owner.

Integrate all completed work in one local batch.

Run one cross-workstream review after integration.

3. Use shared boundaries

Use one shared implementation when multiple consumers use the same contract.

Use shared implementations for these boundaries when applicable:

• Container identity and ownership
• Diagnostic sanitization
• External-process execution
• Podman socket authority
• OpenShell version and artifact identity
• Gateway status interpretation
• SSH target selection

Do not duplicate constants, parsers, or sanitization logic without an approved technical reason.

4. Complete the test matrix

Add these test cases for each changed behavior when applicable:

• Valid input
• Invalid input
• Legacy input
• Ambiguous ownership
• Foreign ownership
• Timeout
• External-process failure
• Cleanup after failure
• Secret-negative diagnostics
• Restart
• Repeated application
• Known-old-version sensitivity

Test behavior through a public boundary. Do not use source text as behavior evidence.

Put a secret marker in controlled external output. Make sure that no log or artifact contains the marker.

Cause each applicable process failure. Make sure that no child process or service remains.

Before Candidate 1, preflight the qualification system.

• Verify that all required build outputs exist.
• Verify that each test image contains the required runtime tools.
• Verify that each activation command has the intended lifetime.
• Verify that each background process stops or stays active as designed.
• Use the production Podman network backend and security policy.
• Do not use a test-only network backend as qualification evidence.
• Version the qualification-receipt schema.
• Test every receipt producer and consumer together.
• Reject an unknown receipt schema.

5. Review the frozen diff

Run separate review passes before Candidate 1.

Use independent review agents. Run all independent review subjects in parallel.

Use these review subjects:

• Functional correctness
• Security
• Data integrity
• Runtime identity
• Lifecycle and cleanup
• E2E isolation
• Migration and recovery
• Test quality

Resolve all valid major and blocking findings in one local batch.

Record minor suggestions. Change code only when a suggestion corrects a real risk or a required behavior.

Classify each failure before you change code.

Use one of these classes:

• Candidate-caused
• Base-wide
• Infrastructure

Compare the failed lane with current base evidence.

Do not add a base-wide correction to an upgrade change.

Run these repository checks before Candidate 1:

• Source-shape
• File-size
• Conditional-count
• Dependency-boundary
• Type
• Workflow-contract
• Artifact-security

After the final base update, run the complete candidate preflight.

• Run all eight required command-line interface (CLI) shards.
• Use the workflow-declared shell and environment.
• Run every test consumer for each changed shared contract.
• Record the consumer list and the test results.
• Do not push Candidate 1 until this preflight passes.
• Do not update the base after this preflight.

A required base update invalidates the preflight. Run the complete preflight again.

Run the applicable local tests and repository checks. Complete this work before you push Candidate 1.

6. Test Candidate 1

Create Candidate 1 as one stable, signed, and verified head.

• Push Candidate 1.
• Do not push another commit during an active review.
• Preserve repository-owned reviewer routing.
• Run all required CI on the exact head.
• Run all required live E2E tests on the exact head.
• Wait until all review rounds finish.
• Put all valid major and blocking findings in one correction batch.

7. Test Candidate 2

Apply the complete correction batch locally.

• Review the complete diff again.
• Run the applicable local tests again.
• Run the complete candidate preflight after the final base update.
• Do not push Candidate 2 until this preflight passes.
• Push Candidate 2 as one stable head.
• Run all required CI on the exact head.
• Run all required live E2E tests on the exact head.
• Wait until all review rounds finish.
• Confirm that no major or blocking thread remains.
• Confirm that no human change request remains.

Do not change code for an informational result that does not identify a real defect.

8. Control an additional revision

Use an additional revision only when Candidate 2 has a new blocker or needs a required base update.

• Record the missing invariant.
• Explain why the first two candidates did not find it.
• Add the missing regression test.
• Update the invariant table.
• Put all known corrections in one batch.
• Run the complete applicable qualification again.
• Do not apply only a local symptom correction.

Work plan

1. Record the baselines

• Complete fix(openshell): complete v0.0.99 compatibility #8583.
• Record its final NemoClaw commit as the repository v0.0.99 baseline.
• Record the last public NemoClaw tag.
• Record the exact OpenShell v0.0.85 identities from that tag.
• Record the final NemoClaw release-candidate SHA.
• Review the v0.0.99...v0.0.101 source boundary.
• Review the v0.0.85...v0.0.101 user boundary.

2. Establish release trust

• Review the published v0.0.101 tag and release.
• Review its checksum manifests, packages, and assets.
• Add the checksum-manifest identities through the base-branch trust model.
• Add these identities before the selector change.
• Record the immutable CLI identity.
• Record the immutable gateway identity.
• Record the immutable supervisor-image identity.
• Record the immutable sandbox-binary identity.
• Record the immutable virtual-machine-driver identity.
• Record the package and platform identities.
• Make sure that all consumers use the same release.

3. Review the changes

• Review the full v0.0.99...v0.0.101 source change.
• Review the full v0.0.85...v0.0.101 user change.
• Review the middleware and HTTP/2 keepalive changes.
• Review the credential and policy changes.
• Review the proxy and sandbox-isolation changes.
• Review the gateway and compute-driver changes.
• Review the package and dependency changes.
• Review all lifecycle changes.
• Generate the child-visible credential manifest for v0.0.101.
• Review the generated manifest.
• Do not rename the v0.0.99 manifest as a substitute.
• Make sure that new upstream functions stay disabled by default.
• Record each changed runtime contract.
• Include CLI output, errors, names, labels, identifiers, and SSH aliases.
• Include supervisor arguments, image metadata, process identity, and socket selection.
• Include policy validation and reconnect behavior.
• Capture fixtures from the published runtime.
• Add a fail-closed contract test for each changed contract.
• Add compatibility corrections before the selector PR when possible.

4. Prepare the selector PR

• Change the minimum and maximum OpenShell selectors to v0.0.101.
• Change all installer, blueprint, and workflow pins.
• Change all fixture and artifact identities.
• Change all trust anchors and credential manifests.
• Change all applicable documents and tests.
• Make sure that all OpenShell components use v0.0.101.
• Do not include unrelated changes.
• Do not merge the branch before qualification is complete.

5. Do the exact-head qualification

Test these installation paths with published artifacts:

1. Install NemoClaw with OpenShell v0.0.101 on a clean host.
2. Upgrade OpenShell v0.0.99 to v0.0.101.
3. Upgrade the last public NemoClaw tag from OpenShell v0.0.85 to v0.0.101.

Use released baseline state and released sandbox images for the upgrade tests.

For each applicable path, do these tests:

• Activate each registered agent.
• Test installation and onboarding.
• Test status, connect, exec, and SSH.
• Test inference.
• Test all supported policy presets together.
• Test managed MCP add, list, update, remove, restart, and rebuild.
• Test provider credential substitution.
• Test recovery and rebuild.
• Test backup and restore.
• Test stop, destroy, cleanup, and uninstallation.
• Test Docker with its real socket and identity contracts.
• Test rootless Podman with its real socket and identity contracts.
• Test supported operating systems and architectures.
• Test central processing unit (CPU) paths.
• Test applicable graphics processing unit (GPU) paths.
• Record an approved platform exception when a platform test is not applicable.
• Do not use an exception for a target-version compatibility failure.
• Run the openshell-00101-keepalive test.
• Apply the same configuration a second time.
• Make sure that the second application does not change the system.
• Keep all failure data short and sanitized.
• Do not publish credentials, tokens, secrets, or raw container data.
• Publish the exact-head qualification receipt.
• Run the applicable tests again after each corrective commit.

After all release changes are complete, test the exact final release-candidate SHA.

Run the clean v0.0.101 installation again. Run the direct v0.0.85 to v0.0.101 upgrade again.

Tests for the previous regressions

These tests apply only to #8590. Run them on the selector-PR head and the final release-candidate SHA.

Do not add these tests to these test groups:

• Default PR tests
• Scheduled tests
• Nightly tests
• The full-E2E matrix
• Tests for unrelated changes

A maintainer must make a separate decision before a test becomes a general gate.

Do these regression tests:

1. Make a regression table for all known v0.0.99 problems.
2. Link each problem to one executable test and one successful exact-SHA result.
3. Include the sandbox-name and supervisor-workdir problems.
4. Include the workspace-name, label, container-ID, and SSH-alias problems.
5. Include the gateway-status, Podman-socket, policy, and reconnect problems.
6. Make an inventory of all active OpenShell version consumers.
7. Make sure that each production consumer selects trusted v0.0.101.
8. Permit older versions only in approved migration fixtures, tests, and historical documents.
9. Put one v0.0.99 component in a v0.0.101 component set.
10. Make sure that validation stops before installation or sandbox changes.
11. Cause controlled failures during download and checksum verification.
12. Cause controlled failures during gateway replacement and sandbox migration.
13. Make sure that the old sandbox and its state stay available or recoverable.
14. Preserve or recover the registry, credentials, and recovery material.
15. Make sure that a second attempt succeeds without duplicate resources.
16. Create two workspaces or gateways with the same sandbox name.
17. Test status, connect, exec, SSH, stop, start, rebuild, and destroy.
18. Make sure that an operation cannot change the peer sandbox.
19. Install the complete Personal policy.
20. Include hostless ports 80/443 and the named mail and local-tool routes.
21. Apply the Personal policy a second time.
22. Make sure that no L4/L7 conflict, route loss, or duplicate state occurs.
23. Make sure that no misleading protocol error occurs.
24. Compare the effective v0.0.101 configuration with the approved baseline.
25. Compare the child-visible credential and policy boundary with the approved baseline.
26. Make sure that credential storage and the SDK stay disabled by default.
27. Make sure that the egress adapter and virtual-machine driver stay disabled by default.
28. Make sure that default credentials, egress, privileges, mounts, and compute-driver access do not increase.

Keep an optional test or fixture only for #8590. A separate maintainer decision is necessary before broader use.

Rootless Podman tests

Use two different proofs. The controlled contract proof does not replace the clean product-path proof.

For the controlled proof:

• Change podman-cpu-lifecycle to use the exact OpenShell v0.0.101 artifacts.
• Keep Docker unavailable.
• Use rootless Podman 5.
• Use the exact Podman socket.
• Start an authenticated OpenShell gateway.
• Activate all registered agents.
• Verify workspace identities, labels, full container IDs, and supervisor commands.
• Verify lifecycle authority and resource ownership.
• Fail the test if a Docker command runs.
• Keep diagnostic data short and sanitized.
• Verify cleanup.

For the clean product-path proof:

• Use a clean supported Linux host.
• Keep Docker unavailable.
• Remove all old NemoClaw and OpenShell state.
• Do not prepare a Podman API socket or OpenShell gateway manually.
• Install and onboard through public NemoClaw commands.
• Do not write the gateway configuration by hand.
• Do not inject a test-only socket.
• Do not start podman system service outside the product bootstrap.

Run all three installation paths with rootless Podman.

Make sure that Docker stays unavailable during each path. Fail the test if it uses a Docker CLI, daemon, socket, or fallback.

Verify these rootless Podman conditions:

• The unprivileged runtime user owns the selected socket.
• podman info reports rootless operation.
• The OpenShell gateway reports the Podman compute driver.
• Each sandbox operation uses the same Podman endpoint.
• Each registered agent activates.
• All required policy, MCP, credential, inference, and lifecycle tests pass.

Restart the Podman API service. Restart the OpenShell gateway. Restart both services together.

After each restart, connect to the existing sandbox. Verify its full container ID and durable marker.

Use one host reboot in one clean product-path test. If a reboot is not possible, restart the user session and all user services.

Install and onboard a second time. Make sure that the second operation creates no duplicate gateway, container, network, volume, secret, socket, or configuration.

Create ambiguous and foreign-workspace containers. Make sure that NemoClaw does not change these containers.

Before each destructive operation, verify these values:

• Labels
• Workspace and namespace names
• Full container ID
• Socket owner
• Process identity

After destroy and uninstallation, verify that no NemoClaw-owned resources remain.

Include containers, networks, volumes, secrets, gateway processes, and obsolete socket configuration in this verification.

Run the supported platform matrix. Put the OpenShell version, Podman version, socket authority, test path, agents, restart phases, and cleanup result in each receipt.

Keepalive test

Add one live test with the name openshell-00101-keepalive.

This test applies only to #8590. Do not add it to default, scheduled, nightly, or full-E2E tests.

Start this test manually with a trusted exact SHA.

Run the test on the selector-PR head. Run it again on the final release-candidate SHA.

Use a real OpenShell v0.0.101 sandbox. Put the middleware HTTP/2 connection behind a controlled proxy.

Configure the proxy to close a connection after 15 seconds without data.

Complete one middleware operation. Keep the connection idle for 35 to 40 seconds. Complete a second operation in the same sandbox.

The second operation must succeed. Do not create a new sandbox.

Verify the original sandbox identity. Verify its durable marker.

Do one sensitivity test with OpenShell v0.0.99. The controlled proxy must cause the known stale-channel failure.

Use the v0.0.99 failure only to verify the test. Do not include it as successful v0.0.101 evidence.

Keep this test optional after #8590 is complete. A maintainer must approve a general gate separately.

6. Enforce the gates and prepare the release

• Test a missing receipt.
• Test a stale receipt.
• Test a SHA mismatch.
• Test a version mismatch.
• Test a skipped, canceled, and failed result.
• Make sure that each negative case stops the selector gate.
• Test the same negative cases for the release gate.
• Update the migration, troubleshooting, security, and compatibility documents.
• Link the final receipt from this epic or the release checklist.
• Do not create the tag until the final receipt passes.

Rejected alternatives

Test only v0.0.99 to v0.0.101

This test does not represent the public upgrade path. Users will upgrade from v0.0.85.

Use only the keepalive unit test

The failure occurs across the gateway, supervisor, and middleware transport. A live test is necessary.

Use only the checklist from #8497

The checklist did not stop the v0.0.99 selector merge. Automated gate evidence is necessary.

Use mocked output or hand-created containers

These resources reproduce NemoClaw assumptions. They do not prove the behavior of the released runtime.

Limits

• Do not enable a new OpenShell function only because v0.0.101 contains it.
• Do not add a new OpenShell extension.
• Do not add a service-specific integration.
• Do not change MCP permits or network policies without a required compatibility correction.
• Do not use v0.0.99 results as v0.0.101 evidence.
• Do not omit the direct v0.0.85 to v0.0.101 test.
• Do not merge the selector before its exact-SHA gate passes.
• Do not create the tag before the final exact-SHA gate passes.

Acceptance criteria

Implementation control

• The work uses separate changes for trust, compatibility preparation, the selector, and qualification enforcement.
• The plan defines independent workstreams before implementation starts.
• All available agent slots are used when independent work exists.
• One integration owner controls shared contracts and candidate assembly.
• Each agent owns one bounded workstream.
• No agents change the same shared contract concurrently.
• Only the integration owner creates candidate commits, pushes branches, and starts evidence runs.
• Each agent reports files, tests, risks, and unresolved questions.
• One cross-workstream review passes after integration.
• Independent review subjects run in parallel.
• Qualification enforcement is separate from selector and compatibility changes.
• The selector and compatibility changes contain no general-purpose qualification infrastructure.
• Each failure has a candidate-caused, base-wide, or infrastructure classification.
• Base-wide failures do not add unrelated corrections to upgrade changes.
• The qualification system passes its own preflight before Candidate 1.
• Required build outputs and runtime tools exist before live qualification.
• Activation commands and background processes have the intended lifetimes.
• All specified repository checks pass before Candidate 1.
• The consumer inventory covers every producer, consumer, fixture, output, and assertion.
• Every listed consumer has a passing test.
• All eight required CLI shards pass before Candidate 1 is pushed.
• All eight required CLI shards pass before Candidate 2 is pushed.
• Shell fixtures use the workflow-declared shell.
• Candidate preflight uses the final selected base.
• A base update invalidates all earlier preflight evidence.
• The complete preflight runs again after a base update.
• No candidate is pushed before its preflight passes.
• The invariant table is complete before selector implementation starts.
• The table identifies all consumers, tests, failure paths, and live evidence.
• All applicable path instructions are reviewed.
• Each shared contract uses one implementation or has an approved reason for duplication.
• Each changed behavior has the applicable positive and negative tests.
• The tests use public behavior boundaries.
• The secret-marker test proves that logs and artifacts contain no secret marker.
• Failure tests prove that no child process or service remains.
• Candidate 1 stays unchanged until all review rounds finish.
• All valid Candidate 1 blockers are in one correction batch.
• Candidate 2 passes all required exact-head reviews, CI, and live E2E tests.
• No major thread, blocking thread, or human change request remains.
• Informational results do not cause code changes without a real defect.
• An additional revision records the missing invariant and adds its regression test.
• This implementation method applies only to [Epic] Qualify and pin OpenShell v0.0.101 #8590.
• This implementation method is not a general repository gate.

Baselines and release trust

• fix(openshell): complete v0.0.99 compatibility #8583 is complete.
• The final repository v0.0.99 baseline is recorded.
• The last public NemoClaw tag is recorded.
• The exact OpenShell v0.0.85 user baseline is recorded.
• The OpenShell v0.0.101 provenance is approved.
• All immutable artifact identities are approved.
• The migration review covers both version boundaries.
• The security review covers both version boundaries.
• The v0.0.101 child-visible credential manifest is generated and approved.
• All active production consumers select the same v0.0.101 release.
• Approved tests protect each changed runtime contract.

General compatibility

• The clean v0.0.101 installation passes.
• The v0.0.99 to v0.0.101 upgrade passes.
• The public v0.0.85 to v0.0.101 upgrade passes.
• OpenShell creates all qualification resources.
• Each registered agent passes activation and lifecycle tests.
• All supported policy presets work together.
• Managed MCP operations pass.
• Provider credential substitution passes.
• Docker and rootless Podman pass the supported platform matrix.
• Repeated installation and configuration do not change the system.
• Failure data is short, sanitized, and free of secrets.

Tests for the previous regressions

• The regression table links each known problem to a passing executable test.
• Both exact SHAs have a successful regression result.
• The version inventory finds no unapproved active older pin.
• A mixed-version component set stops before mutation.
• Each controlled upgrade failure preserves or recovers the old state.
• A second upgrade attempt completes without duplicate resources.
• Equal sandbox names stay isolated across two workspaces or gateways.
• The complete Personal policy installs and applies a second time.
• The Personal policy keeps all named mail and local-tool routes.
• The effective configuration does not enable a new upstream function.
• The credential and policy boundaries do not increase.
• These checks apply only to [Epic] Qualify and pin OpenShell v0.0.101 #8590.
• These checks are not general repository gates.

Rootless Podman

• podman-cpu-lifecycle uses exact OpenShell v0.0.101 artifacts.
• The controlled proof keeps Docker unavailable.
• The controlled proof passes for all registered agents.
• The Podman proofs use the production network backend and security policy.
• The clean Linux test uses the normal NemoClaw installation path.
• The clean Linux test does not use manual socket or gateway preparation.
• All three installation paths pass with rootless Podman.
• Docker stays unavailable and unused in all Podman tests.
• All operations use the verified rootless socket.
• All identity and ownership values match the released contracts.
• All registered agents pass the required Podman functions.
• Existing sandboxes survive all required service restarts.
• One test includes a host or complete user-session restart.
• Repeated installation creates no duplicate resource.
• Ambiguous and foreign-workspace containers stay unchanged.
• Destroy and uninstallation remove only NemoClaw-owned resources.
• No NemoClaw-owned Podman resource remains after cleanup.

Keepalive

• The explicit openshell-00101-keepalive test passes on both exact SHAs.
• The test keeps the same sandbox identity and durable marker.
• The v0.0.99 sensitivity test reproduces the stale-channel failure.
• The keepalive test is not a default or scheduled test.

Enforcement and release

• The selector receipt matches the exact current head SHA.
• Every receipt records its schema version.
• Every receipt producer and consumer accepts the selected schema.
• An unknown receipt schema stops the selector and release gates.
• A later commit makes the old selector receipt invalid.
• The selector gate stops all specified negative evidence cases.
• Repository automation requires the selector receipt for each applicable change.
• Each qualification receipt contains the required run links or run identifiers.
• The final release candidate passes the clean installation again.
• The final release candidate passes the direct public upgrade again.
• The release receipt matches the exact final SHA.
• The release gate stops tag creation without a valid receipt.
• Public documents show the supported path, prerequisites, and compatibility limits.
• Public documents include keepalive and reconnect troubleshooting.

Child issues and dependency waves

#8590 remains the integration owner.

Use one integration-owner thread and up to three independent child implementation threads.

Each child owns one branch, worktree, and pull request during implementation.

The integration owner controls shared contracts, release candidates, and qualification runs.

Do not start a child before its listed dependencies are ready.

All children remain assigned to the integration owner until dispatch.

The integration owner reassigns one child when its implementation thread starts.

Do not let child issues change the same shared contract concurrently.

Each child reports changed files, tests, risks, and unresolved questions before handoff.

Wave 1: parallel preparation

• Record OpenShell v0.0.101 baselines and release trust #8598 records baselines and release trust.
• Review OpenShell v0.0.101 migration and security contracts #8599 reviews migration and security contracts.
• Define OpenShell v0.0.101 qualification receipts and gates #8600 defines qualification receipts and gates.
• Build the OpenShell v0.0.101 keepalive qualification proof #8601 builds the keepalive qualification proof.

Start independent Wave 1 work in parallel.

#8598 records the final #8583 baseline when it becomes available.

Wave 2: parallel compatibility and regression work

• Implement OpenShell v0.0.101 runtime identity compatibility #8604 implements runtime identity compatibility.
• Qualify OpenShell v0.0.101 with rootless Podman #8603 qualifies rootless Podman.
• Qualify OpenShell v0.0.101 policies and credentials #8602 qualifies policies and credentials.
• Build OpenShell v0.0.101 upgrade and recovery regressions #8605 builds upgrade and recovery regressions.

Start Wave 2 after #8599 freezes the changed-contract inventory.

Use the ownership rules in each child issue.

#8603 and #8605 coordinate shared identity expectations with #8604.

#8605 consumes policy behavior from #8602.

Wave 3: selector candidate

• Update NemoClaw selectors and pins for OpenShell v0.0.101 #8606 updates selectors and runtime pins.

Start Wave 3 after all required Wave 1 and Wave 2 acceptance criteria pass.

Wave 4: selector qualification

• Run OpenShell v0.0.101 selector exact-head qualification #8607 runs exact-head selector qualification.

Use the exact candidate from #8606.

Return each candidate blocker to its owning child issue.

Assemble and qualify a new candidate after all corrections pass.

Wave 5: final release qualification

• Qualify the final OpenShell v0.0.101 release candidate #8608 qualifies the final release candidate.

Start Wave 5 after #8606 merges and #8607 publishes a passing receipt.

Required order

1. Complete fix(openshell): complete v0.0.99 compatibility #8583 and record the repository baseline.
2. Add the v0.0.101 release trust identities.
3. Complete both migration and security reviews.
4. Add compatibility corrections before the selector change when possible.
5. Prepare the selector PR.
6. Run all tests on the exact selector-PR head.
7. Correct each failure and run the applicable tests again.
8. Merge the selector after the selector gate passes.
9. Assemble the final release candidate.
10. Run the clean installation and direct public upgrade on its exact SHA.
11. Create the tag after the final gate passes.

Public references

• OpenShell v0.0.101 release
• OpenShell v0.0.99 to v0.0.101 comparison
• OpenShell v0.0.85 to v0.0.101 comparison
• OpenShell keepalive correction
• NemoClaw OpenShell v0.0.99 epic
• NemoClaw v0.0.99 compatibility PR

Category

Feature

Checklist

• I searched for duplicate issues.
• This issue is a design proposal.