Download the PHP package coretsia/platform-cli without Composer

On this page you can find all versions of the php package coretsia/platform-cli. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of coretsia/platform-cli

Informations about the package platform-cli

coretsia/platform-cli

platform/cli is the Kernel-integrated, tag-first command runtime and canonical command-line interface for the Coretsia Framework.

It discovers commands from enabled package providers through the Foundation cli.command tag, dispatches normal commands within the Kernel UnitOfWork lifecycle, supports deterministic configuration-defined workflows through one platform-owned composite-command exception, exposes Kernel-owned operations through the contracts-level Ops port, and renders deterministic, safe output with mandatory shared redaction.

Scope: canonical CLI invocation, source operations-host bootstrap, tag-backed command catalog, descriptor-driven input validation, lazy command dispatch, built-in commands, configuration-defined sequential workflows, deterministic unknown-command suggestions, Kernel Ops transport, invocation-local output buffering, deterministic JSON/table/plain formatting, readable nested tables, terminal color policy, CLI execution observability, and safe failure reporting.

Out of scope: application module selection or dependency synchronization, Kernel configuration loading and compilation, Kernel artifact inspection, owner-package domain validation, owner-package command implementations, Kernel lifecycle hooks or reset orchestration, redaction engine implementation, observability exporters, and repository tooling.

This README is a consumer-oriented package summary.

Package identity

Monorepo versioning is repo-wide only via git tags vMAJOR.MINOR.PATCH.

Per-package independent versions MUST NOT be used.

Dependency policy

This package is a Kernel-integrated source-host CLI runtime.

platform.errors and platform.redaction are required by the platform.cli runtime module dependency closure and direct Composer requirements. CLI consumes canonical Throwable normalization through Coretsia\Contracts\Observability\Errors\ErrorHandlerInterface and redaction through Coretsia\Contracts\Security\SensitiveDataRedactorInterface; it does not import concrete Errors or Redaction implementations.

The coretsia/framework baseline directly installs Kernel and CLI; Errors and Redaction are installed transitively through CLI. Installing a Composer package does not enable its runtime module. Kernel resolves the enabled modules for each application target from the effective preset, overrides, and declared module dependencies. Additional mode-required physical packages are handled only by explicit Kernel DependencySync plan / review / apply operations; application boot performs no implicit dependency synchronization.

Runtime responsibilities

platform/cli provides:

Normal CLI execution reuses the Kernel-owned source operations host and its validated configuration, module/provider plan, context, UnitOfWork, and observability ports. CLI does not create a second configuration or module-resolution pipeline, and normal operations-host boot does not require generated runtime artifacts.

Canonical CLI invocation

coretsia is the single canonical public CLI executable name.

From the monorepo root:

From a Composer-installed Coretsia Skeleton project root:

The direct Composer binary invocation from the consumer project is:

On supported Unix environments, when the Composer binary is directly executable:

These supported invocations reach the same packaged CLI implementation at packages/platform/cli/bin/coretsia (installed as the coretsia/platform-cli Composer binary). The entrypoint layouts have distinct responsibilities:

The Skeleton wrapper emits CORETSIA_CLI_BOOTSTRAP_FAILED: autoload-unavailable followed by one LF to stderr and exits 1 if the installed Composer binary is missing or unreadable. No additional CLI package installation, executable alias, or CLI-specific setup is required after a successful baseline Composer installation.

Boot paths and Kernel operations

The exact coretsia doctor invocation is the only pre-host command path. It uses UltraEarlyDoctorRunner and the same DoctorCommand class advertised in the normal catalog. It performs bounded, allowlisted diagnostics without constructing the Kernel host, catalog, generated-artifact runtime, UnitOfWork, or shared Redaction service. The existing five boolean diagnostic values (cli_sapi, json_available, pcre_available, php_supported, and ready) are projected into fixed human-readable capability lines displaying OK or FAIL and a final READY or NOT READY status. Output uses the existing PlainFormatter and ConsoleOutputWriter, with ANSI disabled. Additional arguments and options are rejected through the existing fixed error boundary.

Every invocation other than the exact ultra-early doctor path uses the normal Console source host. Normal commands enter one Kernel CLI UnitOfWork; the sole built-in composite workflow:run command executes without an outer UnitOfWork and delegates every normal workflow step to its own UnitOfWork. The shared bootstrap and dispatch flow is:

