EnterpriseAI 发布 eai CLI：面向企业 AI 应用的命令行脚手架

eai — EnterpriseAI CLI

Scaffold, configure, validate, and operate EAI applications from a developer terminal.

The CLI gives teams a supported path for application setup, authentication, workspace selection, runtime validation, resource management, and deployment readiness. It keeps platform access behind authenticated commands and public-safe diagnostics, so developers and AI coding agents get useful next steps without exposing private infrastructure details.

Customer-facing CLI language uses workspace. The CLI also accepts the tenant command and --tenant-* options for compatibility with existing scripts and platform API names. Stable fields such as tenantId, --tenant-id, limits.tenants, and role IDs such as tenant-admin remain unchanged. They refer to EAI workspaces or the platform role contract.

Package Trust

This package is intended for public npm installation in enterprise developer workstations, CI agents, Codespaces, and other controlled engineering environments.

Public Repository

This repository is the public source for the EnterpriseAI CLI. The README is the fast path for developers who want to install the tool, understand what it does, and find the maintained documentation.

Public-readiness rule for maintainers: everything committed here must be safe for a public audience. Do not commit secrets, customer data, private workspace details, local .env files, unpublished internal architecture notes, private environment URLs, or temporary build output.

Generated Gofer specs, memory files, logs, checkpoints, and local runtime state are intentionally ignored. The committed .specify directory contains only the reusable scripts and templates needed by eai init and eai gofer refresh.

Install

Recommended install:

npm install -g eai-cli

Canonical package:

npm install -g @enterpriseai/cli

Static registry fallback:

npm install -g @enterpriseai/cli --@enterpriseai:registry=https://eai-support.github.io/eai/registry/

Persistent static fallback setup:

npm config set @enterpriseai:registry https://eai-support.github.io/eai/registry/ --location=user
npm install -g @enterpriseai/cli

If you are validating the generated registry from a local checkout of this repo, install the tarball instead of the packument file:

npm install -g ./docs-site/static/registry/-/@enterpriseai/cli-latest.tgz

docs-site/static/registry/@enterpriseai/cli is the registry metadata file. It is not an installable package directory.

Quick Start

# 1. Run the guided first-time setup
eai create my-app
cd my-app

# `eai create` checks local tooling, signs you in, confirms the signup
# workspace, creates the app, installs dependencies, verifies Gofer, and
# checks builder readiness. Use `eai start` to open a supported AI workspace when
# it finishes. Pass `--no-install` to skip the install and run
# `npm install` yourself.

# 2. For an existing login or automation, use the lower-level commands:
eai whoami
eai workspace select

# 3. Create child workspaces only when you need them
#    `eai workspace create --parent <id>` now creates the workspace record,
#    attempts first-admin bootstrap for the current login, and only marks
#    the workspace usable after workspace-admin membership is confirmed
#    (platform role ID `tenant-admin`).
#    The child home region defaults to the parent region; pass
#    `--home-region au|ca|eu` when the child must use another region.

# 4. Sync project environment if your app needs local configuration
eai env pull --include-secrets

# 5. Define your data model
#    Edit src/eai.config/object-types.ts
#    Keep name PascalCase and declare an exact lowercase kebab-case slug.
#    Relationship targets use the target's exact stored slug.

# 6. Validate, inspect, publish, and verify
eai types validate
eai types diff
eai types seed
eai resources schema --format json

# 7. Start developing
eai dev

eai create installs Gofer AI terminal assets by default. New app repos include Claude commands and agents, shared Antigravity/Codex skills, Grok skills, Copilot prompts and CLI skills, and the .specify commands/scripts/templates/hooks required to run the Gofer pipeline. Use eai create my-app --no-gofer only when you need a bare scaffold. eai init remains available as the low-level, backwards-compatible scaffold command. Use eai create my-app --skip-onboarding when you want the old init prompts without the first-run checks.

By default, eai create my-app creates a new ./my-app folder. If you already created and entered a project folder, run eai init, enter the app name, and answer yes when asked to use the current folder. For automation, pass --current-dir with the kebab-case app name. Current-folder init preserves unrelated existing files and Git metadata, and updates files that are part of the generated scaffold.

