SDK Developer Preview
The MIT-licensed 0.9.111 SDK is an authoring tool, not full game certification. Download and quickstart · Requirements.
Three evidence statuses
- Verified: an affirmative author claim supported by a reason and at least one relative evidence reference. The SDK does not independently inspect or certify those referenced receipts.
- Not Verified: evidence is missing, incomplete or not yet checked for the exact operation. Missing evidence is not automatically a measured failure.
- NA: not applicable, with an explicit operator-reviewed reason. Input N/A is normalized to NA. An unfinished requested feature is not a valid NA waiver.
Evidence reasons are mandatory and bounded to 384 characters. A row may contain at most eight bounded relative references. Do not include credentials, private paths, player identities or URLs. References are metadata: the SDK does not open or execute them.
Claims are bound to the SHA-256 of the exact input bytes, including a UTF-8 BOM if present. Changing a payload, canonicalizing it or signing a different archive requires a fresh binding. Historical evidence must not become a claim about new bytes.
Author-attested, not certified
EvidenceAssurance identifies author attestations. AcceptanceVerifiedByTool and ReleaseCertified remain false. A capability flag, a signed file or a passing synthetic fixture does not turn the corresponding game operation into Verified.
The 22-check adapter ledger
V2FC is the adapter verification checklist identified by V01–V22 below. This table states the required scope, not the current pass status of any game.
| Check | Evidence needed |
|---|---|
| V01 Gallery and identity | Signed discovery, host compatibility, Add/Setup and exact installed identity. |
| V02 Installation | Official distribution, validation, prerequisites, resource estimates and progress/error reporting. |
| V03 Settings and secrets | Approved defaults and limits, game-written settings round trips, unknown-field preservation and credential isolation. |
| V04 Lifecycle and persistence | Start, normal saving Stop and evidence that persisted state reloads. Scope integrity checks and operation receipts to what they actually prove. |
| V05 Readiness and failures | Current-run evidence; process, readiness, listener, LAN and external checks remain distinct. |
| V06 World transfer | ZIP import/export, declared world/settings contents and reload of the transferred world. |
| V07 Backup and restore | Backup catalog/create/restore, pre-restore safety backup and reload. |
| V08 Retention and recovery | Ten-backup retention, stopped-writer exclusion and interrupted save-publication recovery. |
| V09 Nightly maintenance | Back up servers observed running since the preceding scheduled sleep, including those already stopped; retain ten backups. |
| V10 Windows Firewall | Actual configured ports, executable-scoped rules and stale-rule cleanup. |
| V11 Managed Ports | Conflicts, apply/takeover, mode applicability, refresh and confirmed safe old-rule deletion. |
| V12 External checks | Remote Portal stopped nonce checks and separately supported safe live queries. |
| V13 Game-binary updates | Stop/backup/preservation and conditional restart through the supported update path. |
| V14 Adapter updates | Signed package updates preserve profile identity/settings and respect live/save-recovery constraints. |
| V15 Notices and Activity | Update notices and durable progress, completion and failure records. |
| V16 Diagnostics | Prefer supported game-written file logging. Verify exact source/naming, encoding/framing, event coverage, sanitization, rotation/retention and reconnection. Justify any capture fallback: .110 NativeFileOutput uses shared files; historical OutputCapture has Service-lifetime limits. |
| V17 Players and history | Reliable counts/names, join/leave/reconnect, identity handling and history. |
| V18 Discord | Status, authorized commands/help, lifecycle/player reports, heartbeat and deduplication. |
| V19 Reopen and recovery | Supported process adoption, scheduled maintenance/sleep and post-wake recovery. |
| V20 Client consistency | Keldrin app, Local Web and Remote Portal agree on capabilities, settings, health and secret filtering. |
| V21 Removal | Stopped permanent removal, rollback/recovery and stale menu/command/help cleanup. |
| V22 Release integrity | Source/artifact correspondence, regressions, smoke, pinned signatures, immutable objects before catalog and fresh served-download verification. |
Automatic checks, file integrity and recorded operation receipts can support the exact claim they demonstrate; a developer gameplay sign-off is not universally mandatory. A new developer-performed world change is not mandatory for every revision. A backup does not prove an unperformed restore, nor preserve changes that the game never saved. Manual Restart controls are not a checklist requirement: use normal saving Stop, then Start where appropriate. Do not invent last-disconnect automation.
V16 begins with discovery of the game’s supported file logger. Console capture is a justified fallback, with its limitations documented. Neither path alone establishes complete diagnostics, recovery or game acceptance.
The private .110 direct-file fallback does not establish a saving shutdown. Terraria’s .110 KillProcessTree stops the process without a guaranteed final save. Evidence from an earlier stdin save-and-exit candidate cannot certify that changed policy.
Terraria player-event ambiguity
The frozen .110 package can mistake event-shaped chat for join/leave events. Host .111 adds generic AmbiguousLinePrefixes handling: a whole-event match with a declared prefix becomes unavailable, making the roster, names and new activity unknown. It is not counted as a player or an inferred zero.
Terraria declares an angle-bracket prefix. Genuine angle-prefixed names may therefore remain ambiguous; .111 does not promise reliable counts for every native name. Ordinary nonmatching chat is unaffected. A later event or readiness marker does not repair the ambiguous run.
The earlier .110 checkpoint has 9 Verified and 13 Not Verified rows; later scoped operation checks add evidence without rewriting that immutable ZIP. Shared parsing regressions are separate from exact-candidate game acceptance. Neither those partial results nor SDK fixtures establish full Terraria verification or a stable SDK release.
Submission, review and signing
- Prepare: provide the unsigned payload, declared hash-bound assets, exact host bounds and an honest scoped ledger. Keep secrets and private game data out of the submission.
- Review: maintainers check the declarations against measured game behavior and supported host primitives. New formats, protocols or process behavior need host review, not a copied selector.
- Sign: authorized maintainers use the existing official signing workflow. Authors receive neither private signing keys nor a self-service official signer.
- Admit and test: verify the actual signed archive, a complete compatible catalog and normal Service admission. Preserve profile identity, settings, worlds, accepted sequences and recovery state. Never reset catalog high-water state to force acceptance.
- Release separately: applicable operation evidence, regression/smoke results and source/artifact correspondence must support the release claim. Publish immutable reviewed objects before the catalog and freshly verify what is served, with explicit authorization.
No website upload or self-publication endpoint is provided by these docs. Publication of documentation does not publish an adapter or grant permission to install an unsigned input.
Preview documentation is not a stable SDK release
Developer Preview documentation can be useful while individual games still have open verification rows. Every downloadable version needs its exact artifact, retained license/limitations and manifest notices, and verification of the actual served HTTPS length and SHA-256. A stable contract and a fully certified reference adapter have additional, separately defined gates. The historical .110 ZIP must not be relabelled as .111.
Generalization is not complete: reviewed named save formats and some initialization, credential and player mechanisms remain constrained host code. Do not promise that every game can be added with JSON alone or that future changes will never require an app update.
Found a documentation issue? Tell us through Feedback. Do not include credentials or private game data.