diff --git a/agent-setup.mdx b/agent-setup.mdx
index 3f3b3fb..eedbf45 100644
--- a/agent-setup.mdx
+++ b/agent-setup.mdx
@@ -4,6 +4,14 @@ description: "Point an AI coding agent at the canonical Summer Engine prompt: bu
icon: "bot"
---
+
+ This page covers the public Summercraft SDK submission contract. For a supplied native
+ multiplayer development build, first read [Native multiplayer development](/knowledge-base/source-status#native-multiplayer-development)
+ and the API reference shipped with that build. Public production playback remains not
+ live; this does not establish whether your separately configured staging environment
+ supports an online test. Do not mix the two integration paths.
+
+
An AI coding agent can use Summer Engine to build a multiplayer **Summer game** in
**GDScript**, integrate the **Summer SDK**, validate it locally, and submit it through the
live submission API. A human reviews every submission before its catalog status can become
diff --git a/agent-setup/prompt.mdx b/agent-setup/prompt.mdx
index e52cd7b..2f0b6d4 100644
--- a/agent-setup/prompt.mdx
+++ b/agent-setup/prompt.mdx
@@ -5,6 +5,14 @@ icon: "bot"
noindex: false
---
+
+ This page covers the public Summercraft SDK submission contract. For a supplied native
+ multiplayer development build, first read [Native multiplayer development](/knowledge-base/source-status#native-multiplayer-development)
+ and the API reference shipped with that build. Public production playback remains not
+ live; this does not establish whether your separately configured staging environment
+ supports an online test. Do not mix the two integration paths.
+
+
You are an AI coding agent. Your job is to use **Summer Engine** and the **Summer SDK** to
build a multiplayer **Summer game** in **GDScript**, export a game-only `.pck`, and publish
it to Summercraft for review. Follow this document top to bottom. Where a platform
diff --git a/api-reference/summer-sdk.mdx b/api-reference/summer-sdk.mdx
index 759c5c9..fc45fc1 100644
--- a/api-reference/summer-sdk.mdx
+++ b/api-reference/summer-sdk.mdx
@@ -4,6 +4,14 @@ description: "The lifecycle hub for adding Summer SDK capabilities to a Summer g
icon: "gamepad-2"
---
+
+ This page covers the public Summercraft SDK submission contract. For a supplied native
+ multiplayer development build, first read [Native multiplayer development](/knowledge-base/source-status#native-multiplayer-development)
+ and the API reference shipped with that build. Public production playback remains not
+ live; this does not establish whether your separately configured staging environment
+ supports an online test. Do not mix the two integration paths.
+
+
## Add platform capabilities to your Summer game
The **Summer SDK** is the creator-facing platform contract for a **Summer game**. Your
diff --git a/knowledge-base/source-status.mdx b/knowledge-base/source-status.mdx
index 964f660..3856e16 100644
--- a/knowledge-base/source-status.mdx
+++ b/knowledge-base/source-status.mdx
@@ -66,6 +66,49 @@ See [Summer SDK](/api-reference/summer-sdk) for contracts and
[Submit Your Summer Game for Review](/api-reference/summer-sdk/submission-guide) for the
currently deployed submission flow.
+## Native multiplayer development
+
+The production table above describes the public Summercraft submission and playback
+path. It is not a statement that multiplayer engine development or restricted staging
+testing cannot exist. A staging test does not establish general creator access or
+production availability.
+
+Before implementing an online game, identify the environment your installed tools
+actually support. The public SDK examples on this site describe the scaffolded
+`SummerGame` / `SummerPlayer` contract and game-only `.pck` submission. They are not an
+installation or integration guide for a separate native multiplayer development build.
+Do not copy those stubs into a native runtime and assume the APIs are interchangeable.
+
+### If you have a native development environment
+
+Use the documentation shipped with that exact build. Record its version and the target
+environment before writing integration code. A usable environment must supply:
+
+1. A compatible editor/client and an accessible native API reference or starter project.
+2. Creator authentication and a documented publication command for that environment.
+3. A matching hosted build policy, resulting build/release identity, and game configuration.
+4. An authenticated player launcher for each supported device and a documented join flow.
+
+These are setup requirements for an online test, not tasks to solve inside gameplay
+scripts. This public documentation does not currently provide a self-service native
+staging installer, credentials, or player launcher. Do not invent their URLs, substitute
+public PCK submission for a different publication protocol, or require access to an
+internal expert assistant. Missing setup must be reported as a specific missing input.
+
+### Work that can proceed
+
+An agent can inspect installed tools, verify their versions, read the matching API
+reference, and build the requested gameplay when that integration contract is available.
+A missing hosted launch prerequisite does not require abandoning all game development.
+Keep any unfinished online requirement explicit; a local prototype does not complete a
+request to play with friends on separate devices. Do not silently replace that request
+with browser gameplay or a shared keyboard.
+
+For online acceptance, launch the same recorded release on two authenticated devices,
+join the same session, and verify shared gameplay and reconnection. Record any lobby
+capacity limit from the actual configuration; do not promise an unlimited lobby.
+Until this succeeds, report what was built and the exact remaining launch gate.
+
## Is the engine app open source?
No. The desktop app is free proprietary software right now. If Summer publishes engine source later under a no-competing-engine license, the honest term would be source-available, not open source.