Global Flags

All commands support these global flags:

Commands

Scaffolding

The bundled default template is pinned to the latest eai-app-template main commit captured when this CLI release was cut. Use --from to override it with a different repository or a local template path.

Authentication

Codespaces and other remote dev environments can keep the standard localhost callback by forwarding a fixed callback port from the Codespace to your local machine:

# Local machine, keep this running in a separate terminal
gh codespace ports forward -c <codespace-name> 3476:3476

# Codespace terminal
eai login --callback-port 3476

eai login --callback-port <port> still uses http://localhost:<port> for the OAuth callback; it just pins the port instead of choosing a random one. That keeps the public Entra app registration unchanged while allowing your local machine to tunnel the callback into the Codespace.

Environment

Object Types

Object Types keep two different identifiers. The source/model name is PascalCase, such as BoardAppUser. The explicit persisted and transport slug is exact lowercase kebab-case, such as board-app-user. Do not convert every field to the same case.

Generated or persisted linkTypes[].targetObjectType, runtime target_type, resource command arguments, path parameters, and governed v4 query fields use the exact stored slug. A same-manifest PascalCase relationship target is only source shorthand: the CLI resolves it through the target's declared slug before diff or seed and rejects unresolved names. Historical stored slugs are authoritative and must never be silently re-derived or renamed.

{
  name: "BoardAppMembership",
  slug: "board-app-membership",
  linkTypes: [
    {
      name: "user",
      targetObjectType: "board-app-user",
      cardinality: "many-to-one",
    },
  ],
}

Use this publication sequence: eai app provision, eai types validate, eai types diff, eai types seed, then eai resources schema.

Resources

In every command below, <type> and each value passed to --types mean an exact published Object Type slug, not its PascalCase model name. App feature code should use useResources or client.resources so the shared SDK owns route construction.

Workspaces

AI & Documents

PublicAPI V4

Use named commands first for normal workflows. eai publicapi is the advanced V4-only surface for route families that do not yet have a polished command, such as geo, realtime, platform administration, integrations, or DAISY-specific diagnostics. It still uses your current login and workspace context, and PublicAPI still enforces platform workspace authorization.

Deployment

The runtime contract lives in eai.runtime.json. It declares required environment variable names, required secrets, health/runtime endpoints, Auth.js callback path, workspace/workflow key patterns, user-delegated BFF access, and post-deploy smoke tests. It is host-neutral: Vercel, Docker, AWS, Azure, Kubernetes, VM-style hosts, and internal demo environments should translate the same contract into their provider-specific env and secret setup.

eai deploy doctor deliberately does more than /health. A deployment can have /health returning 200 and still fail because Auth.js providers are missing, the Entra callback URL is wrong, workspace/workflow config is empty, a route is trying to use unsupported app-only data-plane access, PublicAPI rejects authorization, or the app runtime is throwing errors.

Diagnostics

Workspace Lifecycle

eai workspace create now distinguishes these states:

• created: the workspace record exists
• bootstrapped: the CLI successfully called the constrained first-admin bootstrap flow for a child workspace
• usable: a refreshed membership check confirmed the current login now holds direct workspace admin access (platform role ID tenant-admin) on that workspace

For child workspaces, the CLI only auto-selects the new workspace when usable is true. If bootstrap is blocked or downstream membership confirmation has not landed yet, the command leaves the active workspace unchanged and reports that explicitly.

The first-admin bootstrap path is intentionally narrow:

• the caller must already hold workspace admin access (platform role ID tenant-admin) on the direct parent workspace
• the target must be an immediate child of that parent
• the child must not already have a workspace admin
• parent child allowance is enforced from limits.tenants

For existing child workspaces that were created before the bootstrap completed, a parent workspace admin can run:

eai workspace bootstrap-admin --parent <parent-workspace-id> --child <child-workspace-id>

By default this bootstraps the current login. To repair another known parent member, pass --user-oid <entra-user-oid> and optionally --user-email <email>.

Workspace Member And Role Management

Use eai user invite for normal "add this person to a workspace" and "make this person a workspace admin/member" requests. The command calls the V4 workspace member invite/add flow and can assign these base roles (platform role IDs):

