@thinkingai/ae-cli 6.0.48-customer.1 → 6.1.0-project-role-upsert.1

package/skills/ae-experiment-design/references/experiment-sdk-contract.md

@@ -0,0 +1,100 @@
+# Experiment SDK Contract
+
+Read this reference when defining Feature retrieval, assignment, defaults, caching, or cross-platform behavior.
+
+## Required sequence
+
+1. Initialize the analytics SDK.
+2. Initialize the Remote Config dependency.
+3. Initialize the experiment SDK with the same verified app and server environment.
+4. Establish the stable assignment identity before the first Feature evaluation.
+5. Fetch or read the Feature using the expected value type.
+6. Apply the assigned behavior.
+7. Record exposure only when the behavior becomes visible or effective.
+8. Report outcome events with an identity that can join to exposure.
+
+The verified Android and iOS experiment documents explicitly require analytics initialization before experiment initialization. Apply the same ordering to JavaScript unless a newer verified main document states otherwise.
+
+## Feature contract
+
+Define the following before implementation:
+
+| Field | Requirement |
+|---|---|
+| Feature key | Stable, environment-correct, and resolved from the real platform asset |
+| Value type | String, number, Boolean, or JSON; match the platform Feature |
+| Default | Typed, safe for control behavior, and owned by the application |
+| Assignment unit | Stable device, account, role, or another verified identifier |
+| Evaluation owner | Client, server, or one side of a hybrid architecture |
+| Exposure owner | Exactly one component |
+| Outcome join | Same stable identity or a verified merge path |
+
+Do not use an empty or null fallback when a safe control behavior is required. A default is product behavior, not only an SDK parameter.
+
+## Assignment identity
+
+Resolve:
+
+- pre-login identity;
+- post-login identity;
+- account switching;
+- multiple roles under one account;
+- device-to-account merge or alias behavior;
+- server/client identity consistency.
+
+If a custom bucket ID is used, set it before fetching or reading the Feature. The verified client SDKs expose a custom bucket map, but the exact key and value semantics must match the experiment configuration. Do not assume that the literal example `bucket_id -> account_id` is the only supported schema.
+
+Do not use custom request parameters as a hidden substitute for assignment identity unless the platform contract explicitly defines that behavior.
+
+## Fetch and cache
+
+Define:
+
+- initial fetch timing;
+- request timeout;
+- retry and backoff;
+- last-known-good cache;
+- cache freshness;
+- whether a stale value may be used;
+- whether a mid-session update can change behavior;
+- control fallback when no value is available.
+
+Avoid UI flicker and treatment changes after the user has already seen control. For a session-scoped experience, freeze the evaluated value for the session unless the product requirement explicitly allows live changes.
+
+Remote Config documentation establishes the general fallback order for configuration keys:
+
+1. remote value;
+2. local default;
+3. empty when neither exists.
+
+For an experiment Feature, prefer an explicit typed application default even when the platform SDK offers an overload or local default store.
+
+## Exposure
+
+Configuration retrieval is not exposure. A getter that automatically reports exposure is valid only if calling the getter coincides with applying the assigned behavior. If the application reads early, preloads, branches later, or may discard the result, disable automatic exposure and use manual exposure at the true activation point.
+
+Read `exposure-contract.md` before finalizing exposure behavior.
+
+## Custom fetch parameters
+
+Use custom fetch parameters only for fields supported by the client configuration channel. Document:
+
+- field name and type;
+- source of truth;
+- whether it affects targeting, diagnostics, or payload enrichment;
+- privacy classification;
+- behavior when absent.
+
+Never place secrets or unstable session values in custom fetch parameters.
+
+## Acceptance checks
+
+- Analytics, Remote Config, and experiment SDK versions are compatible.
+- Initialization uses the intended app and environment.
+- The control default is returned when configuration is unavailable.
+- A test identity receives a stable group across sessions.
+- Client and server agree for the same assignment identity.
+- Exposure occurs once at treatment activation, not at preload.
+- Outcome events join to exposure.
+- Account switching does not leak the previous account’s assignment.
+- Debug logging and test mode are disabled or production-safe before release.

package/skills/ae-experiment-design/references/exposure-contract.md

