@tinkerlandai/indiana-sdk 0.9.5 → 0.10.1

package/CHANGELOG.md

@@ -2,6 +2,17 @@
 
 Release facts and artifact evidence: [SDK release ledger](../../docs/sdk-releases.md).
 
+## 0.10.1 — 2026-10-29
+
+- Add the Server SDK supplemental Invoice preparation API with explicit Customer scope, reason normalization and bounded amounts; align Python/Go methods and transport fixtures.
+- Preserve the original merchant purchase while recovering Paywall failures, and open its Checkout only once.
+- Accept the App Console host in visual diagnostics after the public-site domain split.
+
+- Support merchant-native purchase, subscription changes, refunds and billing records without requiring Stripe object identifiers or credentials.
+- Upgrade the merchant receiver to version 3 with declared commercial profiles, explicit original-operation lookup and fresh Indiana authority before financial execution. Unknown results retain recovery of the original operation.
+- Add the Server SDK authority resolver and align generated DTOs, financial validation and native merchant-provider entry points across all six SDKs.
+- Use only wire protocol 0.10. Requests and responses from protocol 0.9 are refused; Customer Access/Refresh credentials retain their existing lifecycle.
+
 ## 0.9.5 — 2026-10-29
 
 - Synchronize JavaScript, React Native, Swift, Kotlin, Python and Go with the current Customer operations, scope checks, response validation and document semantics.

package/README.md

@@ -1,6 +1,6 @@
 # @tinkerlandai/indiana-sdk
 
-This source checkout is SDK 0.9.5, protocol 0.9. These examples use `https://api.tinker.cash`, using a Sandbox App and credentials issued by the production deployment. Sandbox still contains production data; do not reuse credentials from the separate test deployment. Confirm runtime readiness in [environment state](../../docs/development-status.md) before running them.
+This source checkout is SDK 0.10.1, protocol 0.10. These examples use `https://api.tinker.cash` with a Sandbox App and credentials issued by the production deployment. Sandbox still contains production data; do not reuse credentials from the separate test deployment. Confirm runtime readiness in [environment state](../../docs/development-status.md) before running them.
 
 [简体中文](./README.zh-CN.md)
 
@@ -9,7 +9,7 @@ The Indiana business SDK groups its capabilities as **Identity, Commerce, experi
 **IAM source scanning, generation, validation and upload belong to the independent build package `@tinkerlandai/indiana-iam`.** This business SDK retains only the runtime release binding used by GB visual changes. See [SDK boundaries](../../docs/sdk-architecture.md) and the [IAM package](../iam/README.md).
 
 ```sh
-npm install --save-exact @tinkerlandai/indiana-sdk@0.9.1
+npm install --save-exact @tinkerlandai/indiana-sdk@0.9.5
 ```
 
 This SDK requires HTTP protocol 0.9. Install a version that matches your runtime; publishing a package does not deploy the server. Publication and accepted environment scope are recorded in the [release ledger](../../docs/sdk-releases.md) and [development status](../../docs/development-status.md).