• tenant-viewer
• tenant-staff
• tenant-builder
• tenant-admin

Common examples:

eai user roles --workspace <workspace-id> --format json
eai user invite --email user@example.com --workspace <workspace-id> --role tenant-viewer
eai user invite --email admin@example.com --workspace <workspace-id> --role tenant-admin
eai user list --workspace <workspace-id> --search admin@example.com --format json

If eai user invite fails with a 5xx or EXTERNAL_SERVICE_ERROR, do not guess or edit the database directly. Run:

eai errors explain user_invite_external_service_existing_member --format json
eai user list --workspace <workspace-id> --search <email> --format json

If the person already exists as a direct workspace member and you approve the role change, repair the role through EAI CLI and verify read-back:

eai user role set --workspace <workspace-id> --member-id <member-id> --role tenant-admin --format json
eai user list --workspace <workspace-id> --search <email> --format json

The affected app user may need to sign out and sign back in because Auth.js session or JWT role data can be cached.

eai workspace bootstrap-admin is not a general "make this user an admin" command. It is only for repairing first workspace-admin access on an existing immediate child workspace when the caller already has workspace admin access on the direct parent (platform role ID tenant-admin).

Architecture

Developer Terminal                    EAI Platform
──────────────────                    ────────────
eai login ──────────────────────────→ Entra CIAM (browser PKCE + localhost callback)
eai workspace select ──────────────────→ Current-user memberships → active workspace
eai env pull ───────────────────────→ Azure App Config + Key Vault
eai types seed ─────────────────────→ Platform API → Type Registry
eai resources list <object-type-slug> → Platform API → Data Service
eai workflow status ────────────────→ Platform API → AI runtime readiness
eai chat stream ────────────────────→ Platform API → AI Service
eai docs classify ──────────────────→ Platform API → AI Service
eai runtime validate ────────────────→ eai.runtime.json → local contract evidence
eai deploy env ──────────────────────→ eai.runtime.json → provider env/secret checklist
eai deploy doctor ───────────────────→ deployed app URL → black-box runtime checks
eai deploy trigger ─────────────────→ GitHub Actions → deployment workflow

The CLI authenticates via browser-based authorization code flow with PKCE, stores tokens locally in ~/.eai/, persists the active workspace from your platform memberships, and calls the platform API directly with a Bearer token. .env.local is still available for project runtime configuration, but workspace selection for CLI platform commands comes from eai login and eai workspace select.

Runtime workflow checks are intentionally public-safe. They tell you whether a workflow key is available, operator_required, paid_upgrade_required, rate_limited, blocked, unsupported, or not ready without exposing private platform topology. Use eai workflow request <key> when the platform reports operator_required.

Error Guidance

The CLI uses structured error guidance for consistent human and AI-agent recovery:

• E001-E099: Project errors (not in EAI project, config missing)
• E100-E199: Auth errors (not logged in, token expired)
• E200-E299: Platform errors (API unreachable, resource not found)
• E300-E399: Validation errors (invalid schema, missing field)

Error output explains why the error may have happened, what read-only diagnostics to run first, what mutating eai commands can fix it, and when to stop retrying.

✗ Not logged in.

Why this might happen:
- The CLI does not have a usable local sign-in token.
- The token may have expired or been created for a different local profile.

Try next:
1. eai whoami [read-only]
   Show the current login and active workspace status.
2. eai login [changes state]
   Authenticate with the EAI identity flow.

Error code: E101
Reason: not_logged_in

JSON output keeps the legacy suggestion field and adds structured guidance for AI agents:

{
  "error": {
    "code": "E101",
    "message": "Not logged in",
    "suggestion": "Run `eai login` to authenticate with the platform",
    "guidance": {
      "reasonCode": "not_logged_in",
      "why": ["The CLI does not have a usable local sign-in token."],
      "diagnostics": [{ "command": "eai whoami", "mutates": false }],
      "fixes": [{ "command": "eai login", "mutates": true }]
    },
    "exitCode": 1
  }
}

Use eai errors explain <code-or-reason> for the release-aligned explanation:

