test:install:smoke fails on baseline-install step when corepack pins different pnpm than v2026.5.6.5

[webdevtodayjason]

Summary

pnpm test:install:smoke (Docker) fails before reaching the install-script code under test. The smoke harness checks out the previous release tag (currently v2026.5.6.5) as a baseline-install step, runs pnpm install against it, and the project at that tag pins pnpm@10.23.0. Operators with newer pnpm via corepack get refused:

ERROR  This project is configured to use 10.23.0 of pnpm. Your current pnpm is v11.3.0
Corepack invoked pnpm with this version, and pnpm does not switch versions when running under corepack.

The smoke then exits non-zero before ever testing the install.sh / install-cli.sh / install-hosted.sh code paths that are the actual subject of the smoke. This means any release attempt fails the install-smoke gate, regardless of what the release actually changed.

Hit live on 2026-05-25 attempting to validate v2026.5.6.6 before tag-push.

Repro

git checkout v2026.5.6.6  # any release branch
ARGENTOS_INSTALL_SMOKE_SKIP_NONROOT=1 pnpm test:install:smoke

Expected: smoke checks out previous release, runs the upgrade path against current HEAD, validates installer behavior.

Actual: smoke refuses to install the baseline release because pnpm version mismatch. Smoke exits before the installer logic runs.

Why this is its own bug, not "operator config"

• The corepack pin in v2026.5.6.5's package.json is what's loaded by the baseline-install step
• The current package.json may pin a newer pnpm
• Corepack reads the pin from whatever package.json is in cwd at invocation time and refuses to downgrade
• The smoke runs both side-by-side and there's no per-step pnpm-version isolation

The escape hatch ARGENTOS_INSTALL_SMOKE_SKIP_PREVIOUS=1 exists exactly for this case, but skipping the previous-baseline step means the smoke no longer validates the upgrade scenario — only fresh installs. Real operators almost always hit the upgrade path, not the fresh-install path.

Suggested fixes (ranked)

1. Per-step pnpm version isolation in the Docker smoke. Each phase of the smoke (baseline install, current install, upgrade) runs in its own container with its own pnpm pin. This is the proper fix — Docker is already involved.
2. Bypass corepack in the smoke. Invoke pnpm directly without corepack, or set corepack.disable=true for the smoke's environment. Per the error message, this is documented as --pm-on-fail=ignore.
3. Refresh the baseline pin. Update the package.json pnpm version on dev to match what the smoke harness actually invokes. Brittle long-term but unblocks the immediate problem.
4. Document ARGENTOS_INSTALL_SMOKE_SKIP_PREVIOUS=1 in the release runbook as the standard path when this hits, plus an explicit note that the operator is now on the hook for manual upgrade testing.

Operator-visible impact

• v2026.5.6.6 was cut against ARGENTOS_INSTALL_SMOKE_SKIP_PREVIOUS=1 (partial smoke coverage) because the full smoke could not run
• Future releases hit the same wall until this is fixed
• New-operator install scenario remains partially covered (the fresh-install branch the smoke can still run); upgrade scenario is not covered by the smoke until this lands

Related

• ops/runbooks/release-core.md step 4 currently lists test:install:smoke as mandatory — needs an "escape hatch when corepack issue hits" footnote, OR this gets fixed and the runbook stays clean
• Smoke harness lives in scripts/test-install-sh-docker.sh per package.json

[webdevtodayjason]

Hit a second infra wall on 2026-05-26 trying the ARGENTOS_INSTALL_SMOKE_SKIP_PREVIOUS=1 escape hatch:

```
scripts/test-install-sh-docker.sh: line 14: docker: command not found
ELIFECYCLE Command failed.
```

Operator's machine (the one cutting the release) doesn't have Docker installed, so the smoke can't run regardless of which previous-baseline flag is set.

Combined with the corepack issue: the install-smoke is effectively unrunnable from a non-Docker dev machine, even via the documented escape hatch.

Also noted while looking: .github/workflows/install-smoke.yml only triggers on push: branches: [main] and workflow_dispatch. It does NOT run on tag-push or on PRs against dev. So tag-push of v2026.5.6.6 will not auto-fire the smoke either — operator has to manually trigger via gh workflow run install-smoke.yml after the tag lands if they want smoke coverage at all.

Suggested addition to the fix list:

• 5. Make smoke run on tag-push (additionally to main push). Right now there's no automated coverage at the release-tagging gate, only at the eventual main-promotion gate. That's backwards — you want the smoke BEFORE the immutable tag, not after.

Linking from PR #424 which is the release that surfaced this.