@@ -463,23 +463,12 @@ Customer sessions contain `customerId`, `sessionId`, `accessToken`, `refreshToke
 
 ## Merchant-recorded billing
 
-In a `record_only` App environment, your backend owns Stripe execution and confirms the result. Register its Stripe account ID and submit complete object snapshots with the Server SDK; Indiana does not accept Stripe callbacks or require a Stripe Key/signing secret in this mode. `indiana` mode continues to use verified Stripe callbacks.
-
-```ts
-await server.recordBillingEvent({
-  provider: "stripe",
-  accountId: "acct_your_account",
-  eventId: "your-stable-event-id",
-  type: "invoice.paid",
-  occurredAt: Date.now(),
-  data: completePaidInvoice,
-});
-```
-
-Keep the same event ID, timestamp and data when retrying. Submit all Invoice lines and subscription items; incomplete snapshots are rejected. Existing quote metadata and Price bindings associate the record with the purchase. The receipt identifies merchant provenance with `providerVerified: false`. Customer/Guest clients cannot record billing results.
+In `record_only` mode your backend owns payment execution, verifies its results and submits normalized `provider: "merchant"` facts with the Server SDK. Use `purchase.completed`, `purchase.closed`, `subscription.observed`, `subscription.change.completed`, `invoice.paid` or `refund.updated`. Include the original operation/Customer, complete Invoice lines and subscription items as required. Amounts use minor units; `occurredAt` is an ISO observation time. A durable outbox retains the exact event ID and facts on retry. The receipt records merchant provenance with `providerVerified: false`; Customer/Guest clients cannot submit billing facts. Managed mode retains Indiana-owned provider execution.
 
 ## Merchant bridge
 
-The source export `createMerchantBridge` consumes the version 2 single-receiver merchant adapter for `record_only`. It uses an explicitly scoped capability declaration, native merchant authentication and typed commands at one fixed POST `/integrations/indiana` for presentation, Customer sessions, commerce reads, purchase execution and operation recovery. Call `reset()` on logout/account switch. Display receipts are separate from purchases; the client never retries a charge or opens Checkout automatically. Server Keys and refund/catalog authority remain on trusted backends. See the [merchant specification](https://tinker.cash/docs/merchant-execution) for the manifest, Console configuration and wire fields. This source export requires publication of a package containing it; it does not certify a deployed merchant integration.
+`createMerchantBridge` consumes bridge version 3 at POST `/integrations/indiana`, scoped by App and environment. It uses native login for Customer sessions, presentation, commerce reads and confirmed original operations. Call `reset()` on logout/account switch. The client never automatically retries financial execution or opens Checkout. Protocol 0.10 accepts no older protocol.
+
+The Server entry exports `createMerchantBridgeHandler`, `createMerchantBridgeAuthorityResolver`, `signMerchantBridgeMessage` and `verifyMerchantBridgeMessage`. Supply backend signing keys, native authorization/CSRF, implemented capabilities/profiles and typed handlers. Set `resolveOperationAuthority: createMerchantBridgeAuthorityResolver(server)` so every financial/read command obtains fresh Indiana authority from the original operation API. A signed service request still requires confirmation and exact scope/Customer ownership; it cannot issue user sessions.
 
-The Server source entry also exports `createMerchantBridgeHandler`, `signMerchantBridgeMessage` and `verifyMerchantBridgeMessage`. Supply a scoped declaration, backend-only signing keys, native `authorize(request, input)` and typed command handlers. Authorize identity, CSRF and original operation ownership/confirmation before effects; handlers own durable idempotency and recovery. Console checks run signed Ping, discovery and available catalog reads only. Declarations and 202 acceptance are not purchase/fulfilment completion. Never expose signing keys to browsers. Bridge versioning does not change Indiana protocol 0.9 or billing-result recording.
+Handlers must durably reserve the original operation before external effects and retain the same provider idempotency key. The SDK's preceding lookup is not a concurrency lock. `operation.read` returns `found` or `not_received` without creating effects. Recover `RESULT_UNKNOWN` through that original operation; never infer permission from a browser quote or `pending`. Console discovery is configuration validation, not commercial completion. See the [merchant specification](https://tinker.cash/docs/merchant-execution) for exact fields and recovery.

package/README.zh-CN.md

@@ -1,6 +1,6 @@
 [English](./README.md)
 
-当前源码为 SDK 0.9.5、协议 0.9。本页示例使用 `https://api.tinker.cash` 以及生产部署内签发的 Sandbox App／凭据。Sandbox 仍属于生产数据，不能复用独立测试部署的凭据。运行前核对[环境状态](../../docs/development-status.md)，确认服务已就绪。
+当前源码为 SDK 0.10.1、协议 0.10。本页示例使用 `https://api.tinker.cash` 以及生产部署内签发的 Sandbox App／凭据。Sandbox 仍属于生产数据，不能复用独立测试部署的凭据。运行前核对[环境状态](../../docs/development-status.md)，确认服务已就绪。
 
 # @tinkerlandai/indiana-sdk
 
@@ -9,10 +9,10 @@
 **IAM 的源码扫描、生成、校验和上传属于独立构建包 `@tinkerlandai/indiana-iam`。** 普通业务 SDK 只保留 GB visual 应用页面变更所需的运行时 release 绑定。完整定义见 [SDK 边界](../../docs/sdk-architecture.md) 与 [IAM 构建包](../iam/README.md)。
 
 ```sh
-npm install --save-exact @tinkerlandai/indiana-sdk@0.9.1
+npm install --save-exact @tinkerlandai/indiana-sdk@0.9.5
 ```
 
-SDK 0.9.1 要求 HTTP 协议 0.9。安装版本须与运行服务匹配；发布包不会部署服务端。实际发布、标签与环境验收范围见 [SDK 发布总账](../../docs/sdk-releases.md) 和 [开发状态](../../docs/development-status.md)。
+SDK 0.9.5 要求 HTTP 协议 0.9。安装版本须与运行服务匹配；发布包不会部署服务端。实际发布、标签与环境验收范围见 [SDK 发布总账](../../docs/sdk-releases.md) 和 [开发状态](../../docs/development-status.md)。
 
 数据／会话层负责公开 JSON、完整性校验和鉴权操作；展示宿主将会话接口接入打包的屏幕渲染器，渲染器消费已提供的数据并返回动作意图。客户端按需加载展示；`/server` 入口使用商户后端的受限 Server Key，不加载屏幕展示。SDK 本地检查不替代运行时授权或付款核实。后台 Preview 为同一个展示宿主提供模拟会话和数据。
 