eai errors explain E101
eai errors explain tenant_authorization_incomplete --format json
eai errors explain user_invite_external_service_existing_member --format json
eai errors explain app_token_tenant_context_required --format json

Use app_token_tenant_context_required when platform user lookup or membership prerequisite calls return MISSING_TENANT or "Tenant context required for app tokens"; retry workspace-scoped V4 platform routes before changing workspace members, role definitions, Entra configuration, databases, or cloud portals.

Support reports

Run eai support when you want help with a CLI failure. It shows a locally redacted report and asks before sending. The report includes the last failing command, catalog error code and reason, CLI version, OS, and known workspace/app context. Credentials and unrelated environment settings are excluded. Saved failure context contains command and catalog metadata only, is left out of the report after 24 hours (the CLI shows its time), and --no-last-error skips it.

Every failing command ends with the same offer: "Need help? Run eai support, or ask your AI assistant to get help. Nothing is sent without your approval." Text mode prints this on every nonzero exit. JSON error keys stay unchanged; error.suggestion contains only the catalog suggestion.

Re-run eai init --tool <tool> to refresh instructions in projects created with older CLI versions. eai gofer refresh preserves their CLAUDE.md and AGENTS.md.

An AI harness starts a report only when you ask for EAI Support ("get help" or eai support). Generic coding help, command failures, failed fixes and error hints do not authorize any eai support call, including allocation, preview, sending or decline. Write a short summary of the chat problem, attempts and results, without raw transcripts, environment values or file contents. It passes its bounded session summary (what you asked, the goal, steps, commands, errors, attempted fixes and project-relative files) through --context-file. For a file, run eai support --create-context-file --format json, then write the summary into the returned contextFile without replacing it. The CLI allocates it in ~/.eai/support/context/ (directory 0700, file 0600) and records its identity. Preview keeps it; an approved send deletes it. On a declined preview, run eai support --decline --context-file <path> --format json to clean it up without sending. Marked files older than 24 hours are removed on the next support run. Untracked files and files elsewhere are never deleted.

--context-file, which reads a JSON file or stdin (-), accepts at most 64 KiB, redacts credentials, hides your home directory and project root, and drops the oldest steps, commands and errors to stay within the website's 32 KiB cap:

eai support --source harness --tool codex --context-file - --format json

The JSON preview returns previewText, the whole redacted report as plain text ending with its digest, and bundleDigest. The harness shows previewText unchanged and asks you. After you approve, it reruns with --yes --approved-digest <bundleDigest>; any other digest answers consent_stale and sends nothing. JSON runs without --yes never send a report, and --yes always needs the digest, including interactive text runs.

When the saved session has no active workspace, the report needs to know where your organisation is based so it is stored in that region. A terminal asks you; JSON runs answer consent_required with questions: ["organisationLocation"] until --organisation-location apac|emea|americas is supplied. If the website still cannot place the report it answers region_required, and the CLI returns the Support chat link instead.

The returned link contains only a draft id and one-time token in its fragment. Open it to review and submit the report before the draft expires. A missing or expired eai login session, a website 401, a declined report or region_required returns <website>/support?chat=open, which opens the Support chat without prefill and creates no draft. --no-open prints the link without opening a browser. Reports never go in URL parameters.

Existing projects can preview updated harness instructions with eai gofer refresh --check, then apply the supported refresh. eai update upgrades the CLI package; it does not rewrite project instructions.

Machine-Readable Output

Most data-returning commands that advertise --format <format> support --format json for automation. Check eai --describe or command help before scripting a subcommand; status-only commands such as eai whoami and quick eai verify are plain text today.

# Get JSON output
eai resources list board-app-user --format json

# Parse with jq
eai workspace list --format json | jq '.tenants[] | .slug'

# Use in scripts
if eai verify calls --format json | jq -e '.summary.failed == 0' > /dev/null; then
  echo "Platform contracts are healthy"
fi

The --describe flag outputs the CLI command structure as JSON Schema, enabling AI agents and automation tools to discover capabilities at runtime:

eai --describe        # Describe all commands
eai types --describe  # Describe types subcommands

For AI agents that need to use eai without extra instructions, start with the built-in operating guide:

eai agent guide --format json