@@ -0,0 +1,91 @@
+# Experiment Exposure Contract
+
+Read this reference whenever exposure affects assignment, metrics, SDK code, or rollout readiness.
+
+## Exposure definition
+
+Exposure means the assigned behavior was actually rendered or became effective for the analysis unit. It is not:
+
+- SDK initialization;
+- configuration fetch;
+- Feature preload;
+- getter execution when the result may be discarded;
+- assignment calculation without treatment activation.
+
+## Automatic versus manual exposure
+
+The verified Android, iOS, and JavaScript experiment pages state that a typed getter automatically uploads exposure when `automaticExposureTracking` is enabled.
+
+Use automatic exposure only when the getter is called at the same decision point where the value is applied.
+
+Use manual exposure when:
+
+- values are prefetched;
+- a getter is called before eligibility is final;
+- the result may not render;
+- the server assigns but the client activates;
+- one value is read multiple times before a single activation;
+- the product needs a later, explicit effective point.
+
+Do not combine automatic getter exposure and manual exposure for the same activation.
+
+## Exposure owner
+
+Choose exactly one:
+
+- client rendering owner;
+- server behavior owner;
+- another verified activation service.
+
+Document why that component knows the treatment became effective.
+
+## Deduplication contract
+
+Define an application-level deduplication key from stable facts such as:
+
+- project and environment;
+- experiment or Feature;
+- assignment identity;
+- assignment or group;
+- activation scope such as session, page instance, or decision instance.
+
+Do not invent AE event property names. Let the verified SDK emit its supported schema, or resolve the exposure event contract through `ae-cli`.
+
+Retry must be idempotent at the chosen activation scope.
+
+## Identity and join
+
+The identity used for assignment, exposure, and outcome must either be the same or have a verified merge path.
+
+Block launch when:
+
+- anonymous and logged-in identities can cross groups;
+- server and client use different assignment subjects;
+- exposure uses device identity while outcomes use an unlinked account identity;
+- account switching can inherit a cached assignment;
+- the analysis unit cannot be reconstructed from platform evidence.
+
+## Outcome contract
+
+For the confirmed primary event metric, define:
+
+- event or measure;
+- identity;
+- timestamp;
+- attribution window;
+- denominator or eligible population;
+- relation to exposure;
+- duplicate and late-event treatment.
+
+Do not report an exposure merely to force a user into the denominator. Fix the metric or eligibility contract instead.
+
+## Acceptance tests
+
+- Getter without rendering does not produce exposure in manual mode.
+- Rendering produces one exposure.
+- Re-render behavior matches the pre-registered exposure scope.
+- Retry does not create duplicate logical exposure.
+- Control and treatment exposure are both observable.
+- Assignment proportions match configured allocation.
+- Exposure and outcome join for anonymous, login, logout, and account-switch paths.
+- Offline and delayed-upload behavior is understood before launch.

package/skills/ae-experiment-design/references/hybrid-experiment-sdk.md

@@ -0,0 +1,74 @@
+# Hybrid Experiment Architecture
+
+Read this reference when the server assigns or prepares a variant but the client renders or activates the treatment.
+
+## Ownership model
+
+Assign one owner for each responsibility:
+
+| Responsibility | Typical owner |
+|---|---|
+| Stable identity resolution | Server or shared identity service |
+| Assignment or Feature evaluation | Server |
+| Typed default | Both sides, with one canonical value |
+| Rendering or activation | Client |
+| Exposure | Client when it knows rendering succeeded |
+| Outcome events | Side that owns the business action |
+
+These are design defaults, not fixed product requirements.
+
+## Server-to-client envelope
+
+Define an application envelope such as:
+
+```text
+{
+  featureKey,
+  value,
+  valueType,
+  assignmentOrGroupId,
+  configVersion,
+  evaluatedAt,
+  exposureToken?
+}
+```
+
+This is architecture-level pseudocode. Verify any AE-specific schema through `ae-cli`.
+
+## Consistency rules
+
+- Server and client must use the same project, environment, Feature key, and stable identity.
+- The client must validate the value type before applying it.
+- A missing, invalid, or expired envelope falls back to the typed control behavior.
+- Do not re-evaluate independently on the client after a server assignment unless the product explicitly supports that mode.
+- Do not allow account switching to reuse another account’s cached envelope.
+- Include a configuration version or equivalent diagnostic marker when the verified platform provides one.
+
+## Exposure handoff
+
+The server should not report exposure merely because it returned a treatment envelope when the client may never render it. Prefer:
+
+1. server evaluates;
+2. client receives and validates;
+3. client applies behavior;
+4. client reports exposure once.
+
+If exposure must be server-side, define a client acknowledgment or another verified activation signal and make retry idempotent.
+
+## Failure scenarios
+
+- server evaluation succeeds, client render fails: no exposure;
+- server times out: client uses control;
+- client starts offline with cached assignment: use only within the documented stale window;
+- server and client identity disagree: block rollout;
+- both sides report exposure: disable one path before launch;
+- value arrives after control rendered: freeze control for the session or use an explicitly approved transition.
+
+## Acceptance checks
+
+- Server and client return or apply the same value type.
+- Treatment is not visible before identity is stable.
+- Exposure is reported by one owner.
+- Refresh and retry do not duplicate exposure.
+- Cached assignment is isolated by identity and environment.
+- Outcome events remain joinable across client and server.

