Expand description
The command table: one array, read by every front end.
Invariant: a command exists once. COMMANDS holds its name, its
summary, the parameters it takes and the function that runs it, and the
three front ends read that array rather than each carrying a list:
inillucent <verb>builds its usage and its argument parsing from it;inillucent-mcpbuildstools/listand its JSON Schemas from it;inillucent helpprints it.
crates/inillucent-compat/tests/tooling/command_parity.rs fails the build if a
command loses its description, if a parameter loses one, if a command is
hidden from MCP without a stated reason, or if the two surfaces stop naming
the same set. That test is the whole point of the arrangement: this
repository already argues, in drivers/README.md, that a capability list
nobody runs decays into a list of claims that were true once, and a command
list is the same kind of claim.
Everything here goes through crate::shell::Shell. The shell is
already an adapter over the public facade, and the 416-case differential
probe covers that path. A command table that reached past it to the engine
would be a second path to the same data, answering slightly differently, and
nobody would find out from the tests that exist.
Re-exports§
Modules§
- outcome
- What a command produced, and the two ways it is read.
- verbs
- What each command in the table actually does.
Structs§
- Arguments
- The values a command was given.
- Command
- One command.
- Context
- Where a command runs: the database, and the limits placed on it.
- Param
- One parameter a command takes.
Enums§
- Kind
- What kind of value a parameter takes.
- Open
Mode - Whether a command surface may write to the database it opens.
- Writes
- What a command does to the database, for the two questions that asks.
Statics§
- COMMANDS
- Every command inillucent has, in the order
helplists them.