The normal source host MUST resolve ModulePlan for AppTarget::Console and require platform.cli to be enabled. An absent or explicitly excluded CLI module fails closed with a fixed safe bootstrap diagnostic. Selecting platform.cli brings core.kernel, platform.errors, and platform.redaction into the enabled module dependency closure; a missing or excluded required Errors module fails closed during module composition. A Composer-installed but unselected module does not contribute its runtime services.

Built-in Kernel operation commands include:

<target> must be explicitly supplied as web, api, console, or worker. The CLI never infers the operation target from the current directory, Console host, or command name. Built-in Kernel operation descriptors accept --target only; --mode and --preset are not accepted as Kernel operation overrides.

KernelOpsRequestResolver builds KernelOpsRequest with only the selected appTarget. The Kernel resolves the effective preset through its normal Bootstrap policy: target-specific presets[appTarget], then global preset, then kernel.boot.default_preset (micro by default). CLI renders the effective preset returned by the safe OpsResult; it does not select or override that preset itself.

The Kernel owns module resolution, compilation, hashes, generation publication, and cache verification. Built-in CLI commands consume only Coretsia\Contracts\Kernel\Ops\KernelOpsInterface and its safe result contract; they do not read current, generation manifests, compiled config, container artifacts, or other Kernel artifact files directly.

Command discovery and catalog

cli.command is the sole normal container-backed command discovery tag. Foundation ReservedTags::CLI_COMMAND supplies the tag identifier; platform/cli owns its command metadata and dispatch semantics.

Each tagged service id MUST equal the exact command-class FQCN. The class must be concrete and declare the following typed public constants. Every normal or externally contributed command MUST implement Coretsia\Contracts\Cli\Command\CommandInterface. The sole exception is the built-in Coretsia\Platform\Cli\Command\WorkflowRunCommand, which implements the internal Coretsia\Platform\Cli\Runner\CompositeCommandInterface instead. External command-owner packages cannot use this exception:

The internal execution kind (normal|composite) is derived from validated service identity and is not a seventh metadata field. The built-in composite command uses the same six-key metadata schema and validation policy as normal tagged commands.

The tag metadata must have exactly these six keys, with values derived from the corresponding class constants:

Argument descriptors use exactly name, summary, required, and variadic; option descriptors use exactly name, summary, value, and repeatable. Option value is none, required, or optional. Invalid or unknown metadata keys, including top-level priority or mode, are rejected. The actual TaggedService::priority() must be 0; any non-zero priority fails before metadata validation.

CommandTagSchema validates exact identity, class constants, schema and constant-to-metadata equality by class reflection without resolving or instantiating command services. CommandCatalog retains the deterministic output of TagRegistry::all(ReservedTags::CLI_COMMAND): priority descending, then service id in strcmp order; CLI neither re-sorts nor re-deduplicates it. TagRegistry keeps the first registration of each (tag, serviceId). Distinct service ids claiming the same command name fail deterministically.

The names doctor, help, and list are reserved for their exact built-in service identities. list and help render catalog descriptors without resolving every command service. The selected service is resolved only during dispatch; its runtime type, exact class identity, and name() must agree with its descriptor.

Unknown syntactically valid command names may receive deterministic suggestions generated by SmartSuggestor from the final visible CommandCatalog after validated presentation overrides. Hidden commands are excluded. Suggestions use bounded lowercase ASCII Levenshtein comparison, are ordered by distance and final catalog order for ties, and contain at most three visible command names. The accepted maximum distance is 2 for unknown tokens of 1..8 bytes and 3 for 9..128 bytes. Invalid or out-of-bounds tokens produce no suggestions. Suggestions do not resolve command services or search workflows, filesystem paths, options, or service ids. The original unknown-command error code and reason remain unchanged, and any suggestion record uses the existing final formatter and redactor.

Providing commands from another package

Any enabled package may register its own command through cli.command. The owner package registers both the command service (under its exact class FQCN) and the tag in its own provider. The service may receive constructor-injected domain dependencies from its owner package; the CLI catalog does not construct command services.

For example, an owner package declaring InspectCommand registers its service through the canonical Foundation container definitions and tags the same FQCN with the class-owned metadata:

The example belongs in the command owner's declarative definition provider, with the relevant Foundation imports and its domain service binding in place. This is a registration illustration, not an additional CLI registry.

Owner-package command contracts are:

CommandInterface::run(InputInterface $input, OutputInterface $output): int returns an exit code in 0..255. The owner package defines positional arguments, options, command dependencies, and domain-specific validation; CLI performs structural validation against the selected descriptor before service resolution. Options support bare flags and valued options (--name=value), and repeatable required-value options preserve input order. CLI-global --format and --color are not owner-command options. Owner-domain options such as --mode may be declared by the owner but do not alter Kernel Bootstrap preset selection.

