@memberjunction/cli

The official command-line interface for MemberJunction. Provides tools for installation, database migrations, code generation, metadata sync, AI operations, testing, database documentation, and query generation.

Architecture

graph TD
    subgraph "@memberjunction/cli (mj)"
        A[CLI Entry Point] --> B[Commands]
        B --> C[install]
        B --> D[migrate]
        B --> E[codegen]
        B --> F[sync]
        B --> G[ai]
        B --> H[test]
        B --> I[dbdoc]
        B --> J[querygen]
        B --> Q2[query]
        B --> K[bump]
        B --> L[clean]

        A --> M[Hooks]
        M --> N[init]
        M --> O[prerun]
    end

    subgraph "Underlying Engines"
        P["@memberjunction/codegen-lib"]
        Q["@memberjunction/metadata-sync"]
        R["@memberjunction/testing-cli"]
        S["@memberjunction/db-auto-doc"]
        T["@memberjunction/query-gen"]
        U["@memberjunction/ai-cli"]
        V["@memberjunction/core-entities-server"]
    end

    E --> P
    F --> Q
    H --> R
    I --> S
    J --> T
    G --> U
    Q2 --> V

    style A fill:#2d6a9f,stroke:#1a4971,color:#fff
    style C fill:#2d8659,stroke:#1a5c3a,color:#fff
    style D fill:#2d8659,stroke:#1a5c3a,color:#fff
    style E fill:#7c5295,stroke:#563a6b,color:#fff
    style F fill:#7c5295,stroke:#563a6b,color:#fff
    style G fill:#b8762f,stroke:#8a5722,color:#fff
    style H fill:#b8762f,stroke:#8a5722,color:#fff
    style I fill:#b8762f,stroke:#8a5722,color:#fff
    style J fill:#b8762f,stroke:#8a5722,color:#fff
    style Q2 fill:#b8762f,stroke:#8a5722,color:#fff

Overview

The mj CLI is built on the oclif framework and acts as a unified entry point for all MemberJunction development tools. Each command group delegates to a specialized package.

Installation

# Global (recommended)
npm install -g @memberjunction/cli

# Local
npm install --save-dev @memberjunction/cli

Requires Node.js 20.0.0 or higher.

Using mj from an agent or CI

mj detects whether a human is present and behaves accordingly. Nothing changes for someone typing at a terminal; everything changes for a program.

Prompting follows the terminal

A command prompts when stdin and stdout are both real terminals. When either is piped or redirected, when a CI environment variable is set, or when TERM=dumb, it does not — and a command that needs a value it wasn’t given fails immediately, naming the flag that supplies it, rather than blocking on stdin forever:

$ mj sync init                         # at a terminal: prompts, exactly as before

$ mj sync init < /dev/null             # spawned by an agent
 ›   Error: An entity-directory choice is required and this run has no interactive
 ›   terminal. Pass --setup-entity=ai-prompts|other|no.
 ›   Try this: Pass --setup-entity=ai-prompts|other|no.
$ echo $?
1

$ mj sync init --setup-entity=no       # scripted: runs unattended anywhere

Override the detection in either direction with --interactive / --no-interactive, or pin it for a whole shell session with MJ_CLI_INTERACTIVE=0 (or 1). An agent harness that shells out through a pty should set MJ_CLI_INTERACTIVE=0 so its subprocesses can never block on a question.

Output follows the pipe

With no explicit --format, mj writes human output to a terminal and JSON to a pipe — banner, spinners and color are suppressed automatically when stdout is redirected.

mj usage                       # human-readable domain map
mj usage | jq '.data.domains'  # JSON envelope, no flag needed
mj codegen --format=text > build.log   # force human output into a file
export MJ_CLI_FORMAT=json      # pin the format for a whole session

--format accepts text | json | md everywhere. The older per-family spellings (console/markdown under mj test *, compact/table under mj ai *) still work and still win over auto-detection when passed explicitly.

