dlake release notes

0.5.45 (2026-09-25)

--help works without a profile. Every command prints its help without --profile,
including dlake admin <tool> --help, dlake tool <tool> --help, view list, s3 ls,
docs list, export and status. For the admin and tool passthroughs, a tool's live
argument schema comes from the MCP host, so it is shown when a profile is given; without one
you get the generic help for the verb and a line saying so.
Windows install notes. The README has a Windows PowerShell section: the one-time
execution-policy setting npm's command wrappers need, the install line that allows the
package's download step (npm install -g --allow-scripts=@commercient/dlake @commercient/dlake),
and quoting @file arguments (--columns "@columns.json"), since a bare leading @ is
PowerShell's splatting operator.
A clearer message when the binary is missing. If npm skipped the package's download step,
the first command now says so and names the fix: the allow-scripts install line above, or
npm rebuild @commercient/dlake.
create_table refuses column properties it does not use. A column property outside the
table column shape used to be ignored, so a maxLength became an unbounded column. It is now
refused with the column, the allowed properties and the one you probably meant (maxLength
and length are size, dataType is type, isNullable is nullable). A size on a
numeric type, or precision/scale on a string type, is refused the same way. add_column
and alter_column follow the same rules. The README's app walkthrough now lists the full
column shape with a worked columns.json, and labels the procedure-parameter example as
such.
Scoped keys remind you to restart DAB. create_api_key with a scope now ends its
message with the same restart guidance create_table gives, and returns
restartNeeded: true: the key's per-key role takes effect after restart_dab.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake; add
--allow-scripts=@commercient/dlake if your npm skips install scripts), then run
dlake skills install to refresh the bundled agent skills.

0.5.44 (2026-09-25)

New: dlake registration pin --crm <name>. For CRMs whose connection ends in a PIN, the PIN
is e-mailed to your registration e-mail address; this command confirms it and connects the CRM,
after which step 4 is finalized with dlake admin registration_crm_finalize. The PIN is read
hidden from the terminal, or from stdin with --pin-stdin, and is never echoed. A plain
--pin <value> is refused, so the PIN does not end up in your shell history.
dlake registration oauth tells you what comes next. After the exchange it says whether
the CRM is connected (finalize next), needs a selection (registration action) or is waiting
for the e-mailed PIN (registration pin). For a CRM whose callback goes to the platform, the
command now waits for the code to arrive and completes the handshake itself, instead of leaving
the polling to you.
Clearer sign-up refusals. When dlake register start is refused, the reason now comes
with its code and a next step: an e-mail address that already has an account points you at
dlake register login, a company name that is taken asks for a different --company, and a
password the portal will not accept points you at --generate-password. --json output
carries the code. The registration commands print the refusal code too, with a next step
where there is one.
dlake register status shows where the setup wizard stands: the last completed step, the
step to work on next, the provisioning status and, while it waits for provisioning, the
submitted connector type. Against an older Registration API the output is as before.
Product licence status. dlake registration products list has a STATUS column showing
each product's licence status (licensed, installed or removed); removed products are
still listed, and a product type only your own database knows is marked "(not catalogued)".
A product registered for a different ERP than yours now comes with a warning, printed on
stderr by products list and products add. --json output is unchanged apart from the
new fields.
New: --field Name=Value. registration oauth, registration action and any
dlake admin tool with a single object argument (such as a wizard step's --fields) take a
repeated --field, each setting one value over the --fields JSON. Name=@path reads the
value from a file, the easy way to pass a Windows path or a password. A name given twice is
refused.
The dlake register help now says the starter key you receive when your Data Lake is seeded
lasts seven days.
Skill corrections: the CRMPro skill no longer says that importing a template fills in the
process's field list, and the integration-setup skill now ends with the sync-agent products
step that follows provisioning.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake), then run
dlake skills install to refresh the bundled agent skills.

0.5.43 (2026-09-22)

