@mitralab.io/sdk-core 0.2.0-beta.0 → 0.2.0-beta.1

package/CHANGELOG.md

@@ -2,6 +2,28 @@
 
 All notable changes to this project are documented in this file.
 
+## 0.2.0-beta.1
+
+This working tree prepares the `0.2.0-beta.1` package. Publication provenance remains
+unreleased until the final source commit and registry artifact exist.
+
+- Accept an inline template definition on integration config creation and on
+  provisional credential tests, so an app can connect a provider that has no
+  catalog template. `fieldsSchemaInline`, `requestConfigInline`, and
+  `loginConfigInline` replace `templateId` and reuse the catalog shapes. The
+  producer owns the exclusivity between the two, and Core does not check it.
+- Add `IntegrationFieldSchemaInput`, the authoring shape for an inline field,
+  which leaves `placeholder` and `default` optional because the producer stores
+  an omitted one as null. Responses keep the strict `IntegrationFieldSchema`.
+- Read `templateId: null` on configs created from an inline definition and
+  validate the three inline fields echoed back on config and list responses.
+- Publish contract corpus `0.2.0-beta.1` with the inline create, credential
+  test, and listing cases, leaving the released `0.2.0-beta.0` bytes untouched.
+- Name the array in the integration template field-schema validation message.
+  It now reads `fieldsSchema field 0` instead of `field 0`, because the template
+  and inline paths share one validator. Consumers that reimplement Core response
+  validation, such as the Python SDK, follow the same wording.
+
 ## 0.2.0-beta.0
 
 This working tree prepares the `0.2.0-beta.0` package. Publication provenance remains

package/README.md

@@ -158,6 +158,42 @@ or by their app-scoped alias with `integration.executeByAlias()`. Both methods
 send the proxy request unchanged apart from the required `source: "SDK"` audit
 field and validate the same proxy result.
 
+An integration config normally points at a catalog template through `templateId`.
+When the provider has no template, `integrationAdmin.create()`,
+`integrationAdmin.bulkCreate()`, and `integrationAdmin.testCredentials()` accept
+an inline definition instead, in the same shapes the catalog uses:
+
+```typescript
+await integrationAdmin.create({
+  alias: "erp-inline",
+  fieldsSchemaInline: [
+    { key: "base_url", label: "Base URL", type: "url", required: true },
+    { key: "access_key_code", label: "Access Key Code", type: "secret", required: true },
+    { key: "access_key_token", label: "Access Key Token", type: "secret", required: true },
+  ],
+  requestConfigInline: {
+    headers: {
+      "X-Access-Key-Code": "{{access_key_code}}",
+      "X-Access-Key-Token": "{{access_key_token}}",
+    },
+    credential_rules: null,
+  },
+  loginConfigInline: null,
+  values: { base_url: "https://api.example.com", access_key_code: "...", access_key_token: "..." },
+})
+```
+
+Send `templateId` or the inline definition, never both and never neither. The
+Integration service owns that rule and answers 400; Core forwards whatever the
+caller sends. Configs created this way report `templateId: null` and echo the
+three inline fields back on every config response, with secrets in `config`
+masked exactly as they are for template-backed configs.
+
+Inline fields are authored as `IntegrationFieldSchemaInput`, which makes
+`placeholder` and `default` optional because the producer stores an omitted one
+as null. Responses keep the strict `IntegrationFieldSchema`, where both
+properties are always present.
+
 `integrationAdmin.list()` is the native equivalent for listing configured
 integrations. It calls `GET /api/v1/template-configs` and returns the producer's
 paginated `TemplateConfigSummary` values. With an app-scoped token, the
@@ -267,12 +303,15 @@ The build produces ESM, CommonJS, `.d.ts`, and `.d.cts` artifacts. Package smoke
 
 ## Release order
 
-`0.2.0-beta.0` is the beta producer release for the concrete SDK adapters. Publish Core first:
+Core is the producer for the concrete SDK adapters, so it publishes first. For a prerelease
+`X.Y.Z-beta.N`, currently `0.2.0-beta.1`:
 
