@datarails-ai/dr-cli 1.6.93 → 1.6.94

package/dist/cli.js

@@ -8,7 +8,7 @@ import { fileURLToPath as fileURLToPath3 } from "url";
 // package.json
 var package_default = {
   name: "@datarails-ai/dr-cli",
-  version: "1.6.93",
+  version: "1.6.94",
   description: "Datarails CLI",
   type: "module",
   engines: {
@@ -67,7 +67,7 @@ var package_default = {
 };
 
 // src/buildInfo.ts
-var BUILD_TIME = "2026-10-01T13:51:17.711Z";
+var BUILD_TIME = "2026-10-02T10:34:15.709Z";
 function formatBuildTime(iso) {
   if (iso === "") return "";
   const d = new Date(iso);

package/dist/scopes-map.json

@@ -1,6 +1,6 @@
 {
   "version": 1,
-  "cliVersion": "1.6.93",
+  "cliVersion": "1.6.94",
   "_contract": "Resolve a command path through `aliases` (canonical prefix + alias segment -> canonical path) before any lookup. A path listed in `pendingCommands`, or whose first segment is a key of `pending`, is UNDECIDED, not unrestricted: fail closed or skip it, and never read a path's absence from `commands` as 'no requirement'. An entry carrying `denied` is UNAVAILABLE to any AGENT-SCOPED credential — one whose `scopes` claim carries at least one `resource:action` entry; a claim that is absent, empty, capability-only or wholly unparseable is UNRESTRICTED, and this mark does not apply to it — whatever else that entry says: it is not a ceiling and it is not always-available, its `denied.reason` says why and `denied.until` names the ticket that lifts it, and the absence of `requires` on it must NEVER be read as 'no requirement'. Only an entry in `commands` with an empty `requires` means always-available.",
   "commands": {
     "login": {

package/dist/skills/create-connector-lib/SKILL.md

@@ -63,9 +63,13 @@ parameter fails in `connect()` before the vendor is called.
   vars, HTTP client, CSV writer, paging, auth, dates), then `_core` helpers and an existing connection
   that fits; never a second copy. Name modules after what they do, never after who uses them. Hand the
   user a list of lib improvements you noticed (duplicated helpers, code that belongs in `_core`, a
-  hand-written copy of a kit helper), done in their own PR. The kit comes from the runner image at
-  runtime, not from `.sdk-ref`: publish a kit-based lib connector only once each hook's first log line
-  in that datacenter reads `INFO:dr.sdk: hook=… kit=<version>`.
+  hand-written copy of a kit helper), done in their own PR.
+- **Every new lib is built on the kit.** A new `lib/<vendor>/` module or thin file that defines its own
+  logger, query-vars merge, redaction, CSV block helper, date parser or retry loop is wrong; use the
+  kit call. The kit is live in every production ring, so that is never a reason to copy one. It comes
+  from the runner image at runtime, not from `.sdk-ref`: on a dev or test environment, check that each
+  hook's first log line reads `INFO:dr.sdk: hook=… kit=<version>` before publishing there, and if it
+  does not, get that environment's runner image updated rather than dropping the kit.
 - **Never change what another org lands.** A change to a module other orgs import must be proven
   output-neutral: their tests pass, and for text-only edits, each module's AST with docstrings stripped
   equals `origin/main`'s. A lib merge cuts new versions of every connector that bundles it; none moves

package/dist/skills/datarails-connectors-onboard-connector/SKILL.md

@@ -187,8 +187,12 @@ Those carry org-specific config, may lag the current SDK/runtime contract, and c
 drift — the samples are the single maintained source of truth. At most read an existing one to sanity-check
 one behavior; never use it as the starting point to copy from.
 
-**Shared helpers come from the SDK's connector kit — never copy them, from a sample or anywhere else.**
-A template gives you the structure; the logger, config, retry, CSV and paging code comes from
+**Every new connector is built on the SDK's connector kit. Shared helpers come from the kit — never
+copy them, from a sample or anywhere else.** This is required, not a preference: a new connection or
+dataquery that defines its own `_get_logger`, `_query_vars`, `_safe_snippet`, `_csv_bytes` /
+`_csv_block`, `_parse_date` or a `for attempt in range` retry loop is wrong; replace it with the kit
+call below before it is reviewed. A template gives you the structure; the logger, config, retry, CSV
+and paging code comes from
 `from dr_integrations_sdk import kit` (import the package, not `kit.csv`/`kit.logging` by name — they
 would shadow the stdlib). `sample_http_vendor` uses it; `sample_streaming_fanout` and `lib/sample_vendor`
 still carry hand-written `_get_logger` / `_query_vars` / retry helpers, so swap those for the kit when you
@@ -205,10 +209,13 @@ copy them. Reference: dr-connectors-runner `docs/connector-kit.md`.
 | credentials and tokens | `kit.auth.credential(creds, *keys, vendor=)`, `client_credentials` / `password_grant` → `Token.header()`, `basic_header`, `bearer_header` |
 | a date window | `kit.dates.date_window(vars, start_keys=, end_keys=, required=)`, `DateWindow.chunks(days)`, `parse_date` |
 
-**Publish a kit connector only where the kit is live.** At runtime the kit comes from the **runner
-image**, not from `.sdk-ref` (that pins only what CI tests against). An image with the kit prints
-`INFO:dr.sdk: hook=… correlation_id=… kit=<version>` as each hook's first log line; until that line
-shows in the target datacenter, a connector that imports `kit` fails at import there.
+**The kit is live in every production ring**, so it is never a reason to fall back to copied helpers.
+At runtime the kit comes from the **runner image**, not from `.sdk-ref` (that pins only what CI tests
+against). An image with the kit prints
+`INFO:dr.sdk: hook=… correlation_id=… kit=<version>` as each hook's first log line. On a dev or test
+environment, check for that line before publishing there; if it is missing, a connector that imports
+`kit` fails at import, so get that environment's runner image updated — do not rewrite the connector
+without the kit.
 
 **Batching & output — the non-negotiable pattern (get this right FIRST, before writing fetch).**
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@datarails-ai/dr-cli",
-  "version": "1.6.93",
+  "version": "1.6.94",
   "description": "Datarails CLI",
   "type": "module",
   "engines": {