Note on -o: -o means output format in the mj ai family and output file path in mj test, querygen export, and sql-audit. Prefer --format — it means the same thing in every command.

Discovering commands without burning context

mj usage is a two-tier progressive-disclosure surface. Tier 1 is a ~200-token domain map; tier 2 is one domain’s commands, flags, examples, and expected runtime. Reading the full oclif help tree instead costs roughly 13–15k tokens.

mj usage                    # every domain + a one-line summary + a runtime class
mj sync usage               # every mj sync command, its flags and examples
mj sync usage --format=json # the same, machine-readable

Each entry carries a runtime hint (fast | moderate | slow | variable, often with a typical duration) so a caller wrapping mj in a timeout can budget correctly instead of killing a healthy long-running command. Commands also emit a {"event":"start", ...} line on stderr before doing work.

The result envelope

Commands built on BaseCLIPlugin emit a versioned envelope on stdout, with all progress and logging on stderr:

{"version":"1","success":false,"command":"sync:push","durationSeconds":1.2,
 "errors":[{"context":"metadata/entities","message":"No mj.config.cjs found.",
            "code":"E_NO_CONFIG","suggestion":"Run `mj sync init` in this directory first."}]}

code is stable and safe to branch on; message is free to be reworded. version lets a caller detect a contract change rather than silently mis-parsing.

Configuration

Uses cosmiconfig to find configuration:

• mj.config.js / mj.config.cjs
• .mjrc / .mjrc.json / .mjrc.yaml
• package.json (in "mj" property)

Database Environment Variables

Variable	Default	Description
DB_HOST	localhost	SQL Server hostname or IP
DB_PORT	1433	SQL Server port
DB_DATABASE		Database name
CODEGEN_DB_USERNAME		SQL Server login
CODEGEN_DB_PASSWORD		SQL Server password
DB_ENCRYPT	true	Encrypt the connection (required for Azure SQL)
DB_TRUST_SERVER_CERTIFICATE	false	Trust self-signed certificates (set true for local dev)

These can also be set in mj.config.cjs as dbHost, dbPort, dbDatabase, codeGenLogin, codeGenPassword, dbEncrypt, and dbTrustServerCertificate.

Open App packages and --no-app-packages

Every heavy command (anything that is not version, help, migrate, clean, bump, install, dbdoc * or * usage) imports, before it opens a database, the host’s generated packages and the installed Open Apps’ server packages named in mj.config.cjs — so mj sync push, mj app …, mj test and mj ai construct an app’s real entity subclasses rather than a generic BaseEntity. The command’s process ID is cli:<command> (cli:sync:push), which entries can be scoped to with Processes / ExcludeProcesses and dynamicPackages.policy:

mj.config.cjs

dynamicPackages: {
  server: [
    { PackageName: '@acme/seed-hooks', StartupExport: 'LoadSeedHooks', Processes: ['cli:sync'] },
  ],
  policy: { 'cli:codegen': 'none' },
}

--no-app-packages (global, any command) or MJ_DYNAMIC_PACKAGES=none skips them for one run; --verbose prints what loaded on stderr. Full model: guides/DYNAMIC_PACKAGE_LOADING_GUIDE.md.

Keeping the machine awake

mj install, mj app install, mj app upgrade and mj migrate run for many minutes against the database. If the machine sleeps mid-run, every in-flight request times out on wake and the step is rolled back. On macOS these commands therefore hold a caffeinate assertion for as long as the CLI process lives (it ends with the command). Set MJ_ALLOW_SLEEP=1 to opt out. Nothing holds Windows or Linux machines awake, so on every platform these commands start with a one-line warning not to let the machine sleep (or, on a Mac, close the lid) until they finish.

Commands

mj install

Interactive installer for new MemberJunction environments.

mj install

Sets up the database schema, applies migrations, and generates initial code.

mj migrate

Run database migrations (powered by Skyway).