The same guide is embedded in eai --describe as agentGuide. It tells agents to prefer structured output, run read-only diagnostics before fixes, call eai errors explain <code-or-reason> --format json after failures, use named commands before raw publicapi calls, and stop when retry or escalation conditions match.

To test whether a weak agent can discover that behavior without EAI-specific prompt instructions, run the built-in discovery eval:

npm run build
npm run eval:agent-discovery -- --json

The default regex-small agent is intentionally limited: it starts from generic help/describe output, parses visible error codes or reason codes, and only runs commands it discovers from the CLI output. Use --agent-command <cmd> to plug in a real model runner that accepts the eval JSON turn on stdin and returns a JSON decision.

Gofer AI Terminal Assets

Every eai init project includes the repo-local Gofer assets needed by the AI providers used in this workspace:

The v2 launcher catalog is deliberately fixed and ordered. Its six graphical choices are GitHub Copilot in VS Code, GitHub Copilot app, Google Antigravity 2.0, Claude Desktop, ChatGPT desktop (Codex), and Grok Bot. Its five CLI choices are GitHub Copilot CLI, Antigravity CLI (agy), Claude Code, Codex CLI, and Grok Build. Current installers come only from the official VS Code and Copilot, GitHub Copilot app, Google Antigravity, Claude, Codex, and Grok pages.

eai start reports an accepted operating-system launch request, not a verified provider startup or project handoff. In JSON, launched remains as an EAI Setup 0.3.19 compatibility alias for dispatched; new consumers should use dispatched, confirmed, and launchState. Detection defaults to the v1 contract for Setup 0.3.19, while current Setup explicitly requests v2 with --contract-version v2.

Each graphical v2 entry reports its required CLI and verified installation state. eai start --surface <graphical-id> --install quietly installs or updates that CLI, then runs trusted detection again. A missing desktop app can open its official page. If quiet installation cannot complete, EAI opens or returns the official URL for visible password, consent, terms, or sign-in work.

eai start --check never executes a provider binary. Desktop detection binds macOS/Windows signatures or Linux package ownership, architecture, repository, and signing keys; unsigned Linux portable apps require catalogued immutable hashes and are checked again before launch. Unsupported identities fail closed. Official Antigravity 2.0 and Grok Bot releases include Windows ARM64, and their Linux downloads include ARM64, but architecture availability alone is not proof of identity. EAI reports an installed surface only when that exact build matches trusted signer, package, or immutable artifact-catalog evidence.

The shared workflow artifacts live under .specify/: commands, scripts, templates, hooks, memory, logs, and generated feature specs. Runtime state is added to .gitignore; command definitions and templates are committed with the app.

Updating an existing repo safely

eai update keeps the local EAI toolchain current. It checks the installed CLI against npmjs first, falls back to the public static registry when needed, installs the newer CLI when available, then force-refreshes Gofer-managed files with backups and runs a read-only template check in the current EAI project. It does not rewrite template files or UI components inside an existing app repo.

Use these commands for the full maintenance loop:

# See whether a newer CLI release, Gofer refresh, or template review is available
eai update --check

# Same report through the broader doctor command
eai doctor --check-updates

# Preview safe Gofer-managed asset updates for the current repo
eai gofer refresh --check

# Apply safe Gofer-managed file updates, with backups and conflict detection
eai gofer refresh

# Preview app-template and UI component drift before copying changes manually
eai template check

# Give an AI a read-only EAI capability adoption plan for this repository
eai template check --ai-plan --preserve-ui

Important boundaries:

