Premier commit du cinquième front. Trois parties : - `unity/MyInfoMateVR/` : le projet Unity (6000.0.83f1, URP, Meta XR SDK 205), un APK unique pour tous les clients. Menu flottant à sélection au regard, appairage, chargement de scène GLB, POI, cache de contenu, télémétrie. - `unity-overlay/` : les mêmes scripts à recopier sur un projet Unity neuf, avec les pièges rencontrés consignés dans son README. - `viewer/` : viewer et éditeur de scène web autonome (Vite, TypeScript, three.js), partagé avec les autres fronts. - `docs/` : état des lieux, setup Unity, décisions d'architecture et plan d'exécution en 9 étapes. La scène est décrite par un `scene.json` poussé par `adb push` : l'app le préfère à celui embarqué dans l'APK. Les binaires (GLB, textures de l'échantillon Sponza, DLL Meta XR) passent par Git LFS dès ce premier commit — les y faire entrer après coup demanderait de réécrire l'historique. Les artefacts régénérés par l'éditeur et par CMake (`Library/`, `.utmp/`, Burst debug) sont ignorés. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.0 KiB
3.0 KiB
name, description, allowed-tools, tags
| name | description | allowed-tools | tags | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| hz-meta-xr-operator-unity-test-mechanics | Runs AI-driven test attempts in Unity Meta Quest and Horizon OS projects using a bounded 3-attempt retry policy with an explicit understand → set up → execute → evaluate → report flow. |
|
|
Unity Test Mechanics
Test Unity game mechanics using Meta XR Operator and reach a clear pass/fail conclusion quickly without excessive iteration.
Retry Policy
Do NOT spend excessive time iterating on a behavior that may be broken. Your goal is to reach a clear conclusion quickly:
- Attempt 1: Follow the user's instructions directly.
- Attempt 2 (if needed): Adjust approach — different trigger method, timing, or parameters.
- Attempt 3 (absolute maximum): Meaningfully different strategy — isolate the mechanic, try alternative verification.
Stop early if an attempt reveals an obvious root cause (missing component, compilation error, null reference) - 3 tries is the maximum, not the requirement. The user needs a fast answer, not an exhaustive search.
Workflow
- Understand: Identify the behavior to test, expected outcome, and how to trigger it. Clarify with the user if needed.
- Set up: Verify preconditions (correct scene, editor state, required objects/scripts present). Capture baseline state (i.e. with a screenshot) if useful.
- Execute: Enter Unity play mode (if in editor), then trigger the necessary behavior and actions to test behaviors. Observe via screenshots, console output, object state (inspect GameObjects, components, transforms), and OpenXR tools (controller poses, inputs).
- Evaluate: Compare observed result to expected outcome. On pass, report with evidence. On fail, retry or conclude per the policy above.
- Report (pass or fail): What you tested, what you expected, what happened, any console errors, and your assessment of why (if failing).
Example
User: "Test if the player takes damage when touching the lava"
Attempt 1: Move player to lava, check health → unchanged. FAIL.
Attempt 2: Check console → "LavaDamage script missing collider". Lava has no Collider. Root cause found.
Conclusion: Lava damage broken — missing Collider (trigger) on lava GameObject, so OnTriggerEnter never fires.
Additional Rules
- Follow the user's instructions as closely as possible on the first attempt.
- Use the most direct verification method available.
- Check the console for errors after each attempt.
- Never fix issues without telling the user (unless they asked you to fix it).
- Do not make project changes during testing unless necessary for test setup.
- Each retry must use a different approach — never repeat the same method, and never exceed 3 total attempts.
- Report what you observe (not just pass/fail), and include evidence (screenshots, logs, object state) in your report.
- Load additional Meta XR Operator skills as needed for critical context on specific mechanics and features.