decentraland · anicalbano · Sep 17, 2026 · Sep 14, 2026 · Sep 15, 2026 · Sep 15, 2026
@@ -22,13 +22,13 @@ All 4 repos must be cloned as siblings. Each repo should already be on the corre
 
 ```
 parent-dir/
-├── protocol/           ← must be on `experimental` or a branch derived from it
-├── js-sdk-toolchain/   ← must be on `experimental` or a branch derived from it
+├── protocol/           ← must be on `main` or a branch derived from it
+├── js-sdk-toolchain/   ← must be on `main` or a branch derived from it
 ├── unity-explorer/     ← current working directory (this repo)
 └── sdk7-test-scenes/   ← any branch is fine; will use local SDK path links
 ```
 
-> **Why `experimental`?** Unity-explorer always requires a protocol that is `experimental` or branches from it — using `main` alone will cause missing component files that break compilation. The SDK toolchain follows the same convention for experimental components.
+> **Why `main`?** Unity-explorer consumes `@dcl/protocol@next`, which is published from the protocol `main` branch — a branch that does not derive from `main` will cause missing component files that break compilation. The SDK toolchain follows the same convention.
 
 ---
 
@@ -56,7 +56,7 @@ Fields:
 - `optional bool enabled = 2;` // default true
 - `oneof shape { PointShape point = 10; SphereShape sphere = 11; }`
 
-Component ID: 1401 (experimental range — verify with `make check-component-id`)
+Component ID: 1201 (`12xx` main range — take the next free ID from `make list-components-ids`)
 
 ### PBYourComponentResult (GOVS — Explorer writes, scene reads)
 Result component that reports events back to the scene.
@@ -65,7 +65,7 @@ Fields:
 - `uint32 timestamp = 1;`
 - `YourEventType event_type = 2;`
 
-Component ID: 1402 (experimental range)
+Component ID: 1202 (main range)
 
 ## Behavior
 - Describe how the Explorer should interpret and apply each component at runtime
@@ -109,10 +109,7 @@ The architect will:
 Read the plan carefully before approving. This is the cheapest moment to catch mistakes — corrections at this stage cost nothing, corrections after agents have written code across 4 repos are expensive.
 
 Things to check:
-- Are component IDs in the right range?
-  - `12xx` — main branch components
-  - `14xx` — experimental branch components (most common for new work)
-  - `16xx` — Protocol Squad experimental components
+- Are component IDs in the `12xx` range and free on `main` (`make check-component-id ID=<id>`)? Older docs mention `14xx`/`16xx` experimental ranges; they were never used and are retired.
 - Do field types reuse existing common types (`Vector3`, `Color4`, `FloatRange`, etc.) instead of redefining them?
 - Is the LWW vs GOVS classification correct for each component?
 - Does the plan cover the full component lifecycle: instantiation, update, component removal, entity destruction, world disposal?
@@ -126,7 +123,7 @@ Iterate with the architect in plain conversation until the plan looks right, the
 The architect spawns specialist sub-agents in the correct order:
 
 ```
-[Sequential]  dcl-protocol-specialist    — proto file(s), branch verified from experimental,
+[Sequential]  dcl-protocol-specialist    — proto file(s), branch verified from main,
               |                            make test must pass before handing off
               ↓
 [Parallel]    dcl-sdk-specialist          — TypeScript SDK (make build + make test)

@@ -58,14 +58,14 @@ npm run build-protocol
 **Protocol package installation:**
 ```bash
 cd scripts
-# Always use @experimental to support all experimental features:
-npm install @dcl/protocol@experimental
+# Always use @next (published from the protocol `main` branch):
+npm install @dcl/protocol@next
 # Or use a PR test package for cross-repo testing:
 npm install "https://sdk-team-cdn.decentraland.org/@dcl/protocol/branch/<branch>/dcl-protocol-1.0.0-<hash>.tgz"
 npm run build-protocol
 ```
 
-**IMPORTANT:** unity-explorer must always use `@dcl/protocol@experimental` — otherwise the project won't compile due to missing component files.
+**IMPORTANT:** unity-explorer must always use `@dcl/protocol@next` — otherwise the project won't compile due to missing component files.
 
 ## SDK Component Implementation Checklist
 

@@ -14,24 +14,24 @@ All work happens in `../protocol` (relative to unity-explorer). The GitHub repo
 
 **Never modify files outside this directory.**
 
-## Branch Requirement — MUST Branch from `experimental`
+## Branch Requirement — MUST Branch from `main`
 
-**Before making any changes**, verify that the working branch is `experimental` or derives from it:
+**Before making any changes**, verify that the working branch is `main` or derives from it:
 
 ```bash
 cd ../protocol
