Artisan Commands

Every command in the stack lives under the ui5: namespace. Core ships the generators — the commands that write files — and the SDK ships the operators: the ones that move metadata into the database, compile help, cache the registry, and answer questions about a running installation.

php artisan list ui5 shows what your installation actually has; php artisan help ui5:sync shows a command's own text, which is kept current in the code.

The SDK's commands

Command	What it does
ui5:intake	Creates the platform-owner organisation — the system actor. Runs before the first ui5:sync.
ui5:sync	Persists the registry into the database: artifacts, slots, settings, abilities, roles, Customizing catalogs — then a conformance pass. Idempotent.
ui5:cache	Compiles the registry into a fast runtime cache file.
ui5:nav	Compiles the navigation tree into a cache file.
ui5:help	The help compiler: validate, build HTML, build the search index.
ui5:doc	Scaffolds a new help document with a fresh UUID.
ui5:publish	Copies the SDK's shipped assets into public/sdk.
ui5:i18n	Expands the i18n keys of synced Customizing catalogs into a properties bundle.
ui5:explain	Explains ability resolution for one partner in one app, with sources.
ui5:concept	Inspects the LUX Weave Concept graph.
ui5:describe	Publishes the marketplace descriptor into composer.json.
ui5:slot	Inspects the slot catalog. Overrides Core's ui5:slot, adding the actor overrides.

The ones with options worth knowing

ui5:sync {--dry} — the pipeline that turns declarations into rows. Seven workers run in a fixed order (artifacts, slots, settings, abilities, roles, Customizing, then a value-help scope conformance check), --dry reports every insert, update and delete without writing, and the workers are idempotent, so running it twice changes nothing the second time. See the sync pipeline.

ui5:help — five flags, and the important one is the combination:

--validate   check every declared help document (the default when no flag is given)
--build      compile the HTML into the storage cache
--index      build the Lunr full-text index
--all        all four in one run — including the deprecated --cache
--cache      deprecated; writes a manifest nothing reads, removed in 2.0

A bare ui5:help only validates — it produces no output files. Deployments run ui5:help --all. The build pipeline page carries the full diagnostics table, including what passes in silence.

ui5:explain --app= --partner= --at= — the debugging tool for "why can this person not press that button". It resolves the actor's abilities the way the runtime does and shows where each grant came from: which role or group, which assignment row, and its validity window. --at accepts a datetime, so you can ask the question as of last Tuesday. See the Explain CLI.

ui5:doc {module} {title} {--locale=en} — writes ui5/{module}/doc/{uuid}/{locale}.md with a fresh UUID and frontmatter. The UUID is the identity; never change it after publishing. See authoring help.

ui5:intake — eleven options describing one organisation (--name, --email, --vat, --office, --founded, …). --email is the idempotency key, so re-running with the same address updates rather than duplicates; --force skips the confirmation. Full walkthrough on the system actor page.

ui5:describe {--check} {--package=} — reads the marketplace attributes off your module and writes them into composer.json's extra.laravelui5. --check verifies without writing and exits non-zero on drift, which is what you put in CI.

ui5:publish {--force} — a dumb copy of the package's resources/assets into public/sdk. It prompts unless --force, which is what a deploy script passes. It publishes assets, not stubs — see stubs and scaffolding.

ui5:slot {name?} — with no argument, the whole slot catalog; with a name, that slot's resolution chain plus the per-partner actor overrides Core cannot know about. See actor slot values.

Core's commands, which you also have

These ship with laravelui5/core and generate files. They behave identically with or without the SDK installed — with one exception, noted below.

Command	Generates
ui5:app	A Ui5App module from a UI5 frontend project
ui5:lib	A Ui5Library module from a UI5 library project
ui5:action	An action class and its handler
ui5:card	A card, its provider and its manifest template
ui5:tile	A tile
ui5:chart	A chart
ui5:report	A report
ui5:dashboard	A dashboard
ui5:group	A dashboard group
ui5:resource	A resource
ui5:wire	A view + controller floorplan for a model
ui5:assemble	A self-contained app from a blueprint
ui5:slot	(replaced by the SDK's version)

The one exception is ui5:action. With the SDK installed it generates a typed handler that implements SdkActionHandlerInterface instead of Core's array-returning shape. Nothing else changes — the SDK swaps one scaffolder and hands every other artifact type back to Core's default.

Always scaffold, never hand-write

Artifact classes carry constants, attributes and a manifest wiring that the generators get right and hand-authoring gets subtly wrong. ui5:app --refresh in particular overwrites the generated resources, so a manifest you edited by hand is lost on the next refresh. Edit the source project, then regenerate.

The order that matters

Two sequences are worth memorising, because getting them wrong produces confusing rather than loud failures.

First install:

php artisan migrate
php artisan ui5:intake --name="…" --email="…"   # the system actor must exist first
php artisan ui5:sync                            # stamps it as set_by on seeded rows
php artisan ui5:help --all

Every deploy:

php artisan migrate --force
php artisan ui5:sync
php artisan ui5:cache        # after sync — it bakes the ability ids sync just assigned
php artisan ui5:nav
php artisan ui5:help --all
php artisan ui5:publish --force

Sync before the caches, always: the caches compile what sync has just written. Caching and performance explains what each cache holds — including the one standing caveat about which registry to keep bound in production.