mait.sh1.69.2

Private beta: features and content may change. No warranty; use at your own risk.

Docs / Launcher and command-line tools

CRM CLI

Administer approved customer records, prepare pending registrations and inspect service access.

For operators authorized to administer customer records. Ordinary account holders use their account page or support.

Read from the top for the basics; the later sections go deeper.

Beta
All components

What it doesBasics

  • Create a pending customer with an email and name
  • Look up an exact customer ID, email or provider identity
  • Delete an approved record and verify the result
  • Check service health, inspect diagnostics and stage an update

First useBasics

  1. Obtain the approved Linux amd64 or arm64 executable and verify its published digest through your distribution process.
  2. Run crm version and crm help customer; correct startup settings if even these fail.
  3. Confirm the assigned environment, credential and a customer ID approved for lookup. Use MAIT_CHANNEL=beta only when that is your assigned environment.
  4. Run crm customer get APPROVED_ID and require the expected ID in the response. A zero exit alone does not prove a match.
  5. Restore temporary environment settings afterward. No customer deletion is needed to clean up a read-only check.

Everyday tasksEveryday use

Verify one approved customer

You need to confirm a known customer without changing their record.

  1. Confirm the environment and authorization for that customer.
  2. Run crm customer get APPROVED_ID, or use get-by-email with the approved exact email.
  3. Check the returned ID and relevant fields; there is no list or broad search command.

What you getThe known record is confirmed, or an explicit absence/error is handed to its owner.

How to check: Require the intended ID. A lookup can exit zero after a 404, and missing display fields do not prove absence.

Prepare a pending registration

An authorized operator needs to prepare a record before the customer signs in.

  1. Confirm server support and the operator permission for manual creation.
  2. Run crm customer create --email approved@example.invalid --name "Approved Name".
  3. Require the returned customer ID and retain it for readback. On a duplicate or lost response, reconcile by email before retrying.
  4. The customer later claims that same record through a matching verified sign-in.

What you getA pending customer exists; registration and service provisioning follow the verified claim.

How to check: Creation is not a sign-in, invitation or completed registration. A duplicate response leaves the existing record unchanged.

Delete an approved record

The record owner has authorized removal of one exact customer.

  1. Read and confirm the exact customer ID and approval.
  2. Run crm customer delete APPROVED_ID; it acts immediately without another prompt.
  3. Read the same ID to confirm absence. Do not repeat deletion as a verification step.

What you getThe customer record is removed or a specific failure is reconciled.

How to check: An expected not-found read can exit zero. Downstream cleanup is best effort, so this is not proof of complete erasure.

Diagnose access and stage an update

An operator needs to distinguish a service problem from an outdated executable.

  1. Run crm health and inspect the response, then crm doctor and read every finding.
  2. For an offered update, run crm update in an interactive terminal with the required credential.
  3. After successful staging, use the installation owner’s replacement process and verify crm version plus an authorized read.

What you getThe failed boundary is identified or the replacement executable is independently confirmed.

How to check: Health does not prove permission; diagnostics may skip checks. Downloaded files can remain after a late failure, and next launch does not apply the staged update.

Settings to decideAdvanced

Choose the assigned environment
`MAIT_CHANNEL` selects the shared environment. Confirm it with the operator before any write; do not switch environments to bypass a refusal.
Keep credentials and settings deliberate
`CRM_CREDENTIALS_PATH` takes precedence, even when empty. A nonempty generic `CREDENTIALS_PATH` can otherwise apply. Optional settings are read from the user or system CRM YAML file. There is no arbitrary service-URL flag.
Separate stored names from account presentation
With service version 0.13.0, sign-in preserves nonempty stored name fields. The CLI can retain the manually supplied display name while the account page displays first and last names filled during sign-in. Confirm the same customer ID. Where the current account Profile editor is deployed, the customer can use Edit name; CRM CLI has no profile-name editor. Re-read after an uncertain save instead of deleting or duplicating the account.
Understand update notices
`CRM_UPDATE_COOLDOWN` defaults to 600 seconds between background checks; notices have a separate ten-minute cache. There is no background-disable flag. Shared timeout or re-execution settings do not install staged updates.

CommandsAdvanced

$ crm version
$ crm help customer
$ crm customer get APPROVED_ID
$ crm customer get-by-email approved@example.invalid
$ crm health
$ crm doctor
$ crm update

Problems and fixesHelp

What you seeCheckFix
Sign-in succeeds but access is refusedConfirm the environment, required permission and current service authority.Sign-in and customer permissions are separate. Confirm the assigned environment and permission with its operator. Older service credentials may need reissue after permission changes; repeated login alone does not grant access. A locally valid credential can still be denied when current authority cannot be confirmed.
A customer write lost its responseRead the exact ID or email before retrying.Manual creation requires a compatible service and operator credential. A duplicate response leaves the existing record unchanged. If the response is lost or lacks a customer ID, read by the known email and reconcile before retrying; the write may already have completed.
An update is staged but the version is unchangedCompare `crm version` with the intended installed release.Staging does not replace the executable or apply it at the next launch. Use the installation owner’s replacement process, then verify the version and an authorized read. Preserve errors and staging files until an incomplete update is understood; there is no CLI rollback command.
What you see
Sign-in succeeds but access is refused
Check
Confirm the environment, required permission and current service authority.
Fix
Sign-in and customer permissions are separate. Confirm the assigned environment and permission with its operator. Older service credentials may need reissue after permission changes; repeated login alone does not grant access. A locally valid credential can still be denied when current authority cannot be confirmed.
What you see
A customer write lost its response
Check
Read the exact ID or email before retrying.
Fix
Manual creation requires a compatible service and operator credential. A duplicate response leaves the existing record unchanged. If the response is lost or lacks a customer ID, read by the known email and reconcile before retrying; the write may already have completed.
What you see
An update is staged but the version is unchanged
Check
Compare `crm version` with the intended installed release.
Fix
Staging does not replace the executable or apply it at the next launch. Use the installation owner’s replacement process, then verify the version and an authorized read. Preserve errors and staging files until an incomplete update is understood; there is no CLI rollback command.

All CRM CLI problems and fixes →

Good to knowHelp

  • Signing in does not grant customer administration permissions; current service authority can still deny a request.
  • Pending creation does not sign the customer in, invite them or complete their registration.
  • Deletion is immediate without a confirmation prompt or undo. Staging an update does not install it.