package/skills/ae-experiment-design/references/metric-readiness.md

@@ -0,0 +1,143 @@
+# Metric Readiness
+
+Use this checklist to decide whether a candidate metric can support an experiment decision.
+
+## Contents
+
+- Supported experiment metric contract
+- Preregistered planning policy
+- Evidence levels
+- Feasibility gates
+- Role selection
+- Common blockers
+- Required output
+
+## Supported experiment metric contract
+
+Use event metrics only. A platform enum or API field is not evidence that
+another metric kind is implemented in the report calculation path.
+
+Use only these event calculation codes:
+
+| Code | Calculation | User-level value | Planning type |
+| --- | --- | --- | --- |
+| `A101` | Triggered users | Whether each user triggered the event; compare group trigger rates | `proportion` |
+| `A100` | Total times | Each user's total event count; compare group user-level means | `continuous` |
+| `A201` | Days | Each user's distinct active-event days; compare group user-level means | `continuous` |
+| `A103` | Sum | Each user's sum of a numeric event property; compare group user-level means | `continuous` |
+| `A104` | Average | Each user's average numeric event-property value; compare group user-level means | `continuous` |
+| `A106` | Maximum | Each user's maximum numeric event-property value; compare group user-level means | `continuous` |
+| `A108` | Distinct count | Each user's distinct count of one event property; compare group user-level means | `continuous` |
+
+Require a numeric event property for `A103`, `A104`, and `A106`, and an exact
+event property for `A108`.
+
+The current report calculation uses a two-sided Z test for both planning
+types, returns p-value, lift, and a 95% confidence interval, and uses
+`p < 0.05` plus confidence-interval direction and goal direction to label a
+positive or negative significant result.
+
+## Preregistered planning policy
+
+Fix the family-wise significance level at `alpha=0.05`, the confidence level
+at `0.95`, and the test direction at two-sided to match current reporting.
+Use `power=0.80` as the explicit planning-policy default when the user does not
+provide power, and label its source as `policy_default`.
+
+Require the MDE before definitive planning. Record whether it is `relative` or
+`absolute` and whether the desired effect is an `increase` or `decrease`; never
+silently substitute a 5% lift. Require observed user-level standard deviation
+for continuous metrics; never substitute an assumed coefficient of variation.
+
+For one control and multiple treatments, treat each treatment-versus-control
+comparison as one member of the same family. Use Bonferroni planning:
+`alpha_per_comparison = 0.05 / number_of_treatments`. Return the family alpha,
+adjusted alpha, method, and comparison count. The current native report still
+labels significance with unadjusted `p < 0.05` and a 95% confidence interval,
+so use raw p-values against the preregistered adjusted threshold for the final
+decision and disclose that native-label mismatch.
+
+Use a minimum runtime of seven days and align recommendations to full weeks by
+default; permit explicit overrides when the decision context justifies them.
+When traffic is not fixed, evaluate absolute experiment-traffic candidates no
+greater than the verified layer capacity and choose the smallest candidate
+that reaches the sample target within the maximum runtime. If none is feasible,
+return the true duration at maximum available traffic and mark it infeasible;
+never truncate the duration to the maximum.
+
+Do not add ad hoc missing-value imputation, winsorization, truncation, or
+post-treatment exclusions. Use the exact platform metric definition and
+preregister any supported filtering or data-quality rule before the run.
+
+Call `calculate_experiment_plan.py` with `metric_type`, `baseline`, `mde`,
+`mde_type`, `effect_direction`, `allocations`, and `daily_eligible_units`.
+Pass `standard_deviation` for a continuous metric. Pass `experiment_traffic`
+when traffic is confirmed; otherwise pass `max_available_traffic` and
+optionally `traffic_candidates` to request a recommendation. `power`,
+`min_runtime_days`, `max_runtime_days`, and `align_to_full_weeks` may override
+their policy defaults. Do not pass `confidence_level` other than `0.95`.
+
+Do not create or recommend a metric outside this contract. If the requested
+business outcome cannot be expressed by one supported event calculation,
+state that it is unavailable and propose the closest valid event metric
+without representing it as equivalent.
+
+## Evidence levels
+
+Label every statement:
+
+- `verified`: supported by current `ae-cli` platform output;
+- `provided`: supplied by the user but not verified on the platform;
+- `assumed`: introduced for design or sensitivity analysis;
+- `missing`: required evidence is unavailable.
+
+Only `verified` or explicitly accepted `provided` evidence can support a final readiness decision.
+
+## Feasibility gates
+
+A metric is feasible only when all applicable gates pass:
+
+1. **Contract**: event, supported calculation code, required property, goal
+   direction, filters, and attribution window are explicit.
+2. **Source**: required events and properties exist or are supplied as a concrete schema.
+3. **Identity**: assignment, exposure, and outcome share a stable join path.
+4. **Ordering**: outcome is attributed after exposure or treatment activation.
+5. **Population**: pre-treatment eligibility and exclusions are reproducible.
+6. **Planning evidence**: baseline, MDE and its type and direction, eligible
+   daily units, verified layer capacity when recommending traffic, and—except
+   for `A101`—user-level standard deviation are available before a definitive
+   sample or duration calculation.
+7. **Stability**: collection and definition are not expected to change during the experiment.
+8. **Sensitivity**: the metric can plausibly respond to the treatment.
+
+Block or mark unverified when any required gate lacks evidence.
+
+## Role selection
+
+### Primary
+
+Choose one supported event metric closest to the hypothesis and decision.
+Confirm its calculation code and direction, then establish its baseline and
+minimum business-relevant effect. Do not calculate a definitive duration
+before the metric contract is confirmed.
+
+## Common blockers
+
+- missing exposure event or treatment-activation marker;
+- assignment uses `user_id` while outcomes only have `device_id`;
+- anonymous-to-login identity cannot be reconciled;
+- cross-device identity is unstable;
+- outcome precedes exposure;
+- denominator is filtered by post-treatment behavior;
+- event volume is too low;
+- metric definition or instrumentation changed during the run;
+- cross-platform events use incompatible identities or semantics.
+
+## Required output
+
+For each candidate, return:
+
+| Metric | Status | Event | Calculation | Property | Direction | Join identity | Window | Evidence | Reason or remediation |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+
+When blocked, give the smallest concrete instrumentation or identity change that would make the metric measurable.

