@tinkerlandai/indiana-sdk 0.6.1 → 0.6.3

package/CHANGELOG.md

@@ -1,6 +1,16 @@
 # Changelog
 
-Release facts and artifact evidence: [SDK release ledger](../../docs/sdk-releases.md). The two packages have independent version histories.
+Release facts and artifact evidence: [SDK release ledger](../../docs/sdk-releases.md).
+
+## Unreleased — 0.6.3
+
+- Align JS, Python and Go SDK package versions at 0.6.3 and require matching source versions before publication. Keep HTTP protocol 0.6 and the existing public release artifacts unchanged.
+
+## 0.6.2 — 2026-10-22
+
+- Publish checked artifacts through GitHub Actions with npm Trusted Publishing and verify the public package bytes and independent installation after publication.
+- Export the deterministic hosted renderer shell, content address and CSP from the popup entry so SDK consumers share the same renderer identity.
+- Keep protocol 0.6, the existing API origin and the Customer, entitlement and usage contracts. The 0.6.1 Funnel input, command settlement and Back recovery fixes remain included.
 
 ## 0.6.1 — 2026-10-22
 

package/README.md

@@ -2,14 +2,14 @@
 
 [简体中文](./README.zh-CN.md)
 
-Version **0.6.1 / protocol 0.6** requires a matching Indiana runtime and database. Remote Funnel responses contain the current page's `ScreenDocument` JSON; Local and Remote use the same renderer, canonical Run, business receipts and Queue recovery. Remote graphs and private rules stay on the server.
+Version **0.6.2 / protocol 0.6** requires a matching Indiana runtime and database. Remote Funnel responses contain the current page's `ScreenDocument` JSON; Local and Remote use the same renderer, canonical Run, business receipts and Queue recovery. Remote graphs and private rules stay on the server.
 
-Version 0.6.1 fixes current-screen input patches, Local Feature dependency validation, original-command settlement during host polling and display acknowledgement recovery after Back. Complete production browser and Stripe acceptance remains separate; see the [repair report](../../docs/deployment-receipts/20261022-sdk-funnel-repair/README.md).
+Version 0.6.2 adds a shared deterministic hosted renderer shell and uses GitHub Actions with npm Trusted Publishing. It retains the 0.6.1 fixes for current-screen input patches, Local Feature dependency validation, original-command settlement during host polling and display acknowledgement recovery after Back. Complete production browser and Stripe acceptance remains separate; see the [repair report](../../docs/deployment-receipts/20261022-sdk-funnel-repair/README.md).
 
 Pin this package to a matching protocol 0.6 service. The published npm 0.6.0 package passes 21 foundation operations through `https://api.dev.tinker.cash`, with readiness 200 and correlated Go request logs; remaining capabilities and production business dependencies have separate gates. npm publication does not extend that accepted scope. Actual publication, tags and environment state are recorded in the [release ledger](../../docs/sdk-releases.md).
 
 ```sh
-npm install --save-exact @tinkerlandai/indiana-sdk@0.6.1
+npm install --save-exact @tinkerlandai/indiana-sdk@0.6.2
 ```
 
 Indiana's JavaScript and TypeScript SDK supports browsers, Node.js, screen rendering and optional AI usage integrations. Environment collection controls and existing Invoice/billing-window contracts remain available. Older 0.x protocols are rejected before business execution.
@@ -18,7 +18,7 @@ Indiana's JavaScript and TypeScript SDK supports browsers, Node.js, screen rende
 
 During `0.x`, only the current protocol is supported. Starting with `1.0`, compatibility is preserved within each stable major version. Once the next stable major is published, the preceding stable major remains supported for at least 12 calendar months, with at least 180 days' public notice before retirement. The later deadline applies. See the [support policy](https://tinker.cash/docs/release-notes#support-policy).
 
-Version `0.6.1` sends protocol and SDK version headers and validates the protocol declared by successful responses. Headerless historical clients retain the fixed identity `0.2`; they do not follow the current protocol automatically. Updating source code does not change an existing npm artifact or deploy a server.
+Version `0.6.2` sends protocol and SDK version headers and validates the protocol declared by successful responses. Headerless historical clients retain the fixed identity `0.2`; they do not follow the current protocol automatically. Updating source code does not change an existing npm artifact or deploy a server.
 
 ## One package, seven entry points
 