New: dlake backup. Restorable backups of your Data Lake's DLO schema: a native SQL
Server backup file of a database holding only DLO — tables and their data, views, functions,
procedures, triggers, row-level security, sequences and synonyms. backup run makes one now,
backup list and backup show <id> list and inspect them (object counts, warnings and the
restore statement), backup download <id> [--out <path>] downloads one and checks its SHA-256,
and backup settings [--enabled on|off] [--schedule weekly|daily|off] [--include-sync-tables on|off]
chooses whether and how often they are made, and what they hold. Weekly by default; backups are
kept 30 days.
On shared SQL servers the temporary backup database is created, backed up and removed by a
dedicated backup creator login that may create databases and nothing else; your Data Lake's own
login still makes the copy of your data, so the creator never reads it. An "insufficient
rights" result now says which of the two logins is missing a right.
Connector-fed tables are backed up as schema only by default. Tables a connector sync
writes are rebuilt from their source systems and are usually most of a Data Lake's volume, so a
backup now keeps their structure (columns, keys, indexes, constraints) without their rows; your
own tables, views and procedures are backed up in full. backup show lists the schema-only
tables with the rows each held. backup settings --include-sync-tables on includes their rows
for a self-contained copy.
Platform log tables are always backed up as schema only. The platform's own audit logs,
notifications, run history and event queues keep their structure in the backup but not their
rows, whatever --include-sync-tables says: they record what happened rather than hold your
data, and they start empty after a restore. backup show lists them separately.
The pre-backup space check now counts only the data that will be copied, and a refusal shows
what the room is for: the temporary database, the backup file and headroom, with the connector
data and the platform log data left out reported as separate figures.
Every command after sign-in now goes through the MCP host. keys, projects, query,
export, docs, s3, view, login and status no longer need any other Commercient host,
so the CLI works from any network. dlake login checks your key with one call before it saves
anything: a key that is valid but not a full-scope Admin key is saved for the data plane, and a
rejected key saves nothing. No sign-in token is cached any more; the old token cache is removed
on first run.
dlake s3 and dlake view show|create|alter|drop now need a full-scope key owned by an Admin
user, as dlake keys and dlake projects do. Scoped keys and non-admin users can still use
query, export, docs, tool and view list. This is a temporary restriction for s3 and
the view changes, until they have data-plane equivalents.
dlake view list now lists the views exposed through the Data API that your key can see, with
each one's type and field count; dlake admin list_views still lists every view for admins.
Document uploads are capped at 10 MB. dlake docs upload refuses a larger file before
sending anything.
dlake s3 put and dlake s3 get move files over 8 MB straight between your machine and your
bucket through a short-lived link. dlake s3 ls pages with --token.
Changed JSON output. dlake status --json, dlake login --json and
dlake profiles list --json no longer carry authUrl or apiUrl. status --json reports the
MCP host, the Registration host and whether your key was accepted and on which planes;
profiles list shows each profile's MCP URL. --auth-url and --api-url on dlake login
are accepted and ignored for this release.
dlake watch checks the MCP host, the sign-up catalog and the published downloads (plus, with
--profile, a live query); --tenant-host is accepted and ignored for this release.
Fixed: -o <file> on dlake export and dlake docs get now writes to the file you name.
Portable backups. backup settings --format portable|native|both adds a portable package
(a .bacpac) that restores onto any SQL Server 2016 or later, including Express and Azure SQL,
while the native file stays exact for same-or-newer servers; backup show reports the formats a
backup holds and the oldest server each restores to, and backup download --format picks one.
With both, a portable half that cannot be produced does not fail the backup: the native file
is kept and the reason is recorded.
Choose what a backup holds. backup scope sets, per table, full data, schema only or
excluded, and switches code objects (views, procedures, functions, triggers) on or off; platform
tables keep a protected floor. Portable packages take the tables their foreign keys need.
Backups are consistent to a moment. On SQL Server editions that support it, the copy is taken
from a database snapshot, so every table reflects the same instant; backup show reports
point-in-time or per-table and why. Only one backup runs per Data Lake at a time.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake), then run
dlake skills install to refresh the bundled agent skills.

0.5.42 (2026-09-22)

New: dlake audit retention show and dlake audit retention set <days>. Row-change
history is recorded by the DML audit triggers, which store a full copy of every affected
row, so it grows with how much is written. Retention gives it a floor: 90 days by
default, anything from 7 to 3650 days, and 0 to turn the purge off and keep rows
indefinitely. show says which window is in force and whether it was chosen or is the
default. A change applies on the next daily sweep, and sync-fed and platform tables are
never audited at all, so it governs your own tables' history.
New: dlake audit purge and dlake audit purge --run. A bare purge reports how many
row-change entries are outside your retention window and how many megabytes they hold, and
deletes nothing; --run removes them now instead of waiting for the nightly sweep, with the
same batches and time limit. A purge is refused while retention is 0.
New: dlake storage show, dlake storage sweep [--shrink] and
dlake storage shrink-enabled on|off. Deleting rows does not make a database smaller, and
storage is billed per gigabyte, so a weekly storage sweep now measures every database file and
releases the free space: data files are trimmed to what they hold plus headroom (and the
indexes a trim fragments are rebuilt), and the transaction log is shrunk firmly because Data
Lake databases use simple recovery. show prints each file's size, used and free space,
autogrowth and what a sweep would do; sweep measures now and reports, and --shrink releases
the space once the platform has armed the sweep; shrink-enabled off excludes your database.
The sweep reports by default and never changes autogrowth.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake), then run
dlake skills install to refresh the bundled agent skills.

0.5.41 (2026-09-22)

dlake registration hosting show now reports the engine's run-state. An express Data
Lake's gateway database runs on a container of its own, and the new Engine: line says
whether that container is running, stopped or missing. A stopped engine is a resting
state rather than a fault — it stands down while nothing is using it and comes back on the
next request — and the line says so, so there is nothing to restart by hand. The line
appears for express hosting only.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake), then run
dlake skills install to refresh the bundled agent skills.