• eai update --check is read-only. eai update force-refreshes only Gofer-managed files in an EAI project and backs up conflicting local versions before replacement.
• eai gofer refresh prefers the latest public eai-gofer release at runtime, so Gofer asset updates do not require a new eai CLI release. If the latest release cannot be reached or prepared, it falls back to the bundled snapshot.
• eai gofer refresh manages the Gofer-owned surfaces copied by eai init such as .specify/, .claude/, .agents/skills/, the legacy .gemini/ compatibility layout, and generated Copilot Gofer files.
• It writes or updates .eai-manifest.json so future refreshes can detect local edits. Standalone eai gofer refresh leaves conflicts untouched unless --force is supplied; eai update always uses that backed-up force behavior.
• If a tracked managed file has local edits, refresh leaves it untouched unless you explicitly pass --force, and even then it backs the file up first.
• eai template check previews file-level drift against the published app-template release pinned in the installed CLI and highlights which files are new versus which need manual review, including likely UI paths under src/app and src/components.
• eai template check --ai-plan also works in ordinary Git and JavaScript package repositories. It emits JSON with capability groups, bounded diffs, dependencies, adoption decisions, risks, and validation steps.
• AI plans preserve existing layout, styles, design tokens, content, components, and interaction patterns by default. Presentation files are references and never automatic replacements.
• AI plans are advisory and read-only. They do not install packages, execute project code, write configuration, copy files, or call EAI Platform APIs. The command can access Git to fetch the configured template revision.
• Template or UI component changes are not auto-merged into existing repos yet. Copy additions first, then diff/review existing files that eai template check marks for manual review.
• Normal eai update runs that template check automatically after Gofer maintenance. A template-check failure does not undo a successful CLI or Gofer update; the CLI reports how to retry it.
• During normal interactive CLI use, if the CLI has already cached that a newer release is available, it can ask whether to run eai update immediately. That prompt is suppressed for CI, non-TTY, --describe, --format json, and --json output.

Development

git clone https://github.com/eai-support/eai.git
cd eai
npm install
npm run build        # Compile TypeScript
npm run dev          # Watch mode
npm run typecheck    # Type check without emitting
npm run lint         # Run ESLint

Documentation and GitHub Pages

The documentation site lives in docs-site/ and renders the source content from .tech-docs/, the scenario library, and the generated command/API reference. GitHub Pages is the public deployment target for both the documentation site and the static npm registry fallback used by the install flow.

The Deploy Docs workflow builds docs-site/ on main when documentation, release-doc, registry, or LLM-help assets change. It uploads docs-site/build with the official GitHub Pages artifact action and deploys it to the github-pages environment.

Pages serves these public artifacts:

• /docs/ and /scenarios/ — documentation and scenario library
• /registry/ — static npm registry fallback metadata and tarballs
• /llms.txt, /llms-full.txt, and /cli-help.txt — release-facing AI/help surfaces generated from the current CLI

Releasing

Releases are managed with release.sh. It validates the release candidate locally, bumps the version, refreshes the release-facing docs/help surfaces, regenerates the static registry fallback artifacts, pushes main plus the annotated tag, waits for GitHub Actions to publish the npmjs packages and create the GitHub release, waits for the docs deployment that updates the static registry fallback, and then verifies npmjs plus the public static registry expose the new version.

./release.sh <patch|minor|major> "Release message"

Examples:

./release.sh patch "Fix auth token refresh bug"
./release.sh minor "Add bulk resource import command"
./release.sh major "New config format, breaking changes to types CLI"

Release prerequisites

• Run from a clean main checkout
• gh must be installed and authenticated

What release.sh validates before tagging

The script runs npm run release:check, which covers the main $6_gofer_validate style release gates:

1. Verifies you're on main with a clean working tree
2. Pulls latest and installs dependencies (npm ci)
3. Typecheck (tsc --noEmit)
4. Lint (eslint)
5. Build (tsc)
6. Test (vitest run)
   • Focused SRP CLI evidence also runs as npm run test:eai-cli:ci in GitHub Actions check ci/eai-cli-tests
7. Smoke tests — eai --version, eai --help, eai update --check, and the shipped command groups
8. Docs site build
9. Release-facing docs/help generation (llms.txt, llms-full.txt, cli-help.txt)
10. Registry artifact generation (npm pack + generate-registry.cjs)
11. The eai-cli npm alias package builds and installs the eai command
12. Static-registry fallback metadata stays aligned with the documented install flow
13. Full e2e smoke traceability stays aligned with eai --describe

Optional live full e2e smoke

release:check always validates the full command/CRUD traceability table in .tech-docs/full-e2e-smoke-traceability.md. The destructive live suite is opt-in because it creates a disposable app, publishes Object Types, provisions storage, and CRUDs PostgreSQL, DocumentDB, Blob-backed file, and Search-indexed resources in a dedicated test workspace.