-1. Merge the complete `0.2.0-beta.0` source and contract corpus to `main`.
-2. Run the Release workflow with version `0.2.0-beta.0`. It runs the full package check before
-   tagging and publishes the prerelease under npm's `beta` dist-tag.
-3. Confirm `npm view @mitralab.io/sdk-core@0.2.0-beta.0 version` returns `0.2.0-beta.0`.
+1. Merge the source, the `package.json` version, and the matching contract corpus version to
+   `main` in the same pull request. The Release workflow bumps nothing.
+2. Run the Release workflow with version `X.Y.Z-beta.N`. It checks that the requested version
+   already matches `package.json`, runs the full package check, then tags and publishes the
+   prerelease under npm's `beta` dist-tag.
+3. Confirm `npm view @mitralab.io/sdk-core@X.Y.Z-beta.N version` returns the same version.
 4. Regenerate each adapter lockfile from the npm registry and pin this repository commit in the
    adapter's contract-source manifest before publishing that adapter.
 

package/contracts/README.md

@@ -10,10 +10,17 @@ change requires a new version directory. Consumers may vendor the exact bytes
 and pin their copy with a SHA-256 digest so their tests never depend on network
 access.
 
-A released version directory is immutable. Adding operations means publishing a
-new version and moving `current`, never editing bytes another consumer already
-pinned. Every declared version keeps its digest verified, so a consumer that has
-not migrated stays on the version it vendored.
+A released version directory is immutable. Adding an operation, or widening the
+request or response of one that already exists, means publishing a new version
+and moving `current`, never editing bytes another consumer already pinned. Every
+declared version keeps its digest verified, so a consumer that has not migrated
+stays on the version it vendored.
+
+The `current` version names the package release that will publish it, so it moves
+together with `package.json` in the pull request that prepares that release. The
+release workflow does not bump anything: it checks that the requested version
+already matches `package.json`, runs the full package check, then tags and
+publishes.
 
 ## Versions
 
@@ -23,6 +30,15 @@ not migrated stays on the version it vendored.
   batches, Function administration batches, integration template config
   batches with connection tests and listing, and app members. Its `sources`
   entries pin the producer revisions currently on `origin/alpha`.
+- `0.2.0-beta.1` widens integration template configs with the inline definition
+  contract. A create item or credential test carries `fieldsSchemaInline`,
+  `requestConfigInline`, and `loginConfigInline` instead of a `templateId`, and
+  config responses report `templateId: null`. Operations that accept more than
+  one request shape now keep one success case per shape. It declares no MCP
+  companion artifact because the MCP tool surface is unchanged and each artifact
+  carries its own version identity; the matrix stays pinned at `0.2.0-beta.0`.
+  The `integrationBuilder` source pin still names the last revision on
+  `origin/alpha`, because the producer change is landing in mitra-integration#37.
 
 The `0.2.0-beta.0/mcp-tool-parity.json` companion artifact maps every one of the 120
 `@McpTool` methods on `mitra-mcp-server` `origin/alpha` to a typed Core method.

package/contracts/manifest.json

@@ -1,6 +1,6 @@
 {
   "contract": "SDK-PARITY-001",
-  "current": "0.2.0-beta.0",
+  "current": "0.2.0-beta.1",
   "versions": [
     {
       "version": "0.1.0",
@@ -15,6 +15,11 @@
       "mcpToolsSha256": "77a115d39e2ee195b4e33a86766a6fdd75e89a7a35b6102f6f38f0eeb8c9d587",
       "mcpSourcePath": "v0.2.0-beta.0/mcp-alpha-tools.json",
       "mcpSourceSha256": "480d27eed75f2604da07fadd10f236a0ca971cf6a3c003434a1fb62c4255178f"
+    },
+    {
+      "version": "0.2.0-beta.1",
+      "path": "v0.2.0-beta.1/sdk-parity.json",
+      "sha256": "eb9515241cd092727ddb8cde3e3062df041a4c91f8226da04dc987b7c1053f05"
     }
   ]
 }