0.5.40 (2026-09-19)

Hosting now defaults to express for every registration. A Data Lake's gateway database
lives on a SQL Server 2025 Express container dedicated to it, provisioned when the Data Lake is
seeded, and dlake registration hosting set express records that choice explicitly. The command
reference, the help pages and the bundled skills describe it that way.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake), then run
dlake skills install to refresh the bundled agent skills.

0.5.39 (2026-09-19)

New: dlake registration hosting show and dlake registration hosting set express|standard.
A Data Lake's gateway database lives either on a dedicated container host (express) or on the
shared SQL instance (standard). show reports which one applies, whether it was chosen or
followed from the sign-up — a Data Lake only sign-up gets express, an integration standard —
whether the choice is still open, and, for an express Data Lake, where its container stands.
set makes the choice yours. It is fixed once the Data Lake is seeded.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake), then run
dlake skills install to refresh the bundled agent skills.

0.5.38 (2026-09-18)

dlake registration products list now shows whether the customer's Sync Agent installer
access is granted. The listing reports where that access stands alongside the registered
products, so it no longer has to be inferred from the last call that set it.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake), then run
dlake skills install to refresh the bundled agent skills.

0.5.37 (2026-09-17)

New: dlake registration products allow-sync-agent on|off. Grants or revokes a customer's
access to the customer portal and the Sync Agent installer. Until it is granted the installer
will not run for that customer; this verb also withdraws it. It accepts on/off, true/
false and yes/no, and needs the customer's sign-up to have reached step 5.
dlake registration products request-install now grants that access too. Asking for the
agent install no longer leaves the installer refusing the customer: the request grants the
access in the same call and the verb says so, or says so when the grant did not go through.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake), then run
dlake skills install to refresh the bundled agent skills.

0.5.36 (2026-09-17)

Skills: community templates are now part of every page. Each destination skill's source-system
pages describe the community templates the catalogue carries for that pair alongside the shipped
defaults, and a pair that ships only community templates now has a page of its own. The bundled
skills carry 488 source-system pages, up from 330; the HubSpot skills grow the most, to 67 pages
for TxDownloaderPro and 89 for CRMPro.
Skills: HubSpot default templates for 56 more source systems. The template catalogue now ships
HubSpot defaults for every source system that had them for another CRM, and the pages reflect it.
Skills: every process row carries its name. Process versions that were listed by an internal
identifier now show their process name.

No changes to commands, authentication or output formats. Run dlake skills install after
upgrading to refresh the installed skill files.

0.5.35 (2026-09-12)

Fixed: registration completes against the current Registration API. Sign-up now asks
for the first API key at the moment it is needed instead of picking it up from a status
check. The service no longer hands that key back on a status check, so an earlier CLI waits
for a key that never arrives and registration never finishes. 0.5.35 works against both the
current service and an older one, with nothing to configure; against the current service it
is the version you need to register.
New: agent skills are organised by destination, with a page per source system. The
twenty bundled skills now carry their own child pages — one for each source system a
destination supports, 330 in all — so an agent reads the skill for the destination and then
the page for the system the tenant actually runs. dlake skills list shows how many pages
each skill carries, dlake skills show <skill>/erps/<source> opens one, and
dlake skills install writes the children alongside the skill.
dlake admin says out loud what a generation did not publish. When a DAB generation
leaves an entity out, the affected entities and the reason for each are now printed after
the result instead of sitting several screens down in the payload. Machine-readable output
is unchanged.
A waking tenant reads as a waking tenant. A tenant's Data API scales to zero when idle,
and the first call while it comes back up now says so and suggests retrying, rather than
reporting a bot-verification page or a bare handshake failure.
dlake txdownloaderpro errors and transactions point at a command that exists when the
process id is missing.
Help and the CLI reference now state that a delete on a concurrency-protected table flags
the row rather than removing it, and give the filter for active rows.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake), then run
dlake skills install to refresh the bundled agent skills. Run it without
--skip-existing — the skills were reorganised in this release and every one of them
changed.

0.5.34 (2026-09-09)

