@domino-sdk/relay 1.62.0 → 1.63.0

package/CHANGELOG.md

@@ -1,5 +1,73 @@
 # @domino-sdk/relay
 
+## 1.63.0
+
+### Minor Changes
+
+- 1fa78d2: `limits` reads Relay's platform limits as `number`, so a 1.x release can raise one or add one (released SDKs keep checking the values they shipped with, so Relay answers them within those): `limits.quests`, `limits.questTypes`, `limits.collections`, `limits.sdkRuntime`, `limits.memberCompletions`, `limits.dashboardPanels`, `limits.dashboards`, `limits.defer`, `limits.retryCooldown`, `limits.analyticsQueryRows`, `limits.apps` (secrets, KV and SQL stores, migrations, storage browsing and schedules), `limits.stagedDeployment`, `limits.capabilityCalls`, `limits.trackerData`, `limits.trackerPreview`, `limits.walletsPerChain`, `limits.walletEventLogs` and `limits.walletTransactions`. It is exported from `@domino-sdk/relay/schema`, `/authoring`, `/server` and `/testing`, with its `Limits` type.
+
+  Deprecated, with unchanged values and types: the literal-typed limit constants `limits` replaces, which can never change in 1.x. They are `questScaleLimits`, `sdkRuntimeLimits`, `maxMemberCompletions`, `dashboardLimits`, `deferPolicy`, `retryCooldownPolicy`, `analyticsQueryLimit`, `APP_SECRET_LIMIT`, `APP_KV_LIMIT`, `APP_SQL_LIMIT`, `APP_MIGRATION_LIMIT`, `APP_MIGRATION_FILE_BYTES`, `APP_MIGRATION_TOTAL_BYTES`, `APP_STORAGE_ROW_LIMIT`, `APP_STORAGE_PREVIEW_CHARACTERS`, `APP_STORAGE_CELL_CHARACTERS`, `stagedDeploymentLimits`, `APP_SCHEDULE_LIMIT`, `APP_SCHEDULE_MIN_INTERVAL`, `APP_SCHEDULE_TIMEOUT`, `APP_SCHEDULE_RESULT_BYTES`, `maxCapabilityCalls`, `trackerDataMaxBranches`, `trackerDataMaxEntries`, `trackerPreviewLimits`, `WALLETS_PER_CHAIN`, `maxWalletEventLogs` and `maxWalletTransactions`.
+
+  Deprecated and removed in 2.0.0: Relay's own implementation helpers, which apps and quests have no use for. From `@domino-sdk/relay/server`: `participantRoutes`, `participantRoutePattern`, `sequenceCursorSchema`, `sourceDataSchema`, `trackerDataIssue`, `trackerDataIssues`, `whereSchemaIssue`, `validateQuestShape`, `containsReferralIntegrationReward`, `REFERRAL_INTEGRATION_REWARD_ERROR` and `nextScheduleRun`. From `@domino-sdk/relay/schema`: `dashboardIssue`, `normalizeDashboard`, `compatibleSettingKinds`, `isBoundSetting`, `whereSettings` and `sourceContent`. They keep working until then.
+
+  `z` from `@domino-sdk/relay/authoring` stays zod 4 for all of 1.x.
+
+- 052744c: `inspectIntegrationKey({ baseUrl, integrationKey })` from `@domino-sdk/relay/portal-proxy` answers which app login key a `di_` key is: its `id`, `name`, `organization`, `project`, `environment`, `origin`, `identityKind`, `vouchesAccounts`, `secretExpiresAt` and `appOrigins`, the addresses Domino serves the project's app from in that environment. It calls the new `GET /v1/auth/integration`, never returns a secret, and does not count as a use of the key. An unknown, expired or revoked key throws `ParticipantExchangeError` with 401 `invalid-credential`. `identityIntegrationKeySchema` and the `IdentityIntegrationKey` type are exported from `@domino-sdk/relay/server`.
+
+  Behavior change: `domino secrets set` now checks a value that starts with `di_` before storing it. It refuses, storing nothing and exiting 2 with `INVALID_ARGUMENT`, a key that is unknown, expired or revoked, or that belongs to another project or environment, such as a Live key set as Test's secret. It stores a key whose origin is not the app's own address for that environment with a warning, and a key it could not check (network failure, or a Relay without the route) with a warning. A checked key is named in the result's new `identityIntegration` field. Other values are stored as before.
+
+- e71245d: `createParticipantBackend` accepts `onExchangeError(error, request)`, called with each refused sign-in exchange as Domino answered it (a `ParticipantExchangeError` with `status`, `code`, Domino's `message` and `retryAfter`) before the browser gets its answer, so the app's server can log why sign-in failed. The browser's answer is unchanged, also when the callback throws.
+
+  Behavior change: creating an app login key for one of Domino's own app addresses in the environment that address does not serve is now refused with 400 `invalid-request`, and the message names the right environment. A `<project-slug>--staging.domino.page` or preview address belongs in Test, a live `<project-slug>.domino.page` address in Live. Other origins, custom domains included, can still use either environment, and existing keys keep working. An origin that is a URL but not an exact HTTPS origin is refused with a message that names the origin it accepts ("Use the exact origin https://app.example.com, without a path, query or trailing slash.") or "Use an HTTPS origin." instead of "Use an exact HTTPS application origin"; over HTTP the management API now answers that message instead of "Invalid management request". The app login guide and the Domino skill references gain a troubleshooting section with the exchange refusal codes.
+
+- eaaae2a: Test members that `reset` refuses because they redeemed an offer, hold a reservation or a started reward handover, or took part in a referral can now be purged: `management.testMembers.purge({ actionId, members, reason })` and `domino test-members purge MEMBER... --reason TEXT` delete up to 500 test members in one transaction, in the test environment only. The stock unit each redemption, reservation and pickup handover took goes back to its stock item, so the offer's stock and redeemed count stay consistent, and the members' referrals and referral accounting go with them. List both sides of every referral: one with a member outside the list refuses the call with `test-member-reset-blocked` (`referrals affect another member`, naming the unlisted member in `outside`). Every other reason reset refuses still applies, and a refused purge changes nothing. The audit records one event with the operator, the members, the reason and the stock returned. `reset` is unchanged. See [Purge members reset refuses](https://console.domino.run/docs/use/quests#purge-members-reset-refuses).
+- 69e017d: Erase a member on the person's request: `management.members.erase(member, { reason, actionId? })` and `domino members erase MEMBER --reason TEXT [--yes]` (`POST /management/v1/members/:member/erase`, `publish` permission, live and test). It can't be undone. The member's profile and uploaded avatar, sign-in identities, linked accounts and their tokens, app identities, wallets, sessions, consent, leaderboard aliases, referral code, the evidence of every attempt and the stored content of the tracker records their accounts authored are deleted; reasons people typed on the rows that stay read `[erased]`. The member ID keeps its points, completions, rewards and referrals. The result is `{ member, erasedAt, deleted }`; while an attempt waits for a decision or a reward handover is in progress it is refused with 409 `member-erase-blocked`. See [Erase a member on request](https://console.domino.run/docs/use/member-erasure).
+
+  Member reads (`members.get`, `members.list`) carry a new `erasedAt` on an erased member, and `members.get` answers `profile: null` for it. After erasure, writes naming the member (points, badges, groups, campaigns, consent, profile changes) are refused with the new 409 code `member-erased`, records naming its ID attribute to no one, and the same person signing in again becomes a new member. A member import's revert passes over an erased member's row and reports it in `keptLinks` with reason `member-erased`. The CLI command asks for confirmation in a terminal and needs `--yes` otherwise.
+
+- bbc3623: Klaviyo is the first destination plugin: connected through Klaviyo's OAuth, it keeps opted-in members' Klaviyo profiles current with `domino_` properties (points, ranks, quests completed, unredeemed rewards, campaigns), subscribes and unsubscribes them as their email consent changes (a backfill or resync never resubscribes someone Klaviyo has unsubscribed), and records Domino's events as `Domino …` metrics. It never calls Klaviyo's send, campaign or flow APIs. See the new guide, "Send reminders from Klaviyo".
+
+  `management.connections` gains, experimental like the rest of it:
+
+  - `connect(plugin, { config, dryRun: true })` connects a destination that supports a dry run, in the test environment, without secrets or the vendor's account. It records what it would have sent instead of sending it. `Connection.dryRun` and `PluginInfo.dryRun` say which. Refusals: 409 `dry-run-not-supported`, `dry-run-test-only`.
+  - `activity(plugin)` reads a destination's delivery record: last sync, failing state, members synced and skipped per reason, the latest backfill or resync with its progress, and the latest 20 errors.
+  - `resync(plugin)` sends every member's profile and attributes again, never past events; one runs at a time.
+  - `dryRunLog(plugin, { cursor, limit })` pages through a dry run's requests, newest first.
+
+  These answer 409 `not-a-destination` for other plugins. The CLI adds `domino connections connect --dry-run`, `connections activity`, `connections resync` and `connections log`.
+
+- 9cb68e2: A text setting can be secret: `settings.text({ label, secret: true })`. Operators set its value in Console or with `management.quests.updateSettings`, and the quest's code reads it as usual, but no management response returns it. Releases leave secret settings out of `values` and `configuration`, and list the ones that hold a value in the new optional `withheldSettings`. So `domino deploy --json`, `--preview --json`, `quests list`, `releases get`, deployments, attempts and member reads no longer print a shared code a guest must not see. Console shows a secret as **Set** or **Not set**, with a field to replace it and **Clear**. A secret setting takes no default: one with a non-empty `default`, or a value from a deploy entry's `settings`, is refused, and reusable quest types refuse secret settings. A secret's entry in a release's `fields` says `secret: true`. Settings without `secret` behave as before. Withholding follows each release's own fields, so releases and deployments from before a setting became secret still show its old value: set a new one after marking an existing setting secret.
+- 8ee88a9: Test members can redeem an offer: `management.testMembers.redeem(member, { offer })`, with the offer's key or ID, and `domino test-members redeem MEMBER OFFER`. The redemption runs as a signed-in member's would, with the same price, stock, per-member limit, requirements and refusals, writes the same redemption and entitlement, answers the redemption, and replays by action ID. It works in the test environment only, and the audit names the operator. A test member with a redemption can't be reset.
+- 6fe6f22: The testing kit lists and replays every capability reader, and a few small defaults change.
+
+  - **`capabilityCalls`.** `runQuest`, `createTestContext` and `replayAttempt` results gain `capabilityCalls`: every capability call as `{ sequence, request, outcome }`, with an open `CapabilityCallRequest` whose `kind` names the reader. It includes the calls `calls` left out: Telegram, NFT, contract call, delegation, wallet event and transaction reads, and the member's state. `calls` is deprecated.
+  - **Replay divergences of any reader.** `replayAttempt` reports a call of any reader the capture cannot answer in the new `capabilityDivergence`, and stops there unless `facts` answers it. Before, such a call of a newer reader failed the replay with `TestSetupError`; now the replay resolves with `decision: null`. `divergence` is deprecated, and is `null` when the first divergence is a newer reader's call.
+  - **Tolerant replay.** A captured answer with a field or an enum value a later Relay added, such as a new field on a Discord message, now replays instead of failing. Answers in `facts` are still checked strictly.
+  - **Reader fakes.** `fakeWalletReader(facts)` and `fakeTelegramReader(facts)` from `@domino-sdk/relay/testing` build readers with every method Relay supplies, for tests that assemble their own evaluation context. The readers added after 1.0 stay optional in their types; quest code calls them with a non-null assertion, as the snippets now do (`ctx.wallet.nfts!(…)`, `ctx.telegram!.connection!()`), instead of guarding against a runtime that lacks them.
+  - **Behavior change: Telegram trackers fire once per record.** `automatic()` on a `telegram.reactions()` or `telegram.messages()` tracker now defaults to `on: "new-record"` instead of `"new-observation"`, so a reaction removed and added again no longer runs the quest again. Published quests keep the mode they were published with; republishing one with this SDK switches it unless it sets `on`.
+  - **`domino check` warns `TRIGGER_REFIRES_ON_REFRESH`** for a non-content quest on a YouTube Shorts or TikTok tracker that runs on every observation: each refresh evaluates it again for every video. Use `content({ tracker })` with `performance` for a metric threshold.
+  - **`RelayProvider` takes `followWallet`.** `followWallet={false}` keeps a wallet sign-in's session when the wallet switches account or locks. The default, `true`, signs out as before.
+  - **Behavior change: `unauthenticated` ends the session.** A participant backend's (`createParticipantBackend`) 401 `unauthenticated` now ends the member's session in the SDK's experience, progress and activity observers, as `not-signed-in` does, instead of reporting an error. `RelayErrorCode.Unauthenticated` names it.
+  - **`enrollment` on `not-enrolled` skips.** Tracker trigger outcomes, `relay.quests.outcomes()` and automatic outcomes carry an optional `enrollment` on `not-enrolled` skips: `"quest"` for the quest's own enrollment, `"campaign"` for its campaign's. A campaign skip on a tracker trigger now says "Member has not enrolled in the quest's campaign".
+  - **Naming.** A leaderboard's `balance` is the ledger it ranks and its points pool's `ledger` the one the pool pays into; both are documented on the type. New fields that name a ledger are called `ledger`; existing `balance` fields keep their name in 1.x.
+
+- 561f4ab: Tiered rewards (`defineTieredReward`) can be listed, archived and restored. `management.resources.list()` and `domino resources list` list them in a new `tieredRewards` array (`managedTieredRewardSchema`), beside `offers`, and `domino tiered-rewards list` lists them alone. The experimental `management.tieredRewards.archive` and `unarchive` (`POST /management/v1/tiered-rewards/REWARD/archive|unarchive`) and `domino tiered-rewards archive|unarchive KEY --reason` archive and restore one in test, by key or ID, with `publish` permission; a promotion carries it to live, and Console **Settings → Resources** lists them with the same controls. Each returns `{ resource, changed }`, typed by `tieredRewardLifecycleResultSchema`. While one is archived, a deploy or promotion that would make a quest, offer or leaderboard prize newly grant it fails with 422 `tiered-reward-archived`, naming it in `reward`. What already granted it keeps granting it, its entitlements and handover keep working, and its key stays taken. Console **Rewards** leaves archived tiered rewards out of its rewards. Promotions now list tiered rewards as definitions of kind `tiered-reward`, and a rollback archives one the earlier promotion did not carry.
+- 8d79fd6: Four operations that had two public paths with different results now agree, or say how they differ:
+
+  - `management.deployments.promote`, `submit` and `reject` are deprecated, removed in 2.0.0. `promote` prepares a promotion of all of test and publishes nothing; its JSDoc now says so, and that the answered `id` is the promotion's, read with `promotions.get` and rejected by `deployments.get` and `publish`. Use `management.promotions.prepare()` with a client for test, and `promotions.reject` to decline. `submit` and `reject` act only on live deployments made before live refused them. `domino deploy --promote` is deprecated in favor of `domino promote --environment test`, and prints a warning naming it.
+  - `management.testMembers.acceptAnyway(member, { attempt, rules: "live", reason })` applies live `attempts.acceptAnyway`'s rules in test: `reason` is required, and an archived quest, a superseded attempt, a completion cooldown, an exhausted budget, an existing or revoked completion and a used key are refused with live's 409 codes, leaving the attempt and balances unchanged. The default (`rules: "test"`) still accepts those, with no reason, so a tester can get a test member unstuck. A `reason` is recorded with the decision either way. `domino test-members accept-anyway MEMBER ATTEMPT --live-rules --reason TEXT` sends it.
+  - `GET /v1/reward-deliveries` and `GET /management/v1/reward-deliveries` answer `items` beside `deliveries`, with the same rows, so `paginate((cursor) => relay.me.rewardDeliveries({ cursor }))` and `management.rewardDeliveries({ cursor })` read every page. Both clients fill `items` from `deliveries` when an older Relay sends only `deliveries`. `useExperience().deliveries` reads the role deliveries again on each `delivery.updated` activity event, so a role an operator revoked shows without waiting for focus.
+  - `defineLeaderboard` prints a warning, and `domino check` reports a `LEADERBOARD_TIES_DIFFER` warning, when a board's live `ties` differs from its `settle.ties`, including a board that sets only `settle.ties: "earliest"`, whose standings share ranks while its prizes pay first-to-reach. `leaderboardTiesWarning(board)` from `@domino-sdk/relay/authoring` returns that message, or null. `domino check`'s `diagnostics` now include warnings from data definitions beside its errors; only errors fail it.
+
+### Patch Changes
+
+- cc04dae: Browser apps bundle less of the SDK: an app's bundler now drops the schemas it never reads, such as tracker, wallet-read and management schemas, instead of keeping every schema in each module the client imports. `@domino-sdk/relay/react` adds about 41 KB less minified JavaScript (235 KB instead of 276 KB), and `@domino-sdk/relay/browser` about 42 KB less. Exports and behavior are unchanged.
+- 4842e30: Wording only. The app identity kind example is now `app:game`, including the validation message "Name an app identity kind like app:game: …", since a Telegram account is vouched for rather than modelled as an app identity. The JSDoc of `progress()`, `quests.claim`, `me.claim` and the quest interactions says which meaning of "progress" and "claim" each uses, and `domino test-members pass` help calls `progress(...)` quests counter quests. Examples use the `@XDevelopers` X account. The changelogs mark the versions that were never published to npm.
+- 425e4df: Internal: the "HTTPS, or plain HTTP on a loopback host" check for API URLs, sign-in URLs and portal proxy origins now has one implementation, shared through `@domino-sdk/relay/internal`. Published behavior is unchanged.
+- 8515f3f: `participantResponses` and `capabilityResponses` from `@domino-sdk/relay/schema` now build each reader on first use, as `managementResponses` and the field-tolerant tables already do. Each reader is built once and stays writable; types and parse results are unchanged.
+- 8278803: Relay now refuses a malformed personal API key ID with 400 `invalid-request` ("Use the key's ID, such as ak_…") on `DELETE /management/v1/tokens/:id` and `PUT /management/v1/tokens/:id/scope`. A key ID is `ak_` followed by letters, digits or `_`. IDs from `tokens.list()` and `domino tokens list` already have that form, so no working call changes: an unknown `ak_…` ID still revokes as a silent success, and a key that belongs to someone else is still refused with 403.
+- eb8572b: The testing kit's participant API answers an activity cursor it cannot read as Relay does: 400 `invalid-cursor`, "Invalid cursor. Start from the first page.", instead of `invalid-request`.
+
 ## 1.62.0
 
 ### Minor Changes
@@ -218,6 +286,8 @@
 
 ## 1.58.0
 
+_Not published to npm. Its changes first reached npm in 1.59.0._
+
 ### Minor Changes
 
 - 321763b: `management.discordRoles.list()` lists every Discord role the project's reward deliveries have granted in the environment, with the quests that requested it and its deliveries counted by status (`pending`, `delivered`, `failed`). It reads the whole delivery history, so a role granted only before the newest page of `management.rewardDeliveries` still appears. The response schema is `discordRoleRewardsSchema`.
@@ -228,6 +298,8 @@
 
 ## 1.57.0
 
+_Not published to npm. Its changes first reached npm in 1.59.0._
+
 ### Minor Changes
 
 - 7012d1c: Contract state and Cosmos staking reads in quest evaluators.
@@ -366,6 +438,8 @@ No changes in this release.
 
 ## 1.53.0
 
+_Not published to npm. Its changes first reached npm in 1.53.1._
+
 ### Minor Changes
 
 - 1b789ce: Test members can hold real X and Discord accounts. `management.testMembers.linkAccount(member, { actionId, provider, id })`, or `{ actionId, provider: "x", username }` resolved through X, links a public account to a test member without OAuth, and `unlinkAccount(member, { actionId, provider, id })` unlinks and frees it (`domino test-members link-account` and `unlink-account`). Quest code's `x.profile()`, `follows()`, `reposted()` and Discord role reads then answer for the real account, tracker records it authors are attributed to the member, and `testMembers.record` posts as it instead of refusing with `conflict`. An account another member holds is refused with `account-linked-elsewhere`; when its owner signs in with it or connects it, it moves to them. Reset unlinks it. Relay never writes to a test-linked account: a Discord role reward for one creates no delivery and is never sent, and the attempt's `history` entry carries `rewardsNotSent: [{ reason }]`. Test member results include an optional `accounts` list; managed member identities and `members.oauthAccounts` mark these accounts with an optional `testLinked` flag.
@@ -416,12 +490,16 @@ No changes in this release.
 
 ## 1.48.0
 
+_Not published to npm. Its changes first reached npm in 1.49.0._
+
 ### Minor Changes
 
 - 3213a87: Add group membership quest rewards. `groupMembership(group)` from `@domino-sdk/relay/authoring` takes a `defineGroup` handle and adds the member to that group when the completion's rewards are delivered, recording the completion as the reason in the audit history and checking prerequisite-only automatic quests. Publishing refuses a reward for a group that does not exist or is archived. Revoking the completion removes the membership unless an operator's add or another unrevoked completion also backs it; `CompletionRevocation.groups` reports each group with `stillMember`. Archiving a group that a quest rewards fails with `group-in-use`, naming the quests. SDK 1.x keeps the existing `kind: "tier"` reward envelope with an optional `reward.group` key (`groupReward` and `groupRewardSchema` in `@domino-sdk/relay/schema`), and quest views add an optional `reward.group` with the group's key and title.
 
 ## 1.47.0
 
+_Not published to npm. Its changes first reached npm in 1.49.0._
+
 ### Minor Changes
 
 - 7db52a2: Reward X posts only for approved creators. X does not allow apps that reward users for posting, so a deployment that publishes a quest rewarding X posts without an `inGroup` prerequisite now returns the warning `x-post-rewards-ungated` in `warnings`, naming the quests by key. It applies to an X tracker trigger that pays the post's author and to a content quest on an X tracker, when the quest declares rewards or an engagement rule credits it; `beneficiary: "inReplyTo"` quests are not affected. The deployment still publishes, `domino deploy` prints the warning, and Console shows it on the deployment with a link to **Groups**. Add `requires: [inGroup(group)]` with a group of approved creators you manage in Console **Groups**, with `domino groups`, or with `management.groups`.
@@ -473,12 +551,16 @@ No changes in this release.
 
 ## 1.41.0
 
+_Not published to npm. Its changes first reached npm in 1.42.0._
+
 ### Minor Changes
 
 - c8e46ee: `RelayProvider` reads the session and every query again when `window` receives a `domino:test-state-changed` event. Domino's staging test toolbar fires it after it changes test data under the page, such as moving a test member to the next day or sending a tracker record, so a staging app shows the new state without a reload. Apps that read Domino without `RelayProvider` can listen for the same event. See [trying quests on your staging site](https://console.domino.run/docs/use/quests#try-quests-on-your-staging-site).
 
 ## 1.40.0
 
+_Not published to npm. Its changes first reached npm in 1.42.0._
+
 ### Minor Changes
 
 - 68bf9eb: Promote test to live as one reviewed request ([ADR 0017](https://github.com/GetDomino/relay/blob/main/docs/adr/0017-live-changes-only-through-promotion.md)). A promotion makes live match test for every definition, code-defined and Console-authored, matched by authoring key, and carries the hosted app's active staged build. It lists environment bindings live lacks (integrations, webhooks, participant sign-in, app secrets) as warnings and never copies them.
@@ -521,6 +603,8 @@ No changes in this release.
 
 ## 1.37.0
 
+_Not published to npm. Its changes first reached npm in 1.37.1._
+
 ### Minor Changes
 
 - 701a0d8: Leaderboards can list every member. `defineLeaderboard({ includeUnscored: true })` adds the board's eligible members who have no qualifying points to its standings, `me`, `nearby` and `placement` reads, with a score of 0. They share one rank after every member who scored and are ordered by member ID; the board's group and exclusion group still apply. Settlements leave them out, so they win no prizes. Boards without the option rank as before.
@@ -536,6 +620,8 @@ No changes in this release.
 
 ## 1.35.0
 
+_Not published to npm. Its changes first reached npm in 1.36.0._
+
 ### Minor Changes
 
 - f7ba8d6: Create and change X search trackers without a deployment. `management.trackers.create({ key, title, query, window, refreshSeconds?, maxPages? })` (`POST /trackers`, `domino trackers create`) creates one as data in test, with the same validation as `defineTracker`; its first collection searches from `window.start`. `management.trackers.update(tracker, changes)` (`POST /trackers/:tracker/update`, `domino trackers update`) changes any field but the key, and a new query or window never searches the past. Both need `publish` permission, and live refuses them with `promotion-required`: a data tracker reaches live through a promotion from test, which is not available yet. Console **Trackers** creates and edits them too.
@@ -610,6 +696,8 @@ No changes in this release.
 
 ## 1.28.0
 
+_Not published to npm. Its changes first reached npm in 1.29.0._
+
 ### Minor Changes
 
 - 932e3c1: Add kind-keyed operator identity commands. `management.members.identityStates.list(member)` reads every identity a member proved (wallets, X, Discord and Telegram accounts, and `app:<name>` identities) with its link, revision, sign-in and allowed actions. `identityStates.unlink` and `relink` take an `identity` selector, an `expectedRevision` and a reason, and `identityStates.setSignIn` turns a wallet's sign-in on or off on its own. Each kind keeps its rules: wallet and account unlinks keep sign-in, app identity unlinks end that identity's sessions, and a Telegram account can now be relinked. The CLI adds `domino members identities`, `unlink-identity`, `relink-identity` and `identity-sign-in`.
@@ -620,10 +708,14 @@ No changes in this release.
 
 ## 1.27.1
 
+_Not published to npm. Its changes first reached npm in 1.29.0._
+
 No changes in this release.
 
 ## 1.27.0
 
+_Not published to npm. Its changes first reached npm in 1.29.0._
+
 ### Minor Changes
 
 - 072493d: Leaderboard exclusions are a group (DOM-205):
@@ -636,6 +728,8 @@ No changes in this release.
 
 ## 1.26.0
 
+_Not published to npm. Its changes first reached npm in 1.29.0._
+
 ### Minor Changes
 
 - 91d7ad0: Relay keeps quest submissions (DOM-268). See [ADR 0014](https://github.com/GetDomino/relay/blob/main/docs/adr/0014-relay-keeps-quest-submissions.md).
@@ -647,10 +741,14 @@ No changes in this release.
 
 ## 1.25.1
 
+_Not published to npm. Its changes first reached npm in 1.29.0._
+
 No changes in this release.
 
 ## 1.25.0
 
+_Not published to npm. Its changes first reached npm in 1.29.0._
+
 ### Minor Changes
 
 - 55d08ae: Client SDK paper cuts (DOM-160):
@@ -742,6 +840,8 @@ No changes in this release.
 
 ## 1.17.0
 
+_Not published to npm. Its changes first reached npm in 1.18.0._
+
 ### Minor Changes
 
 - d8a5731: Add ordered quest presentation steps with HTTPS link actions, images and alt text, and account or wallet hints. Collection declarations now accept description, image and alt text. Participant reads and React hooks return these optional fields in the published collection order. Console can edit and reset quest presentation and edit collection details. Presentation changes do not change verification.
@@ -756,6 +856,8 @@ No changes in this release.
 
 ## 1.15.1
 
+_Not published to npm. Its changes first reached npm in 1.16.0._
+
 No changes in this release.
 
 ## 1.15.0
@@ -776,6 +878,8 @@ No changes in this release.
 
 ## 1.13.0
 
+_Not published to npm. Its changes first reached npm in 1.14.0._
+
 ### Minor Changes
 
 - c3601dd: `RelayProvider` now follows the signed-in member's activity feed instead of polling the whole quest experience every 1.5 seconds. Each event reads again only the hooks it changes: an accepted attempt reads the experience, outcomes, rewards, balances, leaderboards, profiles, referral progress and offers; a points award reads balances, leaderboards, offers and deliveries; and so on. The whole experience is read every 30 seconds for changes no event announces, and as the fallback when the feed is unavailable. An idle signed-in tab drops from about 124 requests a minute to about 14. Pass `polling={{ activityMs, snapshotMs }}` to change either interval. `useEntitlements` and `useDeliveries` now poll every 30 seconds instead of 5, since feed events refresh them.
@@ -790,12 +894,16 @@ No changes in this release.
 
 ## 1.12.0
 
+_Not published to npm. Its changes first reached npm in 1.14.0._
+
 ### Minor Changes
 
 - 80f823a: Add `@domino-sdk/relay/testing`, a kit for unit-testing quests locally. `runQuest(quest, { input, tracker, settings, facts, now, seed })` evaluates a quest the way Relay's hosted runtime does: its published settings, rewards and review switch, a frozen clock, seeded randomness, fake answers for `ctx.member`, `ctx.wallet`, `ctx.x`, `ctx.discord`, `ctx.trackers`, `ctx.images` and `ctx.review` checked against Relay's capability contracts, and the reward bounds Relay enforces. `trackerObservation` and `trackerPage` build typed tracker input, `expectAccept`, `expectReject`, `expectReview`, `expectDefer` and `expectProgress` assert decisions, and `createTestContext` returns the host context `quest.evaluate` takes. `buildQuest` now refuses a quest bundle that imports the testing kit. Starters include quest unit tests in `tests/quests.test.ts`.
 
 ## 1.11.2
 
+_Not published to npm. Its changes first reached npm in 1.14.0._
+
 ### Patch Changes
 
 - 7160db6: Include points received before a leaderboard cutoff even when their transaction commits just afterward. New point receipts use database time, and freeze waits for in-flight point writers. Existing frozen settlements remain unchanged.
@@ -838,6 +946,8 @@ No changes in this release.
 
 ## 1.8.0
 
+_Not published to npm. Its changes first reached npm in 1.9.0._
+
 ### Minor Changes
 
 - f19da0d: Add canonical archive, unarchive, pause and resume methods and CLI commands for management resources. Keep older lifecycle and feature-specific publication forms working as deprecated 1.x APIs.
@@ -1840,6 +1950,8 @@ No changes in this release.
 
 ## 0.23.0
 
+_Not published to npm. Its changes first reached npm in 0.23.1._
+
 ### Minor Changes
 
 - 49fa0fd: Apps can now match the ledger and tiered reward IDs that reads return to the keys they declared.
@@ -1861,6 +1973,8 @@ No changes in this release.
 
 ## 0.22.0
 
+_Not published to npm. Its changes first reached npm in 0.23.1._
+
 ### Minor Changes
 
 - 2614ad4: Add `ctx.images` for quest evaluators: `inspect`, `compare` (perceptual hash distances), `review` (AI judgement over up to four images), `extract` (typed fields read from a screenshot) and `seen` (other participants' near-duplicate images). Images are named by reference: the attempt's photo evidence, the linked X profile picture, an X post's attached image, or a reference image listed under the new `images` key in `relay.json` (JPEG, PNG or WebP, up to 5 MiB each and 10 per deployment) and published with `domino deploy`, which uploads new files directly to storage and sends only their hashes. New snippets `x-profile-picture`, `unique-photo` and `community-screenshot` install complete quests with operator-tunable similarity thresholds. `ctx.x.post()` results now include attached `media`.
@@ -1869,10 +1983,14 @@ No changes in this release.
 
 ## 0.21.0
 
+_Not published to npm. Its changes first reached npm in 0.23.1._
+
 No changes in this release.
 
 ## 0.20.0
 
+_Not published to npm. Its changes first reached npm in 0.23.1._
+
 ### Minor Changes
 
 - 2ff82fb: Remove `reviews.list` and `members.list` from `createRelayClient` and their `ReviewListOptions` and `MemberListOptions` types. Since the 0.10.0 release the participant API no longer serves `GET /v1/reviews` or `GET /v1/members`, so these calls fail with every SDK version; removing the methods turns that runtime failure into a type error.
@@ -1974,6 +2092,8 @@ No changes in this release.
 
 ## 0.16.0
 
+_Not published to npm. Its changes first reached npm in 0.16.1._
+
 ### Minor Changes
 
 - abc6358: Add `ctx.review.text({ text, criteria })` with typed pass, fail, and unclear results for authored quest decisions. Review verified content such as X tracker posts using the existing backend AI configuration. Validated results are captured and reused across retries; provider failures remain errors.

package/dist/{accounts-CCqCKCVx.d.ts → accounts-nz3mzfRQ.d.ts}

@@ -1,6 +1,6 @@
 import * as z from 'zod';
-import { R as ResourceHandle, G as GroupHandle } from './tracker-data-Hb1uQnk5.js';
-import { S as SolanaIdlSource } from './wallet-DTO7SXj7.js';
+import { R as ResourceHandle, G as GroupHandle } from './tracker-data-esm3WG8R.js';
+import { S as SolanaIdlSource } from './wallet-B7e06v4m.js';
 
 /**
  * The modules this SDK knows a quest can declare to enable provider readers. Project connections
@@ -24,6 +24,7 @@ type KnownIntegrationModuleProvider = EvaluatorIntegrationProvider;
  * does not; publishing refuses a provider Relay does not know with `unknown-integration-module`.
  */
 type IntegrationModuleProvider = KnownIntegrationModuleProvider | (string & {});
+/** An integration module provider's name, such as `discord`: lowercase letters, digits and hyphens. */
 declare const integrationModuleProviderSchema: z.ZodType<IntegrationModuleProvider>;
 /** A module this SDK has readers for. Evaluator contexts type the readers of these alone. */
 type KnownIntegrationModule = {
@@ -3451,6 +3452,7 @@ declare const rewardEntrySchema: z.ZodObject<{
     type: z.ZodType<RewardType, unknown, z.core.$ZodTypeInternals<RewardType, unknown>>;
     data: z.ZodRecord<z.ZodString, z.ZodJSONSchema>;
 }, z.core.$strip>;
+/** One reward as the open sibling of a `rewards` array lists it: its kind and the rest of it. */
 type RewardEntry = z.infer<typeof rewardEntrySchema>;
 declare function rewardKey(reward: Reward): string;
 declare const triggerSchema: z.ZodUnion<readonly [z.ZodObject<{
@@ -3574,7 +3576,11 @@ declare const textResultSchema: z.ZodObject<{
     reason: z.ZodString;
 }, z.core.$strict>;
 type TextResult = z.infer<typeof textResultSchema>;
-/** Bounds for successful non-terminal evaluator decisions, independent of failure retries. */
+/**
+ * Bounds for successful non-terminal evaluator decisions, independent of failure retries.
+ *
+ * @deprecated Use `limits.defer`, which a 1.x release can raise.
+ */
 declare const deferPolicy: {
     readonly minRetryAfterMs: 1000;
     readonly maxRetryAfterMs: 3600000;
@@ -3586,6 +3592,8 @@ declare const deferPolicy: {
  * Bounds of a quest's retry cooldown (`retryCooldownMs`): how long a member waits after a rejected
  * attempt before submitting the quest again. A completion cooldown (`completionCooldownMs`) has the
  * same bounds. Unrelated to `deferPolicy`, which reschedules an evaluation that has not finished.
+ *
+ * @deprecated Use `limits.retryCooldown`, which a 1.x release can raise.
  */
 declare const retryCooldownPolicy: {
     readonly minMs: 1000;
@@ -3964,6 +3972,7 @@ declare const questDescriptionSchema: z.ZodObject<{
         multiline: z.ZodBoolean;
         picker: z.ZodOptional<z.ZodString>;
         decimals: z.ZodOptional<z.ZodNumber>;
+        secret: z.ZodOptional<z.ZodLiteral<true>>;
         label: z.ZodString;
         description: z.ZodOptional<z.ZodString>;
     }, z.core.$strict>, z.ZodObject<{
@@ -4458,6 +4467,7 @@ declare const storedQuestDescriptionSchema: z.ZodObject<{
         multiline: z.ZodBoolean;
         picker: z.ZodOptional<z.ZodString>;
         decimals: z.ZodOptional<z.ZodNumber>;
+        secret: z.ZodOptional<z.ZodLiteral<true>>;
         label: z.ZodString;
         description: z.ZodOptional<z.ZodString>;
     }, z.core.$strict>, z.ZodObject<{
@@ -4854,6 +4864,7 @@ declare const publishedReleaseSchema: z.ZodObject<{
         multiline: z.ZodBoolean;
         picker: z.ZodOptional<z.ZodString>;
         decimals: z.ZodOptional<z.ZodNumber>;
+        secret: z.ZodOptional<z.ZodLiteral<true>>;
         label: z.ZodString;
         description: z.ZodOptional<z.ZodString>;
     }, z.core.$strict>, z.ZodObject<{
@@ -5252,6 +5263,7 @@ declare const publishedReleaseSchema: z.ZodObject<{
         source: z.ZodType<SolanaIdlSource>;
         idl: z.ZodRecord<z.ZodString, z.ZodJSONSchema>;
     }, z.core.$strict>>>;
+    withheldSettings: z.ZodOptional<z.ZodArray<z.ZodString>>;
 }, z.core.$strict>;
 type PublishedRelease = z.infer<typeof publishedReleaseSchema>;
 declare const templateSchema: z.ZodObject<{
@@ -5364,6 +5376,7 @@ declare const templateSchema: z.ZodObject<{
             multiline: z.ZodBoolean;
             picker: z.ZodOptional<z.ZodString>;
             decimals: z.ZodOptional<z.ZodNumber>;
+            secret: z.ZodOptional<z.ZodLiteral<true>>;
             label: z.ZodString;
             description: z.ZodOptional<z.ZodString>;
         }, z.core.$strict>, z.ZodObject<{
@@ -7253,6 +7266,7 @@ declare const snapshotSchema: z.ZodObject<{
             multiline: z.ZodBoolean;
             picker: z.ZodOptional<z.ZodString>;
             decimals: z.ZodOptional<z.ZodNumber>;
+            secret: z.ZodOptional<z.ZodLiteral<true>>;
             label: z.ZodString;
             description: z.ZodOptional<z.ZodString>;
         }, z.core.$strict>, z.ZodObject<{
@@ -7651,6 +7665,7 @@ declare const snapshotSchema: z.ZodObject<{
             source: z.ZodType<SolanaIdlSource>;
             idl: z.ZodRecord<z.ZodString, z.ZodJSONSchema>;
         }, z.core.$strict>>>;
+        withheldSettings: z.ZodOptional<z.ZodArray<z.ZodString>>;
     }, z.core.$strict>>;
     completions: z.ZodArray<z.ZodObject<{
         key: z.ZodDefault<z.ZodString>;
@@ -8342,6 +8357,7 @@ declare const SignInProvider: {
 };
 /** A provider a member signs in with or links an account of. A newer Relay may name others. */
 type SignInProvider = KnownSignInProvider | (string & {});
+/** A provider name as responses return it: open, so a provider a newer Relay adds still parses. */
 declare const signInProviderSchema: z.ZodType<SignInProvider>;
 /** A provider name as requests send it; Relay refuses one it does not offer. */
 declare const signInProviderInputSchema: z.ZodString;
@@ -8364,6 +8380,7 @@ declare const signInProviderOptionSchema: z.ZodObject<{
     provider: z.ZodType<SignInProvider, unknown, z.core.$ZodTypeInternals<SignInProvider, unknown>>;
     configured: z.ZodBoolean;
 }, z.core.$strip>;
+/** One sign-in provider the platform has, and whether Domino configured it. */
 type SignInProviderOption = z.infer<typeof signInProviderOptionSchema>;
 /**
  * The member's account on one sign-in provider, as `AccountConnection` describes the closed list's,
@@ -8378,6 +8395,7 @@ declare const signInAccountSchema: z.ZodObject<{
     subject: z.ZodNullable<z.ZodString>;
     revision: z.ZodNumber;
 }, z.core.$strip>;
+/** The member's account on one sign-in provider; `subject` is null while disconnected. */
 type SignInAccount = z.infer<typeof signInAccountSchema>;
 declare const discordMemberInputSchema: z.ZodObject<{}, z.core.$strict>;
 declare const discordMessageInputSchema: z.ZodObject<{

package/dist/{attempt-captures-Cm-5G0PC.d.ts → attempt-captures-DMi8oR9T.d.ts}

@@ -1,4 +1,4 @@
-import { O as OpenIdentityKind } from './tracker-data-Hb1uQnk5.js';
+import { O as OpenIdentityKind } from './tracker-data-esm3WG8R.js';
 import * as z from 'zod';
 
 /** One capability call of the captured evaluation run, as Relay stored it. */

package/dist/authoring.d.ts

@@ -1,18 +1,21 @@
-import { _ as EngagementBudget, $ as leaderboardDefinitionSchema, Z as AuthoringIdentity, a0 as pointLedgerDeclarationSchema, a1 as referralAuthoringSchema, a2 as discordMessagesSourceSchema, a3 as DiscordMessageData, a4 as DiscordMessageTextData, a5 as discordReactionsSourceSchema, a6 as DiscordReactionData, a7 as KnownIntegrationModule, P as PointBalance, C as CampaignDefinition, a8 as TextReviewInput, a9 as TextResult, aa as PhotoResult, ab as DiscordReader, ac as Decision, ad as rewardSchema, ae as triggerSchema, af as IntegrationModule, D as QuestPresentation, d as AvailabilityWindow, F as QuestProfile, G as QuizEvidence, W as IntegrationModuleProvider, ag as TieredRewardDefinition } from './accounts-CCqCKCVx.js';
-export { ah as KnownIntegrationModuleProvider, ai as defineCampaign, aj as defineGroup } from './accounts-CCqCKCVx.js';
-import { x as xContentBodySchema, I as IdentityKind, g as customSourceSchema, W as WithRecordData, h as WithContent, i as WithAccountRoles, R as ResourceHandle, Q as QuestHandle, L as LedgerReference, G as GroupHandle, j as TrackerSource, k as trackerDefinitionSchema, l as Tracker, m as TrackerData, S as SourceRoles, n as LedgerHandle, f as TrackerDataSchema, o as xSearchSourceSchema, X as XTweet, p as XContentMetric, q as TrackerTriggerPolicy, r as Where, M as MemberIdentity, u as ReferralHandle, v as TrackerTriggerContext, y as TrackerReader, z as TrackerTriggerMode, A as RoleOf, B as WhereSetting, C as ContentBody, D as BadgeHandle, E as ContentMetricName } from './tracker-data-Hb1uQnk5.js';
-export { F as LedgerSetting, H as TrackerPage, J as TrackerReadQuery, N as trackerDataSchema, P as trackerTriggerContextSchema } from './tracker-data-Hb1uQnk5.js';
-import { R as ResourceSource, S as Setting, A as AmountSetting, B as BalanceChain, M as MemberCompletion, a as Budget, b as AuthorBudget, c as BoundSettings, d as Announcement } from './capability-error-DFMwSuSf.js';
-export { C as CapabilityError, e as CapabilityErrorCode, D as DashboardInput, f as DashboardPanelInput, T as TikTokVideoBody, g as TikTokVideoMetric, Y as YouTubeShortBody, h as YouTubeShortMetric, i as capabilityErrorCodes, j as defineDashboard } from './capability-error-DFMwSuSf.js';
-import { N as NftCollection, o as ContractCall, p as ContractEvent, q as SolanaProgram, r as WalletBalanceSourceQuery, s as WalletTransaction, t as WalletInstruction, e as ProfileReferral, u as WalletReader } from './wallet-DTO7SXj7.js';
-export { v as ContractCallParts, w as ContractCallReturnType, x as ContractEventInput, y as ContractEventParts, z as ContractFunction, B as CosmosDenom, a as CosmosNetwork, E as EvmChainId, D as NftCollectionParts, F as NftStandard, G as WalletBalance, H as WalletBalanceChange, I as WalletBalanceQuery, J as WalletBalanceSample, K as WalletCall, M as WalletCallArgument, Q as WalletCallQuery, R as WalletDelegations, T as WalletDelegationsQuery, U as WalletEventCondition, V as WalletEventValue, X as WalletEvents, Y as WalletEventsQuery, Z as WalletNfts, _ as WalletNftsQuery, $ as WalletTransactions, a0 as WalletTransactionsQuery, a1 as cosmosDenomSchema, a2 as cosmosNetworkSchema, a3 as isContractCall, a4 as isContractEvent, a5 as isEvmChainId, a6 as isNftCollection, a7 as isSolanaProgram, a8 as maxWalletEventLogs, a9 as maxWalletEventLookback, aa as maxWalletTransactionLookback, ab as maxWalletTransactions, ac as parseContractCall, ad as parseContractEvent, ae as parseContractFunction, af as parseNftCollection } from './wallet-DTO7SXj7.js';
+import { _ as EngagementBudget, $ as leaderboardDefinitionSchema, Z as AuthoringIdentity, a0 as pointLedgerDeclarationSchema, a1 as referralAuthoringSchema, a2 as discordMessagesSourceSchema, a3 as DiscordMessageData, a4 as DiscordMessageTextData, a5 as discordReactionsSourceSchema, a6 as DiscordReactionData, a7 as KnownIntegrationModule, P as PointBalance, C as CampaignDefinition, a8 as TextReviewInput, a9 as TextResult, aa as PhotoResult, ab as DiscordReader, ac as Decision, ad as rewardSchema, ae as triggerSchema, af as IntegrationModule, D as QuestPresentation, d as AvailabilityWindow, F as QuestProfile, G as QuizEvidence, W as IntegrationModuleProvider, ag as TieredRewardDefinition } from './accounts-nz3mzfRQ.js';
+export { ah as KnownIntegrationModuleProvider, ai as defineCampaign, aj as defineGroup } from './accounts-nz3mzfRQ.js';
+import { x as xContentBodySchema, I as IdentityKind, j as customSourceSchema, W as WithRecordData, k as WithContent, l as WithAccountRoles, R as ResourceHandle, Q as QuestHandle, L as LedgerReference, G as GroupHandle, m as TrackerSource, n as trackerDefinitionSchema, o as Tracker, p as TrackerData, q as SourceRoles, r as LedgerHandle, i as TrackerDataSchema, u as xSearchSourceSchema, X as XTweet, v as XContentMetric, y as TrackerTriggerPolicy, z as Where, M as MemberIdentity, A as ReferralHandle, B as TrackerTriggerContext, C as TrackerReader, D as TrackerTriggerMode, E as RoleOf, F as WhereSetting, H as ContentBody, J as BadgeHandle, N as ContentMetricName } from './tracker-data-esm3WG8R.js';
+export { P as LedgerSetting, U as TrackerPage, V as TrackerReadQuery, Y as trackerDataSchema, Z as trackerTriggerContextSchema } from './tracker-data-esm3WG8R.js';
+import { R as ResourceSource, M as MemberCompletion, B as Budget, A as AuthorBudget, a as Announcement } from './capability-error-CuI_F7yM.js';
+export { C as CapabilityError, b as CapabilityErrorCode, T as TikTokVideoBody, c as TikTokVideoMetric, Y as YouTubeShortBody, d as YouTubeShortMetric, e as capabilityErrorCodes } from './capability-error-CuI_F7yM.js';
+import { N as NftCollection, p as ContractCall, q as ContractEvent, r as SolanaProgram, s as WalletBalanceSourceQuery, t as WalletTransaction, u as WalletInstruction, e as ProfileReferral, v as WalletReader } from './wallet-B7e06v4m.js';
+export { w as ContractCallParts, x as ContractCallReturnType, y as ContractEventInput, z as ContractEventParts, B as ContractFunction, D as CosmosDenom, a as CosmosNetwork, E as EvmChainId, F as NftCollectionParts, G as NftStandard, H as WalletBalance, I as WalletBalanceChange, o as WalletBalanceQuery, J as WalletBalanceSample, K as WalletCall, M as WalletCallArgument, Q as WalletCallQuery, R as WalletDelegations, T as WalletDelegationsQuery, U as WalletEventCondition, V as WalletEventValue, X as WalletEvents, Y as WalletEventsQuery, Z as WalletNfts, _ as WalletNftsQuery, $ as WalletTransactions, a0 as WalletTransactionsQuery, a1 as cosmosDenomSchema, a2 as cosmosNetworkSchema, a3 as isContractCall, a4 as isContractEvent, a5 as isEvmChainId, a6 as isNftCollection, a7 as isSolanaProgram, a8 as maxWalletEventLogs, a9 as maxWalletEventLookback, aa as maxWalletTransactionLookback, ab as maxWalletTransactions, ac as parseContractCall, ad as parseContractEvent, ae as parseContractFunction, af as parseNftCollection } from './wallet-B7e06v4m.js';
 import * as z from 'zod';
 export { z } from 'zod';
-import { g as badgeDeclarationSchema, h as OfferAuthoring, B as Badge } from './offers-DhAtss4_.js';
+import { g as badgeDeclarationSchema, h as OfferAuthoring, B as Badge } from './offers-CYeN_I0Y.js';
 import { a as StreakPolicy, Q as QuizContent } from './streaks-0YuipsUQ.js';
-import { e as TelegramReader, P as Prerequisite, b as TextEvidence, U as UrlEvidence, c as TextOptions, d as UrlOptions } from './submission-input-DHGKhXfp.js';
-export { f as TelegramChatMember, g as TelegramChatMemberStatus, h as TelegramConnection, i as TelegramMessageData, j as TelegramReactionData, k as balanceAtLeast, l as completed, m as inGroup } from './submission-input-DHGKhXfp.js';
-import { I as ImageReader, X as XReader } from './analytics-BwAKLi7O.js';
+import { S as Setting, A as AmountSetting, B as BalanceChain, a as BoundSettings } from './dashboards-CLemT6kj.js';
+export { D as DashboardInput, b as DashboardPanelInput, e as defineDashboard } from './dashboards-CLemT6kj.js';
+import { e as TelegramReader, P as Prerequisite, b as TextEvidence, U as UrlEvidence, c as TextOptions, d as UrlOptions } from './submission-input-DZCbjQUH.js';
+export { f as TelegramChatMember, g as TelegramChatMemberStatus, h as TelegramConnection, i as TelegramMessageData, j as TelegramReactionData, k as balanceAtLeast, l as completed, m as inGroup } from './submission-input-DZCbjQUH.js';
+import { I as ImageReader, X as XReader } from './limits-kNzYdZ00.js';
+export { L as Limits, l as limits } from './limits-kNzYdZ00.js';
 export { f as formatUnits, p as parseUnits } from './units-CwgsPB_r.js';
 
 declare function defineBadge(input: z.input<typeof badgeDeclarationSchema>): {
@@ -309,6 +312,20 @@ declare function earned(options?: Omit<EarnedScore, "kind" | "quests"> & {
     kind: "earned";
 };
 type SettlementInput = NonNullable<LeaderboardInput["settle"]>;
+/**
+ * Why `board`'s live standings order equal scores differently from its settlement, or null when
+ * they agree or it has no settlement. `ties` defaults to `"shared"` and is not taken from
+ * `settle.ties`, so a board that sets only `settle.ties: "earliest"` shows shared ranks live and
+ * pays first-to-reach. `defineLeaderboard` and `domino check` warn with it. Exported from `/authoring`, not `/schema`, to keep
+ * the schema entry's browser size down.
+ */
+declare function leaderboardTiesWarning(board: {
+    key?: string;
+    ties?: string;
+    settle?: {
+        ties: string;
+    };
+}): string | null;
 declare function defineLeaderboard(input: Omit<LeaderboardInput, "key" | "id" | "balance" | "group" | "score" | "settle"> & AuthoringIdentity & {
     ledger: LedgerReference;
     group?: GroupHandle;
@@ -774,12 +791,21 @@ declare const settings: {
         }, z.core.$strict>>;
         correct: z.ZodString;
     }, z.core.$strict>>>>;
+    /**
+     * Free text. With `secret: true`, operators set the value in Console and it never leaves Relay:
+     * management responses, `domino deploy` and Console withhold it, and the quest's code reads it as
+     * usual. A secret setting has no default, so it reads `""` until an operator sets it.
+     */
     text(options: Label & {
-        default: string;
         minLength?: number;
         maxLength?: number;
         multiline?: boolean;
-    }): Setting<"text", z.ZodDefault<z.ZodString>>;
+    } & ({
+        default: string;
+        secret?: false;
+    } | {
+        secret: true;
+    })): Setting<"text", z.ZodDefault<z.ZodString>>;
     /**
      * A Telegram chat the project connected, by its numeric ID: Console lists the connected chats
      * to choose from. Pass it to `ctx.telegram.member({ chat })`.
@@ -1025,10 +1051,11 @@ type TrackerTriggerInput<T extends Tracker = Tracker, W extends Where<TrackerDat
     /** The tracker handle `defineTracker` returns. */
     tracker: T;
     /**
-     * Which observations fire. `"new-record"`: each record's first observation (the default for X
-     * and Discord trackers, where it means each newly collected post, message or reaction).
-     * `"new-observation"`: each observation that becomes its record's current one (the default for
-     * custom trackers). `"data-changed"`: a
+     * Which observations fire. `"new-record"`: each record's first observation (the default for X,
+     * Discord and Telegram trackers, where it means each newly collected post, message or reaction,
+     * so a removed and re-added Telegram reaction does not fire again). `"new-observation"`: each
+     * observation that becomes its record's current one (the default for other custom trackers,
+     * YouTube and TikTok included, where every refresh observes each video again). `"data-changed"`: a
      * new record, or a current observation whose `data` differs from the previous one.
      */
     on?: TrackerTriggerMode;
@@ -1206,7 +1233,12 @@ type ProgressDefinition<C> = {
     window?: ReturnType<typeof calendar>;
     repeat?: "once" | "repeat";
 };
-/** Accepted evidence contributes once under its distinct key; Relay commits progress with rewards. */
+/**
+ * A counter completion policy: accepted evidence contributes once under its distinct key, and
+ * the quest completes when `goal` distinct actions fall in the window. Relay commits the count
+ * with rewards. Not evaluator progress (`decision.progress`), which reports how far a member is
+ * toward a target the evaluator measures and never counts toward a counter.
+ */
 declare const progress: (definition: ProgressDefinition<KeyedContext>) => {
     distinct: (ctx: KeyedContext) => string;
     kind: "progress";
@@ -1774,6 +1806,7 @@ declare const defineQuest: <T extends Record<string, Setting>, const G extends T
             label: string;
             picker?: string | undefined;
             decimals?: number | undefined;
+            secret?: true | undefined;
             description?: string | undefined;
         } | {
             kind: "integer";
@@ -2274,6 +2307,7 @@ declare const defineQuestType: <T extends Record<string, Setting>, const G exten
             label: string;
             picker?: string | undefined;
             decimals?: number | undefined;
+            secret?: true | undefined;
             description?: string | undefined;
         } | {
             kind: "integer";
@@ -2564,4 +2598,4 @@ declare const defineQuestType: <T extends Record<string, Setting>, const G exten
     }): Promise<Decision>;
 } & ResourceHandle<"quest">;
 
-export { AmountSetting, BalanceChain, ContentBody, type ContentData, ContentMetricName, type ContentTrigger, type ContentTriggerInput, ContractCall, ContractEvent, DiscordMessageData, DiscordMessageTextData, DiscordReactionData, DiscordReader, type EvaluationCalendar, type EvaluationCalendarDay, type EvaluationContext, type EvaluationMember, GroupHandle, IdentityKind, ImageReader, IntegrationModule, IntegrationModuleProvider, type KeyedContext, type KeyedOptions, KnownIntegrationModule, LedgerHandle, LedgerReference, MemberCompletion, type MemberCompletionQuery, MemberIdentity, NftCollection, type Outcome, type PerformanceContext, type PerformanceOutcome, PointBalance, ProfileReferral, QuestHandle, type QuestKeyedContext, ReferralHandle, RoleOf, Setting, SolanaProgram, TelegramReader, Tracker, TrackerData, TrackerDataSchema, TrackerReader, type TrackerTrigger, TrackerTriggerContext, type TrackerTriggerInput, type TriggerAdmission, WalletBalanceSourceQuery, WalletInstruction, WalletReader, WalletTransaction, Where, type XContentBody, XReader, automatic, automaticFulfillment, badge, budget, calendar, content, count, customSource, decision, defineBadge, defineEngagementReward, defineLeaderboard, defineLedger, defineOffer, defineQuest, defineQuestType, defineReferral, defineTieredReward, defineTracker, discord, earned, evaluators, evidence, groupMembership, instruction, invoked, keyed, manual, once, pointLedgers, points, progress, questCompleted, received, rolling, settings, spent, staffHandover, streak, swapped, telegram, tiktok, untracked, wallet, x, youtube };
+export { AmountSetting, BalanceChain, ContentBody, type ContentData, ContentMetricName, type ContentTrigger, type ContentTriggerInput, ContractCall, ContractEvent, DiscordMessageData, DiscordMessageTextData, DiscordReactionData, DiscordReader, type EvaluationCalendar, type EvaluationCalendarDay, type EvaluationContext, type EvaluationMember, GroupHandle, IdentityKind, ImageReader, IntegrationModule, IntegrationModuleProvider, type KeyedContext, type KeyedOptions, KnownIntegrationModule, LedgerHandle, LedgerReference, MemberCompletion, type MemberCompletionQuery, MemberIdentity, NftCollection, type Outcome, type PerformanceContext, type PerformanceOutcome, PointBalance, ProfileReferral, QuestHandle, type QuestKeyedContext, ReferralHandle, RoleOf, Setting, SolanaProgram, TelegramReader, Tracker, TrackerData, TrackerDataSchema, TrackerReader, type TrackerTrigger, TrackerTriggerContext, type TrackerTriggerInput, type TriggerAdmission, WalletBalanceSourceQuery, WalletInstruction, WalletReader, WalletTransaction, Where, type XContentBody, XReader, automatic, automaticFulfillment, badge, budget, calendar, content, count, customSource, decision, defineBadge, defineEngagementReward, defineLeaderboard, defineLedger, defineOffer, defineQuest, defineQuestType, defineReferral, defineTieredReward, defineTracker, discord, earned, evaluators, evidence, groupMembership, instruction, invoked, keyed, leaderboardTiesWarning, manual, once, pointLedgers, points, progress, questCompleted, received, rolling, settings, spent, staffHandover, streak, swapped, telegram, tiktok, untracked, wallet, x, youtube };