Platform v0.2.0 — 2026-06-09

The first production-deployable WonderTwin platform release. Identity, subscriptions, licensing, twin registry, telemetry ingest, and portal are wired end-to-end with real Clerk authentication and Ed25519-signed licenses behind it.

What changed

Identity and authentication

• Dual-auth middleware — Clerk JWT for dashboard users + HMAC-hashed API keys for CLI and MCP. Both validated at the same boundary.
• Account-as-unified-tenant model — accounts is the canonical tenant; orgs resolve through the Identity Provider mapping layer (Clerk Organizations today).
• Account-deletion retention policy — account.deleted audit-log row written inside the delete transaction; cascade across 23 tables.
• API-key prefix simplified: wt_live_ → wt_. HMAC-at-rest unchanged.
• Dev IdentityProvider hardening — WT_DEV_AUTH=1 requires WT_ENV=development and a non-empty token HMAC; prod boot panics if dev-auth is enabled.

Signed licensing

• Ed25519 license issuance + verification. cmd/issue-license mints licenses; the runtime validates against a configured public key.
• License delivery via MCP. Server-side install endpoint speaks the structured outcome envelope (installed, queue, deny, setup_required, upgrade_required, trial_started_and_installed, policy_error).

Subscriptions, entitlements, trials

• subscription_events schema + domain.
• Clerk webhook ingest with svix-id dedup and nonce rollback on transient dispatch failure.
• clerk_webhook_events sweeper bounds table growth.

Twin registry

• twin_versions, twin_artifacts, version_pins schema.
• Presigned-download artifact retrieval via gocloud.dev/blob (S3 in production).
• Per-namespace publish authz — platform-admin v1.
• Public registry snapshot endpoint feeds the marketing build.
• Catalog bootstrap tool — one-shot seed of the commercial twin catalog at v0.2.0, with the fixture embedded in the binary so no cross-repo checkout is required at deploy time.
• Catalog renames: logodev → logo-dev, qbo → quickbooks.

Telemetry and inference

• telemetry_events, telemetry_settings, inference_results, beliefs schema.
• Ingest pipeline with audience-claim validation; settings store; query endpoints.
• Inference engine interface with a NoopEngine placeholder so customer-specific engines plug in later without rewiring the ingest path.
• Server-side payload redaction at ingest — sensitive field scrubbing before persistence.

Portal

• Audit-log query and dashboard summary endpoints feed the wondertwin-web portal at /{org}/....

Production deployment hardening

The customer-launch P0 cluster from the 2026-06-04 readiness audit closed across this release. They are the work that made “prod-deployable” mean “deployed to prod and not silently broken.”

• Litestream replication wired and verified — discovery and main databases replicated to S3, with a daily restore drill operator-checked from wondertwin-ops.
• Image pinned by digest in prod and staging — no latest-tag drift; reproducible deploys.
• Migration discipline — single shared runner across main + telemetry databases; single-tx migration loop fixing silently-ignored DSN params.
• Graceful shutdown — WaitGroup-drain of background workers before the database closes.
• CSP correctness in prod — Clerk dashboard origin uses clerk.wondertwin.ai, not the dev *.clerk.accounts.dev placeholder.
• Bootstrap workflow — bootstrap-verify (read-only host invariant check) and bootstrap-fix-env-perms. Prod Clerk credentials seeded into the host .env via a dedicated workflow.
• WT_ENV auto-healed on staging and production deploys, preventing the dev-auth-in-prod class of misconfig.
• Compose + Caddyfile + litestream.yml sync to the prod host on every deploy.
• Dockerfile bumped to golang:1.26.4-alpine to match go.mod.

New MCP tools

This release introduced the wt CLI’s first MCP surface — discovery and acquisition affordances for agents.

• wt_catalog — browse the catalog by name, category, tier
• wt_catalog_detail — per-twin detail
• wt_subscribe — per-twin subscribe verb (superseded by wt_install in CLI v0.3.0; see v0.3.0 release notes)
• wt_request / wt_request_list — request a twin that doesn’t exist; check status

All returned structured JSON. The CLI version contemporaneous with this platform release is wt v0.1.0.

Breaking changes

None — this is the first production release.

Deprecations

None.

Known limitations

These were customer-visible at the v0.2.0 cut and were addressed in v0.2.1:

• Three real-name PII strings leaked through to the prod web bundle (caught in the post-ship audit pass; cleaned up in v0.2.1).
• Three real-name references in the catalog UI that the v0.2.0 PII purge missed.
• The wt-collector telemetry endpoint was missing the wt-auth-class hardening (structured logging, key-length floors, bounded request reads, graceful shutdown).
• The MCP install endpoint is intentionally deferred in production — wt_install (added in CLI v0.3.0) returns SETUP_REQUIRED envelopes against prod until the MCP-auth design lands.
• Approval workflow UI — when policy requires admin approval for a twin install, the request is recorded but no in-portal approve/deny interface exists yet.
• Policy management UI — policy can be set via API, but the portal admin page is pending.

Dependencies and coordination

• Customer install path at v0.2.0 ship: brew install wondertwin-ai/tap/wt → wt v0.1.0 → catalog + scan + subscribe + request flows work end-to-end.
• Twin versions — community twins at registry v0.1.0 (2026-02-18 cuts). One commercial twin, twin-measure, tagged v0.1.0 in 2026-05.

Install

The platform is operator-deployed via Docker Compose. For the customer-facing CLI:

brew install wondertwin-ai/tap/wt
wt version    # 0.1.0 at v0.2.0 ship time; upgrade to current via `brew upgrade`