New: dlake registration products — say what the customer's Sync Agent should run. The
sign-up wizard waits for an agent to appear but never decides which products it runs. These
verbs list, register and remove them, and ask for the agent to be installed: products list
(which also prints the accepted product names, several of which cannot be guessed), products add <id-or-name> [--request-install], products remove <id> and products request-install.
Registering is idempotent and removal is soft, so a removed product still shows in the list
marked as removed.
New: dlake crmpro log — read the sync agent's own log. The error view and the agent's
self-report were already there; this is the log the sync actually wrote. --grep searches it
(--regex for a regular expression), --tail and --page choose how much comes back, and
--source-page reads it in source order.
New: dlake txdownloaderpro — the TxDownloaderPro transaction log. errors <processId>
groups failures by business key and shows which of them eventually got through; transactions <processId> is the attempt grid with a date window, a status filter and free-text search; and
transaction <recordId> opens one attempt with the request and response payloads.
Log output is bounded, and says so. These logs run to hundreds of thousands of lines, so
every log command returns a window — by default the most recent 100 matching lines, or 25 rows
— and reports how many lines or rows matched in total, so a narrow view is never mistaken for a
short log. Narrow it with a search rather than paging through everything.
--out <file> writes the whole thing to a file. dlake crmpro log --out sync.log and
dlake txdownloaderpro transactions <id> --out rows.jsonl save the complete, unfiltered result
and print a single line saying where it went and how big it is.
The new commands are also available to agents and MCP clients as tools on the admin control
plane, with the same filters and the same bounds.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake), then run
dlake skills install to refresh the bundled agent skills. Run it without
--skip-existing — that flag leaves your earlier skill files in place, and the CRMPro,
TxDownloaderPro and Sync Agent skills all changed in this release.

0.5.33 (2026-09-08)

New: dlake watch — a live monitor that tells you when something breaks. It polls the
surfaces your Data Lake depends on (both APIs, the Data API plane, the sign-up catalog and the
published CLI downloads, plus — when you name a tenant — your Data Lake's web app, its three
planes and a live SELECT 1) and prints a status table each cycle with state, latency and the
reason for any failure.
Alerts fire on changes, not on every cycle. When a check goes from healthy to failing, or
recovers, watch prints a timestamped line, raises a desktop notification (Windows, macOS or
Linux) and rings the terminal bell. A single failed probe is absorbed; two in a row declare a
check down, and one success declares it back. A check that has been down for an hour does not
keep alerting.
--webhook and --log for unattended use. Each transition can be posted as a small flat
JSON document — with a ready-made text field, so it reads correctly in Slack or Teams — and
appended to a file, one JSON object per line.
--once for schedulers. One cycle, then exit 0 if everything passed and 1 if anything did
not, so cron or Task Scheduler can act on the result. --json prints one document per cycle,
--quiet prints only transitions.
Every default check is anonymous and read-only; the authenticated SELECT 1 runs only when you
pass --profile. Nothing is stored and there is no config file.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake).

0.5.32 (2026-09-07)

New: dlake register erps lists the instance types sign-up accepts. It needs no account and
no key, so you can run it before you register, and it prints the display name alongside the
machine code.
register start --instance-type now takes either the code or the display name, in any
casing, and sends the code. A value that is not in the catalog is refused before the account is
created, instead of failing at the server, so a typo can no longer register you against the
wrong ERP. Omitting the flag is unchanged — that remains the right choice for a standalone
Data Lake.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake).

0.5.31 (2026-09-06)

Fix: the CLI no longer follows HTTP redirects and never sends credentials to a host other
than the configured API host. A redirect is reported as what it is — something answering in
place of the API — instead of being followed, and every request that carries your API key or
token is checked against the endpoints your profile is configured with before it is sent.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake).

0.5.30 (2026-09-04)

dlake skills install now refreshes existing skill files. Installing over an earlier copy
updates it in place and reports each file as created, updated or unchanged. The previous
behaviour, leaving existing files alone, is available with --skip-existing; --force is still
accepted and has no effect.
Every agent skill now tells the agent to check for a newer dlake first. Updates are frequent
and the skill text ships inside the CLI, so each skill opens with the two commands that confirm
you are on the latest version and refresh the installed copies.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake).

0.5.29 (2026-09-04)

CRMPro agent skills: corrected change-detection guidance. The dlake-crmpro and
dlake-crmpro-hubspot skills now state the source-view change-detection rule correctly: a
record with no saved cursor counts as changed. A view written to the previous example could
leave records created on the first run permanently un-updated. The HubSpot skill also
documents the three source-view kinds, the properties a record needs at creation, and the
rowversion pattern for views that join several tables.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake).

0.5.28 (2026-08-29)

Tool listings now tell you what your key can actually use. The Help and
API guides, the CLI reference and the dlake agent skill no longer quote a
fixed number of admin or data-plane tools: what is available depends on the
key you are signed in with, so dlake admin list and dlake tool list are
the answer — run either one to see your own surface.
Both npm packages now link to the product overview from their README and
registry page.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake).

0.5.27 (2026-08-27)

New agent skill: dlake-crmpro-hubspot. The HubSpot specifics of a CRMPro
forward sync, in one place: the configuration a HubSpot process needs, what its
source view must provide, the seed-then-upsert pair that lets some fields stay
CRM-owned while the rest follow the ERP, the field-list rows an object needs
before it will push anything, and the checks to run when a sync finishes
without writing records. Read it with
dlake skills show dlake-crmpro-hubspot, or install all nine with
dlake skills install.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake).

0.5.26 (2026-08-27)