Use a dedicated test user and workspace. Do not paste the password into a chat or commit it to the repo; store it in your shell only for the run, or in GitHub Actions secrets.

export EAI_RELEASE_FULL_E2E_SMOKE=1
export EAI_E2E_TEST_PROFILE=test
export EAI_E2E_TEST_USERNAME='<dedicated-test-user-email>'
export EAI_E2E_PARENT_TENANT_ID='<dedicated-test-workspace-id>'

# Authenticate the profile before the run:
eai --profile "$EAI_E2E_TEST_PROFILE" login

# Or provide a secure bootstrap command that leaves whoami working:
export EAI_E2E_AUTH_COMMAND='<secure-auth-bootstrap-command>'

npm run smoke:eai-full:live

If an external bootstrap command needs a password, pass it through an environment secret such as EAI_E2E_TEST_PASSWORD. The smoke runner redacts password-like values from failures and does not print or persist the password.

What happens after the local checks pass

1. release.sh bumps the requested semver level
2. It updates the visible .tech-docs/ release metadata to the new version and release message
3. It regenerates docs-site/static/registry/, docs-site/static/llms.txt, docs-site/static/llms-full.txt, and docs-site/static/cli-help.txt
4. It commits the release, creates an annotated vX.Y.Z tag, and pushes main --follow-tags
5. The tag-triggered GitHub Actions Release workflow verifies the committed release docs/help surfaces, publishes @enterpriseai/cli and eai-cli to npmjs with trusted publishing, then creates the GitHub release and attaches the packaged tarballs
6. The Deploy Docs workflow publishes the matching static registry fallback and release-doc bundle to GitHub Pages
7. release.sh waits for both workflows and verifies npmjs plus the canonical @enterpriseai/cli static fallback

If npmjs or the static registry fallback does not converge to the new version, the script exits non-zero so the release is treated as incomplete.

The EAI CLI is also part of SRP release evidence. Repo-local CLI behavior is owned here through ci/eai-cli-tests; deployed read-only CLI schema, error, auth, and preview canaries live in enterpriseaigroup/eai-testing-dev under the eai-cli cross-service surface. Keep prod CLI canaries read-only; preview lifecycle checks must stay explicit and cleanup-backed.

The release path publishes the repository exactly as committed. Bundled Gofer and linked-source refreshes happen separately via npm run sync:gofer / npm run sync:linked-sources and should be committed before you cut a release. At runtime, eai gofer refresh still checks the public latest eai-gofer release and falls back to that bundled snapshot when offline.

Before making or keeping the repository public, run a public-readiness check:

npm run release:check
git grep -n -E "SECRET|TOKEN|PASSWORD|PRIVATE KEY|CLIENT_SECRET|API_KEY|connection string|AccountKey|Bearer "

GitHub secret scanning and push protection should also be enabled for the repository so accidental credential commits are blocked or alerted before they become a public incident.

Helpful maintainer commands:

npm run docs:release-assets
npm run docs:release-assets:check

Release channel policy

• npmjs is the primary release and update channel
• Recommended install: npm install -g eai-cli
• Canonical package install: npm install -g @enterpriseai/cli
• Static fallback: npm install -g @enterpriseai/cli --@enterpriseai:registry=https://eai-support.github.io/eai/registry/
• Persistent fallback setup: npm config set @enterpriseai:registry https://eai-support.github.io/eai/registry/ --location=user
• Use eai update to update the installed CLI and refresh safe project assets

Documentation

Full documentation: https://eai-support.github.io/eai/

93 pages covering getting started, guides, concepts, command reference, 50 industry scenarios, and examples in 7 languages.

Roadmap

• eai types define — interactive Object Type builder
• eai dev --offline — local mock gateway for offline development
• eai tunnel — Cloudflare tunnel for webhook testing
• npmjs install alias (npm install -g eai-cli) with static registry fallback

Bundled Gofer assets stay pinned to v3.14.3 and include the support-only patch from eai-gofer#433 until its release. Regenerated entrypoints include the existing Gofer 3.12.7 to 3.14.3 generator drift.