# 1.2.0 release validation

This release uses the npm name `dsh-codex-style-computer-use`. The repository remains
`ltmroberthk915/dsh-computer-use`. The existing npm name `dsh-computer-use` points to
another author's repository, so legacy Git/tarball installations require one migration
through the plugin UI. Tool names, the settings namespace, approval gates and the
1.2.0-rc.2 native input behavior are retained.

## Verified locally on Windows, 2026-10-03

- All 37 regression scripts passed. The suite includes native input fixtures,
  approval/brake/cancellation contracts and 10 new installation cases. The optional
  exit-coherence native leg retains its existing opt-in policy.
- New installation coverage: no PowerShell on PATH, no available compiler with a
  valid prebuilt helper, stale source identity, damaged binary/cache, Unicode and
  space-containing paths, and four simultaneous cold starts.
- Both native helpers carry source and binary SHA-256 identities. Helpers run from
  a user cache outside `node_modules`, so a running helper does not lock package
  files during an update. Source checkouts use Windows' own .NET Framework compiler
  directly without invoking PowerShell.
- The actual npm tarball was installed through dshmarket's official desktop bridge
  and the unmodified DSH Desktop 0.2.0-rc.2 PluginManager into an isolated profile.
- The published npm candidate was downloaded and verified against the local archive,
  installed through that bridge, and reinstalled at the same version successfully.
  The market's actual update check detected `1.2.0-rc.3` → `1.2.0`; applying that
  update installed `1.2.0`, after which the check correctly reported no update.
  The registry download of the final release is byte-identical to the local archive.
- An empty-PATH, cold-cache smoke test against that installed package passed worker
  ping, cursor query, read-only screenshot capture and attention-helper startup.
  This smoke test does not inject desktop input.
- The installed plugin imports successfully through the official DSH runtime's
  package resolver. Its 18 desktop tool schemas compile with both the installed
  older CLI DSL and the official Desktop 0.2.0-rc.2 DSL.
- The tarball contains precompiled JavaScript, both native helpers and manifests,
  C# source, bundle patch and all skill references. It contains no install, prepare,
  prepack or prepublish lifecycle hooks and no package-manager bootstrap.

The isolated manager has no running UI/HMR service and correctly reports a restart
requirement. These checks do not establish live activation in every DSH version.
Follow the host's restart indication. Market catalog acceptance and propagation are
managed by the external marketplace, separately from npm publication.

## Release procedure

1. Run `node scripts/build-native.mjs` on Windows after modifying either C# source.
2. Run `node scripts/verify-package.mjs`, the regression suite and tool-schema guard.
3. Pack and test the actual archive. Publish the intended stable version to `next`
   first (`npm publish <archive> --tag next`), and verify that the existing `latest`
   tag has not changed. Do not use `--tag latest` for a newly published build.
4. Test with independent cache/store directories and explicit strict release age,
   in addition to the default host configuration. Verify same-version reinstall,
   config composition and updates through the actual market bridge.
5. After at least 24 hours, run `node scripts/release-channel.mjs check <version>`.
   Only when ready, use `node scripts/release-channel.mjs promote <version>` to
   recheck the registry and move `latest`. The command rejects young versions,
   missing times, wrong repository identity, prereleases and downgrades. Then
   promote the corresponding GitHub release to latest and verify both downloads.
6. Verify that the market catalog resolves the repository to the new npm name.

### Registry access for publisher checks

`check` defaults to `https://registry.npmjs.org`. Set `CU_REGISTRY` to an accessible
HTTPS registry for a read-only mirror check, for example in PowerShell:

```powershell
$env:CU_REGISTRY = 'https://registry.npmmirror.com'
node scripts/release-channel.mjs check 1.2.0
Remove-Item Env:CU_REGISTRY
```

Successful JSON reports both `registry` and `authoritative`; a mirror result has
`authoritative: false`. Failure output identifies the selected registry. Exit
codes are `0` (ready), `2` (still cooling), and `1` (query or validation failed).
A failed request does not prove that the package is unpublished, and a mirror
may not have synchronized its metadata yet. Configure npm's network/proxy access
if necessary; do not change the end user's package registry for this check.

`promote` always queries and writes the official registry, ignoring `CU_REGISTRY`.
It must obtain fresh publication-age and repository evidence there before moving
`latest`; a mirror's verdict never authorizes promotion by itself. This script is
for publishers only and is not an installation hook.

The npm package is discovered by the market from the repository's `package.json`
and its matching npm repository metadata. The source catalog does not accept an
`npm:` field in individual YAML entries.

## Third-round distribution correction — 2026-10-03

The original matrix used the default, non-strict pnpm 11 policy. That policy
automatically records a single-version age exception. It did not establish that
first-day installation works with a user's explicit strict policy.

The new matrix runs the bundled Electron Node executable and pnpm.mjs from DSH
Desktop, with separate profiles, caches, stores and configuration for every case:

| Cold install case, using actual published 1.2.0 | Result |
|---|---|
| Default policy, bare package name | Installs; pnpm adds a version-specific exception |
| Explicit `minimumReleaseAge: 1440`, bare name | Rejected: NO_MATURE_MATCHING_VERSION |
| Same strict policy, exact `@1.2.0` | Rejected: NO_MATURE_MATCHING_VERSION |
| Same strict policy, npm tgz URL | Rejected: NO_MATURE_MATCHING_VERSION |
| Same strict policy, exception for only `name@1.2.0` | Installs; registry dependency recorded |

No claim of a universal tarball bypass is made. The default 24-hour cutoff for
1.2.0 is 2026-10-04 03:50:11.586 UTC. Mirrors and longer user policies remain host
constraints. No newer npm version was published for these documentation and
publisher-tool fixes, so the existing 1.2.0 publication clock is preserved.

The official app-boot composer also reproduced the rename bug: an old-name
override was skipped and `read-only` reverted to the bundle's `standard` default.
After the narrowly scoped migration, all config values and the disabled flag were
retained, with no name-mismatch warning. Tests cover backup integrity, comments and
CRLF preservation, idempotence, invalid YAML and concurrent-edit refusal.

Run the publisher checks with `node build/test-release-channel.mjs`. Run the host
composition check with `node build/verify-profile-migration.mjs <DSH-runtime-dir>`;
the runtime directory contains the host package.json and dependencies. The
migration tool is an explicit repair utility, not an install/startup hook.

Issue #1 follow-up used the actual installed Desktop 0.2.0-rc.2 app.asar manager,
its bundled Electron/Node and pnpm 11.7.0, and dshmarket 1.66.7's bridge. Fresh
default-profile installation and an exact-version re-add succeeded; the market
update check reported 1.2.0 current with no update. A separate strict profile
reproduced the release-age refusal. These are isolated installation checks, not
a claim that every same-source install path avoids the host's ambiguity check.
The corrected publisher CLI also passed live read-only checks against npm's
origin through a proxy and npmmirror directly with no proxy override; both
reported the same publication time, their registry provenance and exit code 2
while the release was younger than 24 hours. An unreachable registry returned
exit code 1 with an explicit query failure, not an unpublished-version verdict.
No npm version or runtime file changed for this follow-up.

The third-party installation report observed new bundles loading live without a
restart. That corrects a blanket restart requirement, not the host's explicit
restart-required result when replacing an already loaded module. Follow that
result and verify tools/skill availability.