The Sync Agent guidance now states that available commands vary by agent
build: try a command as written, and where a build prompts instead of
accepting a flag, work through it interactively — --help on that machine
is the authority on the form it takes.
The db_owner requirement for the Normal Sync source login is now in the
Help and CLI guides as well as the agent skills.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake).

0.5.25 (2026-08-27)

Normal Sync and CRMPro guidance, considerably expanded. The agent skills
now spell out what a CRMPro source view has to contain and how to build one
that syncs — the identity and change-detection joins, key formats, process
naming, and the value rules each destination CRM enforces (currency codes,
email addresses, dates). Reading dlake skills show dlake-crmpro before
building a process is now the short path.
The Normal Sync guidance states the source SQL login needs db_owner on the
ERP database, and why a read-only login passes the connection test but
cannot sync.
Upgrade: npm install -g @commercient/dlake (or npm install -g datalake).

0.5.24 (2026-08-26)

New: Normal Sync resync. dlake normalsync resync --confirm asks the
on-premises agent to re-pull every synced table on its next run;
--table <name> queues a single table (SYSPRO custom tables like
ArCustomer+ are fully supported), and --clear discards the queued list.
Nothing is deleted or dropped — the agent does the work.
New: dlake normalsync resync-status. Shows what is queued, plus clone
coverage: the rows actually present in each clone table against the count
recorded at the last sync — the quickest way to see whether a sync actually
moved data, per table.
The same operations are available to AI agents as four new admin tools, and
the Normal Sync guide and skills cover them. Upgrade:
npm install -g @commercient/dlake (or npm install -g datalake).

0.5.23 (2026-08-26)

Documentation refresh: the npm package README now describes all eight bundled
agent skills, including dlake-syncagent.
No functional changes. Upgrade:
npm install -g @commercient/dlake (or npm install -g datalake).

0.5.22 (2026-08-25)

Clearer package listing on npm: @commercient/dlake now opens by describing
what the CLI and the platform actually do, with a first-run example, rather
than starting with installer internals. Both packages also carry a fuller set
of keywords, so the CLI is easier to find when searching npm for ERP and CRM
integration, sync, and SQL Server tooling.
No functional changes. Upgrade:
npm install -g @commercient/dlake (or npm install -g datalake).

0.5.21 (2026-08-25)

New agent skill: dlake-syncagent. Installing and configuring the
Commercient Sync Agent — the Windows agent that runs on your own ERP server and
actually reads your source data. Covers signing in, listing your licensed
products, installing one, configuring it per product type, testing the
connection, and reading the agent's health, using the scriptable
CommercientSyncAgentCLI.exe. It is the on-premises companion to the existing
skills, which cover the platform side. Read it with
dlake skills show dlake-syncagent, or install all of them with
dlake skills install.
The Help guide and the CLI reference gained a Sync Agent section covering the
same ground, including the install-and-test sequence and the exit codes worth
branching on in a script. Upgrade:
npm install -g @commercient/dlake (or npm install -g datalake).

0.5.20 (2026-08-25)

New: --generate-password on dlake register start. The CLI can now mint
the portal password for you: a strong 20-character password that meets the
portal's password policy, printed once so you can save it. Recommended for
headless and scripted registrations — the password never touches argv or shell
history.
Password checking moved up front. register start now validates the
password before submitting and, if it refuses, names exactly which characters
or rules to fix. The portal password is 8–32 characters: letters, digits and
! # $ % & * ? @ _ only, with at least one uppercase, one lowercase, one digit
and one of those specials.
The Help guide, CLI reference and the registration agent skill were updated to
match, including the headless registration recipe. Upgrade:
npm install -g @commercient/dlake (or npm install -g datalake).

0.5.19 (2026-08-22)

Corrected bundled agent-skill guidance. The dlake-apisync skill shipped in
0.5.18 showed an endpoint-configuration example that could not work: the
configuration-JSON call omitted the object name, which the platform requires on
every save. The skill now says so and both examples include it. If you scripted
from the 0.5.18 example, add --objectName <name> to the JSON call.
The sync skills now point at each other. dlake-normalsync and
dlake-integration-setup name dlake-odbcsync (sources that are not
Microsoft SQL Server) and dlake-apisync (API sources), so an agent working on
one part of a setup can find the skill for the next part.
dlake admin apisync_save_endpoint_config now asks for --objectName up front
and says what is missing, instead of the platform rejecting the call afterwards.
The CLI reference gained sections for both sync surfaces, and the Help and API
guides were corrected to match. Upgrade:
npm install -g @commercient/dlake (or npm install -g datalake).

0.5.18 (2026-08-21)