mj migrate
mj migrate [--verbose] [--tag <version>] [--schema <name>] [--dir <path>]

Options:

• -v, --verbose: Enable detailed logging
• -t, --tag <version>: Specify a version tag for migrations (e.g., ‘v2.10.0’)
• -s, --schema <name>: Target schema (overrides coreSchema from config)
• --dir <path>: Migration source directory (overrides migrationsLocation from config)

Schema Handling:

• When using --schema, the specified schema will be automatically created if it doesn’t exist
• This enables migrating to new schemas without manual DDL setup
• The schema creation uses Flyway’s createSchemas feature

Examples:

# Basic migration
mj migrate

# Migrate to a specific version tag
mj migrate --tag v2.10.0

# Migrate a custom schema with custom migrations directory
mj migrate --schema __BCSaaS --dir ./migrations/v1

# Verbose output for debugging
mj migrate --verbose

mj codegen

Run MemberJunction code generation.

# Run full code generation
mj codegen

# Generate class registration manifests only
mj codegen manifest
mj codegen manifest --exclude-packages @memberjunction --output ./src/generated/manifest.ts

v5.0 Entity Name Migration Commands

Starting in MemberJunction v5.0, all 272 core entity names are being normalized with the "MJ: " prefix to prevent naming collisions on client systems (e.g., "Actions" becomes "MJ: Actions"). The database migration handles the rename automatically, but hardcoded entity name strings in your TypeScript source, Angular HTML templates, and metadata JSON files also need updating. These three commands automate that process.

All three commands share the same workflow:

1. Dry-run first (default) — scans and reports what would change, without modifying any files.
2. Fix mode (--fix) — applies the changes in place.
3. Rename map — built dynamically by parsing @RegisterClass(BaseEntity, 'MJ: XYZ') decorators from entity_subclasses.ts. No hardcoded list to maintain.

These commands will be kept for 1-2 years to support the v5.0 upgrade window, then removed.

mj codegen 5-0-fix-entity-names

Scans TypeScript source files (.ts) using the TypeScript compiler AST to find hardcoded entity names that need the "MJ: " prefix. This is the most comprehensive scanner — it understands code context, not just string matching.

Detected patterns:

Pattern	Example
GetEntityObject calls	md.GetEntityObject<T>('Actions')
OpenEntityRecord calls	this.OpenEntityRecord('Entities', id)
navigateToEntity calls	navigateToEntity('Templates')
BuildRelationshipViewParamsByEntityName calls	BuildRelationshipViewParamsByEntityName('Roles')
NewRecordValues calls	NewRecordValues('Users')
IsCurrentTab calls	IsCurrentTab('Queries')
EntityName: property assignments	EntityName: 'AI Agent Examples'
.Name === / .Entity === comparisons	entity.Name === 'Actions'
@RegisterClass decorator (BaseEntity)	@RegisterClass(BaseEntity, 'Actions')

Default exclusions: node_modules, dist, build, .git, __tests__, *.d.ts, *.spec.ts, *.test.ts, generated/, Demos/

# Dry-run: scan entire packages/ directory
mj codegen 5-0-fix-entity-names --path packages/

# Dry-run: scan a single file
mj codegen 5-0-fix-entity-names --path packages/Angular/Explorer/dashboards/src/Actions/components/actions-overview.component.ts

# Apply fixes
mj codegen 5-0-fix-entity-names --path packages/ --fix

# Custom entity_subclasses.ts location
mj codegen 5-0-fix-entity-names --path packages/ --entity-subclasses ./path/to/entity_subclasses.ts

# Quiet mode (summary only)
mj codegen 5-0-fix-entity-names --path packages/ -q

mj codegen 5-0-fix-html-entity-names

Scans Angular HTML template files (.html) using targeted regex patterns for entity name references in template expressions and attribute values.

Detected patterns:

Pattern	Example
Method calls in event/property bindings	(click)="navigateToEntity('Actions')"
OpenEntityRecord / openEntityRecord	(click)="OpenEntityRecord('Entities', id)"
BuildRelationshipViewParamsByEntityName	[Params]="BuildRelationshipViewParamsByEntityName('Roles')"
RowsEntityName attribute	RowsEntityName="Users"
JoinEntityName attribute	JoinEntityName="Roles"

Default exclusions: node_modules, dist, build, .git, generated/, Demos/

# Dry-run: scan Angular templates
mj codegen 5-0-fix-html-entity-names --path packages/Angular/

# Apply fixes
mj codegen 5-0-fix-html-entity-names --path packages/Angular/ --fix

# Verbose output showing individual file progress
mj codegen 5-0-fix-html-entity-names --path packages/ -v

mj codegen 5-0-fix-metadata-names

Scans metadata JSON files (including dotfiles like .mj-sync.json) for entity name references that need the "MJ: " prefix. Targets the metadata/ directory used by mj sync.

Detected patterns:

Pattern	Example
@lookup: entity name	@lookup:Entities.Name=Dashboards
@lookup: value (in Entities lookups)	@lookup:MJ: Entities.Name=Actions
Folder config entity/entityName	.mj-sync.json with "entity": "Dashboards"
relatedEntities object keys	"relatedEntities": { "Actions": [...] }
fields.Name in Entities folders	Entity record data files where Name is the entity name

# Dry-run: scan metadata directory
mj codegen 5-0-fix-metadata-names --path metadata/

# Apply fixes
mj codegen 5-0-fix-metadata-names --path metadata/ --fix

# Scan a specific subdirectory
mj codegen 5-0-fix-metadata-names --path metadata/resource-types

# Scan and fix a single file
mj codegen 5-0-fix-metadata-names --path metadata/entities/.audit-related-entities.json --fix

Common flags (all three commands)

Flag	Short	Description
--path <dir|file>	-p	File or directory to scan. Defaults to current directory.
--fix		Apply fixes in place. Without this flag, runs in dry-run mode.
--entity-subclasses <path>		Path to entity_subclasses.ts. Auto-detected if omitted.
--quiet	-q	Suppress detailed output, show summary only.
--verbose	-v	Show detailed progress for each file scanned.

Recommended migration workflow

# 1. Scan everything first (dry-run)
mj codegen 5-0-fix-entity-names --path packages/
mj codegen 5-0-fix-html-entity-names --path packages/
mj codegen 5-0-fix-metadata-names --path metadata/

# 2. Review the output, then apply
mj codegen 5-0-fix-entity-names --path packages/ --fix
mj codegen 5-0-fix-html-entity-names --path packages/ --fix
mj codegen 5-0-fix-metadata-names --path metadata/ --fix

# 3. Build and test
npm run build

mj sync

Metadata synchronization between JSON files and the database.

# Initialize metadata directory
mj sync init

# Check sync status
mj sync status

# Pull metadata from database to files
mj sync pull

# Push metadata from files to database
mj sync push

# Validate metadata files
mj sync validate

# Watch for file changes
mj sync watch

# Reset file state
mj sync file-reset

mj ai

AI-powered operations.

mj ai

mj test

Testing framework operations (delegates to @memberjunction/testing-cli).

# Run a test
mj test run --name "My Test"

# Run a suite
mj test suite --name "My Suite"

# List tests
mj test list

# View history
mj test history --name "My Test"

# Compare runs
mj test compare --run1 id1 --run2 id2

# Validate test config
mj test validate --name "My Test"

mj dbdoc

Database documentation generation.

# Initialize documentation
mj dbdoc init

# Analyze database schema
mj dbdoc analyze

# Export documentation
mj dbdoc export

# Check status
mj dbdoc status

# Reset documentation
mj dbdoc reset

# Generate sample queries
mj dbdoc generate-queries
mj dbdoc export-sample-queries

mj query

Saved query maintenance.

mj query refresh

