Drop the filler and factually loose comments added with the tool-pwsh rows:
the platform expressions self-explain, the web-app overlay comment repeats
the file header, and the spec comments now state only the platform-scoped
evaluation fact.
The web-app overlay now disables the host tool-pwsh row too, and the shipped
presets (standard/code/cordis) declare both shell tool rows with inverted
platform gates — tool-bash on POSIX, tool-pwsh on win32 — so the preset layer
exposes exactly one shell tool per host and a preset can drop or replace the
shell tool on either platform. windows-shell.spec pins both preset gates and
both host tool rows disabled in the web composition; the loader and Windows
pwsh notes are updated in place.
Entry \disabled\ interpolation makes the launcher's separate platform layer
unnecessary: the base bundle's cordis.patch.yml now gates both shell stacks
on its own rows — bash-sandbox/tool-bash disable on win32, and their twins
pwsh-sandbox/tool-pwsh mount only there with the inverted expression — so
exactly one shell stack mounts per host from one shared patch file.
windows.cordis.patch.yml and the launcher's windows-shell.ts injection (boot,
live recomposition, config dumps) are deleted, with the workspace-constraints
entry and the dsh-base exports/files entries following. The windows-shell spec
pins the effective per-platform roster through the real bundle layers, and
base.spec pins the four symmetric gates. The superseded active notes are
updated and cross-linked; the loader note records the fold itself.
The Windows platform layer disables tool-bash and inserts the pwsh stack, but the shipped presets each mount a tool-bash row that re-enabled the tool on win32 — the session had both a PowerShell-backed bash tool and tool-pwsh, silently, because no spec pinned the composed preset layer.
The Loader now evaluates a disabled: !!js expression against the loader context at every mount decision; disabled is the only interpolated metadata field, and the raw node stays in the options so write-back keeps the !!js form. The standard/code/cordis presets gate tool-bash with process.platform === 'win32', verify-cordis-config allows expressions in disabled only, and the windows-shell spec pins the preset-level invariant.
loadOverlayPatches already throws on a missing file (the caller named
it, so absence is a misconfiguration) — the existsSync guard was a
second fail-loud mechanism for the same miss with a prettier message.
The loader's throw keeps the fail-loud contract the Windows-default
note records.
The launcher's healProfilesModuleFallback BFS-links the apps/cli dependency closure into the profile's node_modules (the pwsh-local precedent): without dsh-pwsh-sandbox in apps/cli dependencies, a fresh Windows host cannot resolve the inserted row. Assert the closure reaches both inserted packages in the real-layers composition; rewrap the windows-shell layer comment.
The Windows platform layer re-enables the base fs-sandbox row (removing its disable), but still inserted dsh-fs-local: both extend FileSystem and provide ctx.fs, so every shipped win32 profile failed at load. Delete the insert; fs-sandbox stays the single fs provider exactly as on POSIX. Sync the roster specs, the base/reference README pairs, the sandbox core doc (read-only grants no sink on Windows), the windows-shell JSDoc, and re-record the i18n pairings.
The resolver suite previously exercised only fixture patch lists, leaving
the real shipped windows.cordis.patch.yml and the bundle→windows→user
composition ordering untested on Linux CI. The new cases load a temp
profile whose bundle layers resolve from the real dsh-base/dsh-web-app
packages (app installation anchor), apply the platform layer through the
boot's own composeEntries algorithm with the platform injected, and
assert the win32 danger-full-access roster (eight disables, three
inserts, no warnings on the web profile). A second case pins POSIX
unchanged and the base-only-profile ui-permission no-match warning as
warned-but-harmless, matching the patch header's documented contract.
win32 hosts booting a shipped profile now get pwsh-local as the ctx.bash
executor and tool-pwsh as the shell tool through the base bundle's new
windows.cordis.patch.yml platform layer, injected by the launcher between
the bundle layers and the user layers on win32. bash-sandbox, tool-bash,
permission, and ui-permission are disabled there: the POSIX-only executor
cannot run on Windows, and dsh-permission requires a confining executor.
Overriding the default is a composition decision through the user's
cordis.patch.yml; there is no environment override channel.
apps/cli and dsh-base re-declare dsh-pwsh-local/dsh-tool-pwsh so the
profile module fallback links them for cold starts (the profiles rework
had dropped them from the CLI closure).
Promotes the windows-pwsh-default Agent Note from proposed to implemented
and documents the platform layer in the base bundle README.