New: ODBC Sync setup from the CLI. Eight odbcsync_* admin tools configure
the sync agent for sources that are not Microsoft SQL Server: the S3 bucket
registry, the bucket's IP allow-list (the step without which the agent cannot
upload), the agent's configuration file, and two verification reads (what the
agent has staged, and the last 24 hours of errors).
```
dlake admin odbcsync_status
dlake admin odbcsync_register_bucket --bucketName <name> --confirm true
dlake admin odbcsync_allow_ip --bucketName <name> --ipAddress <ip> --confirm true
dlake admin odbcsync_read_agent_config
```
New: Generic API Sync setup from the CLI. Six apisync_* admin tools turn
the API-source sync product on and describe the endpoints it calls: enable
(idempotent), endpoint configurations, the per-ERP endpoint-template catalogue,
and a hosted customer's real ERP table columns.
```
dlake admin apisync_status
dlake admin apisync_enable --confirm true
dlake admin apisync_templates --erpName <erp>
```
Every new tool is Admin-only (reads included), acts only on the key's own
tenant, and shows its argument schema with dlake admin <tool> --help.
Two new bundled agent skills — dlake-odbcsync and dlake-apisync —
teach an AI agent both surfaces, including the ordering and the traps (the
config editor's encrypted settings; the endpoint save's two modes).
The Help and API guides gain matching sections. Upgrade:
npm install -g @commercient/dlake (or npm install -g datalake).
If your MCP client was already connected, restart it (or re-add the connector)
to see the new tools — the tool list is cached per session.

0.5.17 (2026-08-21)

Updated bundled agent skills. The integration-setup skill now gives an AI
agent much firmer guidance through the CRM OAuth step:
- which callback style to use per CRM (HubSpot always uses the website
  flow - no local listener needed, and the browser can be on any machine);
- completing the token exchange promptly once the authorization lands
  (authorization codes are short-lived);
- that confirmation PINs arrive by email after the exchange completes -
  they are never shown on screen;
- asking you before deferring a CRM connection or submitting placeholder ERP
  credentials, and saying clearly when a setup will not sync yet.
The npm packages (@commercient/dlake and the datalake alias) now link
the GitHub repository and the browsable skills folder from their pages.
No CLI command changes. Upgrade: npm install -g @commercient/dlake
(or npm install -g datalake).

0.5.16 (2026-08-19)

New: dlake normalsync — choose which of your ERP tables get synced, from the
command line. Normal Sync is the on-premises agent that copies changed rows
out of your ERP database and into your Data Lake; this group is the table
selection for it:

dlake normalsync tables                 tables you could add
dlake normalsync selected               tables you have added, and their settings
dlake normalsync readiness              is the sync actually set up, and if not why
dlake normalsync select <table> <id>    add a table to your sync
dlake normalsync enable | disable <table> <id>   turn one table's sync on or off
dlake normalsync filter <id> --where "<sql>" --confirm   sync only some rows
dlake normalsync filter <id> --clear --confirm          sync the whole table again
dlake normalsync catalog <table> --confirm   register a table name for your ERP
dlake normalsync add <table> --confirm      register it and add it in one step

catalog, add and filter need --confirm, and the command stops before
doing anything if it is missing. Two of those are worth the extra keystroke:
the table register is shared by everyone using the same ERP and nothing can
remove an entry from it, and a row filter is run against your ERP database by
the on-premises agent exactly as you wrote it.

The same operations are still available in full. Every verb has a longer
form as dlake admin normalsync_<name>, with --help for its arguments;
dlake admin list names them.
Normal Sync commands need the Admin role. The API key has to belong to a
user who holds Admin on the tenant. If it doesn't, the command says so plainly
and exits 3; nothing is changed.
Adding tables is not the same as syncing them — dlake normalsync readiness
reports what is still missing, including the parts (the agent install and your
ERP connection details) that these commands cannot set.
The bundled Normal Sync guide (dlake skills show dlake-normalsync) and the
CLI reference ship updated in this version. Upgrade:
npm install -g @commercient/dlake

0.5.15 (2026-08-19)

Maintenance: corrected the download-host URL in the bundled guide's install
example and refreshed package links. No functional changes. Upgrade:
npm install -g @commercient/dlake (or npm install -g datalake)

0.5.14 (2026-08-19)

Package metadata refresh: the npm package now carries a proper description,
keywords, and links to the GitHub repository and the official downloads
site. No functional changes. Upgrade: npm install -g @commercient/dlake

0.5.13 (2026-08-18)

Updated guidance in the bundled guides and skills. When registering,
answer one question first: is this an integration (your CRM and/or ERP
syncing through the platform) or a standalone Data Lake? For an
integration, pass your real ERP as --instance-type (e.g. SAGEINTACCT)
so the CRM and connector setup match your ERP from the first step; for a
standalone Data Lake, omit it — the default is the correct choice there.
Your Data Lake is created either way.
The bundled guide now covers the TxDownloaderPro management tools available
through dlake admin, and the TxDownloaderPro skill gained a section on
them.
No behaviour changes. Upgrade: npm install -g @commercient/dlake

0.5.12 (2026-08-18)

