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.
24 lines
943 B
TypeScript
24 lines
943 B
TypeScript
/**
|
|
* The verify-cordis-config metadata contract: `disabled` is the one entry
|
|
* metadata field whose `!!js` expression the Loader interpolates; every other
|
|
* metadata field must stay static, and a disabled expression must parse.
|
|
*/
|
|
|
|
import { describe, expect, it } from 'vitest'
|
|
import { metadataExpressionErrors } from './verify-cordis-config.ts'
|
|
|
|
describe('verify-cordis-config metadata expressions', () => {
|
|
it('accepts a disabled !!js expression', () => {
|
|
const problems = metadataExpressionErrors(
|
|
{ id: 'tool-bash', name: '@deepseek-ai/dsh-tool-bash', disabled: { __jsExpr: "process.platform === 'win32'" } },
|
|
'[0]',
|
|
)
|
|
expect(problems).toEqual([])
|
|
})
|
|
|
|
it('rejects an expression in a static metadata field', () => {
|
|
const problems = metadataExpressionErrors({ id: { __jsExpr: 'process.platform' }, name: 'pkg' }, '[0]')
|
|
expect(problems).toContain('[0].id: !!js is not interpolated here')
|
|
})
|
|
})
|