engine.apiReference {} -> {markdown} writes a reference from the built-in
commands' parameter schemas each time it runs: a section per command that
has a schema, in registry order, with its label, menu path, API levels,
what it writes, cost, summary and return, and a table of its parameters
(type, range with included or excluded ends, unit, JSON or worked-out
default, required, levels and description; object members as dotted
rows). Commands without a schema, plug-in commands included, are left
out. Schema text is escaped so it stays plain text in its cell, control
characters become spaces, and a reference past 1 MiB is an error rather
than a cut-short text. The command needs no document.
MCP serves the same text as the fixed resource
vectorcraft://commands/reference (text/markdown; charset=utf-8); the
other resources still read as JSON.
The command's own schema raises the schema API level to 2. Its label and
its size error have rows in every catalog that needs them.
Docs: docs/mcp.md, docs/target-app-parity.md.
A server confined with --automation-read-root or
--automation-write-root has no plug-in store, so a grant accepted under
the flag could not be written to grants.json and recorded grants were
not read. mcp now refuses the combination at start-up.
The help text, docs/plugins.md and docs/mcp.md state that a confined
server does not install a module that lists permissions or asks for a
heavy budget, and that with VECTORCRAFT_NO_PREFS set a grant accepted
under the flag lasts for that session only.
plugin_grants_need_the_start_up_flag now drives `vectorcraft-cli mcp
--headless` over stdio. plugin.install with grant is refused without
--allow-plugin-grants and accepted with it.
`plugin.install` accepted `grant` and `allowHeavy` from any client, so
the program installing a plug-in could answer its own permission
prompt.
The desktop app now shows an approval dialog that names the module,
its hash and what it asks for. Confirming it gives the engine a
one-use approval tied to that module id, hash and permission list. A
control or MCP request and a frame of synthetic input cannot confirm
the dialog, and Enter does not confirm it.
Without such an approval, `grant` and `allowHeavy` are refused. The
new `--allow-plugin-grants` flag on `mcp` and `run` lets a person who
starts a headless session accept them from requests. The flag cannot
be combined with `--connect`. A module already approved in the desktop
app still installs through its stored grant.
`vectorcraft-cli mcp --help` stopped with "unknown mcp option `--help`",
and `run`, `convert`, `info`, `bench` and `perf` treated `--help` and
`-h` as an unknown option or a file name, while `vectorcraft-cli help`
printed the usage. `--help` or `-h` after a subcommand now prints the
same usage and exits successfully, before the subcommand parses a value
or reads a file, so `run --commands missing.json --help` prints it too.
As the value of an option it stays that option's value: `run --cmd -h`
and `convert IN --range -h` still read `-h` as before.
The error for `--connect` with an automation root also had a run of 21
spaces in the middle of its text; it now has one.
* CI: line tables only for workspace crates, no debug info for dependencies
* CI: one integration-test binary per crate
Each crate's tests/*.rs files become modules of tests/it/main.rs. Files that change
process-wide state (Color Settings, the font database, installed plug-ins, the working
directory), the fuzz sweeps and the test targets the Affinity corpus workflow names stay
their own binaries.
* Docs: name the integration tests' new paths
* CI: xtask test with nextest and doctests, one wasm check, clippy --keep-going
cargo xtask ci runs the tests with cargo nextest (cargo test when it is not installed),
builds them with --lib --bins --tests, runs the doctests as their own step, and checks
the wasm crates in one cargo check --keep-going call.
dotCooCoo