-git branch --show-current                  # Check current branch
-git log --oneline experimental..HEAD       # Check if current branch is ahead of experimental
+git branch --show-current            # Check current branch
+git log --oneline main..HEAD         # Check if current branch is ahead of main
 ```
 
-If the current branch is `main` or any branch that does NOT include `experimental` commits, create a new branch from `experimental`:
+If the current branch does NOT include `main` commits, create a new branch from `main`:
 
 ```bash
-git fetch origin experimental
-git checkout -b feat/your-feature origin/experimental
+git fetch origin main
+git checkout -b feat/your-feature origin/main
 ```
 
-**Why this matters:** unity-explorer always requires a protocol that is either `experimental` or branches from it. Using a branch based on `main` alone will cause missing component files that break unity-explorer compilation.
+**Why this matters:** unity-explorer consumes `@dcl/protocol@next`, which is published from `main`. A branch that does not derive from `main` will produce missing component files that break unity-explorer compilation.
 
 ## Repo Structure
 
@@ -60,13 +60,9 @@ Makefile
   option (ecs_component_id) = <ID>;
   ```
 
-## Component ID Ranges
+## Component ID Range
 
-| Range | Purpose |
-|-------|---------|
-| `12xx` | Main branch components |
-| `14xx` | Experimental branch components |
-| `16xx` | Protocol Squad experimental components |
+All new SDK components take an ID from the `12xx` block (1200–1299). Pick the next free ID after the highest one listed on `main`. The former `14xx` (experimental) and `16xx` (Protocol Squad) ranges were never assigned and are retired now that work branches from `main`.
 
 **Always verify ID uniqueness:**
 ```bash

@@ -38,7 +38,7 @@ Do NOT proceed until the user confirms. Repo paths may differ between machines.
 Example format:
 ```
 Implementation Plan:
-1. [Sequential] dcl-protocol-specialist — create proto file, ensure branch is from `experimental`
+1. [Sequential] dcl-protocol-specialist — create proto file, ensure branch is from `main`
 2. [Parallel]   dcl-sdk-specialist + dcl-explorer-specialist — SDK TypeScript + Unity C# (independent repos)
 3. [Sequential] dcl-test-scene-specialist — test scene (depends on SDK build from step 2)
 4. [Architect]  Cross-layer verification checklist
@@ -53,7 +53,7 @@ Show the plan to the user and Wait for user confirmation before executing.
 ### Phase 1: Protocol (sequential — everything depends on this)
 Spawn `dcl-protocol-specialist` to create/modify `.proto` files.
 
-**CRITICAL: Always instruct the protocol specialist to verify that the working branch is `experimental` or branched from it.** Unity-explorer always requires a protocol that is either `experimental` or derives from it. The specialist must check and, if needed, branch from `experimental` before making any changes.
+**CRITICAL: Always instruct the protocol specialist to verify that the working branch is `main` or branched from it.** Unity-explorer consumes `@dcl/protocol@next`, which is published from `main`. The specialist must check and, if needed, branch from `main` before making any changes.
 
 Wait for completion before proceeding.
 
@@ -76,7 +76,7 @@ Cross-layer compatibility checks (see checklist below).
 When delegating to a specialist, always include:
 
 1. **What to implement** — component name, fields, behavior
-2. **Protocol package source** — PR test URL or `@experimental`
+2. **Protocol package source** — PR test URL or `@next`
 3. **Branch name** — use consistent branch names across all 4 repos (e.g., `feat/your-feature`)
 4. **Cross-repo dependencies** — what's been done in other repos, package URLs
 5. **Verification commands** — what to run to confirm success
@@ -133,30 +133,26 @@ After all specialists complete, verify:
 ### Step 1: Merge Protocol PR first
 The protocol defines the schema that both SDK and Explorer depend on.
 
-### Step 2: Sync experimental branch (if needed)
-- If protocol was merged to `main`: the `experimental` branch must sync the new changes before step 3
-- If protocol was merged to `experimental`: proceed directly to step 3
-
-### Step 3: Update downstream PRs
-Update both `js-sdk-toolchain` and `unity-explorer` PRs to use the published `@dcl/protocol@experimental` package (NOT the PR test package URL).
+### Step 2: Update downstream PRs
+Update both `js-sdk-toolchain` and `unity-explorer` PRs to use the published `@dcl/protocol@next` package (NOT the PR test package URL).
 
 **js-sdk-toolchain:**
 ```bash
-npm install @dcl/protocol@experimental
+npm install @dcl/protocol@next
 make install && make build
 ```
 
 **unity-explorer:**
 ```bash
 cd scripts
-npm install @dcl/protocol@experimental
+npm install @dcl/protocol@next
 npm run build-protocol
 ```
 
