@hsuite/smart-engines-sdk 4.0.0 → 4.2.0

package/CHANGELOG.md

@@ -1,5 +1,20 @@
 # Changelog
 
+## 4.2.0 — 2026-06-26
+
+### Added
+
+- **Two-phase EXECUTABLE-agent surface (additive, non-breaking).** Reflects the host change that promotes a payer-funded XRPL agent into an executable AGENT record during the execute-create/finalize half. Lets the app-as-proxy consumer drive the full prepare → fund → execute agent flow type-safely.
+  - **`EntityCreationResult.agentId?: string` + `status?: string`.** The host now merges `{ agentId, status }` additively onto the execute-create envelope once the funded entity is promoted to an agent record (`executeCreateAgent`, and the convenience `createAgent` on payer-funded chains). Present ONLY on the agent execute/finalize path; undefined for non-agent entity types and on the prepare half. Field names + `string` types match the host controller's `executeCreate` return (`apps/smart-host/.../entities.controller.ts`) verbatim.
+  - **`CreateAgentRequest.rulesConfig?: Record<string, unknown>` + `capabilities?: string[]`.** Carried through `prepareCreateAgent` (which already forwards the whole request body) so the host can stash them VERBATIM on the PENDING registry row at prepare and recover them at execute to mint the agent record — avoiding a `rulesHash` divergence from re-deriving them from the bound rule. Field names + types mirror the host `PrepareCreateDto` / `entity-registry.schema.ts` verbatim. Optional/additive; ignored by the legacy synchronous `createAgent` and by non-agent entity types.
+  - **App-as-payer `fundWith` documented.** `CreateAgentRequest.fundWith` now documents that a smart-app may supply a SERVER-SIDE `fundWith` that signs the prepared payer `Payment` with the app's OWN treasury key and sets `payerAccountId` to that treasury account. No new method — the existing `prepareCreateAgent` → `fundWith` → `executeCreateAgent` sequence already supports an app funding an agent on a customer's behalf.
+
+## 4.1.0 — 2026-06-25
+
+### Added
+
+- **`AgentRegisterRequest.primaryChain?: string`.** Agent registration mints the agent's on-chain wallet ENTITY on the chain named by `primaryChain`; the host requires it and defaults a missing value to `'hedera'` (which has no funded payer in XRPL-only deployments → `PAYER_ACCOUNT_NOT_FOUND`). The field was always accepted at runtime (`AgentsClient.register` forwards the whole body to `POST /api/v3/baas/agents/register`), but the SDK type omitted it, so consumers couldn't set it type-safely. Now declared as a plain optional `string` — valid host values: `'hedera'`, `'xrpl'`, `'polkadot'`, `'solana'`, `'ethereum'`, `'polygon'`, `'bitcoin'`, `'stellar'`. Additive and backward-compatible.
+
 ## 4.0.0 — 2026-06-25
 
 **SDK revision — align the surface to the REAL reachable endpoints; remove the un-ingressed-tier footguns.** Two profiles, two tiers: `BaasClient` is the app-as-proxy / external profile (host BaaS tier, `{gateway}/host/api/v3/baas/*`); `SmartEngineClient` is the in-cluster / validator-direct profile (raw `/api/v3/*` tier, un-ingressed at the gateway). The web3 authorization proxy is the HOST, which already exposes the entity value-movement routes — so value-movement now lives on `BaasClient.entities`, and the raw-tier transactions arm is removed from `BaasClient`.

package/dist/index.d.ts

@@ -3825,6 +3825,7 @@ export type AgentRegisterRequest = {
 	description?: string;
 	capabilities: string[];
 	rules: AgentRules;
+	primaryChain?: string;
 	fundingConfig?: {
 		chain: string;
 		maxAmount: string;
@@ -25328,6 +25329,8 @@ export type CreateAgentRequest = {
 	agentType?: string;
 	securityMode?: EntitySecurityMode;
 	payerAccountId?: string;
+	rulesConfig?: Record<string, unknown>;
+	capabilities?: string[];
 	fundWith?: FundWith;
 };
 export type EntityCreationResult = {
@@ -25335,6 +25338,8 @@ export type EntityCreationResult = {
 	ruleRef: RuleRef;
 	chainAccounts: Record<string, string>;
 	transactionId?: string;
+	agentId?: string;
+	status?: string;
 };
 export type EntityInfo = {
 	entityId: string;