package/skills/ae-experiment-design/references/platform-operations.md

@@ -0,0 +1,105 @@
+# Platform Operations
+
+Read this reference before any AE/TE platform interaction.
+
+## Hard boundary
+
+Use `ae-cli` for all platform operations. Do not call raw APIs, use browser automation, query a database, or fabricate a platform result.
+
+Use curated commands when their contract is known. Use the Capability Gateway for experiment capabilities that do not yet have a curated command:
+
+```bash
+ae-cli capability search "<terms>" --domain <domain> [--project-id <id>]
+ae-cli capability inspect <capability-id> --project-id <id>
+ae-cli capability validate <capability-id> --input '<json-object>'
+ae-cli capability dry-run <capability-id> --input '<json-object>'
+ae-cli capability run <capability-id> --input '<json-object>'
+```
+
+Search and inspect before constructing input. Never guess capability IDs, fields, enums, resource IDs, or project IDs. Search with the narrowest useful terms, then inspect every plausible candidate.
+
+Use at most one normal pre-check:
+
+- use `validate` while correcting a complex nested payload;
+- use `dry-run` for the final request when execution impact or deletion risk must be reviewed;
+- do not routinely stack `validate`, `dry-run`, and `run`.
+
+## Host compatibility
+
+After every `ae-cli` invocation, inspect stderr and `_notice.host_compat`. If a notice exists, start the user-facing result with a version warning and reproduce its update command lines verbatim. A successful envelope does not cancel the notice.
+
+## Project gate
+
+When the user supplies a project ID, resolve it directly:
+
+```bash
+ae-cli project info get --project-id <id>
+```
+
+When the user supplies only a project name, search and disambiguate:
+
+```bash
+ae-cli project info list --query "<project name>" --fields '["project_id","project_name"]' --limit 20 --offset 0
+```
+
+Reuse a project only when its ID and host were verified in the same continuous conversation. If multiple projects match, stop and ask the user to choose.
+
+## Metadata and metric evidence
+
+Use these curated reads when applicable:
+
+```bash
+ae-cli analysis-meta event list --project-id <id> --query "<event>" --fields '["event_name","event_desc","authentication_status"]' --limit 20 --offset 0
+ae-cli analysis-meta property list --project-id <id> --scope event --event-name "<event>" --limit 50 --offset 0
+ae-cli analysis-meta property list --project-id <id> --scope user --limit 50 --offset 0
+ae-cli analysis-meta metric list --project-id <id> --query "<metric>" --fields '["metric_id","metric_name","metric_desc","authentication_status"]' --limit 20 --offset 0
+```
+
+Use `ae-cli analysis-meta metric get` after list/search when the exact metric definition is required. Use `ae-cli analysis adhoc run|export` for historical baseline and eligible-traffic evidence, following the installed `ae-analysis` command reference. Do not infer a baseline from a metric definition.
+
+For metric creation, use the curated `ae-cli analysis-meta metric create`
+command only after the supported event-metric definition and calculation code
+are exact. Use `--validate` while fixing complex metric input. Do not create a
+metric from a prose-only definition.
+
+## Experiment capability discovery
+
+Discover, inspect, and select capabilities for the semantic operation. Typical search concepts include:
+
+- experiment list, get, draft save, readiness, conflict, submit, start, pause, end, delete;
+- Feature list, get, create, update;
+- layer or bucket list and available traffic;
+- experiment metric report, summary, trend, sample, group, or exposure.
+
+Catalog wording and capability IDs may differ by deployment. The inspected `input_schema`, `risk`, auth requirements, output contract, and supported dry-run behavior are authoritative.
+
+If search returns no supported capability, report `capability gap` and continue with an offline design. Do not convert an intended platform write into raw HTTP.
+
+## Experiment detail link
+
+After a successful experiment save or verified exact-match reuse:
+
+1. Read the actual `expId` from the successful `ae-cli` result; do not use a proposed input ID unless the inspected output contract confirms that the save preserved it.
+2. Prefer a canonical detail link returned by the inspected capability output contract.
+3. When the result contains the actual `expId` but no link, use the verified relative frontend route:
+
+```text
+/#/atlas/experiment/detail?expId=<actual-expId>&currentProjectId=<actual-projectId>
+```
+
+The user-facing response must render this as a Markdown link with a localized label. Do not put it in a code block, output it as bare text, add a `{domain}` placeholder, or construct it when either verified ID is missing.
+
+## Risk and lifecycle policy
+
+- `read`: execute after project and target resolution.
+- `write`: execute when it is directly requested and inputs are exact.
+- `high-risk-write`: dry-run the final input, summarize target and impact, wait for a later explicit confirmation, then execute unchanged input with `--yes`.
+
+Regardless of catalog risk, require a separate explicit confirmation before submitting, starting, changing live traffic, pausing, ending, or deleting an experiment. A request to design or create a draft is not authorization to launch.
+
+## Envelope handling
+
+- `ok: true` with empty data is a successful empty result.
+- `ok: true` with `meta.partial: true` is partial success; preserve `meta.failures`.
+- `ok: false` is failure; preserve error code, message, request ID, invocation ID, stage, and failures.
+- Do not retry an unchanged failed request.

