Clarify native multiplayer development versus public submission

agent-setup.mdx

@@ -4,6 +4,14 @@ description: "Point an AI coding agent at the canonical Summer Engine prompt: bu
 icon: "bot"
 ---
 
+<Note>
+  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.
+</Note>
+
 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

agent-setup/prompt.mdx

@@ -5,6 +5,14 @@ icon: "bot"
 noindex: false
 ---
 
+<Note>
+  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.
+</Note>
+
 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

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"
 ---
 
+<Note>
+  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.
+</Note>
+
 ## Add platform capabilities to your Summer game
 
 The **Summer SDK** is the creator-facing platform contract for a **Summer game**. Your

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.