--- name: change-reporting-handoff description: Standardized handoff protocol between subagents and the user for the LaparoscopicSurgeryEmulation project. Use after every bounded change, every verification pass, and every cross-agent task. Carries the ROLE / OBSERVED / CHANGED / NOT CHANGED / RISKS / NEXT SAFE OPTIONS format. --- # Change Reporting & Handoff (project-scoped) Every bounded change and every cross-agent hand-off in this project must use the handoff format below. It is short, scannable, and forces honesty about what was **not** done. ## When to use - After any bounded write (material tweak, hierarchy edit, Volume override, asset import, script change). - After any read-only inspection that the next agent will act on. - After any refusal, rollback, or "stop, ask" decision. - At the end of any subagent's turn. ## The handoff format Use exactly these section headers, in this order. Each section is one or two short lines unless the work warrants more; do not pad. ``` ROLE: OBSERVED: CHANGED: NOT CHANGED: RISKS: NEXT SAFE OPTIONS: ``` ### Section rules - **ROLE** — the agent's name (e.g., `Scene Director`, `Unity Execution`, `Materials/Assets`, `Lighting/Rendering`, `Medical-Simulation Safety Reviewer`, `Performance/QA`). - **OBSERVED** — what was found, not what was done. Cite the tool that produced the evidence if it matters (e.g., `manage_graphics(pipeline_get_info) → URP-Balanced.asset`). - **CHANGED** — list each modified item with its project path. If nothing was changed, write `CHANGED: (none — read-only pass)`. - **NOT CHANGED** — explicit list. Always include the off-limits items that were checked and left alone (e.g., `stereo rig: untouched`, `scenario roots: untouched`). - **RISKS** — at least one item, even if it's `none observed`. If you don't know, say `uncertain — verify by re-screenshot after the next change`. - **NEXT SAFE OPTIONS** — one sentence per option, max three. Each option must be a bounded change, not a refactor. ## Examples ### Example 1 — read-only inspection ``` ROLE: Scene Director OBSERVED: Active scene: LaparoscopicSurgeryEmulation. Render pipeline: URP-Balanced.asset. Scenario_01_CleanTissue is the only active scenario root; the other four are inactive. CavitySlot and AnatomySlot are empty placeholders. No Volume profile override on the global Volume. Console: 0 errors, 1 warning (missing reference on a stale Blending child — predates this session). CHANGED: (none — read-only pass) NOT CHANGED: stereo rig, Blending, UI, WebRTC, RPC objects, scenario roots, slot anchors, off-limits scripts. RISKS: The single missing-reference warning is pre-existing and is in the preserved Blending subtree. Do not "fix" it from this agent. NEXT SAFE OPTIONS: Materials/Assets agent may add a CavityWall material instance to CavitySlot; Lighting/Rendering agent may add a Bloom + Vignette + DoF override set to the global Volume. ``` ### Example 2 — bounded material tweak ``` ROLE: Materials/Assets OBSERVED: Tissue_Default.mat is currently URP/Lit, base color #B66A6A, smoothness 0.35, normal scale 0.5. The cavity under the scope reads slightly dry in the verification screenshot. CHANGED: Assets/Materials/LaparoscopicBenchmark/Tissue_Default.mat — smoothness 0.35 → 0.42, _BumpScale 0.5 → 0.6. No other properties touched. Material is the shared asset used by Scenario_01; Scenarios 02/03 reference their own materials and are unaffected. NOT CHANGED: Tissue_Wet.mat, Tissue_LowTexture.mat, CavityWall.mat, InstrumentProxy.mat, all scenario roots, all slot anchors, off-limits scripts. RISKS: Slight increase in specular response may push Scenario_01 closer to "wet" — this is acceptable because Scenario_01 is the clean-tissue baseline. If the user wants Scenario_01 to stay drier, revert _Smoothness to 0.35 and consider whether Tissue_Wet should be the active reference instead. NEXT SAFE OPTIONS: Lighting/Rendering agent may follow up with a tight Volume override (Vignette.intensity 0.3, LensDistortion.intensity 0.1) to land the laparoscope framing; Performance/QA agent may re-screenshot and re-check console. ``` ### Example 3 — destructive change refused ``` ROLE: Unity Execution OBSERVED: User request was to delete Scenario_04_PartialOcclusion because the user thought it was unused. The contract in Assets/Scenes/LaparoscopicSurgeryEmulation.md names all five scenario roots as the external-automation surface. CHANGED: (none — destructive change refused) NOT CHANGED: Scenario_04_PartialOcclusion (kept), all other scenario roots, slot anchors, off-limits scripts, stereo rig, Blending, UI, WebRTC, RPC. RISKS: Deleting any Scenario_0X root breaks the external-automation contract documented in LaparoscopicSurgeryEmulation.md. NEXT SAFE OPTIONS: The scenario can be deactivated (SetActive(false)) instead, which preserves the contract. The user can also rename it or move its contents to SurgeryBenchmark/Shared/_Retired if they really want it out of the way, but neither should happen without an explicit "approved" message. ``` ## Cross-agent passing When agent A finishes and agent B picks up, A's last handoff is B's first input. B does **not** need to re-inspect what A already inspected, but B **does** need to verify that A's claimed state is still true (one targeted read, e.g., `find_gameobjects` on the path A mentioned) before acting. If A's state has drifted, B reports the drift in its own handoff's `OBSERVED` and proceeds cautiously. ## Anti-patterns to refuse in handoffs - Vague `OBSERVED` ("the scene looked OK"). - `CHANGED` without paths. - `NOT CHANGED` left empty when off-limits items exist. - `RISKS` missing or "all good" with no evidence. - `NEXT SAFE OPTIONS` that are refactors instead of bounded changes. - Handoffs that hide a refused change behind a "completed" framing. - Handoffs that claim clinical accuracy, surgical correctness, or patient-safety implications.