#Console and Composer Command Catalog

This document inventories the complete Symfony Console surface shipped by k0smos and identifies direct or related Composer scripts.

The command surface is tenant-scoped. Module commands are registered only when their module is active. This catalog includes core and module command declarations, including the committed-content recovery command added on 2026-09-13. Module availability depends on the resolved tenant; the live source of truth is always:

TENANT_ENV=k0smos.example.com php bin/console list

Use -- to forward command options through Composer. For example:

TENANT_ENV=k0smos.example.com composer app:favicons:clean-rebuild -- --dry-run

In the tables below, Direct means the Composer script invokes that exact console command. Related workflow means the Composer script changes scope or combines the command with additional operations. A dash means there is no Composer counterpart.

#Symfony built-in commands

#Core application commands

#Module commands

Fresh non-SQLite migration uses a complete portable SQLite snapshot before recording versions and backfilling configuration. The owned MySQL 8.4.11 full installation and unchanged rerun now pass after Esapi/Ai/AppSettings identity and Bookmark/Invoice/Kit lookup-index repairs. Their Version20261015120000 migrations preserve complete values and use the same discovered projection as fresh bootstrap. Base Version20261015110000 upgrades canonical existing MySQL settings tables only with all writers quiesced and a reviewed backup; custom schema/artifacts require explicit reviewed recovery. Esapi Version20261015130000 requires quiesced sync writers/workers and backup. Version recording now initializes metadata, and migrate/generate share platform- bounded table naming while retaining valid legacy names. Existing truncated PostgreSQL metadata requires reviewed recovery, never a new empty history. These fresh checks do not qualify full backend upgrades or commerce lifecycle. See the migration section of the complete reference before scheduling this rollout.

Site Publish contributes site:import (read-only preview by default; exact --confirm-checksum authorizes insert-only import), site:publish (full snapshot and queued build, optional --retry=GENERATION), site:build --generation=GENERATION, site:status (optional --reconcile) and site:rollback --generation=GENERATION. Mutations require --actor=USER_ID and recheck that active user's permissions. All support --host as a tenant host or ID, and appear only when the module is active. There are no root Composer aliases. The offline site's own Bun tooling owns schema initialization, standalone build, serve, handoff and rollback; see Site Publish.

These commands appear only when their owning runtime module is active.

Discovery contributes two commands only while its module is active:

discovery:work --advance --steps=100 --seconds=45 is the periodic recovery path for due work not covered by a live queue wakeup. Projection commands require --corpus; mutations require an explicit --actor, and generation actions take --generation. Structured configuration/report/epoch input comes from a local JSON --input-file bounded to 16 KiB. Runtime activation and publication remain explicit operations. See modules/Discovery/src/README.Discovery.md.

#Composer workflows without a one-to-one console command

QA and test helpers (composer test, composer qa:*, and composer seed) are development workflows rather than wrappers around application console commands. Run composer run --list for the live Composer script inventory.

#Maintaining this catalog

After adding, removing, or renaming a console command or an app:* Composer script:

1. run TENANT_ENV=localhost php bin/console list --raw;
2. run composer run --list;
3. update this catalog and the owning module documentation;
4. verify any direct wrapper with its non-mutating option when one exists.