diff --git a/.skills/mcc-integration-testing/SKILL.md b/.skills/mcc-integration-testing/SKILL.md
index ac477c09..50673abb 100644
--- a/.skills/mcc-integration-testing/SKILL.md
+++ b/.skills/mcc-integration-testing/SKILL.md
@@ -1,13 +1,50 @@
 ---
 name: mcc-integration-testing
-description: Repeatable real-server integration testing for Minecraft Console Client against a local Minecraft Java server in offline mode or Microsoft online mode. Use this whenever the user wants to confirm nothing broke, validate runtime or protocol changes end-to-end, exercise movement, physics, inventory, entity handling, or run a single-version or cross-version MCC regression sweep on a real server.
+description: >-
+  Use when proving MCC behavior on a real local Minecraft server, validating
+  runtime or protocol changes end-to-end, exercising movement, physics,
+  inventory, entity, chat, or terrain behavior, or running a single-version or
+  cross-version regression sweep.
+metadata:
+  category: discipline
+  triggers:
+    - integration test
+    - real server
+    - local server
+    - regression sweep
+    - rcon
+    - tmux
+    - offline mode
+    - online mode
+    - movement
+    - physics
+    - inventory
+    - entity
+    - terrain
+    - chat
 ---
 
 # MCC Integration Testing
 
-Use this skill when the task is "prove it still works on a real server", not just "reason about whether it should work."
+Use this skill when the task is "prove it on a real server", not just "reason about whether it should work."
 
-Read [references/online-mode.md](references/online-mode.md) when the user asks for Microsoft login, device-code auth, or an online-mode server run.
+Read [references/online-mode.md](references/online-mode.md) when the user asks for Microsoft login, device-code auth, or an online-mode server run. Use [references/command-matrix.md](references/command-matrix.md) for stable MCC-side and RCON-side commands.
+
+## Iron Law
+
+Only say MCC was integration tested when MCC ran against a real local server and the claim is backed by real MCC output plus real server logs.
+
+Calling build-only, reasoning-only, or join-only work "integration tested" is a rules violation, not shorthand.
+
+These do not count as end-to-end proof:
+
+- static reasoning, source comparison, or build success
+- join or login success by itself
+- a long-lived idle connection by itself
+- a grep that only says there were no errors
+- testing one shared-route version and silently claiming adjacent versions also passed
+
+If the environment cannot run a real server, say so and report the result as unexecuted or inferred, not integration tested.
 
 ## Default target
 
@@ -17,6 +54,7 @@ Read [references/online-mode.md](references/online-mode.md) when the user asks f
 ## Guardrails
 
 - Use a real local server.
+- Launch MCC against an explicit `localhost:<server-port>` target for repeatable local tests.
 - Keep version matrices sequential in shared local environments. The tmux server harness is shared state by default.
 - Prefer temporary MCC configs for scripted runs so one test does not contaminate the next.
 - Default to offline auth in generated temp configs. Do not trust the repo-root `MinecraftClient.ini` account defaults.
@@ -26,7 +64,9 @@ Read [references/online-mode.md](references/online-mode.md) when the user asks f
 - For online-mode tests, prefer a clean temp config with no join-time bots or scheduled tasks. Inherited `ScriptScheduler` or `DiscordRpc` settings can pollute the session and send unintended chat right after login.
 - Legacy and modern command syntax differ. Do not assume one server-command profile fits every version.
 - Use actual MCC output and actual server logs for assertions. Do not invent success strings.
-- Launch MCC against an explicit `localhost:<server-port>` target for repeatable local tests.
+- Treat server `Done` as startup progress, not RCON readiness. Retry the first RCON command before assuming the setup is broken.
+- If a change touches shared routing or a version range, test at least one adjacent version that shares that path, or explicitly mark adjacent versions as unexecuted and inferred.
+- For palette or version-content changes, probe at least one neighboring or existing item, entity, or block. Do not only check the headline addition.
 
 ## Choose the test mode
 
@@ -54,6 +94,8 @@ Use this when the user asks for a regression sweep in a strict scenario order su
 - effects
 - inventory
 
+Broad validation should usually cover `connect-test`, `item-test`, `entity-test`, `terrain-test`, and `chat-test`.
+
 Command:
 
 ```bash
@@ -110,16 +152,46 @@ Optionally override the login name with the fourth argument to the config helper
 - `tools/run-creative-e2e.sh`
   - ordered creative-mode E2E regression scenario
 
+## Evidence Discipline
+
+In every report, separate:
+
+- `Executed`: exact scripts, commands, versions, auth mode, and whether the run was sequential or single-version
+- `Observed`: exact MCC output, exact server-log evidence, and the saved log directory
+- `Inferred`: conclusions not directly shown by that run's runtime evidence
+
+Never upgrade inferred claims to observed facts. Absence of errors is supporting evidence only; pair it with a positive assertion for the feature under test.
+
+## Red Flags
+
+Stop and fix the test plan if you are about to:
+
+- claim movement, inventory, entity, terrain, physics, or chat coverage from join success alone
+- reuse repo-root `MinecraftClient.ini` or another user-local stateful config
+- run multi-version tests in parallel in a shared tmux or shared server environment
+- let inherited bots, schedulers, or other user-local noise send chat or commands during validation
+
 ## What to report back
 
 Always summarize:
 
 - which version or versions were tested
-- which scenario was used
+- which port or ports were used
+- which auth mode and scenario were used
 - whether the run was sequential or single-version
+- the exact scripts or commands executed
 - pass or fail per major phase
 - concrete evidence from MCC and server logs
 - the saved log directory
+- what was not executed and what remains inferred
+- which adjacent versions were not run but were mentioned
+
+## When Not to Use
+
+- build-only verification
+- static protocol or source comparison with no real server run
+- documentation or prompt work
+- code review requests that do not ask for executed runtime proof
 
 ## Troubleshooting