nccgs 3.0.0-rc.2 → 3.0.0-rc.3

package/CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changelog
 
+## 3.0.0-rc.3 — 2026-11-06
+
+- `/adopt` skill for a project that already has code, scenes, tests and design documents: inventory (versions, asmdefs, tests, scenes, the team's own documents, existing Claude rules), `brief.md` and `systems.md` written from the project as it is, decisions recorded in `state.md`, and one `ADOPT` task (existing EditMode tests, console ground truth, Play Mode + one screenshot) that proves the loop runs there. Nothing in the game changes without the user agreeing to the item. `/unity-foundation` stays the empty-project version.
+- Coming from NCCGS 2.x: `install`/`update` now recognise a 2.x install state and refuse with the exact steps (`npx nccgs@<2.x> uninstall`, then `npx nccgs@rc install`, then `/adopt`) instead of stacking two frameworks' hooks and skills. 2.x task records left in `.nccgs/tasks/` (schema 1/2) are kept as history and never listed, so they cannot block a session, a close or an uninstall.
+
 ## 3.0.0-rc.2 — 2026-11-05
 
 - Feedback with consent and transport: `feedback.consent` in project.json is `ask` until the person decides (`auto` / `manual` / `off`); the first session where an issue shows up asks once through Claude. With `auto`, a bundle is POSTed to `feedback.endpoint` when diagnostics cross a threshold (any task crash or hook error, 3 failed Unity calls, 5 failed verifications), when a task closes partial/blocked/failed, or every `periodicDays`; with `manual`, NCCGS suggests `/feedback` at most once per 6 h. Every send is logged in `.nccgs/feedback/sent.jsonl`; a copy of each bundle stays local. `nccgs feedback --send | --consent <level>`. Receiver: `tools/feedback-worker` (Cloudflare Worker → GitHub issue).

package/README.md

@@ -7,7 +7,7 @@ brief → options for the user → contract → edit → run (tests, Play Mode,
       → look → fix or ask → independent review → close → one-page report with real token cost
 ```
 
-**3.0.0-rc.2.** Built and verified on Unity 6000.3 and 6000.6 with Unity CLI 1.0.0-beta.14 and com.unity.pipeline 0.9, Claude Code 2.1.3xx, Windows. The sample game (a 2D endless runner) went from an empty scene to a vertical slice in four tasks with this loop; its reports are the reference for what a closed task looks like.
+**3.0.0-rc.3.** Built and verified on Unity 6000.3 and 6000.6 with Unity CLI 1.0.0-beta.14 and com.unity.pipeline 0.9, Claude Code 2.1.3xx, Windows. The sample game (a 2D endless runner) went from an empty scene to a vertical slice in four tasks with this loop; its reports are the reference for what a closed task looks like.
 
 ## Requirements
 
@@ -22,7 +22,7 @@ npx nccgs doctor  --project D:\Games\MyGame
 npx nccgs run     --project D:\Games\MyGame
 ```
 
-`install` adds `CLAUDE.md` (kept if you have one), `.claude/skills/` (11 NCCGS skills + 35 official Unity Skills), `.claude/agents/nccgs-*.md`, `.claude/nccgs/` (runtime, protocols, Ponytail) and `.nccgs/` (project config, tasks, evidence, reports). It merges hooks into `.claude/settings.json` without touching your other settings. `update` replaces managed files you did not change and records the ones you did; `uninstall` removes managed files, keeps `.nccgs/` and backs up what it removes. `run` launches Claude Code with the permission mode and MCP policy NCCGS expects (`acceptEdits` by default; `--autonomy full` for `bypassPermissions`).
+`install` adds `CLAUDE.md` (kept if you have one), `.claude/skills/` (12 NCCGS skills + 35 official Unity Skills), `.claude/agents/nccgs-*.md`, `.claude/nccgs/` (runtime, protocols, Ponytail) and `.nccgs/` (project config, tasks, evidence, reports). It merges hooks into `.claude/settings.json` without touching your other settings. `update` replaces managed files you did not change and records the ones you did; `uninstall` removes managed files, keeps `.nccgs/` and backs up what it removes. On a project that still carries NCCGS 2.x, `install` stops and prints the path (`npx nccgs@2.1.1 uninstall --project .`, then `install`, then `/adopt`); 2.x records under `.nccgs/` stay as history. `run` launches Claude Code with the permission mode and MCP policy NCCGS expects (`acceptEdits` by default; `--autonomy full` for `bypassPermissions`).
 
 ## Daily use
 
@@ -35,6 +35,7 @@ Open the project in the Editor (screenshots and live tests need it; without it t
 | `/status` | where are we | `.nccgs/project.html` and ten lines of status |
 | `/brainstorm` → `/map-systems` → `/vertical-slice` | a new game or a multi-task feature | `brief.md`, `systems.md`, `slice.json`, then one `/work` per planned task |
 | `/unity-foundation` | a fresh project, or tests cannot run | asmdefs, test assemblies, input, pipeline as a measured task |
+| `/adopt` | a project that already has code, scenes, tests, documents | `brief.md` + `systems.md` from what exists, `foundation.md`, one `ADOPT` task proving the loop runs here |
 | `/playtest` | does it feel right, tuning, difficulty | telemetry artifact, the playtester's judgement, your decision |
 | `/art-bible`, `/asset-spec` | before and after art | visual rules; import settings checked against them |
 | `/feedback` | something went wrong, or after a few days of use | a local bundle (`.nccgs/feedback/`) of what ran, failed and was blocked, to send for review |

package/cli/install.mjs

@@ -34,6 +34,7 @@ export function install(root, { update = false, force = false, dryRun = false, m
   if (!isUnityProject(root)) throw new Error(`${root} is not a Unity project (needs Assets/ and ProjectSettings/ProjectVersion.txt)`);
   const stateFile = at(root, "installState");
   const previous = exists(stateFile) ? readJson(stateFile) : null;
+  if (previous && isLegacy(previous)) throw new Error(legacyMessage(previous));
   if (update && !previous) throw new Error("NCCGS is not installed here; use `install`");
   if (!update && previous && !force) throw new Error(`NCCGS ${previous.version} is already installed; use \`update\``);
   const actions = [];            // { action: add|replace|keep|override|skip, path }
@@ -81,6 +82,21 @@ export function install(root, { update = false, force = false, dryRun = false, m
   return { version: PKG.version, dryRun, counts: count(actions), overrides, actions: dryRun ? actions.filter(a => a.action !== "keep") : undefined };
 }
 
+// NCCGS 2.x wrote the same state file with `frameworkVersion` and a `files` array. Its hooks live in
+// .claude/nccgs/hooks/ (not runtime/hooks/), so a 3.x install on top would leave two frameworks running.
+export const isLegacy = state => !!state && (typeof state.frameworkVersion === "string" || Array.isArray(state.files) || typeof state.version !== "string");
+function legacyMessage(state) {
+  const v = state.frameworkVersion ?? "2.x";
+  return [
+    `NCCGS ${v} is installed here. 3.x does not upgrade a 2.x install in place (its hooks, 58 skills, agents, rules and .nccgs/project.yaml would stay active next to the new ones).`,
+    `Remove 2.x with its own package first, then install 3.x:`,
+    `  npx nccgs@${/^\d/.test(v) ? v : "2"} uninstall --project . --dry-run`,
+    `  npx nccgs@${/^\d/.test(v) ? v : "2"} uninstall --project .`,
+    `  npx nccgs@rc install --project .`,
+    `2.x uninstall keeps .nccgs/ (state.md, tasks, reviews, evidence) and your CLAUDE.md; 3.x reads state.md and leaves the rest in place. Then run /adopt in Claude Code to bring the project under the 3.x loop.`
+  ].join("\n");
+}
+
 function count(actions) { return actions.reduce((acc, a) => { acc[a.action] = (acc[a.action] ?? 0) + 1; return acc; }, {}); }
 
 // Merge our hooks and deny rules into .claude/settings.json without touching anything else.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nccgs",
-  "version": "3.0.0-rc.2",
+  "version": "3.0.0-rc.3",
   "description": "NCCGS 3 - a Unity-first evidence loop for Claude Code: contract, run, look, review, report.",
   "license": "MIT",
   "type": "module",

package/runtime/task/ledger.mjs

@@ -15,13 +15,18 @@ export const taskFile = (root, id) => path.join(at(root, "tasks"), `${id}.json`)
 export function loadTask(root, id) {
   const file = taskFile(root, id);
   if (!exists(file)) throw new Error(`Task ${id} not found (${file})`);
-  return readJson(file);
+  const task = readJson(file);
+  if (!isOurs(task)) throw new Error(`Task ${id} is an NCCGS ${task.schemaVersion ?? "1"}.x record (${file}); 3.x reads only schema 3. It is kept as history and not opened or closed by this version.`);
+  return task;
 }
+// NCCGS 2.x kept its own records in the same folder (schema 1/2, `closed` flag). They stay as history
+// and are never listed, so a leftover 2.x task cannot block a session or an uninstall.
+const isOurs = task => task?.schemaVersion === 3 && typeof task.status === "string";
 export function saveTask(root, task) { task.updatedAt = nowIso(); writeJson(taskFile(root, task.id), task); return task; }
 export function listTasks(root) {
   const dir = at(root, "tasks");
   if (!exists(dir)) return [];
-  return fs.readdirSync(dir).filter(f => f.endsWith(".json")).map(f => readJson(path.join(dir, f))).sort((a, b) => (a.openedAt < b.openedAt ? 1 : -1));
+  return fs.readdirSync(dir).filter(f => f.endsWith(".json")).map(f => readJson(path.join(dir, f))).filter(isOurs).sort((a, b) => (a.openedAt < b.openedAt ? 1 : -1));
 }
 export function openTasks(root) { return listTasks(root).filter(t => t.status !== "closed"); }
 

package/template/CLAUDE.md

@@ -10,7 +10,7 @@ This Unity project runs under NCCGS 3: a task is done when the game has run and
 5. `.claude/nccgs/protocols/*.md`, then the official Unity Skills in `.claude/skills/`, then your own inference.
 
 ## Skills
-`/brainstorm` → `/map-systems` → `/vertical-slice` for a new game or a multi-task feature (brief, systems map + slice plan, then `/work` per planned task). `/unity-foundation` on a fresh project. `/playtest` for feel and tuning (telemetry + playtester judgement + user decision). `/art-bible` and `/asset-spec` before and after art. `/status` for where we are. `/feedback` when something went wrong or after a few days of use.
+`/brainstorm` → `/map-systems` → `/vertical-slice` for a new game or a multi-task feature (brief, systems map + slice plan, then `/work` per planned task). `/unity-foundation` on a fresh project; `/adopt` on a project that already has code, scenes and tests (brief and systems map from what exists, one task that proves the loop runs). `/playtest` for feel and tuning (telemetry + playtester judgement + user decision). `/art-bible` and `/asset-spec` before and after art. `/status` for where we are. `/feedback` when something went wrong or after a few days of use.
 
 ## The loop (skill `/work`)
 Brief → options for the user when the decision is subjective → `task open` → edit → `task verify` → **look at the screenshots and console** → fix or ask → `task review` (rigor ≥ production) → `task close` → report.

package/template/skills/adopt/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: adopt
+description: Bring an existing Unity project (code, scenes, tests and design documents already there) under NCCGS - inventory what exists, write the brief and systems map from the project as it is, record the foundation, and close one task that proves the evidence loop runs on this project. Use right after `nccgs install` on a project that is not empty, or when NCCGS was added late.
+allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Agent, AskUserQuestion
+---
+
+# /adopt
+
+Output: `.nccgs/design/brief.md`, `.nccgs/design/systems.md` and `.nccgs/design/foundation.md` written from the project **as it is** (not from an idea), and a closed task `ADOPT` whose evidence proves the loop runs here. Nothing in the game changes unless the user agrees to a specific item in step 4.
+
+`/brainstorm` and `/map-systems` assume a new game; this skill is their replacement for a project that already has months of work in it. `/unity-foundation` is the smaller version of this for an empty project.
+
+## 1. Inventory (read-only, no Unity calls)
+
+Read, in this order, and write what you find to `.nccgs/design/foundation.md` under **Present / Missing / Decision needed**:
+
+- `ProjectSettings/ProjectVersion.txt`, `Packages/manifest.json`: Editor version, render pipeline, Input System or legacy input, test framework, `com.unity.pipeline`.
+- `Assets/` layout: top-level folders, every `.asmdef` (runtime and test), scenes in Build Settings (`ProjectSettings/EditorBuildSettings.asset`), the scene that loads first.
+- Tests: `Assets/**/Tests/**`, EditMode and PlayMode assemblies, roughly how many tests, whether they compile against the current code (`unity test --mode EditMode` is run in step 5, not here).
+- Design documents the team already keeps: `*.md` in the repo root and `Docs/`, `README`, a GDD, a Notion/Confluence export, issue templates. Name each with one line on what it is the source of truth for. These stay where they are; NCCGS points at them, it does not move them.
+- Existing Claude material: the project's `CLAUDE.md` (`install` kept it), `.claude/rules/`, other `.claude/skills/` and `.claude/agents/` not from NCCGS, `.cursorrules`, `.github/copilot-instructions.md`. List anything that contradicts `.claude/nccgs/protocols/*.md` (for example a rule that says "done when tests pass" or a Unity MCP route).
+- The game itself, from code: the MonoBehaviours on the first scene, the main loop (what starts a run, what ends it), the systems that own state (player, spawning, score, save, UI), where input is read (`InputAction` or polling), where tuning numbers live (ScriptableObjects, constants, inspector fields).
+
+Keep the inventory to facts you read. Do not guess versions or test counts; write "not found" instead.
+
+## 2. Brief and systems map from the existing project
+
+Write `.nccgs/design/brief.md` with the `/brainstorm` headings (Fantasy, Core loop, Pillars, Vertical slice proves, Feel numbers, Out of scope, Open questions), but every line comes from what the project already does. "Vertical slice proves" becomes **What already works** (seen in code and scenes) and **What is unproven** (never had a test or a measurement). Feel numbers are the values found in ScriptableObjects, constants and inspector fields, with the file each one lives in; the "who decides" column is empty until the user fills it.
+
+Write `.nccgs/design/systems.md` as `/map-systems` would: 3–8 systems, each with its responsibility, the state it owns, what it reads, its Unity surface and **the files that implement it today**. Mark the two riskiest couplings and any system whose logic is only in MonoBehaviours (no plain C# → no EditMode tests possible without a refactor; note it, do not refactor).
+
+Show both files to the user with AskUserQuestion before going on; fix what they correct. Where the project's own documents disagree with the code, say so and ask which one is the truth — never rewrite their design documents from code without being asked.
+
+## 3. Decisions the user owns
+
+Ask only about real forks, one at a time:
+
+- Which existing design document is the source of truth for the brief (`state.md` will link to it).
+- Default `rigor` for this project (`production` is right for anything that ships; `prototype` for a jam).
+- Rules in the existing `CLAUDE.md` or `.claude/rules/` that contradict NCCGS: keep theirs, drop theirs, or merge. Propose the merge text; the user decides. Never delete a rule silently.
+- If input is polled or on the legacy Input Manager: note that `simulate_key`, `--shots` and playtests will not drive the game until it reads input through `InputAction`s. Offer it as a later `/work` task; do not do it now.
+
+Write the decisions to `.nccgs/state.md` under a dated **Adopted** entry.
+
+## 4. The ADOPT task
+
+Open one task that proves the loop runs on this project, with the smallest possible edit set:
+
+```
+node .claude/nccgs/runtime/task/task.mjs open --id ADOPT --title "Adopt NCCGS on <project>" --rigor production --files "<test asmdefs and smoke test files only>" --criteria-json '[
+  { "id": "editmode", "description": "the existing EditMode tests pass", "assertions": [{ "artifact": ".nccgs/evidence/measurements/ADOPT-tests.json", "pointer": "/failed", "op": "eq", "value": 0 }, { "artifact": ".nccgs/evidence/measurements/ADOPT-tests.json", "pointer": "/passed", "op": "gte", "value": 1 }] },
+  { "id": "compiles", "description": "no compilation errors in the console", "assertions": [{ "artifact": ".nccgs/evidence/measurements/ADOPT-console.json", "pointer": "/groundTruth/compilationFailed", "op": "eq", "value": false }] },
+  { "id": "observe", "description": "the first scene enters and exits Play Mode with no exception and one screenshot shows the game", "assertions": [{ "artifact": ".nccgs/evidence/measurements/ADOPT-observe.json", "pointer": "/exceptionCount", "op": "eq", "value": 0 }, { "artifact": ".nccgs/evidence/screens/ADOPT/01.png", "op": "image" }] }
+]' --notes "How to try it: open the project, run the EditMode tests, press Play on <scene>."
+```
+
+If the project has no test assembly at all, add the `playmode` criterion from `/unity-foundation` and create only `Assets/Tests/EditMode/<Game>.Tests.EditMode.asmdef` plus one smoke test that references one real class of the game (so the test proves the runtime assembly is reachable). Nothing else is created; packages are not added without asking, and `com.unity.pipeline` is installed with `unity pipeline install --project-path .` only after the user agrees.
+
+## 5. Run, look, review, close
+
+`task verify --kind tests`, `--kind console`, `--kind observe --hold 5` as in `/work`; look at the screenshot and the console before anything else. A failing existing test is a finding for the user, not something to fix inside ADOPT: record it in `foundation.md` and in the task notes, and close `partial` if it blocks a criterion. Review and close as in `/work`; the report is the first one this project gets and the baseline every later report is compared with.
+
+End with: the three design paths, the report path, the list of decisions still open, and `next:` either `/map-systems` (when the user wants a slice plan for the next milestone) or `/work` for the first real change.

package/unity-skills/implement-in-app-purchases/README.md

@@ -1,233 +0,0 @@
-# Unity In-App Purchases Skill
-
-This skill helps you implement, configure, debug, and migrate Unity In-App Purchases (IAP) using `com.unity.purchasing` v5. It covers standard Apple App Store / Google Play billing, IAP D2C Capabilities (Direct-to-Customer — Stripe/Coda via Unity Cloud), and conversion from a wide range of third-party and native billing implementations.
-
----
-
-## What This Skill Covers
-
-| Path | When to use |
-|---|---|
-| **Add IAP to a new project** | No existing IAP — start from scratch with Unity IAP 5 |
-| **Migrate v4 → v5** | Project uses `IStoreListener`, `UnityPurchasing.Initialize`, or `ConfigurationBuilder` |
-| **Convert native Google BillingClient** | Project calls Android BillingClient via `AndroidJavaObject` / JNI bridge |
-| **Convert native iOS StoreKit** | Project uses a custom ObjC/Swift StoreKit plugin bridged via `DllImport("__Internal")` |
-| **Convert Essential Kit billing** | Project uses VoxelBusters Essential Kit for in-app purchases (without losing other features) |
-| **Assess/Convert UniPay (FLOBUK)** | Project uses UniPay — determines whether migration is needed or possible |
-| **Assess/Convert RevenueCat** | Project uses RevenueCat — evaluate/implement observer mode to work with Unity IAP 5 |
-| **Assess/Convert Adapty** | Project uses Adapty — evaluate/implement observer mode to work with Unity IAP 5 |
-| **Implement IAP D2C Capabilities** | Add third-party payment provider (Stripe or Coda) via Unity Cloud |
-
-The skill always scans the project first and routes to the correct path automatically. You can also specify a path manually if you know exactly which one you need.
-
----
-
-## Example Prompts
-
-```
-Add in-app purchases code to my game. I have a 100-coin pack and a Remove Ads unlock.
-```
-```
-Migrate my existing IAP code in the project from Unity IAP v4 to v5.
-```
-```
-My project uses AndroidJavaObject to call Google Play BillingClient. Convert it to Unity IAP.
-```
-```
-I have a custom ObjC StoreKit plugin with SKPaymentQueue. Replace it with Unity IAP.
-```
-```
-Disable Essential Kit billing and replace with Unity IAP 5. Keep other Essential Kit features working as before.
-```
-```
-Can my RevenueCat project implement app store purchases through Unity's IAP v5?
-```
-```
-My project uses Adapty. What features will we lose if we use Unity IAP instead? Give me a detailed report and do not make any changes now.
-```
-```
-Add Stripe payment support via Unity IAP D2C Capabilities.
-```
-```
-Add a web checkout option for my players using Unity's IAP D2C Capabilities with Coda.
-```
-
----
-
-## Path Details, Limitations, and Best Practices
-
-### Add IAP to a New Project
-
-**What it does:** Installs Unity IAP 5, creates an `IAPManager`, wires up the two-step purchase flow (pending → confirm), integrates with your existing save system, and connects to your shop UI.
-
-**Limitations:**
-- The skill cannot create App Store Connect or Google Play Console product entries — you must do that manually.
-- If you use local Google Play receipt validation, you must run the Receipt Validation Obfuscator manually in the Unity Editor (**Services > In-App Purchasing > Receipt Validation Obfuscator**).
-- Apple local receipt validation is a no-op under StoreKit 2. Use server-side JWS validation for Apple.
-
-**Best practices:**
-- Define all products in one authoritative catalog (a `ScriptableObject` or constants class) — not scattered across button click handlers.
-- Always call `ConfirmPurchase` **after** saving the granted reward. An unconfirmed purchase re-delivers safely; a confirmed-but-unsaved one loses the reward permanently.
-- Subscribe to all events **before** calling `Connect()` — pending purchases from a previous session may fire immediately on reconnect.
-- Add a "Restore Purchases" button for any project with NonConsumable or Subscription products — required on iOS.
-
----
-
-### Migrate v4 → v5
-
-**What it does:** Replaces the listener-based `IStoreListener` / `UnityPurchasing.Initialize` / `ConfigurationBuilder` pattern with the event-driven `StoreController` pattern.
-
-**Limitations:**
-- `product.receipt` and `product.hasReceipt` are removed. The skill migrates ownership checks to `store.CheckEntitlement(product)` — verify your entitlement logic after migration.
-- Apple local validation via `CrossPlatformValidator` still compiles but is a no-op under StoreKit 2. If your project validates Apple receipts locally, this validation silently stops working after migration.
-- Developer payload (the third `Purchase()` argument) is removed. If your backend uses it, a backend change is required.
-- `SubscriptionManager` is replaced — subscription info is now on `order.Info.PurchasedProductInfo`, not on `CartItem`.
-
-**Best practices:**
-- Migrate one system at a time: get initialization working first, then purchase flow, then restore.
-- Run the migration in a branch. The skill uses `#if` guards where needed, but test thoroughly before removing the old code.
-- After migration, recheck all `OnPurchaseConfirmed` handlers — the event now receives `Order` (base type) and you must pattern-match `ConfirmedOrder` vs `FailedOrder`.
-
----
-
-### Convert Native Google BillingClient
-
-**What it does:** Converts C# → JNI → BillingClient bridge code to Unity IAP 5, preserves the public billing API via a compatibility facade, and wraps old native code in `#if !USE_UNITY_IAP_V5` for easy rollback.
-
-**Limitations:**
-- **Multiple subscription base plans / offer tokens** (`basePlanId`, `offerToken`, `offerId`) are a hard blocker — Unity IAP does not expose offer-level selection. You must either simplify your Play Console subscription setup to one base plan per product, or stay on native billing.
-- **Personalized price disclosure** (`setIsPersonalizedPrice`) and **alternative billing / external offers** are hard blockers.
-- **Multi-quantity purchases** (quantity > 1 per transaction) are not supported in Unity IAP.
-- A mixed native BillingClient + Unity IAP architecture is not supported — both compete for the same `PurchasesUpdatedListener` slot. The skill will not generate a mixed setup.
-- The receipt format changes: the backend receives `order.Info.Receipt` (a JSON object containing `purchaseToken`, `orderId`, and `signature`) instead of raw fields. If your backend parses these fields individually, a backend update is required.
-
-**Best practices:**
-- Run the blocker scan and read the migration report before making any changes. Hard blockers require a decision before code is written.
-- Keep the Gradle billing dependency in place until migration is validated — Unity IAP brings its own BillingClient, but removing the old dependency prematurely can break the build in unexpected ways.
-- Use the `#if USE_UNITY_IAP_V5` / `#if !USE_UNITY_IAP_V5` guards throughout. The rollback path (remove the define) must work cleanly before you ship.
-- Test on a physical Android device with a real sandbox account — the BillingClient behavior in the Unity Editor and on emulators is not representative of production.
-
----
-
-### Convert Native iOS StoreKit
-
-**What it does:** Converts a custom Objective-C or Swift StoreKit plugin (bridged via `DllImport("__Internal")` and `UnitySendMessage`) to Unity IAP 5, preserving the C# game-facing API via a compatibility facade.
-
-**Limitations:**
-- **Receipt format is a breaking backend change.** Unity IAP uses per-transaction JWS (StoreKit 2 style) rather than the SK1 base64 app receipt bundle. If your backend validates the receipt bundle against Apple's `/verifyReceipt` endpoint, it must migrate to Apple's App Store Server API or JWS validation before you can ship.
-- **Promotional offer signing** (`SKPaymentDiscount` / SK2 signed offers) is a hard blocker — Unity IAP has no equivalent for server-signed promotional offers.
-- **Win-back offers** (StoreKit 2) are not supported in Unity IAP 5.4.
-- **`SKStorefront`** (region detection via storefront change observer) is not exposed in Unity IAP.
-- **`SKReceiptRefreshRequest`** has no direct equivalent — `store.FetchPurchases()` covers the purchase re-delivery use case but not manual receipt refresh.
-- ObjC/Swift plugin files cannot use C# `#if` defines. The skill guards only the C# call sites — the native files remain in `Assets/Plugins/iOS/` and compile unconditionally.
-- A mixed native StoreKit + Unity IAP architecture is not supported — both register as `SKPaymentQueue` observers and only one reliably receives callbacks.
-
-**Best practices:**
-- Audit the backend receipt validation endpoint before starting. If it calls `/verifyReceipt`, plan the backend migration in parallel with the client migration.
-- If the plugin intercepts App Store promotional purchases (`shouldAddStorePayment`), wire up `OnPromotionalPurchaseIntercepted` and `ContinuePromotionalPurchases()` before removing the native interceptor.
-- Test Ask-to-Buy explicitly — the deferred → pending two-stage flow behaves differently than a native `PURCHASING` → `PURCHASED` transition.
-- Validate the migration on TestFlight, not just in the Unity Editor or Simulator. StoreKit behavior differs between Editor sandbox, Simulator, and TestFlight builds.
-
----
-
-### Convert Essential Kit Billing
-
-**What it does:** Disables the Essential Kit Billing service flag in `EssentialKitSettings.asset`, removes the conflicting `com.android.billingclient` Gradle dependency, and implements Unity IAP 5 using the product catalog extracted from the Essential Kit settings.
-
-**Limitations:**
-- Essential Kit C# source files are **not deleted**. The Billing service is disabled via the settings flag — all EK code remains and compiles. Do not expect a clean removal.
-- Only the Billing service is affected. All other Essential Kit services (Notification, GameServices, etc.) are left completely untouched.
-- **Product IDs must not change.** The same IDs used in Essential Kit must be carried over to Unity IAP to preserve store history.
-- If your project uses **server-side receipt validation**, the receipt format changes from `transaction.RawData` (Android) and `transaction.Receipt` (iOS JWS) to `order.Info.Receipt` and `order.Info.Apple?.jwsRepresentation`. Document the backend change required.
-- Subscriptions are fully supported, but the restore path changes — EK's `OnRestorePurchasesComplete` maps to both `store.OnPurchasesFetched` and the `RestoreTransactions` callback in Unity IAP.
-
-**Best practices:**
-- Run `Assets > External Dependency Manager > Android Resolver > Force Resolve` after removing the Gradle billing dependency — do not skip this step.
-- Verify the Essential Kit Billing service is visually disabled in **Window > Voxel Busters > Essential Kit > Open Settings → Services** after the settings file edit.
-- Confirm all product IDs in App Store Connect and Play Console match the Unity IAP catalog exactly before testing.
-
----
-
-### Assess UniPay (FLOBUK)
-
-**What it does:** This path does **not** perform a conversion. It assesses whether migration is needed and routes to one of three outcomes: unsupported platform (stop), upgrade required (stop), or no action needed (UniPay already wraps Unity IAP 5).
-
-**Limitations:**
-- UniPay's Steam, Meta Quest, PayPal, and Facebook Instant Games integrations have **no Unity IAP equivalent**. If your project targets any of these platforms, there is no migration path — keep UniPay.
-- If `com.unity.purchasing` is below v5.4, IAP D2C Capabilities (Stripe/Coda) are not available — an upgrade to the latest stable v5.4+ is needed before adding D2C support.
-- The skill does not perform a "remove UniPay" conversion — that is a manual refactor scoped to what features you are replacing.
-
-**Best practices:**
-- If the assessment concludes "no action needed," there is no code to write. Work within UniPay's API for new products or purchase logic changes.
-- If you want to remove UniPay entirely and use Unity IAP directly, ask the skill explicitly and describe which UniPay features you are replacing — it will assess feasibility and scope.
-
----
-
-### Assess/Convert RevenueCat
-
-**What it does:** Evaluates whether the project can switch to Unity IAP 5 for handling purchases. Produces one of three outcomes: already in observer mode (no action), blockers detected (report + two choices), or no blockers (two conversion paths: observer mode or full removal).
-
-**Limitations:**
-- **Amazon Appstore** is a hard blocker — Unity IAP 5 has removed Amazon support. RevenueCat observer mode also does not work reliably on Amazon builds. If your project targets Amazon, conversion is not viable.
-- **RevenueCat Offerings / remote paywalls** have no Unity IAP equivalent — all products must be defined in code or a local catalog.
-- **RevenueCat A/B testing (Experiments)** has no Unity IAP equivalent.
-- **Cross-platform entitlement sync** (a user who buys on iOS retains access on Android) has no Unity IAP equivalent without a custom backend.
-- **RevenueCat webhook events** (subscription renewals, cancellations, billing issues) are not delivered by Unity IAP — you would need to build your own subscription event infrastructure.
-- In **observer mode**, `SyncPurchases()` must be called after every Unity IAP confirmed purchase. Missing this call means RevenueCat does not validate the receipt and `CustomerInfo` is not updated.
-
-**Best practices:**
-- Run the full feature check before deciding. RevenueCat's value often comes from features that are not obvious in the codebase (e.g., webhooks configured server-side).
-- If the project has a marketing team managing paywall copy or pricing remotely via RevenueCat Offerings, a full removal will require significant UI work to replace that capability.
-- Observer mode is the lower-risk path — it preserves RevenueCat's server-side validation and subscription lifecycle tracking while Unity IAP handles the native purchase flow.
-
----
-
-### Assess/Convert Adapty
-
-**What it does:** Evaluates whether the project can switch to Unity IAP 5 for app store purchase handling. Produces one of three outcomes: already in observer mode (no action), blockers detected (report + two choices), or no blockers (observer mode or full removal).
-
-**Limitations:**
-- **Adapty Paywall Builder** has no Unity IAP equivalent — and it is also **unavailable in Adapty's own Observer Mode**. Switching to observer mode loses Paywall Builder regardless of whether Unity IAP is involved.
-- **Adapty A/B testing** has no Unity IAP equivalent. In observer mode, A/B testing is possible but requires significant manual instrumentation.
-- **Cross-platform entitlement sync** has no Unity IAP equivalent without a custom backend.
-- In **observer mode**, `Adapty.ReportTransaction()` must be called after every Unity IAP confirmed purchase. Missing this call means Adapty does not validate the receipt server-side.
-
-**Best practices:**
-- If your marketing team uses Adapty's Paywall Builder to update paywall layouts without app releases, note that this capability is lost in observer mode. Make sure all stakeholders understand this before proceeding.
-- Full removal requires replacing any `AdaptyUI` / `PaywallView` shop UI with custom Unity UI before Adapty can be removed. Budget time for this work.
-- Observer mode is the lower-risk path and preserves Adapty's webhook delivery and analytics integrations.
-
----
-
-### Implement IAP D2C Capabilities
-
-**What it does:** Adds Direct-to-Customer (D2C) third-party payment provider support (Stripe or Coda) via Unity Cloud, including remote catalog setup, deep link configuration, the built-in payment options picker UI, Apple/Google external purchase compliance tools, and entitlement delivery guidance.
-
-**Limitations:**
-- Requires **Unity IAP v5.4+**, **Unity Editor 2022.3+**, `com.unity.services.authentication` **v3.7.1+**, and `com.unity.services.core` **v1.18.0+**. All must be satisfied before any code is written.
-- **Subscriptions are not supported** by IAP D2C Capabilities in v5.4. Only Consumable and NonConsumable products can be used.
-- Requires a **Stripe or Coda account** connected in the Unity Cloud IAP dashboard, and Unity must enable D2C for your organization — contact your Unity Client Partner if it is not yet enabled.
-- **Routing rules** must be configured in the Unity Dashboard before any player is offered a D2C payment option. Without a routing rule, no provider is offered even if a provider account is connected.
-- **External web payments via Stripe/Coda are permitted in select regions only.** Apple and Google have their own program eligibility requirements. The developer is responsible for determining eligibility and meeting disclosure requirements — the skill does not perform compliance on your behalf.
-- **Anonymous sign-in** must not be used as the authentication method. If a player's session token is lost (reinstall, app data clear), purchase history tied to an anonymous identity becomes unrecoverable.
-- The **receipt format is different from standard IAP 5** — D2C purchases go through Unity Cloud, not the device's native store, so `order.Info.Apple` and `order.Info.Receipt` behave differently for D2C orders.
-
-**Best practices:**
-- Set up **routing rules** in the Unity Dashboard before testing. Without them, `GetEligiblePaymentProviders()` returns an empty list and the purchase UI never appears — this is a common "nothing happens" issue during initial integration.
-- Use a **proxy HTML page** for the Success Redirect URL rather than a direct app-scheme URL. On some Android and iOS devices, direct app-scheme redirects from the payment provider domain are silently dropped. Host the proxy on a stable HTTPS domain you control.
-- Use **`ShowPurchaseOption(catalogListingId)`** as the primary purchase entry point — it shows the built-in picker UI and handles provider selection automatically. Only fall back to `PurchaseProduct` directly when `GetEligiblePaymentProviders()` returns an empty `Providers` list.
-- Configure a **Cancel Redirect URL** in the payment provider dashboard — without it, the checkout page has no "Back" button and players who change their mind are stuck in the browser.
-- The SDK remembers the **last used payment provider per player per device** (provider memory). This is expected behavior, not a bug. Clear app data to reset it during testing.
-- Deploy the **Deployment package** (`com.unity.services.deployment`) early — it is required to push `.ucat` product definitions to the Remote Catalog. Without it, the catalog cannot be deployed and `FetchRemoteCatalog()` returns no products.
-
----
-
-## General Best Practices
-
-- **Always let the skill scan first.** The pre-check (`pre-check.md`) detects third-party packages, native billing code, and existing Unity IAP versions before routing. Skipping it leads to incompatible changes.
-- **Read the migration report before approving any code changes.** Every conversion path produces a report covering what will change, what blockers were found, and what manual steps remain. Review it before proceeding.
-- **Never confirm a purchase before saving the reward.** An unconfirmed purchase re-delivers safely. A confirmed-but-unsaved one is gone permanently.
-- **Subscribe to all failure events.** `OnProductsFetchFailed`, `OnPurchasesFetchFailed`, `OnStoreDisconnected` — not subscribing generates runtime warnings and leaves failures silently unhandled.
-- **Subscribe to `OnPurchaseDeferred`.** Ask-to-Buy (iOS) and Google Play deferred purchases fire this event. Not subscribing silently drops them.
-- **Use `#if USE_UNITY_IAP_V5` guards** for all migration work. The rollback path (remove the define from Player Settings) must work cleanly before shipping.
-- **Test with real sandbox accounts on real devices.** Editor sandbox and emulators do not reproduce all edge cases — particularly pending purchases, deferred flows, and restore behavior.

package/unity-skills/optimize-web/resources/WebOptimizer.cs

@@ -1,21 +0,0 @@
-using UnityEditor;
-using UnityEditor.Build;
-
-public class WebOptimizer
-{
-    [MenuItem("Tools/Apply Web Release Settings")]
-    public static void Optimize()
-    {
-        var target = NamedBuildTarget.WebGL;
-        PlayerSettings.SetIl2CppCodeGeneration(target, Il2CppCodeGeneration.OptimizeSize);
-        PlayerSettings.SetManagedStrippingLevel(target, ManagedStrippingLevel.High);
-        PlayerSettings.stripUnusedMeshComponents = true;
-        PlayerSettings.WebGL.dataCaching = true;
-        PlayerSettings.WebGL.compressionFormat = WebGLCompressionFormat.Brotli;
-        PlayerSettings.WebGL.exceptionSupport = WebGLExceptionSupport.None;
-        PlayerSettings.WebGL.debugSymbolMode = WebGLDebugSymbolMode.Off;
-        PlayerSettings.WebGL.wasm2023 = true;
-        UnityEditor.WebGL.UserBuildSettings.codeOptimization =
-            UnityEditor.WebGL.WasmCodeOptimization.DiskSizeLTO;
-    }
-}

package/unity-skills/optimize-web/resources/toktx-examples.sh

@@ -1,11 +0,0 @@
-# Albedo / diffuse (ETC1S, lossy, smallest)
-toktx --bcmp --lower_left_maps_to_s0t0 output.ktx2 input.png
-
-# Normal / metallic / detail (UASTC, high fidelity)
-toktx --encode uastc --uastc_quality 2 --t2 --lower_left_maps_to_s0t0 output.ktx2 input.png
-
-# Fix "ICC profile not found" errors
-toktx --bcmp --assign_oetf srgb --lower_left_maps_to_s0t0 output.ktx2 input.png
-
-# Linear data (normal maps, masks)
-toktx --bcmp --assign_oetf linear --lower_left_maps_to_s0t0 output.ktx2 input.png

package/unity-skills/setup-vivox-voice-chat/evals/.env.example

@@ -1,6 +0,0 @@
-# Copy this file to .env and fill in your credentials:
-#   cp .env.example .env
-#
-# Get your LiteLLM API key from: https://uai-litellm.internal.unity.com
-OPENAI_API_KEY=your-litellm-api-key-here
-OPENAI_BASE_URL=https://uai-litellm.internal.unity.com

package/unity-skills/setup-vivox-voice-chat/evals/README.md

@@ -1,101 +0,0 @@
-# Vivox Voice & Text Chat Skill Eval Suite
-
-Evaluation suite for the `setup-vivox-voice-chat` skill, powered by [Promptfoo](https://www.promptfoo.dev/). Validates that the skill routes the model to the correct Vivox v16 APIs (no v4/legacy hallucinations) across init, channel join, and messaging.
-
-## Prerequisites
-
-- **Node.js** v18 or later
-- A **LiteLLM API key** (from https://uai-litellm.internal.unity.com)
-
-## Setup
-
-### 1. Install Promptfoo
-
-```bash
-# Option A: install globally
-npm install -g promptfoo
-
-# Option B: use npx (no install needed)
-npx promptfoo@latest eval
-```
-
-### 2. Configure your API key
-
-```bash
-cd evals/
-cp .env.example .env
-```
-
-Open `.env` and set your personal LiteLLM key:
-
-```
-OPENAI_API_KEY=your-litellm-api-key-here
-OPENAI_BASE_URL=https://uai-litellm.internal.unity.com
-```
-
-> **Important:** Never commit your `.env` file. It is already in `.gitignore`.
-
-## Running the evals
-
-All commands should be run from the `evals/` directory.
-
-Use `-j 10` to run up to 10 eval requests concurrently.
-
-### Run the full suite
-
-```bash
-promptfoo eval -j 10
-```
-
-### Run a specific test file
-
-```bash
-promptfoo eval --tests tests/init-and-login.yaml -j 10
-promptfoo eval --tests tests/voice-channels.yaml -j 10
-promptfoo eval --tests tests/text-chat.yaml -j 10
-```
-
-## Viewing results
-
-### Terminal output
-
-Results are printed to the terminal with pass/fail per assertion.
-
-### Interactive web UI
-
-```bash
-promptfoo view
-```
-
-Opens a local UI (usually `http://localhost:15500`) for browsing results, filtering, and comparing runs.
-
-## Assertions used
-
-| Type | What it checks |
-|---|---|
-| `icontains` | Response contains a substring (case-insensitive), e.g. an exact Vivox API name |
-| `not-icontains` | Response does NOT contain a substring (used to catch v4 legacy names like `Client.Instance`) |
-| `llm-rubric` | An LLM judges whether the response meets a semantic requirement (e.g. correct init order) |
-
-## Adding new tests
-
-1. Create a new YAML file in `tests/`:
-
-```yaml
-- description: "Short description of what is being tested"
-  vars:
-    user_message: "The user request to test"
-    reference_content: "file://../references/your-reference.md"  # optional
-  assert:
-    - type: icontains
-      value: "VivoxService.Instance.JoinGroupChannelAsync"
-    - type: not-icontains
-      value: "SendDirectedTextMessageAsync"
-    - type: llm-rubric
-      value: |
-        Describe the semantic requirement the response must meet.
-```
-
-2. Add the file to `promptfooconfig.yaml` under `tests:`.
-
-3. Run it: `promptfoo eval --tests tests/your-new-test.yaml`.

package/unity-skills/setup-vivox-voice-chat/evals/promptfooconfig.yaml

@@ -1,32 +0,0 @@
-description: "Vivox Voice & Text Chat Skill Eval Suite"
-
-providers:
-  # Evaluated model: used by the test itself
-  - id: openai:chat:claude-sonnet-4-5
-    config:
-      max_tokens: 2048
-
-prompts:
-  - id: eval-prompt
-    label: "Eval prompt"
-    raw: "{{skill_content}}\n\n{{reference_content}}\n\n{{custom_instructions}}\n\n## User Request\n\n{{user_message}}"
-
-defaultTest:
-  options:
-    # Assertion judge: used by llm-rubric
-    provider: openai:chat:claude-sonnet-4-6
-  vars:
-    skill_content: file://../SKILL.md
-    reference_content: ""
-    custom_instructions: |
-      IMPORTANT:
-      - This is a planning eval. Do not emit MCP XML/tool-call tags.
-      - Refer to APIs with their exact names as documented in the provided skill and references. Do not invent or paraphrase symbol names.
-      - Do not mention tool names you will not call. If a step is inapplicable, explain the behavior without naming the omitted API.
-      - Always present the complete plan up front. If a step requires a user action, describe what you will do after it succeeds and what happens if it fails, in a single response.
-      - Answer only the step or phase requested by the user message. Do not include unrelated setup or migration content that was not asked for.
-
-tests:
-  - file://tests/init-and-login.yaml
-  - file://tests/voice-channels.yaml
-  - file://tests/text-chat.yaml

package/unity-skills/setup-vivox-voice-chat/evals/tests/init-and-login.yaml

@@ -1,76 +0,0 @@
-# ============================================================
-# WORKFLOW: Init + Login — correct order and re-init guard
-# ============================================================
-
-- description: "Cold-start init: UGS Core -> Auth -> Vivox Init -> Vivox Login, in order"
-  vars:
-    user_message: |
-      I'm adding Vivox to a fresh Unity project. Walk me through
-      the initialization from an empty MonoBehaviour Start method.
-    reference_content: file://../references/init-and-login.md
-  assert:
-    - type: icontains
-      value: "UnityServices.InitializeAsync"
-    - type: icontains
-      value: "AuthenticationService.Instance.SignInAnonymouslyAsync"
-    - type: icontains
-      value: "VivoxService.Instance.InitializeAsync"
-    - type: icontains
-      value: "VivoxService.Instance.LoginAsync"
-    - type: llm-rubric
-      value: |
-        The response MUST describe the four initialization calls in this
-        exact order:
-        1. UnityServices.InitializeAsync
-        2. AuthenticationService.Instance.SignInAnonymouslyAsync
-        3. VivoxService.Instance.InitializeAsync
-        4. VivoxService.Instance.LoginAsync
-        Any other ordering (e.g. Vivox init before UGS init, or Login
-        before Vivox init) is a failure.
-        The response MUST NOT use v4 legacy patterns (Client.Instance,
-        ILoginSession, AccountId, ChannelId) as callable code. It is
-        fine — even helpful — to mention those names in a "don't use
-        these" warning or migration note; a failure is only when the
-        code samples or step-by-step instructions actually invoke them.
-
-- description: "Login with display name: LoginOptions.DisplayName"
-  vars:
-    user_message: |
-      After Vivox is initialized, sign the player in with the display name
-      "Sunbeam" and enable text-to-speech.
-    reference_content: file://../references/init-and-login.md
-  assert:
-    - type: icontains
-      value: "LoginOptions"
-    - type: icontains
-      value: "DisplayName"
-    - type: icontains
-      value: "EnableTTS"
-    - type: icontains
-      value: "VivoxService.Instance.LoginAsync"
-    - type: llm-rubric
-      value: |
-        The response must construct a LoginOptions with DisplayName set to
-        "Sunbeam" and EnableTTS set to true, then pass it to
-        VivoxService.Instance.LoginAsync. It must not USE the v4 AccountId
-        or ILoginSession types as callable code (mentioning them in a
-        "don't use" warning is acceptable — failure is only when the code
-        actually invokes them).
-
-- description: "Double-init must warn about VxErrorAlreadyInitialized (5041)"
-  vars:
-    user_message: |
-      My Start method runs every time the main scene reloads and I'm
-      seeing Vivox errors. How do I stop it from re-initializing?
-    reference_content: file://../references/init-and-login.md
-  assert:
-    - type: icontains
-      value: "5041"
-    - type: llm-rubric
-      value: |
-        The response must identify the underlying issue as
-        VivoxService.Instance.InitializeAsync being called more than once,
-        cite the 5041 VxErrorAlreadyInitialized error, and propose a fix
-        such as guarding with IsInitialized or making the bootstrap
-        object DontDestroyOnLoad. The fix must NOT be to catch and
-        swallow the exception.

package/unity-skills/setup-vivox-voice-chat/evals/tests/text-chat.yaml

@@ -1,65 +0,0 @@
-# ============================================================
-# WORKFLOW: Text chat — channel messages, directed messages, history
-# ============================================================
-
-- description: "Send a channel message and receive channel messages"
-  vars:
-    user_message: |
-      Send the text "gg" into the "lobby" channel from a UI button, and
-      log every message received in that channel to the console.
-    reference_content: file://../references/text-chat.md
-  assert:
-    - type: icontains
-      value: "VivoxService.Instance.SendChannelTextMessageAsync"
-    - type: icontains
-      value: "VivoxService.Instance.ChannelMessageReceived"
-    - type: icontains
-      value: "VivoxMessage"
-    - type: llm-rubric
-      value: |
-        The response must call VivoxService.Instance.SendChannelTextMessageAsync
-        with channelName "lobby" and message "gg", AND subscribe to
-        VivoxService.Instance.ChannelMessageReceived with a handler that
-        takes a VivoxMessage and logs at least MessageText and
-        SenderDisplayName. It must NOT wire the send path to the
-        DirectedMessageReceived event.
-
-- description: "Send a directed (direct) message — must use SendDirectTextMessageAsync, not SendDirected..."
-  vars:
-    user_message: |
-      Whisper "meet me at the north gate" to the player whose PlayerId
-      is "abc123".
-    reference_content: file://../references/text-chat.md
-  assert:
-    - type: icontains
-      value: "VivoxService.Instance.SendDirectTextMessageAsync"
-    - type: llm-rubric
-      value: |
-        The response must call VivoxService.Instance.SendDirectTextMessageAsync
-        with playerId "abc123" and the exact message
-        "meet me at the north gate". The method name must be
-        SendDirectTextMessageAsync (with "Direct", no "ed" before "Text").
-        SendDirectedTextMessageAsync does not exist in the SDK and MUST
-        NOT be USED as callable code — but mentioning it in a "common
-        hallucination, don't use this" warning is fine and even helpful.
-        The response may also mention subscribing to the
-        DirectedMessageReceived event on the recipient side.
-
-- description: "Fetch the most recent channel chat history"
-  vars:
-    user_message: |
-      Fetch the last 25 messages from the "lobby" channel and print them
-      to the console in oldest-to-newest order.
-    reference_content: file://../references/text-chat.md
-  assert:
-    - type: icontains
-      value: "GetChannelTextMessageHistoryAsync"
-    - type: llm-rubric
-      value: |
-        The response must call
-        VivoxService.Instance.GetChannelTextMessageHistoryAsync with
-        channelName "lobby" and requestSize 25 (or equivalent). It must
-        note that the returned collection is newest-first and must
-        reverse the collection (or iterate in reverse) before printing to
-        achieve oldest-to-newest ordering. It should reference
-        VivoxMessage.SenderDisplayName and VivoxMessage.MessageText.

package/unity-skills/setup-vivox-voice-chat/evals/tests/voice-channels.yaml

@@ -1,74 +0,0 @@
-# ============================================================
-# WORKFLOW: Voice channels — group, positional, join lifecycle
-# ============================================================
-
-- description: "Join a lobby group channel with voice and text"
-  vars:
-    user_message: |
-      The player is logged into Vivox. Have them join a non-positional
-      channel called "lobby" with both voice and text enabled.
-    reference_content: file://../references/voice-channels.md
-  assert:
-    - type: icontains
-      value: "VivoxService.Instance.JoinGroupChannelAsync"
-    - type: icontains
-      value: "ChatCapability.TextAndAudio"
-    - type: not-icontains
-      value: "JoinPositionalChannelAsync"
-    - type: not-icontains
-      value: "IChannelSession"
-    - type: llm-rubric
-      value: |
-        The response must call VivoxService.Instance.JoinGroupChannelAsync
-        with the channel name "lobby" and ChatCapability.TextAndAudio. It
-        must NOT use the positional or echo join methods, and must not
-        use any v4 IChannelSession API.
-
-- description: "Join a 3D positional channel with Channel3DProperties"
-  vars:
-    user_message: |
-      Set up proximity voice: players near each other in the world should
-      hear each other, and voices fall off with distance. Name the
-      channel "world-proximity".
-    reference_content: file://../references/voice-channels.md
-  assert:
-    - type: icontains
-      value: "Channel3DProperties"
-    - type: icontains
-      value: "Set3DPosition"
-    - type: not-icontains
-      value: "JoinGroupChannelAsync"
-    - type: llm-rubric
-      value: |
-        This is a planning eval: judge the plan's correctness, not whether
-        it names APIs literally or includes runnable code. The plan must:
-        (a) identify positional (3D) channels as the mechanism — mentioning
-        "positional channel", "3D channel", or JoinPositionalChannelAsync
-        all count, since positional channels have exactly one join method;
-        (b) use the channel name "world-proximity";
-        (c) configure Channel3DProperties (naming at least the audible/
-        conversational distance concept, and ideally the fade model);
-        (d) state that each player's 3D position needs a per-frame update
-        via Set3DPosition (or an equivalent per-frame transform sync) so
-        distance attenuation actually works;
-        (e) make clear that awaiting the join call is not sufficient —
-        ChannelJoined must be subscribed to first for the join to be
-        observable.
-
-- description: "Subscribe to ChannelJoined BEFORE calling JoinGroupChannelAsync"
-  vars:
-    user_message: |
-      When I call JoinGroupChannelAsync my UI never activates for the
-      newly joined channel. What am I doing wrong?
-    reference_content: file://../references/voice-channels.md
-  assert:
-    - type: icontains
-      value: "ChannelJoined"
-    - type: llm-rubric
-      value: |
-        The response must diagnose the problem as the ChannelJoined event
-        being subscribed AFTER the join call, and instruct the user to
-        subscribe to VivoxService.Instance.ChannelJoined BEFORE calling
-        JoinGroupChannelAsync. It must clearly state that awaiting the
-        JoinGroupChannelAsync call does NOT mean the join is complete —
-        the join completes when the ChannelJoined event fires.