package/skills/ae-experiment-design/references/sdk-index.md

@@ -0,0 +1,76 @@
+# Experiment SDK Documentation Index
+
+Read this reference before giving exact experiment-SDK versions, dependencies, packages, imports, or API calls.
+
+## Source policy
+
+- Bundled references contain a concise extract for common questions.
+- The local official Wiki is preferred for exact version-specific APIs when it contains the relevant main page.
+- If the Wiki mirror is missing an experiment page, use the verified official source below and label the local mirror gap.
+- Recheck document version and update date before generating production code.
+- Do not use a page merely because a link label says it is an SDK page; verify its title and content.
+
+## Experiment SDK matrix
+
+Verified from the official Feishu pages on 2026-07-26:
+
+| Platform | Experiment SDK | Analytics dependency | Remote Config dependency | Main source |
+|---|---:|---:|---:|---|
+| Android | `TDExperiment` 1.0.1 | `TDAnalytics` >= 3.3.6 | `TDRemoteConfig` >= 1.3.0 | `CQ83wzJjui88V1keGtNcKLxgnXb` |
+| iOS | `TDExperiment` 1.0.2 | `ThinkingSDK` >= 3.1.6 | `TDRemoteConfig` >= 1.3.1 | `RlYIwkcvXizJeFkhp2acbWGwnFf` |
+| JavaScript | experiment package 1.0.0 | `TDAnalytics` >= 2.6.0 | `TDRemoteconfig` >= 1.3.0 | `GlR8w2bFbiJKqUka03pcJEdnndf` |
+
+Official source pages:
+
+- Client SDK overview: `https://thinkingdata.feishu.cn/wiki/MCy3w6eKjihQsmkZWSQcNlrQnie`
+- Android experiment SDK: `https://thinkingdata.feishu.cn/wiki/CQ83wzJjui88V1keGtNcKLxgnXb`
+- iOS experiment SDK: `https://thinkingdata.feishu.cn/wiki/RlYIwkcvXizJeFkhp2acbWGwnFf`
+- JavaScript experiment SDK: `https://thinkingdata.feishu.cn/wiki/GlR8w2bFbiJKqUka03pcJEdnndf`
+
+## Remote Config dependency matrix
+
+| Platform | Remote Config version | Minimum OS | Main source |
+|---|---:|---:|---|
+| Android | 1.3.0 | Android 4.0 / API 14 | `Lsdmwhhigi9Z3AkKs2fc9tw3nEd` |
+| iOS | 1.3.1 | iOS 9.0 | `K85DwZetDidpMPkGHWhccKQGnUf` |
+| JavaScript | 1.3.0 | Not stated in the verified page | `Yg3uw8RDii2WEskhz2Qc4zOanwg` |
+
+Official source pages:
+
+- Android Remote Config: `https://thinkingdata.feishu.cn/wiki/Lsdmwhhigi9Z3AkKs2fc9tw3nEd`
+- iOS Remote Config: `https://thinkingdata.feishu.cn/wiki/K85DwZetDidpMPkGHWhccKQGnUf`
+- JavaScript Remote Config: `https://thinkingdata.feishu.cn/wiki/Yg3uw8RDii2WEskhz2Qc4zOanwg`
+
+## Local Wiki discovery
+
+The runtime mirror is expected under:
+
+```text
+~/.ae-cli/wiki/te-docs/
+├── index.md
+├── synthesis/
+└── raw/
+```
+
+Before reading a local experiment page:
+
+1. Check whether `index.md` exists.
+2. Search the index and `raw/` for `experiment`, `TDExperiment`, `remote config`, `配置中心`, and `实验`.
+3. Choose the latest main page, not a historical/versioned copy.
+4. Read synthesis for orientation and raw for exact API details.
+
+At the verification date, the local mirror used to build this reference did not contain experiment or Remote Config pages. Do not assume this remains true after a Wiki refresh.
+
+## Known source conflict
+
+The client SDK overview page labels `AvX7wAp0zix522kSy9BcBziMnJd` as the JavaScript Remote Config document, but that token currently resolves to a Data Platform Release Note. The JavaScript experiment page links to `Yg3uw8RDii2WEskhz2Qc4zOanwg`, which resolves to the verified JavaScript Remote Config 1.3.0 document.
+
+Use `Yg3uw8RDii2WEskhz2Qc4zOanwg` until the overview page is corrected. If either page changes, verify the title, SDK version, and API content again.
+
+## JavaScript spelling warning
+
+The verified JavaScript experiment page spells the global object `TDExpriment`. This may be an SDK export name or a documentation typo. Copy it only after checking the downloaded package or a newer verified main document. Do not silently “correct” it to `TDExperiment`, and do not ship the documented spelling without verification.
+
+## Unsupported exact-code cases
+
+The supplied official pages do not establish an exact server-side experiment SDK or server evaluation API. For server or hybrid implementation, follow the architecture references and use pseudocode until `ae-cli` or verified server documentation resolves a concrete API.