-### Step 4: Merge SDK and Explorer
+### Step 3: Merge SDK and Explorer
 `js-sdk-toolchain` and `unity-explorer` can be merged in any order — they don't depend on each other.
 
-### Step 5: Merge test scene last
+### Step 4: Merge test scene last
 The test scene PR depends on the published SDK package.
 
 ## Cross-Repo Package Linking
@@ -187,7 +183,7 @@ cd ../sdk7-test-scenes/scenes/<x>,<y>-<scene-name>
 npm install ../../js-sdk-toolchain/packages/@dcl/sdk
 ```
 
-Local linking is ideal for rapid iteration before PRs are created. **Before merging**, all repos must switch to published `@experimental` packages (see PR Merge Order).
+Local linking is ideal for rapid iteration before PRs are created. **Before merging**, all repos must switch to published `@next` packages (see PR Merge Order).
 
 ### Option B: GitHub Bot Test Packages (CI-verified, closer to production)
 
@@ -199,11 +195,11 @@ After each PR is created, a GitHub Bot comments with a test package URL:
 Use these for cross-repo testing during development:
 1. Protocol PR package → install in SDK and Explorer for testing
 2. SDK PR package → install in test scene for testing
-3. Before merging → replace all test packages with published `@experimental` versions
+3. Before merging → replace all test packages with published `@next` versions
 
 ### Mixing strategies
 
-You can use local linking during development and switch to PR packages for final verification. The key rule is: **before merging any downstream PR, it must point to published `@experimental` packages, not local paths or PR test URLs.**
+You can use local linking during development and switch to PR packages for final verification. The key rule is: **before merging any downstream PR, it must point to published `@next` packages, not local paths or PR test URLs.**
 
 ## Git Rules
 

@@ -71,8 +71,7 @@ npm install "https://sdk-team-cdn.decentraland.org/@dcl/protocol/branch/<branch>
 
 **For final PR** (after protocol is merged):
 ```bash
-npm install @dcl/protocol@next          # main branch
-npm install @dcl/protocol@experimental  # experimental branch
+npm install @dcl/protocol@next   # main branch — the tag unity-explorer consumes
 ```
 
 **From local protocol repo** (for rapid iteration):

@@ -17,10 +17,7 @@ user-invocable: false
 
 ### Step 1: Protocol Definition
 
-Create protobuf definition in the `protocol` repository with a unique component ID:
-- `12xx` -- Main components
-- `14xx` -- Experimental components
-- `16xx` -- Protocol Squad components
+Create protobuf definition in the `protocol` repository (branch from `main`) with a unique component ID from the `12xx` block. Take the next free ID after the highest one listed by `make list-components-ids`. The `14xx`/`16xx` experimental ranges are retired.
 
 ### Step 2: TypeScript Code Generation
 
@@ -29,7 +26,7 @@ In `js-sdk-toolchain`, generate serialization code and optional helper functions
 ### Step 3: C# Code Generation + Unity Implementation
 
 In `unity-explorer`:
-1. Run protocol update: `npm install @dcl/protocol@experimental && npm run build-protocol`
+1. Run protocol update: `npm install @dcl/protocol@next && npm run build-protocol`
    - Node/npm only — `build-protocol` runs the `protoc-gen-bitwise` plugin, a dependency-free Node script bundled in `@dcl/protocol` (no Python or extra packages required).
 2. Add partial class to `IDirtyMarker.cs`
 3. Register in `ComponentsContainer.cs` using `SDKComponentBuilder<T>`

@@ -71,3 +71,5 @@ Explorer/Assets/*.rsp text eol=lf
 # fail them with "$'\r': command not found" (seen on every Windows cloud build
 # running the UBA preBuildScript).
 *.sh text eol=lf
+
+Explorer/Assets/StreamingAssets/Js/sdk6-adapter.min.js -text
@@ -149,9 +149,6 @@ Emit these as warnings in the review body. They do NOT cause a FAIL on their own
 - **Main Scene Modified** — If `Explorer/Assets/Scenes/Main.unity` or its `.meta` appears in the changed files:
   > ⚠️ **Main scene modified** (`Explorer/Assets/Scenes/Main.unity`). This file is rarely changed intentionally — verify this wasn't pushed by mistake.
 
---- Security review integration ---
-Follow deployed Jarvis `skills/security-review/SKILL.md` and its Unity reference for security checks, evidence-based remedies, advisory scope and snapshot/run-marker publication. Put its single `DEPENDENCY_REVIEW` line before the verdict block below; preserve the four code-review lines and attribution.
-
 --- STEP 9 — Verdict ---
 Emit exactly these four lines at the end of the review body you post to GitHub, immediately before the attribution line (order matters — downstream automation parses them):
 REVIEW_RESULT: PASS ✅  (or FAIL ❌)