@@ -34,6 +34,10 @@ Version `0.6.1` sends protocol and SDK version headers and validates the protoco
 
 The same package supports JavaScript and TypeScript and includes type declarations. Internal `@indiana/contracts` code is bundled; consumers do not install private workspace packages. Swift and Kotlin use their own package ecosystems and are released separately.
 
+The separate [Python server SDK](../python/README.md) provides synchronous and asynchronous Customer, holdings, entitlement-check and usage clients against the same current HTTP protocol. It is distributed from `https://tinker.cash/sdk/python` (not PyPI) and is not part of this npm package.
+
+The [Go server SDK](../go/README.md) provides the same initial capabilities with typed responses, Context cancellation and goroutine-safe client reuse. It is installed with `go get tinker.cash/sdk/go` through the default Go module proxy and is versioned separately from this npm package.
+
 ## API origin and test services
 
 The canonical repository policy, including production/test domain roles, package tags and test-host configuration, is [SDK API entry and development testing](../../docs/sdk-endpoints-and-testing.md).
@@ -126,7 +130,7 @@ await indiana.createGuestCustomer({
 
 Indiana keeps the first supplied signal as an environment-scoped hash; later values do not replace it. Missing input is valid and retains per-Customer trial deduplication. `unique_fingerprint` additionally deduplicates the configured Product trial across Customers sharing the signal. Business user IDs do not identify an installation; Customer/Guest/session tokens and request IDs have their own lifecycles and should not be fingerprints.
 
-On Web, an independent first-party installation cookie can retain the signal. Clearing it or changing browser storage can produce a new value; sign-out need not reset it. Native hosts persist a random installation signal and define reinstall, restore and reset behavior. This signal is separate from device attestation and authentication. See the [identity guide](https://tinker.cash/docs/identity#fingerprint) for HTTP host examples. Trial conflicts remain generic to clients; retain `X-Request-Id` for server-side diagnosis.
+On Web, an independent first-party installation cookie can retain the signal. Clearing it or changing browser storage can produce a new value; sign-out need not reset it. Native hosts persist a random installation signal and define reinstall, restore and reset behavior. This signal is separate from device attestation and authentication. Trial conflicts remain generic to clients; retain `X-Request-Id` for server-side diagnosis.
 
 ## Funnel, Feature, and standalone Paywall
 
@@ -134,7 +138,7 @@ A trusted backend calls `createFunnelStartClient().start()` with `funnelId`, a r
 
 `createFunnelClient({ customerToken, ...options })` is for clients that already hold a Customer credential. Its `start()` omits `customer` and `customerData` and runs as the credential's Customer. After response loss, retry with the same request ID and input. Put commercial parameters in `parameters.commerce`. Each Run has its own Run Token, which cannot switch Customer identity.
 
-`createFunnelDecisionClient.submit/decide` and the server entry's `createFunnelCampaignClient` use the same explicit Customer reference. Campaign `decide/start` operations report durable frequency or active-Run suppression as `suppressed` with a retry time. Report `shown` only after the Run is actually displayed; page closure or local storage cannot replace a durable presentation fact.
+`createFunnelDecisionClient.submit/decide` and the server entry's `createFunnelCampaignClient` use the same explicit Customer reference. Campaign `decide()` waits for a `FunnelDecision`; a lookup can return the original accepted decision and its original request ID. Campaign `start()` returns either Run credentials or `{ suppressed: true, reason, retryAt }` when frequency or an active Run blocks a new start, without fabricating Run credentials. Report `shown` only after the Run is actually displayed; page closure or local storage cannot replace a durable presentation fact.
 
 In a browser, use `createFunnelRunController` and `showFunnelRun`. The controller handles current-protocol commands, reads, retries, recovery, and subscriptions. Presentation handles provide `refresh()` and `destroy()`. Published nodes delegate business operations to the server. A client assertion or redirect is not payment evidence.
 
@@ -148,7 +152,7 @@ For Customer-based evaluation, `id` means the Indiana Customer UUID (`customer.i
 
 `setAttributes()` replaces the complete object, so retain the bucketing fields on every update. Anonymous page/visual experiments instead default `id` and `deviceId` to the shared first-party device cookie; they do not automatically match an account-based experiment. Sticky capabilities differ by adapter: managed Local Run instructions receive server state, while pure local tools require their existing host persistence adapter for durable Sticky. No new shared state is introduced. See the [architecture boundary](../../docs/growthbook-sdk-delivery.md#跨消费方求值边界与分桶身份).
 
-### Server-side local Funnel evaluation (unreleased source)
+### Server-side local Funnel evaluation
 
 For a Local Funnel containing only Entry, Condition, Feature, Split and literal/Feature End or Output nodes, use the explicit local evaluator. Reuse the client/evaluator across requests; create a session for one verified identity and attribute/parameter snapshot:
 
@@ -233,7 +237,7 @@ See the [SDK release ledger](https://github.com/tinkerlandai/Indiana/blob/main/d
 
 ## Shared public configuration (Indiana-test candidate)
 
-Use one manager per trusted origin and exact App/environment for Features, canonical Funnel files and enabled page experiments. This source addition is opt-in and requires the matching Indiana-test gateway plus an explicitly reviewed publication. It is not part of the published 0.5.0 package yet.
+Use one manager per trusted origin and exact App/environment for Features, canonical Funnel files and enabled page experiments. This source addition is opt-in and requires the matching Indiana-test gateway plus an explicitly reviewed publication. It is included in published packages since 0.6.0.
 
 ```ts
 import {
@@ -310,7 +314,7 @@ Screens, live Customer/Coupon data, shown acknowledgements, Paywall and external
 
 Old host checkpoints must be reconciled or drained with their original business identities before switching clients. Do not turn an old execution into a fresh start/request ID. The SDK does not import old checkpoints. On existing test targets the retirement candidate moves the original observation relation into a private read-only archive, preserves every row and continues refusing scoped legacy execution IDs; already accepted managed Runs retain exact replay. It accepts no new observations and creates no new business model. The production packet adds no observation or archive table. A mode change does not rewrite a Run's original policy or accepted commands. New results against a stale policy fail closed; close/reconcile that original Run before starting another intent.
 
-The native renderer shell uses the same pure JavaScript calculation adapter and native Run-command bridge; credentials remain in the native session. A headless Swift/Kotlin session exposes the pending calculation and does not silently calculate it remotely. Wire schemas and the renderer shell are generated together. Installing the package does not migrate a database or deploy a runtime. Browser, provider, capacity and native-store acceptance remain separate. See the [unification receipt](../../docs/implementation-receipts/20261020-funnel-shared-execution.json).
+The native renderer shell uses the same pure JavaScript calculation adapter and native Run-command bridge; credentials remain in the native session. A headless Swift/Kotlin session exposes the pending calculation and does not silently calculate it remotely. Wire schemas and the renderer shell are generated together. Installing the package does not migrate a database or deploy a runtime. Browser, provider, capacity and native-store acceptance remain separate. See the unification receipt.
 
 ## Funnel-scoped resource requests
 

package/README.zh-CN.md

@@ -10,14 +10,14 @@ Local / Remote 只区分纯条件、Feature / 实验和 Feature 选择在哪里
 
 条件结果尚未提交时，Run 停车并释放 Worker，仍需 Local 宿主返回；条件结果已受理后，后台业务操作可以通过原来的 Queue / Cron 脱离宿主恢复。Local SDK 不再直接调用发券服务来推进图，也没有第二套宿主业务执行器、定时器和展示状态。独立 Coupon API 保留自己的自领政策、权限、资格、库存、幂等和原有效期，不要求创建 Funnel。
 
-步骤记录共用后端限制；历史 `report_progress` 仍是调用方观察，不能当成发券证明。原生渲染壳复用同一个 JS 纯求值器及原生 Run bridge；无界面 Swift/Kotlin 会明确返回待本地求值，不自动切换 Remote。详细使用和迁移边界见[英文说明](README.md#local-funnel-execution)及[统一回执](../../docs/implementation-receipts/20261020-funnel-shared-execution.json)。安装本包不会自动迁移数据库或部署服务；浏览器、支付渠道、容量和原生商店验收分别记录。
+步骤记录共用后端限制；历史 `report_progress` 仍是调用方观察，不能当成发券证明。原生渲染壳复用同一个 JS 纯求值器及原生 Run bridge；无界面 Swift/Kotlin 会明确返回待本地求值，不自动切换 Remote。详细使用和迁移边界见[英文说明](README.md#local-funnel-execution)及统一回执。安装本包不会自动迁移数据库或部署服务；浏览器、支付渠道、容量和原生商店验收分别记录。
 
-本包版本为 **0.6.1／协议 0.6**，须配套同协议运行时和数据库。Remote Funnel 返回当前页面 JSON，与 Local 共用渲染器，完整 Remote 图和私有规则仍在服务端。公开 npm 0.6.0 已通过 `api.dev.tinker.cash` 的 21 项基础操作，foundation readiness 为 200；Funnel、公共配置、支付执行和生产业务仍有独立验收边界。实际发布、标签和环境状态见[SDK 发布总账](../../docs/sdk-releases.md)。
+本包版本为 **0.6.2／协议 0.6**，须配套同协议运行时和数据库。Remote Funnel 返回当前页面 JSON，与 Local 共用渲染器，完整 Remote 图和私有规则仍在服务端。公开 npm 0.6.0 已通过 `api.dev.tinker.cash` 的 21 项基础操作，foundation readiness 为 200；Funnel、公共配置、支付执行和生产业务仍有独立验收边界。实际发布、标签和环境状态见[SDK 发布总账](../../docs/sdk-releases.md)。
 
-0.6.1 修复当前 Screen 的输入 patch、Local Feature 依赖校验、host 轮询时原命令结算，以及 Back 后的展示确认恢复。完整生产浏览器与 Stripe 验收分别记录，见[修复报告](../../docs/deployment-receipts/20261022-sdk-funnel-repair/README.md)。
+0.6.2 增加共享的确定性托管渲染 shell，并通过 GitHub Actions 与 npm Trusted Publishing 发布；继续包含 0.6.1 的当前 Screen 输入 patch、Local Feature 依赖校验、host 轮询时原命令结算和 Back 后展示确认恢复修复。完整生产浏览器与 Stripe 验收分别记录，见[修复报告](../../docs/deployment-receipts/20261022-sdk-funnel-repair/README.md)。
 
 ```sh
-npm install --save-exact @tinkerlandai/indiana-sdk@0.6.1
+npm install --save-exact @tinkerlandai/indiana-sdk@0.6.2
 ```
 
 ## 版本兼容与支持
@@ -40,6 +40,10 @@ npm install --save-exact @tinkerlandai/indiana-sdk@0.6.1
 
 JavaScript 与 TypeScript 共用本包，声明文件随包提供。内部 `@indiana/contracts` 在构建时内联，接入方无需安装私有包。Swift 和 Kotlin 使用各自的包管理生态，不在本次 npm 发布范围内。
 
+独立的 [Python 服务端 SDK](../python/README.md) 使用同一当前 HTTP 协议，提供同步、异步 Customer、持仓／权益检查和用量上报。它从 `https://tinker.cash/sdk/python` 分发（不在 PyPI），不属于这个 npm 包。
+
+[Go 服务端 SDK](../go/README.md) 提供同样的首版能力，使用类型化响应、Context 取消和 goroutine 并发复用客户端。通过 Go 默认模块代理以 `go get tinker.cash/sdk/go` 安装，版本与 npm 包分开。
+
 ## API 默认地址与自测
 
 默认地址、四个域名、版本标签和测试配置的持续规范见 [SDK API 入口与开发测试规范](../../docs/sdk-endpoints-and-testing.md)。
@@ -93,28 +97,27 @@ Indiana 在普通 SDK 请求中自动延续同一 Customer 会话和 Token，默
 
 Customer 使用原始业务字段；资料更新是部分 patch，没有 Customer revision。Guest 登录到已有 Customer 时返回 `switched: true`，资源和历史保留原归属，接入方应为目标 Customer 创建新 Session／Funnel；不合并旧 Guest 的财务事实。
 
-## Optional stable fingerprint
+## 可选的稳定 fingerprint
 
-`fingerprint` is a host-supplied stable deduplication signal, such as an installation identifier. Initialize and retain it before the first Guest/Customer request, independently of login and credentials. Reuse it across Guest identification, account changes and session renewal. The SDK does not collect or generate it.
+`fingerprint` 是宿主提供的稳定去重信号，例如安装标识。首次 Guest／Customer 请求之前初始化并保留它，独立于登录和凭据；Guest 识别、账号切换和会话续期共用同一信号。SDK 不采集或生成它。
 
 ```ts
-// Trusted backend fragment: installationSignal is retained by the host;
-// verifiedUser.id comes from the host's authenticated login.
+// 可信后端：installationSignal 由宿主独立保留；
+// verifiedUser.id 来自宿主已验证的登录会话。
 const { customer } = await indiana.getOrCreateCustomer({
   externalUserId: verifiedUser.id,
   fingerprint: installationSignal,
 });
-// On Guest creation, use that same installationSignal and separately
-// retain/reuse guestToken for creation retries.
+// Guest 创建使用同一安装信号；创建重试另行保留并复用 guestToken。
 await indiana.createGuestCustomer({
   guestToken: retainedGuestToken,
   fingerprint: installationSignal,
 });
 ```
 
-Indiana keeps the first supplied signal as an environment-scoped hash; later values do not replace it. Missing input is valid and retains per-Customer trial deduplication. `unique_fingerprint` additionally deduplicates the configured Product trial across Customers sharing the signal. Business user IDs do not identify an installation; Customer/Guest/session tokens and request IDs have their own lifecycles and should not be fingerprints.
+Indiana 将首次提供的信号保存为环境内的哈希，后续值不替换它。可以省略输入，保留按 Customer 去重 Trial 的行为；`unique_fingerprint` 进一步在共享信号的 Customer 之间去重所配置的 Product Trial。业务用户 ID 不是安装标识；Customer／Guest／会话 Token 和请求 ID 各有自己的生命周期，不应充当 fingerprint。
 
-On Web, an independent first-party installation cookie can retain the signal. Clearing it or changing browser storage can produce a new value; sign-out need not reset it. Native hosts persist a random installation signal and define reinstall, restore and reset behavior. This signal is separate from device attestation and authentication. See the Web developer documentation's `/docs/identity#fingerprint` guide for executable HTTP host examples. Trial conflicts remain generic to clients; retain `X-Request-Id` for server-side diagnosis.
+Web 宿主可以用独立的第一方安装 cookie 保留信号。清除 cookie 或更换浏览器存储可能产生新值；退出登录无需重置它。原生宿主持久保存随机安装信号，并定义重装、恢复和重置行为。该信号独立于设备证明和身份认证。客户端只收到通用的 Trial 冲突信息；保留 `X-Request-Id` 供服务端排查。
 
 ## Funnel、Feature 与独立 Paywall
 
@@ -122,7 +125,7 @@ On Web, an independent first-party installation cookie can retain the signal. Cl
 
 `createFunnelClient({ customerToken, ...options })` 用于已持有 Customer 凭据的客户端；其 `start()` 不指定 `customer` 或 `customerData`，始终以凭据所属 Customer 运行。响应丢失时保留原编号和输入重试，商业参数放在 `parameters.commerce`。运行有独立的 Run Token，不能据此切换 Customer。
 
-`createFunnelDecisionClient` 的 `submit/decide` 与 `/server` 的 `createFunnelCampaignClient` 同样使用明确的 `customer` 引用。Campaign 客户端提供显式 `decide/start`；受频率或进行中运行限制时，`start` 返回 `suppressed` 和重试时间，不伪造 Run 凭据。Run 实际展示后才提交 `shown`，不能用页面关闭或本地存储代替持久的展示事实。
+`createFunnelDecisionClient` 的 `submit/decide` 与 `/server` 的 `createFunnelCampaignClient` 同样使用明确的 `customer` 引用。Campaign `decide()` 等待返回 `FunnelDecision`；查询可能返回原已接受的决策及其原 request ID。Campaign `start()` 返回 Run 凭据，或在频率／进行中 Run 阻止新启动时返回 `{ suppressed: true, reason, retryAt }`，不伪造 Run 凭据。Run 实际展示后才提交 `shown`，不能用页面关闭或本地存储代替持久的展示事实。
 
 浏览器使用 `createFunnelRunController` 与 `showFunnelRun`。控制器负责当前协议的命令、读取、重试、恢复和订阅；展示句柄提供 `refresh()` 和 `destroy()`。业务操作按当前发布节点委派给服务端，客户端声明或重定向不构成付款证明。
 
@@ -136,7 +139,7 @@ Customer 求值中的 `id` 是 Indiana Customer UUID（`customer.id`），`exter
 
 `setAttributes()` 替换整个对象，每次更新都保留分桶字段。匿名页面／视觉实验默认的 `id` 和 `deviceId` 来自共用的第一方设备 cookie，不自动与账号实验同组。各适配器的 Sticky 能力有区别：共用 Run 的 Local 指令读取服务端状态，纯本地工具的持久 Sticky 使用已有宿主适配器，不新增共享状态。完整要求见[架构边界](../../docs/growthbook-sdk-delivery.md#跨消费方求值边界与分桶身份)。
 
-### 服务端 SDK 本地 Funnel 求值（未发布源码）
+### 服务端 SDK 本地 Funnel 求值
 
 纯 Local Funnel 支持 Entry、Condition、Feature、Split，以及普通值或 Feature 值的 End／Output。复用 client／evaluator，每个可信身份及属性、参数快照创建独立计算会话：
 
@@ -221,13 +224,13 @@ npm 发布不部署 Web 服务、不应用数据库迁移，也不发布 Swift
 
 源码新增 `createConfigurationSync({ origin, scope })`；`scope` 必须明确包含 `projectId`、`environment` 和 `environmentId`。将同一个实例作为 `configuration` 传给 `createIndiana`、Funnel start／Run controller 和 `createPageExperiments`，共用清单、文件缓存、并发请求和更新通知。`/server` 导出的 `createSynchronizedFunnelLocalEvaluator(configuration, funnelId)` 使用同一份规范 Funnel 文件与 GB 代次进行纯判断，保留仅可信服务端执行的边界。
 
-此能力需要匹配的 Indiana-test 网关及已审核发布的配置，尚未发布到 npm 0.5.0。公共文件不需要 Customer 凭据；业务操作沿用现有凭据和服务端资格检查。完整调用示例见[英文说明](README.md#shared-public-configuration-indiana-test-candidate)。
+此能力需要匹配的 Indiana-test 网关及已审核发布的配置，自 npm 0.6.0 起包含在公开包中。公共文件不需要 Customer 凭据；业务操作沿用现有凭据和服务端资格检查。完整调用示例见[英文说明](README.md#shared-public-configuration-indiana-test-candidate)。
 
 初始化总等待不超过 5 秒；活跃消费者共用 12–15 秒轮询，并在回前台／联网后刷新。Local 控制状态自源站验证起最多有效 60 秒，旧 304 或失败不能续期。暂停／过期后停止新本地判断及客户屏幕；冷启动离线时，仅凭持久缓存不能恢复 active 权限。Indiana Run 的命令与观察直接读取服务端状态，独立于 CDN 控制有效期。
 
 内存缓存上限 128 项／32 MiB，浏览器默认 localStorage 的公共文件缓存上限 128 项／2 MiB／7 天。可设置 `storage: null` 或提供 `ConfigurationStorage`；额度不足时退回内存。单文件上限 1 MiB，清单上限 512 KiB，使用前校验作用域、schema 和哈希。共享缓存不存凭据、用户属性、Sticky 或已接受的决策。共享实例由宿主统一 `destroy()`，单个消费者退出不会销毁其他消费者的同步能力。
 
-## 共享 Funnel UI 宿主（未发布源码）
+## 共享 Funnel UI 宿主
 
 `showFunnelRun(container, { client: started.controller })` 在 Local / Remote 都接收同一个服务器 Run controller。屏幕、Customer / Product / Coupon 数据、shown 回执、Paywall、外部任务和未知结果重试共用后端路径。宿主销毁只卸载 UI；停止一个 Run 需要显式提交 Close。Console 私有预览仍是无真实业务效果的模拟。