No changes to platform/cli or imports of the owner package are necessary for generic command discovery. A command package is visible only when Kernel's resolved module/provider graph enables its contributing provider.

Configuration

The config root is cli. The canonical defaults file is config/cli.php, which returns the cli subtree only, without a repeated root key:

Kernel's canonical config pipeline loads, merges, and validates the global cli.* subtree. config/rules.php defines the strict schema: unknown structural keys are rejected. Dynamic map keys are permitted only under cli.commands.overrides and cli.workflows.definitions. Command overrides are subsequently validated by CommandOverrides; workflow definitions are deeply validated by WorkflowSchema when the lazy WorkflowCatalog is resolved. CLI does not read application PHP config files or construct a separate config merge pipeline.

The configuration consumers are:

Valid cli.output.format_default values are adaptive|json|table|plain. The adaptive interactive and non-interactive settings accept json|table|plain. Valid cli.output.color_default values are auto|always|never.

The explicit CLI-global --format=<adaptive|json|table|plain> and --color=<auto|always|never> options take precedence over their respective configured defaults. They are parsed only before the -- end-of-options marker and are removed from the command-facing input. Repeated or malformed global options fail deterministically. Tokens after -- remain positional arguments, even if they look like global options.

adaptive chooses cli.output.adaptive.interactive when stdout is interactive, otherwise cli.output.adaptive.non_interactive. The packaged default is table for both interactive and non-interactive output. Machine consumers must explicitly request --format=json. TerminalCapabilitiesDetector detects terminal capabilities once at the normal entrypoint boundary to support adaptive policy selection and ANSI safety; terminal detection does not select a separate formatter implementation or introduce another output pipeline.

There are no configurable switches for redaction, UnitOfWork, reset, observability, executable aliases, color palettes, or arbitrary ANSI codes. CLI configuration does not select the application target or effective Kernel preset.

Configured workflows

Workflows are declared exclusively under the validated cli.workflows.definitions configuration subtree. The packaged default is an empty definitions map. Workflow definitions are not discovered from the current working directory, filesystem paths, globs, templates, environment variables, or command-owner packages.

A consumer application may provide the following workflows subtree within its merged cli configuration:

Every workflow definition has exactly summary and steps. Every step has exactly command, arguments, and options. Arguments are ordered string lists; command-owned options use validated strings, bare true flags, or ordered lists of repeated string values. Different steps may specify different explicit application targets. The shared CommandInputValidator remains responsible for descriptor-dependent argument, option, and repeatability validation.

The built-in workflow commands are:

workflow:list displays configured workflow names and summaries. workflow:run requires exactly one positional workflow name and declares no command-owned options. In particular, it does not accept --mode, --preset, or a top-level inherited --target. Kernel operation steps carry their own explicit target in their validated definitions. Global --format and --color retain their existing CLI-global semantics.

WorkflowCatalog validates all configured workflow definitions and referenced command identities before executing the first step. The catalog is resolved lazily only for workflow commands; deep-invalid but structurally Kernel-loadable definitions do not block unrelated normal command discovery or dispatch.

WorkflowRunner executes the declared normal command steps sequentially through the existing CommandRunner. Each dispatched step receives exactly one independent Kernel CLI UnitOfWork, its own normalized input, and a fresh child output buffer. There is no outer workflow UnitOfWork, and nested workflows or composite steps are forbidden.

Execution is fail-fast. The first non-zero step exit code stops subsequent execution and is returned with the completed failing step and its records. A thrown exception or step-input validation failure produces no completed workflow result and no partial child output. Workflow execution is not transactional: side effects from previously completed steps are not rolled back.

Completed workflow results are aggregated into one top-level JSON-like record, pass through the existing parent output limits, and receive one mandatory shared redaction and formatting pass. Child records are neither separately rendered nor persisted. CLI workflow replay, recording, playback, output transcript storage, and retention capabilities are not provided.

Output and determinism

Commands report output exclusively through Coretsia\Contracts\Cli\Output\OutputInterface. CommandOutputBuffer stores ordered text, json, and error records locally for one invocation; it never writes directly to stdout or stderr and is not a shared container service.

The pipeline is:

The output contract enforces:

Formatters receive normalized, redacted records rather than raw command payloads. The JSON envelope itself is constructed from safe, fixed CLI-owned fields after record redaction. A formatting or redaction failure discards unsafe output and produces a single fixed safe fallback; it never retries rendering through a less restrictive pipeline.

