cli

Overview ¶

apikey_cmd.go — wowapi apikey: issue, list, rotate, and revoke machine API keys / service principals (roadmap S1/CA-3). Tenant-scoped: connects as app_rt and binds the given tenant, so RLS applies exactly as at runtime. Issue and rotate print the plaintext token ONCE — it cannot be recovered later.

audit_cmd.go — wowapi audit: verify a tenant's tamper-evident audit chain offline (roadmap S6/CA-11). Connects as app_rt, binds the tenant, walks the hash chain, and reports any mutation (row hash mismatch) or deletion (seq gap).

Package cli implements the wowapi command dispatcher. cmd/wowapi is a thin main over Run so behavior is unit-testable. Private implementation detail.

config_cmd.go — wowapi config subcommands (framework-side, Phase 1).

Framework-repo fallback: all subcommands run against config.Framework alone. Product-repo configcheck integration (tools/configcheck) arrives in Phase 10.

Precedence used by the loader: compiled defaults ← base.yaml ← env overlay ← env vars ← secret resolution. See docs/blueprint/12-configuration-and-deployment.md §3.

config_delegate.go — product-local config delegation + `config diff`.

The installed wowapi binary cannot import product config types (it is prebuilt), so `wowapi config <mode>` delegates to the product-local checker scaffolded by `wowapi init` at tools/configcheck (blueprint 12 §8). When that checker is absent (e.g. inside the framework repo) the commands fall back to validating config.Framework alone.

deploy_cmd.go — `wowapi deploy render` (Phase 10). Renders a deployment manifest (docker-compose or a plain env file) for the api/worker/migrate processes from a small set of flags. The DB DSN is emitted as a secretref://env/… reference (config.DB.DSN is a Secret), never an inlined value — the manifest is safe to commit.

dlq_cmd.go — wowapi dlq: inspect and operate the dead-letter queues (R4).

gen_cmd.go — wowapi gen: code generation subcommands (crud, ...).

i18n_cmd.go — `wowapi i18n validate` (B1). Mirrors `wowapi seed validate` (seed_cmd.go): it loads a product's locale catalogs through the SAME kernel/i18n loader the app uses at boot, so an authoring defect — missing locale coverage, a duplicate key within a layer, an unauthorized kernel.* write, or a placeholder-arity mismatch between a translation and the framework default — is caught in CI (exit 1) instead of at deploy time.

It runs over the framework's embedded defaults PLUS the product's locales/ tree (loaded as a sanctioned framework-override fs layer, so a product-local kernel.* override is checked, not rejected), which is exactly the layer stack the generated binaries build from the product's i18n config. It needs no database and no product config.

init_cmd.go — wowapi init: scaffold a product repository.

lint_cmd.go — `wowapi lint boundaries` (Phase 10) and `wowapi lint lifecycle` (backlog B9). boundaries enforces the import law in a product repo the same way scripts/lint_boundaries.sh does for the framework: modules are isolated (a module never imports another module's internals — they collaborate through ports), and in the framework repo the kernel/module/app/adapters layering holds. lifecycle checks the static provider/lifecycle manifest (kernel/lifecycle) for wiring mistakes (scope leaks, raw pools, tenant-scope escapes, migrate-only leaks into runtime, missing providers/cycles). Both rule checkers are pure functions so they are unit tested without a live `go list` / real kernel boot.

migrate_cmd.go — `wowapi migrate` helpers (Phase 10). `create` scaffolds the next-numbered goose migration file; the actual apply lives in the product's cmd/migrate (generated by `wowapi init`) which calls database.Migrate.

new_module_cmd.go — wowapi new-module: scaffold a module package.

openapi_cmd.go — `wowapi openapi merge` (Phase 10). Merges per-module OpenAPI fragments (the JSON each module registers via ctx.OpenAPI) into one document, failing loudly on a duplicate path or schema so two modules cannot silently clobber each other's API surface.

scaffold.go — shared helpers for wowapi scaffold commands (init, new-module, gen).

seed_cmd.go — `wowapi seed validate`/`wowapi seed sync` (Phase 10, GAP-003; escape-hatch framing per B4). validate loads a module's seed bundle through the same kernel/seeds.Load the app uses at boot, so a seed error is caught in CI (exit 1) rather than at deploy time. sync loads one or more modules' seed bundles and applies them to a real database with kernel/seeds.Sync, on a platform-privileged connection — but it is a LOW-LEVEL STANDALONE ESCAPE HATCH, not the production lifecycle path: the generated cmd/migrate is (loads the composed product config via appcfg.Load(), runs migrations, then seeds.Sync, then rules.SyncDefinitions — see internal/cli/templates/init/cmd_migrate_main.go.tmpl and docs/user-guide/database-migrations.md). This command connects via a bare DATABASE_URL env var (no product config layering, no secretref:// resolution, hardcoded pool defaults) and never calls rules.SyncDefinitions: rule points exist only as Go declarations registered by a booted product process (mc.Rules().Register(...)), so a framework-only binary has no registry to read — there is nothing for this command to sync even in principle (see kernel/rules.SyncDefinitions's doc comment). Use it to re-sync seed catalogs without a full migrate run; it is not a substitute for the generated migrate on a fresh environment.