Changelog

Changes in omm and the SDK @orbito/api-lib that matter when you build a module, newest first. Entries marked Breaking need a change in your commands or code.

omm

Update: npm i -g @orbito/omm.

omm 2.1.2 (2026-10-25)

• omm warns when the core address is the old https://v2.orbito.pl/api (saved by omm login, from OMM_CORE or --core): every command that uses the core prints a core notice ({"kind": "core", ...} in notices with --json) with the fix omm login --core https://my.orbi.do/api. The notice needs no network, so it is shown also offline and with OMM_NO_UPDATE_CHECK=1.
• The Access forbidden error after the redirect gets the same hint, and the core-login check of omm doctor reports the move as warn.
• The agent skill tells the agent to inform the human about the move, have them log in again with omm login --core https://my.orbi.do/api and update v2.orbito.pl in their project after they confirm. Run omm skill install to get it.

omm 2.1.1 (2026-10-25)

• The Orbito panel and API moved to my.orbi.do; the old v2.orbito.pl redirects there. The default core address of omm is now https://my.orbi.do/api.
• A saved omm session keeps the core address it was created with. If yours points to https://v2.orbito.pl/api, run omm login --core https://my.orbi.do/api once. The old address answers with a 308 redirect, but fetch drops the Authorization header when the origin changes, so authenticated calls through the redirect fail with 403 Access forbidden.

omm 2.1.0 (2026-10-16)

• omm solution publish [dir] | list | unpublish <slug>: business solutions, curated sets of published modules with automation templates that a company installs in one click (the automations land as disabled drafts). Only members of the core namespace (Orbito) can use them; anyone else gets 403 with a hint to check omm whoami. The solution directory holds solution.yaml, an optional README.md and cover, and automation files in the omm automation create -f format without params.__instanceId. See Business solutions (Polish).

omm 2.0.0 (2026-10-15)

