Skip to main content

Tooling Command APIs

Morph packages can own CLI behavior through tooling descriptors and tooling implementations.

Tooling Is A First-Class Extension Surface​

A package command is not just a helper function.

It is part of the package contract:

  • command identity
  • aliases
  • usage/help text
  • execution behavior

This lets commands live in package space instead of in core dispatch tables.

What Tooling Features Own​

A tooling feature can own:

  • top-level commands
  • nested commands
  • package-specific diagnostics
  • orchestration over build or execution hosts

Examples already exist in packages such as Build, Vcon, and Test.

Why This Matters​

If commands are hardcoded in core:

  • every new package command requires core edits
  • plugin ownership is broken
  • build and execution behavior become centralized again

Tooling APIs prevent that by making commands discoverable through the Morph graph.

What Package Authors Should Do​

If your package needs a command:

  1. add a package-owned tooling feature
  2. declare command metadata through the package system
  3. implement the behavior inside the package

If the current tooling host cannot express the command pattern, widen the generic tooling API.

What Package Authors Should Not Do​

Do not:

  • hardcode new command names in core dispatch
  • attach one package's command behavior to generic CLI files
  • bypass tooling descriptors with manual side-channel registration

Next Steps​