A one-command, no-API-key end-to-end gate for the Python<->Unity bridge,
runnable locally and in CI.
- tools/local_harness.py: boots a headless Hub-licensed Editor (or attaches
with --reuse) and runs smoke + EditMode + PlayMode legs over the bridge,
aggregating JUnit; exit codes 0-5 (pass / regression / unreachable /
no-compile / no-license / no-editor)
- Server/tests/e2e/bridge_smoke.py: deterministic no-LLM contract driver over
the real wire path; the no-LLM counterpart to claude-nl-suite.yml
- .github/workflows/e2e-bridge.yml: PR gate booting headless Unity in CI;
self-skips (warns) when Unity license secrets are absent
- .github/workflows/python-tests.yml: run the hermetic harness unit tests and
add tools/** to the path triggers
- tools/tests/test_local_harness.py: 69 hermetic unit tests for the harness's
Unity-free decision logic (discovery, version resolution, exit-code mapping)
- Document the harness in CLAUDE.md and the contributor docs
9 hand-written pages flagged NEW in the locked IA. All wired into
sidebars.js and verified by `npm run build`.
Getting Started:
- first-prompt.md: end-to-end "build a red cube" walkthrough with the
exact MCP tool chain the assistant should call, common failure modes,
and escalating prompts that exercise other groups.
- clients.md: capability matrix across all 12 supported MCP clients
(transport, auto-config, streaming, free tier, per-client toggles).
Guides:
- multi-instance.md: set_active_instance semantics — Name@hash, hash
prefix, port shorthand; HTTP vs stdio isolation; per-call unity_instance
routing for cross-project prompts.
- tool-groups.md: the 9 groups, how manage_tools(activate/deactivate/
list_groups/sync/reset) works, why per-session visibility exists
(prompt economy, routing clarity, package hygiene), server vs session
state reconciliation.
Architecture:
- transports.md: HTTP vs stdio decision matrix, the architecture of each,
what instance routing semantics each gives you, network security guards
(loopback by default, LAN/remote opt-in).
- python-layers.md: the three Python surfaces (MCP tools, CLI commands,
resources), why they're hand-maintained instead of auto-generated,
domain symmetry rule.
- unity-compat.md: the four active shims, when to add a new shim, what
doesn't belong in a shim, static-dispatch vs reflection patterns,
link to the canonical UnityCompatShims.cs marker class.
Contributing:
- testing.md: Python pytest, Unity EditMode/PlayMode, multi-version
compile matrix, pre-push/pre-commit hooks, stress scripts, CI surface.
- docs.md: hand-written vs auto-generated split, examples block
preservation rule, slug discipline (brand-neutral), redirect protocol
for slug renames, CommonMark vs MDX.
sidebars.js: uncommented the NEW entries; left reference/cli and
reference/manifest TODOs in place for a follow-up.
Verified:
- npm run build succeeds (Client 2.4s, Server 1.1s) with no errors
Shutong Wu