Re-establishes saved queries’ parameters, fields, entities and dependencies from their SQL and the database server. The SQL itself is never changed. It runs the same extraction that saving an edited query runs: each query is described on the database server and parsed, the child rows are corrected, and the query’s ExtractedSQLHash, ExtractionStatus and ExtractionMessage are updated. Authored annotations (descriptions, and a Manual parameter’s type, default, sample value and filters) are kept.

# Recommended after upgrading: review first, then apply
mj query refresh --all --dry-run
mj query refresh --all

# One query by full path, or every query with a bare name
mj query refresh --name "MJ/Reports/Top Customers"

# A category and everything below it, filling empty descriptions with the LLM
mj query refresh --category MJ --with-ai

# Every query that reads an entity
mj query refresh --entity "MJ: AI Agents"

Flag	Description
--id <id>	Refresh the query with this ID. Repeatable.
--name <name>	A query name or a full path Category/Sub/Name. A bare name selects every query with that name. Repeatable.
--category <path>	A category path: the queries in it and in every category below it. Given once.
--entity <name>	The queries that read this entity. Repeatable.
--all	Refresh every query.
--dry-run	Report the changes without writing anything.
--with-ai	Fill empty descriptions with the LLM description pass (off by default).
-v, --verbose	Also list queries that are unchanged.
--format <text|json>	Output format (default text). json prints the full run report.

At least one of --id, --name, --category, --entity or --all is required. The selectors are not mutually exclusive: when several are given, the queries any of them select are refreshed. Each query is refreshed in its own transaction, and the queries a composition depends on are refreshed before the queries that compose them.

Output. Progress goes to stderr, one line per query ([3/31] Refreshed AIUsageHourly). The report goes to stdout: one heading per query with its outcome and extraction status, then its changes, then a summary line:

WOULD REFRESH "AIUsageHourly" (<query ID>) [OK]
    + field CacheReadTokens
    ~ parameter start (Type)
    - entity MJ: AI Models
    ! parameter scope: authored, no longer used by the SQL (kept)
31 queries: 1 would be refreshed, 30 unchanged, 0 failed (dry run: nothing was written).

+, ~ and - mark child rows added, updated (with the changed columns) and removed; ~ query (...) lists changed columns on the query row itself. The outcomes are REFRESHED (WOULD REFRESH in a dry run), UNCHANGED, NOTPERMITTED, UNAVAILABLE and FAILED. Without --verbose, unchanged queries with no diagnostics are left out. A failed query reports the reason, and nothing is written for it.

Exit codes.

Code	Meaning
0	Every selected query was refreshed, was unchanged, or was skipped as not permitted.
1	A query failed, or an --id or --name you gave matched no query you can read.
2	No selector flag was given.

Permissions. A refresh, including a dry run, needs Update on MJ: Queries and Create, Update and Delete on MJ: Query Fields, MJ: Query Parameters, MJ: Query Entities and MJ: Query Dependencies. For each query it also needs read access to every entity the query reads, with no field denied on any of them. A query that fails these checks is reported as NOTPERMITTED in a bulk run, with no reason given. mj query refresh runs in process as the System user, using the database connection in mj.config.cjs; the same checks apply when a refresh is started from MJAPI or Explorer as a signed-in user.

mj query usage

Prints every mj query command with its flags, examples and runtime hints. --format takes text, json or md; it defaults to text on a terminal and json when stdout is piped.

mj query usage
mj query usage --format=json

mj querygen

Query generation tools.

mj querygen generate
mj querygen export
mj querygen validate

mj bump

Version management for packages.

mj bump

mj clean

Clean build artifacts.

mj clean

mj app

Install, upgrade, and manage MJ Open Apps (packaged via @memberjunction/open-app-engine).

# List installed apps
mj app list

# Show detailed info for one app
mj app info <name>

# Install from a GitHub repository
mj app install https://github.com/acme/mj-crm
mj app install https://github.com/acme/mj-crm --version 1.2.0