The generic TableFormatter presents nested JSON-like maps and lists as readable structured sections, including indexed lists and ordered workflow child records. Nested collections are not embedded as serialized JSON inside table cells. The formatter preserves canonical map ordering, original list ordering, and the existing deterministic width and ANSI rules. No Kernel Ops-specific or workflow-specific table renderer is introduced.

Explicit --format=json preserves the existing coretsia.cli-output@1 envelope and canonical JSON encoding. Improved human-readable presentation does not alter the machine-readable output schema. For completed workflows, child JSON records expose their normalized content under data instead of the internal structural payload key, allowing the existing shared redactor to inspect sensitive nested values without redacting an entire child record solely because of its envelope key.

Colors

Color policy accepts exactly auto, always, or never, through cli.output.color_default and the CLI-global --color override.

TerminalCapabilitiesDetector is the only CLI component probing stdout/stderr interactivity and ANSI support. ANSI decoration uses the fixed internal semantic palette:

Only formatter-owned semantic roles can generate escape sequences. Command output and configuration cannot inject raw ANSI codes or define custom escape sequences or palettes. Ineligible formats and disabled color emit no ANSI sequences.

Context and UnitOfWork

CommandRunner executes every selected normal command inside exactly one KernelRuntimeInterface::runUnitOfWork(UnitOfWorkType::CLI, ...). The normal command service is resolved and invoked inside that callback, not while constructing the catalog. list, help, workflow:list, and built-in Kernel operation commands follow this normal lifecycle.

The exact coretsia doctor invocation is the only pre-host command path and does not enter a Kernel CLI UnitOfWork. The built-in workflow:run command is the only source-host composite command allowed to execute without an outer Kernel CLI UnitOfWork. Every successfully dispatched workflow step executes as a normal command through CommandRunner and receives exactly one independent Kernel CLI UnitOfWork. Kernel remains responsible for context, hooks, after-UoW processing, reset, and nested-UoW rejection; workflow infrastructure introduces no additional lifecycle coordinator.

CLI supplies only these safe UnitOfWork attributes:

KernelRuntime owns UnitOfWork context writes (ContextKeys::CORRELATION_ID, ContextKeys::UOW_ID, ContextKeys::UOW_TYPE), hook execution, reset orchestration, and failure precedence. CLI does not write ContextStore, invent correlation/UoW ids, enumerate kernel.reset, invoke reset services, or store a CLI-specific output format in context.

For optional log correlation, CommandRunner reads only CORRELATION_ID and UOW_ID through ContextAccessorInterface::has() / get(), inside the UnitOfWork callback before Kernel cleanup. Missing or invalid safe identifiers are omitted without affecting execution. Invocation-local output buffers and immutable catalog/output-policy services introduce no shared mutable state requiring CLI-owned resets; any future shared mutable service must follow the canonical ResetInterface discipline.

Observability

CommandRunner owns CLI command-execution telemetry, separate from Kernel-owned kernel.uow and kernel.operation observability. No CLI formatter, writer, or built-in Kernel operation command duplicates Kernel operation telemetry.

The canonical command span name is:

Its initial attributes are operation and format. The final attributes are operation, format, outcome, and exit_code.

The canonical CLI command metrics are:

Both metrics allow only operation and outcome labels. Command duration is observed in integer milliseconds.

The safe completion log message is:

Completion logs include operation, outcome, and exit_code. Normal command logs may also contain previously captured and validated safe correlation_id and uow_id values obtained inside their own Kernel CLI UnitOfWork. Top-level composite workflow:run logs and spans do not inherit or emit context-derived correlation or UnitOfWork identifiers.

operation is the canonical descriptor command name, format is the effective json|table|plain presentation format, and outcome is success for exit code 0 or failure for a non-zero return or thrown command failure. Kernel CLI UnitOfWork attributes use output_format, which is distinct from the command span's format attribute. Span exit_code is not a metric label. Metric labels MUST NOT include output format, exit code, target, preset, correlation/UoW identifiers, or unbounded values.

For normal commands, the command span begins before the Kernel UnitOfWork call and ends after its lifecycle completes. For the built-in workflow:run composite, CommandRunner emits one top-level cli.command observation spanning composite execution without an outer Kernel UnitOfWork. Each executed workflow step emits its own normal cli.command observation covering its independent UnitOfWork lifecycle. Unexecuted steps emit no lifecycle observations.