@@ -352,10 +352,12 @@ export async function showBanner(
 
 ## 商户主动记账
 
-`record_only` 环境由商户后端执行支付并确认结果，再通过服务端 SDK 的 `recordBillingEvent({ provider: "stripe", accountId, eventId, type, occurredAt, data })` 提交完整对象快照。`occurredAt` 是毫秒时间戳；重试保留相同事件 ID、时间和数据。发票必须包含全部行，订阅必须包含全部项目，并保留原报价的关联信息与 Price 绑定。Indiana 复用现有订单、订阅和账本，明确记录商户来源；此模式不接收 Stripe 回调，也不需要 Stripe API Key 或 Webhook 签名密钥。Customer/Guest 客户端不能记账。`indiana` 全托管模式继续使用 Stripe 验签回调。
+`record_only` 由商户后端执行并核对支付，再提交 `provider: "merchant"` 的归一化事实。事件包括 `purchase.completed`、`purchase.closed`、`subscription.observed`、`subscription.change.completed`、`invoice.paid`、`refund.updated`，按事件携带原操作、Customer、完整发票行和订阅项目。金额使用最小币种单位，`occurredAt` 为真实观察时间的 ISO 字符串。可靠 outbox 在重试时保留相同事件 ID 和事实。回执以 `providerVerified: false` 标记商户来源；Customer/Guest 无权记账。托管模式继续由 Indiana 执行渠道业务。
 
 ## 商户桥接
 
-源码导出 `createMerchantBridge`，用于 `record_only` 的版本 2 单入口商户适配层。客户端按明确 App/环境/账户的能力声明，使用商户原生登录向固定 POST `/integrations/indiana` 发送有类型的展示、会话、商业状态、购买和操作恢复指令。退出或切账号时调用 `reset()`。展示回传与购买独立，不自动重试扣款或打开 Checkout；Server Key、退款和目录读取权限留在可信后端。能力声明、Console 配置及字段见[商户接入规范](https://tinker.cash/zh-CN/docs/merchant-execution)。此导出需要发布包含它的 SDK 包后才可安装使用，源码存在不代表商户已经部署。
+`createMerchantBridge` 使用版本 3 单入口 POST `/integrations/indiana`，按 App 和环境固定范围，通过原生登录接入 Customer 会话、展示、商业读取和已确认原操作。退出或换号调用 `reset()`。客户端不自动重试财务执行或打开 Checkout。当前协议为 0.10，不兼容旧协议。
 
-Server 入口源码另导出 `createMerchantBridgeHandler`、`signMerchantBridgeMessage` 和 `verifyMerchantBridgeMessage`。商户提供固定范围的能力声明、服务端签名密钥、原生 `authorize(request, input)` 与指令处理器；原生授权必须在业务写入前核对身份、CSRF、原操作归属与确认，处理器负责持久幂等和恢复。Console 只执行签名 Ping、能力发现及可用的目录读取，不把声明或 202 受理当作购买／权益完成。签名凭据不得交给浏览器。桥接版本不改变 Indiana 协议 0.9 或账单结果回传契约。
+Server 入口导出 `createMerchantBridgeHandler`、`createMerchantBridgeAuthorityResolver`、`signMerchantBridgeMessage` 和 `verifyMerchantBridgeMessage`。配置后端签名密钥、原生授权/CSRF、实际已实现的能力与 profiles，并设置 `resolveOperationAuthority: createMerchantBridgeAuthorityResolver(server)`，每次从 Indiana 原操作 API 读取最新权限。服务签名仍需原确认事实和准确范围、Customer 归属，不能据此签发用户会话。
+
+业务处理器必须在调用外部渠道前持久预留原 operationId，并使用稳定渠道幂等键；SDK 的先查询不能代替并发锁。`operation.read` 返回 `found` 或 `not_received`，严格只读。`RESULT_UNKNOWN` 只恢复原操作，不能根据浏览器报价或 pending 状态自行推断执行权限。Console 能力检查不证明商业完成。精确字段和恢复规则见[商户接入规范](https://tinker.cash/zh-CN/docs/merchant-execution)。

package/dist/{ai-usage-CUTIHAU0.d.ts → ai-usage-Cn7dhvFw.d.ts}

@@ -1,5 +1,5 @@
 import { LanguageModelV4Usage, LanguageModelV4Middleware } from '@ai-sdk/provider';
-import { F as FoundationApi, A as ApiInput } from './api-BXu6TAoB.js';
+import { F as FoundationApi, A as ApiInput } from './api-DC44FaTV.js';
 import { z } from 'zod';
 
 declare const tokenCounts: z.ZodObject<{
@@ -98,7 +98,7 @@ declare function createAiPricing(options?: AiPricingOptions): {
         receipt: {
             id: string;
             internal_feature_id: string;
-            kind: "refund" | "consume" | "reserve" | "confirm" | "release" | "expire";
+            kind: "release" | "refund" | "consume" | "reserve" | "confirm" | "expire";
             originalId: string | null;
             quantity: string;
             accepted: boolean;
@@ -169,7 +169,7 @@ declare function createConfiguredAiPricing(client: Pick<FoundationApi, "readAiPr
         receipt: {
             id: string;
             internal_feature_id: string;
-            kind: "refund" | "consume" | "reserve" | "confirm" | "release" | "expire";
+            kind: "release" | "refund" | "consume" | "reserve" | "confirm" | "expire";
             originalId: string | null;
             quantity: string;
             accepted: boolean;