Command reference

Everything in the first table works with no instance, no account and no network. That split is worth seeing at a glance, so the CLI’s own help prints it the same way. Every command accepts --json.

Offline

Command	What it does
`cordango new <first-app>`	Create a workspace and its first app. Needs an empty directory.
`cordango add app <name>`	Add another app to this workspace. One workspace holds many.
`cordango configure [--target <id>]`	Decide once where this workspace’s apps run, and write it into `cordango.yaml`. `--show` prints what is set.
`cordango import <app.definition.json> [--app <name>]`	Bring an App Definition on disk in as source files you can edit.
`cordango check [--app <key>] [--target <id>]`	Parse, lower and validate. No model, no database. With `--target`, also ask whether that generator can build it.
`cordango validate [--app <key>] [--target <id>]`	The same command, spelled the other way.
`cordango targets`	What this build can generate, and what each target deliberately won’t.
`cordango build [--app <key>]`	Do what `configure` said. Deterministic.
`cordango build --target <id> [--app <key>]`	Generate with a target this once, whatever the configuration says.
`cordango inspect [path] [--app <key>]`	Describe the workspace, one app, or one aggregate.
`cordango discover [<query>] [--entities\|--events\|--actions\|--rules] [--limit <n>]`	What already exists: every app’s entities, the events it announces, the actions it offers. Run it BEFORE modelling. A login adds the rest of the instance’s apps.
`cordango vocabulary [<name>]`	What may be written: Cord’s words, or one construct’s schema.
`cordango example [<block kind>]`	What a correct one looks like: a worked block taken from a shipped app that passes the gate. With no kind, lists the kinds it has.
`cordango apply <ops.json> --app <key> --scope <kind[:key]>`	Apply semantic operations and rewrite the affected source files.
`cordango fmt [--app <key>]`	Rewrite every `.cordango.yaml` file in canonical form.
`cordango custom [--app <key>]`	Set up this app’s own code, and refresh the record types an editor resolves.
`cordango doctor`	Check the workspace for problems that aren’t source errors.
`cordango version`	CLI, source-format and App Definition schema versions.

Platform features need a Cordango workspace. Sign up here and create one in a few minutes.

Connected to an instance

Command	What it does
`cordango login <token> [--instance <url>]`	Connect to a Cordango instance. Make a token under your avatar, Personal Access Keys.
`cordango whoami [--offline]`	Which instance this workspace publishes to, and as whom.
`cordango publish [--app <key>] [--force]`	Build from source, send it to the instance, and make it live.
`cordango import [<app>] [--list]`	The way back: bring one of the instance’s apps in as source. With no name it asks which one.
`cordango logout [--instance <url>] [--all]`	Forget a stored credential on this machine. Does not revoke it.

See Publishing for what those do in practice.

import

Two routes into the same place — a definition becomes semantic source under apps/, split one file per aggregate, and it is registered in cordango.yaml.

cordango import expenses.json     # a file. No connection, no account, no network.

cordango import                   # connected: lists the apps you can reach, and asks
cordango import support           # or name one, when you already know
cordango import --list            # just look

The remote route is what makes publishing a round trip: an app built in Studio, or published from somebody else’s checkout, comes back as files you can read, diff and edit.

name

The directory under apps/ to import into. Defaults to the app’s handle, or its key for a file. Use it to import a second copy alongside one you already have.

Importing never merges. An app whose directory already exists is refused rather than half-overwritten — it would have to guess which of two versions of an aggregate you meant. A file path that exists always wins over an app of the same name, so ./support is never ambiguous.

configure

Where a workspace’s apps are meant to run is one decision, and it belongs in the repository rather than in everybody’s shell history.

cordango configure                        # asks, when somebody is there to ask
cordango configure --target standalone    # the same answer, as a flag
cordango configure --show                 # what is set, if anything

It writes a build: block into cordango.yaml, which is committed. cordango build then needs no flags, for you or for anyone who clones it.

cordango.yaml

build:
  target: standalone
  runtime: package
  allowIncomplete: false
  seed: 42

Every flag build takes for one run, configure takes to settle for good. A platform workspace writes target alone — the other three describe generating source into a directory, which publishing does not do.

standalone | dotnet-vue | platform

standalone generates a repository of its own. platform publishes to a Cordango instance.

package | source

package restores Cordango.Standalone from NuGet. source checks it into the generated project instead. Defaults to package.

number

The demo dataset every build of this workspace gets.

flag

Settle for builds the generator can’t finish. Right while you’re still building, wrong for a release — so this one is worth leaving unset and passing per run.

A missing key inside a build: block that exists takes its default rather than failing, so a hand-written two-line block is a perfectly good one. Where the output goes is not one of the questions. A generated application lands in generated/<app>/ inside the workspace, one directory per app, and there is no --out. It is gitignored build output, reproducible from the source beside it — and still yours: move the directory when an application is ready to have a life of its own. The platform target needs a connection, and both configure and build refuse without one. That isn’t ceremony: on the platform an app can see the other apps in the workspace and the core apps, so there is nothing useful to decide about it offline. Run cordango login first. A workspace with no build: block is not misconfigured — nobody has been asked yet. cordango build asks when there is a terminal, and otherwise writes its definition artifacts and says what it did not do.

build

cordango build on its own writes deterministic build artifacts under .cordango/build/<key>/. Given the same source it writes the same bytes. When the workspace is configured for a target, it also generates each app into generated/<key>/. --target on the command line overrides the configuration for that one run:

cordango build --app support --target dotnet-vue

number

Generate a different demo dataset.

flag

Accept a build the generator can’t finish, and report what got left out. Without it, missing behaviour refuses the build.

flag

Check the Cordango.Standalone source into the generated project, as a runtime/ project beside api/, instead of restoring the package. Use it to work on the runtime itself, or to build against a version no feed has yet.

check

cordango check
cordango check --app support
cordango check --app support --target dotnet-vue

No model, no database, no network. This is the command for a pre-commit hook and for CI, and it works from a clone of the open source repository with nothing else installed. cordango validate is the same command. Use whichever word fits the sentence you’re writing.

​Offline

​Connected to an instance

​import

​configure

​build

​check

Offline

Connected to an instance

import

configure

build

check