CLI FEATURE
Runtime Maintenance
Strong CLI does not stop at code generation. It also gives operators and developers a disciplined way to refresh, validate, and diagnose a live Semitexa runtime.
Feature Guide
A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.
What this does
The framework exposes maintenance commands for code pickup, cache hygiene, generated metadata, linting, and DI probing.
How it works
server:reload rebuilds autoload and sends a graceful Swoole reload signal, cache:clear removes compiled cache artifacts, registry:sync refreshes generated registry data, and lint/test commands validate architecture and instantiation assumptions.
Why it matters
Without a disciplined maintenance surface, teams fall back to ad-hoc deletes, vague restarts, and guesswork. These commands make routine recovery and validation explicit.
Key concepts
- server:reload
- Gracefully reloads Swoole workers so code changes are picked up without a full container restart.
- cache:clear
- Clears compiled cache artifacts such as Twig output when runtime state becomes stale.
- test:handler
- Instantiates one handler and reports whether DI properties were wired successfully.
Maintenance Surface
Refresh, validate, and inspect the runtime without improvisation
These commands cover the maintenance loop that teams hit all the time: stale templates, generated registries, architecture drift, and suspicious DI wiring.
Graceful refresh. server:reload picks up code changes without a full container restart when the Swoole runtime is healthy.
Architectural checks. lint:* and test:handler turn framework invariants into explicit checks instead of “I hope boot catches it.”
State hygiene. cache:clear and registry:sync reduce the class of issues caused by stale compiled artifacts or outdated generated bindings.
| Command | Purpose | Why it matters |
|---|---|---|
bin/semitexa server:reload |
Gracefully reload Swoole workers after code changes. | Fast path for normal development when containers do not need a full restart. |
bin/semitexa cache:clear --twig |
Clear compiled Twig cache after template changes or stale render state. | Cuts straight to one of the most common SSR debugging needs. |
bin/semitexa registry:sync |
Regenerate DI-oriented registry artifacts such as contract resolvers. | Keeps generated framework metadata aligned with current code. |
bin/semitexa lint:handlers |
Validate handler signatures and payload/resource bindings. | Catches architecture drift before it shows up as a weird runtime failure. |
bin/semitexa test:handler Semitexa\\Demo\\Application\\Handler\\PayloadHandler\\Testing\\AiToolingHandler |
Probe handler instantiation and property injection directly. | Useful when DI uncertainty is more valuable to test than business behavior. |
Refresh changed templates safely
bin/semitexa cache:clear --twig
bin/semitexa server:reload
Check architecture after refactor
bin/semitexa registry:sync
bin/semitexa lint:handlers
bin/semitexa lint:di
Probe one suspicious handler
bin/semitexa test:handler 'Semitexa\\Demo\\Application\\Handler\\PayloadHandler\\Testing\\RuntimeMaintenanceHandler'
Verified against Semitexa Ultimate 2026.09.19.1020
Runtime Maintenance
Strong CLI does not stop at code generation. It also gives operators and developers a disciplined way to refresh, validate, and diagnose a live Semitexa runtime.
How it works
server:reload picks up code changes without a full container restart. cache:clear handles stale compiled Twig templates and other artifacts. registry:sync regenerates DI-oriented registry bindings. lint:* validates handler signatures and architectural invariants. test:handler probes instantiation and DI wiring for a specific handler class.
Why this matters
Without explicit maintenance commands, teams fall back to ad-hoc shell scripts, full restarts, or trial-and-error debugging. A coherent maintenance surface keeps the runtime operable and reduces the cost of investigating unexpected behavior during development and production operations.
How it works
server:reload rebuilds autoload and sends a graceful Swoole reload signal, cache:clear removes compiled cache artifacts, registry:sync refreshes generated registry data, and lint/test commands validate architecture and instantiation assumptions.
Why it matters
Without a disciplined maintenance surface, teams fall back to ad-hoc deletes, vague restarts, and guesswork. These commands make routine recovery and validation explicit.
Key concepts
- server:reload
- Gracefully reloads Swoole workers so code changes are picked up without a full container restart.
- cache:clear
- Clears compiled cache artifacts such as Twig output when runtime state becomes stale.
- test:handler
- Instantiates one handler and reports whether DI properties were wired successfully.