Corrected the wording of the two backup statements on dlake register start.
--consent-crm-backup and --consent-erp-backup confirm that you have made
your own backups of your CRM and ERP data — they were previously described
as consenting to Commercient making backups, which is not what they mean.
The flags, their behaviour, and the sign-up flow are unchanged;
--consent-phone (consent to phone contact) is unchanged. The help text and
bundled guides now state the correct meaning. Upgrade:
npm install -g @commercient/dlake

0.5.11 (2026-08-17)

Please upgrade if you use dlake register — sign-up now requires consent flags.

Changed: dlake register start requires three affirmation flags.
Registration now asks for the same three statements as the sign-up website,
and the server refuses to create an account without them. The backup flags
confirm that you have made your own backups of your CRM and ERP data
(they do not ask Commercient to make any backup). Pass each flag to affirm
its statement:
```
--consent-crm-backup    I confirm I have made my own backup of my CRM data
--consent-erp-backup    I confirm I have made my own backup of my ERP data
--consent-phone         I consent to being contacted by phone
```
Older CLI versions cannot complete register start any more — upgrade:
npm install -g @commercient/dlake. There is also a new optional
--document-sync flag for File-Sync-only accounts.
New: dlake registration oauth — connect an OAuth CRM in one command.
It opens your browser at the provider's authorization page, catches the
redirect on this machine, and completes the exchange automatically — no more
copying code and state out of the address bar. --no-browser keeps the
manual flow if you prefer it, and the command falls back to it by itself when
a browser can't be opened.
New: dlake registration action — the provider-specific setup steps.
Salesforce's managed-package install links and Monday's workspace picker
(SalesforceSetup, MondayListWorkspaces, MondayPickWorkspace) are now
reachable from the CLI; previously these steps could not be completed outside
the portal.
The bundled guides and the integration-setup skill are updated to match.

0.5.10 (2026-08-15)

Refreshed the built-in guides and documentation. No functional changes.
Downloads for older versions have been retired; installs of pinned versions
below 0.5.10 will no longer fetch binaries. Upgrade:
npm install -g @commercient/dlake

0.5.9 (2026-08-15)

New: dlake crmpro — run CRMPro from the command line. The everyday verbs
for the forward ERP→CRM sync, without opening the portal:

dlake crmpro processes [--active]     the sync grid
dlake crmpro process <id>             one process in full
dlake crmpro status                   is the sync on or off
dlake crmpro enable | disable         turn it on or off
dlake crmpro history <id>             what was pushed, when, to which CRM record
dlake crmpro errors                   why records are missing in the CRM
dlake crmpro connections              the CRM connections a process can use
dlake crmpro mapping <id>             a process's field mapping

enable and disable set the state you asked for — run either twice and
nothing moves — and each prints what the setting was before, what it is now,
and whether anything changed, so a no-op no longer looks like a success.

Everything else CRMPro can do is available too. Creating, editing and
deleting processes, importing templates, listing CRM objects and fields, the
sync flags, the sync agent's own version report — 24 operations in all — are
there as dlake admin crmpro_<name>, each with --help for its arguments.
dlake admin list names them.
CRMPro commands need the Admin role. The API key has to belong to a user
who holds Admin on the tenant. If it doesn't, the command says so plainly and
exits 3; nothing is changed.
The bundled CRMPro guide (dlake skills show dlake-crmpro) ships updated in
this version — read it before the editing commands: a few of them protect you
from behaviour that is not obvious from the arguments alone.

0.5.8 (2026-08-14)

Fixed: dlake status reported every host as blocked when the platform was
fine. The health check was acquiring an API token before probing, so if one
service was unreachable the check failed for all of them — including hosts whose
commands worked seconds later. Health checks now send no credential, and each host
is judged on its own.
Corrected in the bundled setup skill: creating a key is
create_api_key --keyName <name> --expirationDays <7|30|90|180> (both required),
and connecting an OAuth CRM needs --redirectUri http://127.0.0.1:8801/callback/
— without it you get missing_redirect_uri, which is a step earlier than the
provider-side provider_app_not_configured. The skill now lists all three codes
and says which are yours to fix.
Also clarified: you do not need to pick a different CRM to finish the CRM
step. Select it, run crm_finalize, and complete the authorization later.

0.5.7 (2026-08-14)

Please read the first item — it changes how you run every command.

You now name the tenant on every command: --profile <name>. There is no
default profile any more, and dlake profiles use is gone. Set DLAKE_PROFILE
once if you'd rather not repeat the flag in a shell session.
Why: previously a command could run against a tenant you hadn't named. Register a
new tenant on a machine that already had one, and the very next command — the one
the CLI itself printed — went to the old tenant, with nothing on screen to say
so. If you look after several customers, that is the wrong customer.
The skills ship inside the CLI. dlake skills list, dlake skills install,
dlake skills show <name>. Four guides: using the Data Lake, setting up a new
integration, and operating each of the two sync agents. No download, no internet.
--help works when your key doesn't. Tool help is served from a local cache
when the live call fails, clearly marked as cached. Documentation shouldn't need
the credential you're trying to fix.
After registering, the key check is trustworthy. It retries before saying
anything, and if it still can't confirm, it tells you the key is saved and the
registration complete — the check is what's inconclusive.
Fewer misleading messages. A blocked network no longer suggests you raise a
firewall ticket when the cause may be an endpoint we pointed you at. Wizard output
no longer shows a CRM you never chose, or a "not seeded" flag for a lake that is.
Old profiles pointing at a download host that only answers on certain networks are
moved to the public one automatically.
dlake profile works as well as dlake profiles.
npm install -g now shows progress instead of sitting silent for minutes.

