Project-local runtime resolution

For normal project commands, codepotx-cli prefers the consumer project's local codepotx/runtime installation. The CLI should not embed a second independent copy of compiler and generator behavior.

Resolution flow

This keeps the frontend aligned with the runtime version chosen by the project lockfile.

Why this matters

Without project-local resolution, a globally installed CLI could silently run a different compiler, artifact schema, template engine, or generation policy from the version declared by the project.

Project-local resolution provides:

• reproducible behavior across developer machines;
• compatibility with the project's lockfile;
• one domain implementation for CLI and programmatic use;
• safer upgrades;
• clearer version diagnostics.

Supported package boundaries

The CLI loads the published runtime entrypoint:

It must not import private runtime handlers or internal source files from the consumer project.

Explicit project paths

Use explicit paths when the command is launched outside the project root:

The CLI passes these values into runtime resolution. It does not interpret contract or task semantics itself.

Version and compatibility failures

A clear failure should be returned when:

• codepotx is not installed in the project;
• the runtime entrypoint is unavailable;
• the CLI and runtime operation contracts are incompatible;
• the project requires a newer feature than the loaded runtime provides;
• an unsupported private entrypoint is referenced.

Do not fall back silently to unrelated global engine behavior.

Embedded use

Applications that do not need terminal parsing can call the runtime directly. The CLI also exposes a programmatic entrypoint for terminal-compatible invocation:

Use the runtime API instead when the caller wants typed results rather than CLI exit-code and presentation behavior.