Textus Samples 01: Minimal Execution

Created: 2026-06-29 Updated: 2026-07-06

Textus Samples is a collection of small samples for learning Textus component development step by step.

This article examines the first development step for a minimal Operation: naming Component / Service / Operation and making it invokable through a selector.

01-minimal is the smallest sample with one Component, one Service, and one Operation.

Prerequisite

This article uses the environment prepared in 📄 Textus Samples: Launchers and Installation.

textus-tutorial-0.1.3 has been extracted
The cozy , cncf , and textus launchers have been installed
The runtime version for each launcher has been checked

The download steps are covered in the prerequisite article, so they are not repeated here.

What You Learn

The basic CNCF engine selector shape
The boundary between Component, Service, and Operation
The difference between development classpath and runtime builtin surfaces

Purpose / Why This Sample Matters

This sample checks the smallest Textus component development unit from both its names and execution path. Component / Service / Operation are invoked through the selector minimal.main.hello .

run.sh is a helper script, while the actual invocation is cncf dev command --project-dev . minimal.main.hello . This reads the current sample directory as the development project.

Concept Focus

A Component is the unit registered with the runtime, a Service groups operations, and an Operation is the behavior being executed.
In the ordinary edit/run loop, explicitly load the sample directory as the development project with --project-dev . .

Sample Directory

samples/01-minimal
samples/01.a-invocation-source-lab
samples/01.b-startup-shapes-lab
samples/01.c-builtin-and-help-lab

Program

The minimal component in 01-minimal is defined in component.d/minimal.md .

# minimal
## Service
- `main`
## Operation
- `hello`
## Behavior
- prints `Hello CNCF`

In this definition, the component name is minimal , the service name is main , and the operation name is hello . Therefore, the selector used from the CLI is minimal.main.hello .

The run.sh file is a small wrapper that passes this selector to cncf dev command .

#!/usr/bin/env bash
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
cd "$SCRIPT_DIR"
exec cncf dev command --project-dev . minimal.main.hello "$@"

The program body here is the hello operation that outputs Hello CNCF . run.sh is the entry point that starts that operation in command mode.

Run

First, run the Operation by specifying the selector directly.

$ cd samples/01-minimal
$ cncf dev command --project-dev . minimal.main.hello

--project-dev . reads the current directory as the development project. minimal.main.hello selects the hello operation in the main service of the minimal component.

bash run.sh is a helper script that runs the same check.

$ bash run.sh

Command Walkthrough

cncf dev command starts a component from the development project once as a command. The argument minimal.main.hello follows <component>.<service>.<operation> and selects the operation to invoke inside the started component.

When comparing run.sh and packaged invocation, focus on where the component is loaded from rather than on the output. The former uses the development classpath; the latter uses a jar placed in a component directory.

Expected Result

message: Hello CNCF

The companion labs inspect the same minimal.main.hello through development source, startup shape, and builtin/help surfaces.

Reading the Output

message: Hello CNCF confirms that the selector was resolved in the runtime and that the Operation was executed.

At this stage, persistence, server, client, and job behavior are not covered. Later articles examine the same selector model in other execution forms.

Common Pitfalls

If you see selector not found , check the CLI selector shape minimal.main.hello rather than the Scala class capitalization.
Run ordinary development checks from the sample directory with --project-dev . . This uses a different loading source from packaged component verification.

CNCF Engine Meaning

A CNCF engine selector is component.service.operation .

Later CRUD, CQRS, Job, and Subsystem samples also use this selector and execution-unit structure as their basis.

In the next article 📄 Textus Samples 02:Component Packaging, we examine formal packaged components and the CAR loading path.

References

In Site

Glossary

Component: A software construct that encapsulates well-defined responsibilities, contracts, and dependencies as a reusable and replaceable unit. In the logical model, it serves as an abstract structural unit; in the physical model, it corresponds to an implementation or deployment unit.
Cloud Native Component Framework (CNCF): Cloud Native Component Framework (CNCF) is a framework for executing cloud application components using a single, consistent execution model. Centered on the structure of Component, Service, and Operation, it enables the same Operation to be reused across different execution forms such as command, server (REST / OpenAPI), client, and script. By centralizing quality attributes required for cloud applications—such as logging, error handling, configuration, and deployment—within the framework, components can focus on implementing domain logic. CNCF is designed as an execution foundation for literate model-driven development and AI-assisted development, separating what is executed from how it is invoked.
verification: Verification is the activity of confirming that an implementation conforms to its specified design or requirements.