WorkflowRunner and WorkflowRunCommand do not emit duplicate command lifecycle telemetry. The existing span attributes remain operation|format initially and operation|format|outcome|exit_code finally, with format bounded to json|table|plain. The existing cli.command_total and cli.command_duration_ms metrics retain exactly operation|outcome labels. Workflow names, step arguments, and option values are excluded from telemetry labels and attributes.

Stopwatch measures elapsed time with a non-negative integer 0 fallback when unavailable. Trace start, attribute update, end, metric increment/observation, logger, stopwatch, and permitted context-read failures are independently best-effort: they never skip or repeat command execution, replace the primary failure, alter exit codes, or interfere with Kernel-owned hooks and reset. The ultra-early doctor path emits no normal command telemetry.

Raw argv, option or argument values, command output, paths, endpoints, config/env values, payloads, secrets, and exception traces are forbidden in CLI telemetry.

Errors

CLI reports stable, path-safe error codes and bounded reason tokens rather than raw Throwable messages, stack traces, command-line contents, configuration values, or filesystem diagnostics. CliApplication uses the injected canonical ErrorHandlerInterface to normalize normal-path Throwables into safe ErrorDescriptor values. The CLI-owned CliExceptionMapper contributes allowlisted CLI and Kernel Ops exception classification as a shared service under ReservedTags::ERROR_MAPPER (error.mapper), with priority 100 and empty metadata []. The canonical registry preserves Foundation TagRegistry ordering, lazily resolves mapper services, and selects the first non-null descriptor; the CLI does not re-sort candidates or select the final fallback.

CliExceptionMapper returns null for unsupported Throwables. When no mapper selects a descriptor, platform/errors returns the fixed CORETSIA_UNHANDLED_EXCEPTION descriptor, and CLI-owned ExceptionRenderer presents it as CORETSIA_CLI_INTERNAL_ERROR with message Internal CLI error. This translation is transport rendering, not another Throwable mapping pass. The normal command failure boundary discards partial output before emitting a deterministic error record and preserves the existing exit-code contract.

The main CLI error code families are:

The packaged CLI and Skeleton wrapper use the fixed pre-autoload/bootstrap fallback CORETSIA_CLI_BOOTSTRAP_FAILED: autoload-unavailable when their required Composer autoload/binary path is not available. Console source-host failure emits CORETSIA_CLI_HOST_BOOT_FAILED: host-boot-failed. A final rendering failure emits CORETSIA_CLI_RENDER_FAILURE: render-failure. These diagnostics do not disclose Throwable details or paths.

Command exit codes are integers in 0..255. The built-in Kernel operation mapping is:

The cache:verify statuses come only from safe Kernel OpsResult data, never direct artifact inspection. Non-built-in owner commands select their own valid 0..255 exit codes; CLI preserves those returns without reinterpreting their domain semantics. An out-of-range return fails closed.

Security / Redaction

Redaction is mandatory for every normal CLI output batch and cannot be disabled through configuration or command options. OutputFormatter consumes Coretsia\Contracts\Security\SensitiveDataRedactorInterface supplied by the selected platform.redaction module provider and applies RedactionContext('cli.output', RedactionMode::Placeholder) to text, JSON-like payloads, and safe error messages before rendering.

Redaction is defense in depth, not permission to pass secrets or raw sensitive data through a public result. Kernel OpsResult remains safe by construction; Kernel owns the classification and disclosure boundaries for configuration, manifests, artifacts, paths, and environment data. CLI must never attempt to sanitize raw Kernel artifacts or secret-bearing configuration by formatting them.

Command output normalization rejects unsafe control characters, raw ANSI input, malformed JSON-like data, unsafe map keys, and oversized record batches before final publication. CLI diagnostics, telemetry, and built-in operations must not expose credentials, personal data, request/response bodies, raw command argv, absolute paths, environment values, previous exceptions, or stack traces. Redaction or formatting failures fail closed with a fixed safe diagnostic and no unsafe fallback output.

The ultra-early doctor uses a fixed allowlist of booleans and fixed diagnostic records, requires no shared redactor, and must not output raw environment values, paths, or runtime internals.

Non-goals

This package does not provide:

References

All versions of platform-cli with dependencies

PHP Build Version
Package Version
Requires php Version ^8.4
coretsia/core-contracts Version ^0.10.0
coretsia/core-foundation Version ^0.10.0
coretsia/core-kernel Version ^0.10.0
coretsia/platform-errors Version ^0.10.0
coretsia/platform-redaction Version ^0.10.0
psr/container Version ^2.0
psr/log Version ^3.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package coretsia/platform-cli contains the following files

Loading the files please wait ...