# Upgrade to a newer version (latest if --version omitted)
mj app upgrade acme-crm
mj app upgrade acme-crm --version 1.3.0

# Enable / disable without removing
mj app enable <name>
mj app disable <name>

# Remove (add --keep-data to preserve the schema)
mj app remove <name>
mj app remove <name> --keep-data

# See which installed apps have newer versions available
mj app check-updates

Private repositories

Some BizApp repositories are private or internal (bizapps-ats is one). GitHub answers 404, not 403, for a repository it will not show you, so an install without a credential fails as though the app or the version did not exist. Supply a token one of three ways:

# 1. Environment variable
GITHUB_TOKEN=$(gh auth token) mj app install https://github.com/MemberJunction/bizapps-ats

# 2. mj.config.cjs — per-repository tokens, keyed by repo URL
#    openApps: { github: { tokens: { 'https://github.com/MemberJunction/bizapps-ats': process.env.ATS_TOKEN } } }

# 3. mj.config.cjs — one token for every Open App repo
#    openApps: { github: { token: process.env.GITHUB_TOKEN } }

If more than one is set, the per-repo tokens entry wins, then token, then GITHUB_TOKEN — so a stale token left in mj.config.cjs silently shadows a freshly exported GITHUB_TOKEN.

The token needs repo scope for the repositories you install from.

Internal / dangerous flags

Intentionally omitted from --help. Almost never needed: MJ’s own Open Apps use the __mj_<AppName> schema namespace (__mj_BizAppsCommon, __mj_BizAppsForms, …), which installs on the default path with no flag at all.

• --dangerously-ignore-dbl-underscore-schema-rule — available on mj app install, mj app upgrade and mj app remove. Allows a __-prefixed schema name outside the __mj_ app namespace (e.g. __bcsaas). Reserved schemas remain hard-blocked regardless, on both supported platforms: every schema the database owns — dbo, sys, guest, SQL Server’s nine db_* fixed database-role schemas, public, anything starting pg_, and information_schema — plus every schema MJ owns: __mj and __mj_UDT. Each of these already exists in a stock database, so naming one would not create it, it would adopt it — and mj app remove would then drop it.

  Removing an app installed under one of those __-outside-namespace names (e.g. __bcsaas) needs the same flag again: mj app remove <app> --dangerously-ignore-dbl-underscore-schema-rule drops the schema. --keep-data is the exit for the platform- and MJ-reserved names above, which MJ must never drop: mj app remove <app> --keep-data unregisters the app and leaves the schema in place.

mj app install https://github.com/BlueCypress/SaaS \
  --dangerously-ignore-dbl-underscore-schema-rule

mj baseline

Build, compare, and round-trip baseline migrations — a single SQL script that captures the end-state of an entire V-stack (schema + every row of every table) into one deterministic B-prefixed file that Flyway/Skyway can apply to a fresh database in place of the long migration chain.

Niche command — only needed when collapsing a V-stack into a new baseline (within-major rebaseline) or cutting a new major version (e.g. v5 → v6). Day-to-day MJ development never touches this; use mj migrate for routine schema changes.

Three subcommands:

• mj baseline build — connect to a live MSSQL database, introspect everything, dump every row of every table, and emit a canonical T-SQL script.
• mj baseline compare — diff two live databases object-by-object and row-by-row.
• mj baseline roundtrip — build + apply to a fresh DB + compare in one shot. Proves the new baseline is byte-equivalent to the V-stack it replaces.

Two operating modes

Mode	Trigger	Version source	Timestamp	Output folder
AUTO — within-major rebaseline (default)	--baseline-version omitted	Major.Minor parsed from the latest V-file in --source-dir	latest V-file’s timestamp + 1 minute	the same migrations/v{N}/ it scanned
EXPLICIT — major-boundary baseline	--baseline-version M.N provided	the flag value	Date.now() UTC	migrations/v{N+1}/ (new)

