The Test for Agent-Native Software

CLI-Anything begins with a simple ambition: let an agent use software designed for humans without reducing that software to a toy. The harder question is how to tell whether the ambition has been met. This final chapter reconnects the command contract, the source-to-harness lifecycle, the real-backend boundary, persistent state, layered verification, discovery, and previews. It offers a conditional test for CLI-Anything and similar systems: trace an agent's intent all the way to a verified artifact, then ask which dependencies and evidence limits still stand in the way.

The complete path is a chain, not a feature list

An agent-native workflow starts before a command is issued. The agent must be able to identify a relevant capability through help, a skill document, or a catalog. It then needs to inspect the target's current state, because a command that is correct for an imagined project may be wrong for the actual one. The mutation must be expressed through a command contract that provides structured output and explicit failure. The harness must apply that mutation to a project or session representation that preserves the target's meaningful relationships.

The path becomes consequential when it reaches the real software. A native renderer, scripting API, existing CLI, or another faithful backend must interpret the state and produce the result whose semantics matter. The harness then needs to return more than a reassuring exit status: it should identify the artifact, expose warnings or limitations, and support checks appropriate to the claim. A preview can provide an inexpensive intermediate checkpoint; a final export and domain-specific verification can support delivery.

State management sits across the whole path. A REPL can hold context while an agent explores. One-shot commands must persist changes if later processes depend on them. Undo and status make correction possible. Auto-save and locking keep state from vanishing or being corrupted between invocations. A skill and a package entry point make the capability reusable outside the source tree. CLI-Hub can discover and install it without taking over the target application's semantics.

The chain can be written as a compact test:

  1. Can the agent discover the capability and its prerequisites?
  2. Can it inspect the current state and express a bounded operation?
  3. Does the harness preserve the target's meaningful state and reach the real backend?
  4. Can it recover from failure and persist or reverse changes predictably?
  5. Can it verify the relevant intermediate or final artifact?
  6. Can another process or agent find, install, and learn the same tool?

These are not six independent product features. They are conditions in a causal path. Discovery without a working entry point is unusable. A working entry point without a semantic backend is misleading. A backend without verification leaves the agent unable to distinguish truth from an attractive accident. Verification without persistence cannot support an iterative workflow. The value of CLI-Anything lies in how the pieces reinforce one another.

flowchart LR A["Target task"] --> B{"Source and semantic seam available?"} B -- "no" --> R["Reject, narrow claim, or find another path"] B -- "yes" --> C["Choose native or intermediate state"] C --> D{"Real backend available and runnable?"} D -- "no" --> R D -- "yes" --> E["Build command, state, and JSON contract"] E --> F["Run layered tests and artifact checks"] F --> G{"Evidence supports the intended workflow?"} G -- "no" --> H["Refine boundary or narrow claim"] H --> E G -- "yes" --> I["Publish skill, package, and Hub metadata"] I --> J["Use previews or final artifacts for feedback"] J --> K["Adopt for the supported workflow"]

The diagram is a decision path rather than a maturity ladder. A failed condition does not always mean that the entire idea must be abandoned. It may mean that the harness should make a narrower claim, add a missing dependency, or return to analysis and refinement. What matters is that the failure changes the decision instead of being hidden behind a generic success message.

What each layer can and cannot prove

The command contract proves that an agent has a structured way to ask for an operation and receive a response. It does not prove that the operation has the right semantics. JSON makes a result parseable; it does not make the result true. Help and skills make a capability legible; they do not guarantee that the agent will select it correctly or that the target backend is installed.

The source-to-harness lifecycle proves that CLI-Anything has a method for moving from source inspection to architecture design, implementation, testing, documentation, packaging, and refinement. It does not guarantee complete coverage on the first run.