Action and capability contract#

Distinguish the action manifest, offline preflight receipt, and unavailable installed-capability report in the public CLI.

Overview#

The public CLI contains an action manifest, an offline preflight, and an installed capability report. The current archive can use the first two. It cannot produce the installed capability report because it does not include the installer receipt layout.

Customer Action Manifest#

The versioned manifest contains 25 actions:

  • 22 actions are marked executes=true;

  • altifigence.analyze.run, altifigence.evolve.launch, and altifigence.verify.run are the three plan-only actions.

executes=true means the action is defined as executable. The actual command can still need a local engine, account permission, or remote service. A plan-only action validates and returns a plan without running a job.

Use alti commands to inspect the manifest shipped with the current binary. Do not copy a command list from a different release.

Offline Preflight Receipt#

The offline job validate workflow verifies one bounded CPU RTL envelope and a safe workspace-relative source. A successful receipt explicitly states submitted: false and server_authority_verified: false. It does not run a local engine or contact a hosted service. See CLI First Success.

Installed Engine Capability Contract#

The capability schema defines these states for a correctly installed, receipt-backed release:

State

Meaning

real

The installed release provides the documented local surface

partial

Only the reported subset is available

unavailable

The installed release cannot provide the surface

default-off

The surface requires an explicit, documented opt-in

plan-only

The action returns a plan rather than evidence of execution

The public archive has no installer, installed catalog, or receipt layout, so alti capabilities cannot produce a successful trusted capability report from it. Do not work around that by copying a binary elsewhere or hand-writing a receipt.

That failure is about the capability report, not about the engine binaries. The archive ships them beside alti, and alti resolves an engine as a sibling of its own executable — falling back to PATH — and runs it, so a sibling executable name does correspond to a binary that can run. What the missing report withholds is the signed, receipt-backed claim about which surface the installed release provides. Keep the two questions apart:

Question

Answered by

Did this command run here, and with what result?

The command’s own exit status and the receipt line naming the binary, the resolution, and the status

Does this installed release report the capability as available?

A successful alti capabilities report on an installed release

A successful local command reports what ran on that machine. Automation that depends on an installed product capability should also require the capability report.

Source Upload Is Opt-In#

The packaged stdio MCP server hides the three plan actions that can include source files. They require separate environment credentials and use the Cloud client. The current public release does not provide a complete remote execution workflow for them.

An opt-in permits transmission; it does not turn a plan-only action into a real run or make a remote service available.

Handle Each Result Separately#

When automating the CLI, handle these results as different states:

  • a local capability is available;

  • a request was validated;

  • a plan was returned without execution;

  • work was accepted by an explicitly enabled authority;

  • work completed and produced evidence;

  • a capability or authority was unavailable.

Collapsing these states into a single success value can make a plan or preview look like completed engineering work.