The gate treated a literal process.env substring search as repository-wide source-ownership enforcement. It missed equivalent syntax while matching comments and strings, so the allowlist projected a security guarantee the implementation could not provide.
Remove the scanner and its allowlist. Keep the independently useful shipped-config inline tripwire, and narrow both the module contract and bilingual Agent Note to its actual source-shape claim.
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.
Link-blue at rest with hover underline, matching URL-promoted inline
code; an at-rest underline collides with monospace descenders inside
the code chip.
- apps/cli/reference/README: state the win32 permission/sandbox/approval
degradation so the workspace-write promise no longer misleads Windows users
- bundle README + agent note: give the complete bash-restore recipe (disable
pwsh-local/tool-pwsh and re-enable bash-sandbox/tool-bash), since both
executors register the same bash service and an incomplete recipe fails
loud at load
- windows.cordis.patch.yml: header comment notes the recipe and that the
ui-permission row belongs to dsh-web-app (base-only profiles get a
harmless no-match warning)
- profile-boot.ts: rewrap composeProfile JSDoc
- re-record i18n hashes for the touched bilingual pairs
Master added this scenario while this branch was open, so its golden froze
the composer seat's "Select model" fallback. The scaffold's route-only
adapter (added here for fixture-less scenarios) makes the seat resolve the
model those scenarios actually route to, which is what the other eight
goldens on this branch already show. Only the two seat lines move.
`resolveModel` validated the profile's reasoning level against the exact
model and threw when it did not fit. That call builds the model catalog,
and the catalog build catches per PROVIDER — so one mis-set field took the
whole provider out of every picker behind a single error row, hiding even
the models that do support the level. Measured: `anthropic` set to `max`
threw for six of its eight models.
Describing what a model can do now reports an unusable profile level as no
default rather than throwing; the request path still refuses it, which is
where a bad configuration belongs. The existing spec asserted the old
throw and now asserts both halves of that split.
Known gap, left deliberately: a model that cannot take the route's level
still fails its first request while the picker shows 「Default」 for it,
because the request path keeps using the profile level as the fallback.
Reaching that needs a hand-written `settings.yaml` — the Models page no
longer writes the field — and the error names the model and the level, so
selecting a supported level is a way out. Closing it properly means giving
`AgentOptions` a `reasoningEffort` so compositions without a model picker
keep an entry point, then dropping the provider-scoped field altogether;
that is its own change.