• Breaking: one Orbito account. The registry has no passwords of its own: omm login signs in to Orbito Core with the e-mail and password of the Orbito account (v2.orbito.pl), saves the core session and, with the same session, creates a publish token in the registry. One login fills both; omm login --core is no longer a separate step (--core <url> only picks the core address). After updating, run omm login again.
• omm login --token <core JWT> logs in to both; omm login --token omm_... (CI) to the registry only. omm logout revokes the publish token and removes the core session too.
• Breaking: modules belong to namespaces, not to developer accounts. The module code is <namespace>/<slug>; every member of the namespace can create, publish and configure its modules, only the owner manages members. Existing codes do not change (Orbito's own modules are in the core namespace).
• New omm namespace list | create <name> | members <name> | invite <name> <email> | remove <name> <email>. An invitation for an e-mail that never used the registry turns into membership on that person's first login.
• omm init --namespace <name>: the namespace of the new module card; required (with --json) when the account has several. Without any namespace omm init fails with omm namespace create <name> as the fix.
• omm whoami --json prints { registry, id, email, name, namespaces: [{ id, name, role }] }; the registry-login check of omm doctor warns when the account has no namespace.
• Breaking: omm company dev-token and the company dev-token are removed. Drafts are visible and installable for members of the module namespace in any company they belong to; the first omm install / omm update of a draft grants that company access for good. Other companies get access in the developer panel. The 404 hint of install / update now points to namespace membership (omm whoami).
• omm repo links are visible to every member of the module namespace.

omm 1.4.0 (2026-10-14)

• omm repo, omm repo set [url] (default: git remote get-url origin without credentials), omm repo unset: the git repository link of the module card.

omm 1.3.0 (2026-10-14)

• omm automation: automations of the working company without the web panel (see Company automations):
  • list [--enabled|--disabled] [--query <text>], get <id> (graph and validation),
  • elements [--kind trigger|action] [--query <text>], element <type> (full definition as JSON),
  • create -f <file> (always a disabled draft; -f - reads stdin), update <id> -f <file> (never changes isEnabled), enable <id>, disable <id>, duplicate <id>, delete <id> --yes,
  • runs [--automation <id>] [--status <status>] [--event <value>] [--limit <n>], run <runId> (steps with branch and outcome),
  • var list, var get <key>, var set <key> <value>.
• create and update are validated by the core as a whole graph; a rejected graph fails with 422 Automation graph is invalid.
• --json errors carry validation when the server sends it (for automations: validation.errors as [{ path, code, message }]).
• install.sh (live since 2026-10-13) checks the global npm directory before npm i -g; when it is root-owned (EACCES) it stops with two fixes (sudo for the install step only, or a user-owned npm prefix) and never runs sudo itself.

omm 1.2.0 (2026-10-13)

• omm skill install [--project] [--all] [--agent <name>...] [--no-npm]: installs the skill for Claude Code, Codex and OpenCode and saves the @orbito scope line in the npm config. Works on Windows, macOS and Linux; with no sh at hand run npm i -g @orbito/omm --@orbito:registry=https://git.kozminski.net.pl/api/packages/orbito/npm/ and then omm skill install.
• install.sh is now a thin wrapper: it sets the @orbito npm scope, runs npm i -g @orbito/omm and then omm skill install with the same options. The curl -fsSL https://orbito.pl/docs/skill/install.sh | sh line still works on Linux and macOS.
• The fix in the outdated-skill notice and in omm doctor is now omm skill install (project copies: omm skill install --project) instead of curl … | sh.

omm 1.1.0 (2026-10-13)

• Update notices: once a day omm checks for a newer omm, a newer @orbito/api-lib than the one in package.json of the module in the current directory, and a newer skill. Notices go to stderr after the command result (text: lines starting with !; --json: one line {"notices":[…]}), so stdout stays the clean result. OMM_NO_UPDATE_CHECK=1 turns the check off.
• omm doctor [--json]: forces the check and runs the checks node, omm, npm-scope, registry-login, core-login, company, module and skill:<agent>. With --json it prints { checks: [{ name, status: ok|warn|fail, message, fix }], notices }; it exits with 1 only when a check fails.
• OMM_PACKAGES_REGISTRY overrides the npm registry of the @orbito packages (update checks and the npm-scope check).

omm 1.0.1 (2026-10-13)

• omm install and omm update failing with 404 suggest omm company dev-token (in --json as hint next to error and status). Removed in 2.0.0.
• Drafts are installable only in companies holding the author's dev-token. Run omm company dev-token --json once per test company before the first omm install of a draft; published versions do not need it. Replaced by namespaces and company access in 2.0.0.

omm 1.0.0 (2026-10-13)

• Breaking: omm dev and omm dev unlink are removed, together with omm.config.js, .omm-dev.json and .env loading. Test a module as a draft instead: omm publish, omm install, omm update (see The build loop).
• New core commands, the build and test loop without the web panel:
  • omm login --core [url], omm login --core --token <jwt>, omm whoami --core, omm logout --core,
  • omm company list, omm company use [id], omm company dev-token [uuid] (removed in 2.0.0),
  • omm install [--name <name>], omm update [--instance <id>] (same version: reloads the instance with the fresh draft image), omm instances,
  • omm logs [--since <iso>] [--day <YYYY-MM-DD>] [--container], omm problems [--status <status>],
  • omm call <method> [--params <json>].
• omm init <name> creates the module card in the registry and scaffolds the module from the built-in template (--code, --dir, --description).
• --json on every command: the result as JSON on stdout, errors as { "error", "status" } on stderr with a non-zero exit code.
• Command help in English.

@orbito/api-lib

Update in the module: set the version in package.json dependencies, run npm install, then publish a draft and check it as usual.

@orbito/api-lib 4.3.0 (2026-10-06)

• Core.getCompany(): the profile of the company the container serves (name, timezone, address, tax data). timezone is always filled (IANA name, Europe/Warsaw by default). Nothing is cached; fetch it when you need it.
• Time namespace: Time.inZone(timeZone) returns date helpers for a time zone (parseDate, formatDate, dateBoundary, addCalendarDays); Time.forCompany() does the same for the company's time zone.
• Call origin: entries added with History.add inside an automation action, or inside a method or hook handler reached from one, are shown in the panel as performed by that automation. No code changes; handlers can read this.origin / ctx.origin (null outside automation runs).

@orbito/api-lib 4.2.0 (2026-10-06)

• OAuth.createTicket(): a one-time ticket for an OAuth callback handled by the core. The module gets { state, redirectUri, expiresAt } and builds the provider's consent URL; after the redirect the core calls the module's finish method in the user's context.

@orbito/api-lib 4.1.0 (2026-09-30)

• Docs.register(): markdown documents with the module's domain knowledge (statuses, terms, dependencies) for the company's AI assistant. A new set replaces the previous one.

@orbito/api-lib 4.0.0 (2026-09-29)

• Breaking: keys in trigger emits, action requires and template variable group requires are KEY (owned by the declaring module) or <moduleCode>:KEY (another module's key, prefix mandatory). A malformed key throws at registration. To migrate: prefix every key of another module (ORDER_ID in a shipping module → 'core/orders:ORDER_ID'), send callTrigger params under the same keys as in emits, and read other modules' keys from ctx.event.params with the prefix.
• Templates.registerVarGroup(): groups of variables for message templates, resolved by the core.