AUTO mode is the right choice 99% of the time. EXPLICIT is for starting a new major version (e.g. v6.0).

Filename format: B{YYYYMMDDHHMM}__v{Major}.{Minor}.x__Baseline.sql (literal lowercase x matches the V-file patch convention — patches don’t carry migrations).

mj baseline build

# AUTO — within-major rebaseline (writes back into ./migrations/v5/)
mj baseline build --out ./migrations/v5/

# EXPLICIT — start a new major version (writes into ./migrations/v6/)
mj baseline build --baseline-version 6.0 --out ./migrations/v6/

# Schema-only, no data inserts
mj baseline build --no-data --out ./baselines/

Key flags: --baseline-version, --source-dir, --database, --out, --exclude-data <csv>, --batch-size, --no-data, --dry-run, --verbose. Run mj baseline build --help for the full list with defaults.

Database host/user/password come from the MJ config (mj.config.cjs / .env); --database overrides only the database name.

mj baseline compare

# Full row-by-row diff (default)
mj baseline compare --left MJ_BL_Stack --right MJ_BL_New

# Counts-only (fastest)
mj baseline compare --left A --right B --row-compare counts

# CI use — fail the build on any diff, write reports
mj baseline compare --left A --right B --fail-on-diff --out ./diffs/

Row-compare modes: full | hash | counts | none. Hash mode supports --row-hash-algo sha256|md5|checksum_agg. --dialect mssql|postgres (both sides must match).

mj baseline roundtrip

# AUTO — verify the current v5.x V-stack collapses cleanly
mj baseline roundtrip --source MJ_BL_Stack --target MJ_BL_New

# EXPLICIT — verify a v6.0 baseline
mj baseline roundtrip --baseline-version 6.0 --source MJ_BL_Stack --target MJ_BL_New

--source is the gold-standard DB with the V-stack already applied; --target is an empty DB the new baseline will be applied to and compared against. Add --keep-target to inspect the post-apply DB after a failed diff. --apply-cmd lets you override the default sqlcmd apply step (tokens: {file}, {database}).

Related tooling

• Slash command — /create-new-baseline-migration drives the workbench end-to-end from a local Claude Code session (spins up the workbench, runs the roundtrip, stages the file in migrations/ only if byte-equivalent).
• Workbench script — docker/workbench/baseline-roundtrip.sh (aliases mjbaseline, mjbaseline-mssql, mjbaseline-pg inside the workbench container) is the 7-phase end-to-end runner the slash command invokes.
• Design record — packages/MJCLI/src/commands/baseline/PLAN.md documents the architecture, decisions, and component layout.
• PostgreSQL — the T-SQL baseline is converted via mj migrate convert (see /pg-migrate skill) before being applied to a PG target.

Hooks

Hook	Timing	Purpose
init	Before any command	Loads configuration, initializes environment
prerun	Before command execution	Validates configuration, connects to database

Plugin System

The CLI includes these oclif plugins:

• @oclif/plugin-help — Auto-generated help text
• @oclif/plugin-version — Version display
• @oclif/plugin-warn-if-update-available — Update notifications (checks daily)

Dependencies

Package	Purpose
@memberjunction/codegen-lib	Code generation engine
@memberjunction/metadata-sync	Metadata synchronization
@memberjunction/testing-cli	Testing framework CLI
@memberjunction/db-auto-doc	Database documentation
@memberjunction/query-gen	Query generation
@memberjunction/ai-cli	AI operations
@memberjunction/config	Configuration management
@memberjunction/server-bootstrap-lite	Lightweight server initialization
@memberjunction/sqlserver-dataprovider	Database connectivity
@oclif/core	CLI framework
cosmiconfig	Configuration file loading
@memberjunction/skyway-core	Database migration execution
simple-git	Git operations
figlet	ASCII art for banners

License

Business Source License 1.1 — see LICENSE for details.