Still needs an allowlisted network: query, export, views, s3, keys,
projects. dlake tells you when that's what you're hitting.

0.5.6 (2026-08-13)

Fixed: dlake admin and dlake tool now work from any network. They used
to fail with '<' is an invalid start of a value unless you were on an
allowlisted network. Both now go through the public host, so a new customer can
drive the setup wizard from anywhere. Just upgrade — nothing to reconfigure.
Better errors when something blocks you. If a network filter answers instead
of the API, dlake now says so and tells you what to ask support for, rather
than printing a parser error. dlake status no longer reports a service as
"down" when it is your network being challenged.
dlake status shows each host separately, so you can see at a glance which
commands will work.
After registering, the CLI now tests your new API key instead of just
claiming everything works.
Clearer guidance when you have no profile yet — if your registration is
still finishing, it points you at dlake register status instead of a login you
cannot complete.
dlake profile now works as well as dlake profiles.
Help fixes: --phone is marked required; the scripted sign-up example keeps the
password you will need later to resume; the two progress numbers now say what
each one measures.
SHA256SUMS verifies correctly on Linux and macOS. It shipped with Windows
line endings, so sha256sum -c reported every file as failed even when the
download was fine.

Still requires an allowlisted network: query, export, views, s3, keys,
projects. dlake now tells you when that is what you are hitting.

0.5.5 (2026-08-13)

New: dlake register login --email <you> — resume a registration from any
machine. Signs back in with the password you chose at register start and
refreshes the saved token, so register status and register resend work
again with no flags. Use --password-stdin for scripts; you'll be prompted
otherwise.
After your Data Lake is seeded, the registration wizard (CRM and ERP connector
setup) can also be driven through dlake admin — run dlake admin list and
look for the registration_* tools.

0.5.4 (2026-08-12)

Registration and updates now use datalake-ms-dab.commercient.com. On some
networks the old host could block dlake register, npm install and CLI
updates; the new host works everywhere. No action needed — override with
--api-base / DLAKE_DOWNLOAD_BASE if you use a custom host.
No changes to commands, authentication, or workflows.
macOS binaries are code signed as usual. If you downloaded a macOS build on
2026-08-12 and it fails to start, simply re-download it.

0.5.3 (2026-08-01)

Clearer error messages for tool calls.
dlake entities list now shows whether each entity is currently being served.
Docs and embedded links refreshed.

0.5.2 (2026-07-31)

macOS binaries are now code signed. Fixes an intermittent startup failure on
Apple Silicon. If an older download misbehaves, re-sign it once locally:
xattr -dr com.apple.quarantine ./dlake && codesign --force --sign - ./dlake
(see dlake guide cli). No command changes.

0.5.1 (2026-07-26)

New dlake register command group — create a Data Lake account entirely from
the terminal (register start, register status [--watch], register resend).
Array and object arguments now accept JSON, and any argument accepts @file
(e.g. --columns @columns.json) — the recommended form on Windows.
Two new platforms: macOS Intel (osx-x64) and Linux ARM (linux-arm64) —
five supported in total.
Per-tool --help now documents the argument forms.

0.4.1 (2026-07-25)

Fix: dlake tool commands work reliably again.
Cleaner MCP error output.

0.4.0 (2026-07-24)

dlake tool — generic data-plane passthrough (records, query, aggregate,
export, time travel, documents), completing MCP parity.
dlake guide — the platform docs (api, help, cli) printed to stdout.
login --mcp-url per-profile override.

0.3.0 (2026-07-19)

dlake s3 attach / detach / discover — external tables on SQL Server
2022+ tenants.
New dlake view command group (list, show, create, alter, drop).
dlake --version.
Install and credential-handling improvements.

0.2.1 (2026-07-18)

Runs on minimal Linux images (slim/alpine) with no extra packages beyond
ca-certificates. Drop-in replacement for 0.2.0.

0.2.0 (2026-07-17)

Object storage: the dlake s3 command group — connections, browse (ls),
streaming put/get, rm, and server-side table export into a bucket.

0.1.0 — initial release

API-key login + per-tenant profiles, API keys & projects, query, export,
entities list, status, and the dlake admin control-plane passthrough.
Platforms: win-x64, linux-x64, osx-arm64. npm wrapper @commercient/dlake.

dlake 0.5.45