# M01-QAR-SERVER-SPAWN-RENDERER-001 — Golden server spawn renderer evidence ## Ownership - Target: M01 - Program: QAR/RND - Owner/Agent ID: sindo-main-codex - Branch: `work/sindo-main-codex/m01-server-spawn-renderer` - Lease expires UTC: 2026-07-15 - Integrator: M01 milestone integrator ## Outcome Route the pinned AzerothCore Human Warrior spawn fixture through `CoordinateMapper` into the live Eastern Kingdoms renderer and produce repeatable headless contract checks plus GUI screenshot evidence at the mapped ADT tile/chunk. ## Non-goals - Connecting to a live AzerothCore or TrinityCore database. - Claiming TrinityCore spawn equivalence without a pinned populated TDB row. - Changing coordinate formulas, streaming radii, terrain, player movement or production character presentation. - Adding proprietary assets or screenshots to Git. ## Paths - Exclusive: `src/tools/server_spawn_render_manifest.json`, `src/tools/verify_server_spawn_renderer.gd` - Shared/hotspots: `src/tools/capture_render_checkpoints.gd`, renderer runner, coordinate/world-renderer module documentation, `RENDER.md`, this claim - Generated/ignored: Godot UIDs/import metadata and `user://` PNG/JSON evidence ## Contracts and data - Fixture schema and coordinate contract version remain unchanged. - Additive diagnostic checkpoint metadata may request a renderer-native marker; existing M00 checkpoints remain byte-for-byte compatible. - The spawn remains sourced from pinned AzerothCore revision `68fcf0098b16388093989627f37be530fc91f07d`. ## Dependencies - Requires: merged M01 packages through `a07a487` - Blocks: M01 golden server-spawn renderer criterion and milestone closeout - External state: GUI capture requires the existing local extracted/cached renderer corpus; headless contract verification remains non-proprietary ## Verification - Commands: dedicated spawn verifier, coordinate fixture/mapper/boundary gates, renderer baseline dry-run, GUI checkpoint capture and human inspection - Fixture: AzerothCore race `1`, class `1`, map `0`, server position `(-8949.95, -132.493, 83.5312)` - Expected renderer result: Godot position `(17199.159666667, 83.5312, 26016.616666667)`, ADT `(32,48)`, MCNK `(3,12)` - Fidelity classification: server/coordinate integration evidence only; it does not establish full original-client visual parity ## Documentation deliverables - Inline API/tool documentation for new verifier and marker metadata - Coordinate-mapping module capability/evidence update - World-renderer checkpoint input/output/source-map update when marker support is added - Existing synchronous coordinate data-flow diagram updated only if flow changes ## Simplicity and naming - Important names: `server_spawn_render_manifest`, `verify_server_spawn_renderer`, `diagnostic_spawn_marker` - Simplest approach: reuse the existing checkpoint capture pipeline with one dedicated manifest and a renderer-native diagnostic marker - Rejected complexity: live DB adapter, new scene-test framework and production spawn entity implementation before the network/gameplay milestones - Performance: one diagnostic checkpoint outside production runtime ## Status - State: ready-for-review - Done: fixture-to-renderer manifest/verifier, renderer-native marker, unified baseline integration, cold/warm GUI evidence, documentation and log cleanup - Next: integrator review, merge cleanup/handoff and M01 closeout audit - Blocked by: ## Handoff - Commits: implementation `24ddc99`; required cleanup `318e6ae` - Branch: `work/sindo-main-codex/m01-server-spawn-renderer` - Outcome: the pinned AzerothCore Human Warrior start is routed through `CoordinateMapper` into the ordinary Eastern Kingdoms capture scene. A depth-tested magenta marker begins at the exact mapped spawn origin. - Contract/schema: additive diagnostic manifest schema 1 and marker metadata; coordinate contract version 2, production renderer APIs, cache formats and `Blizzlike335` behavior are unchanged. - Verification: `SERVER_SPAWN_RENDERER PASS spawn=1 checkpoint=1 tile=32_48 chunk=3_12 profile=Blizzlike335`; unified renderer dry-run passed project, materials, M2 dedupe, shutdown, `7/7/7` manifest, five-point calibration, coordinate-boundary and server-spawn steps; coordinate golden fixtures, mapper, StreamingFocus, domain identities, documentation and whitespace gates passed. Coordination passed with five expired M00-claim warnings only. - GUI evidence: two `1280x900` cold/warm PNGs captured under `user://server_spawn_renderer_m01_gui_run2`; focus tile `(32,48)`, terrain quality `100/100`, missing cache `0`, queues drained, report results `2`. Human inspection confirms the marker is on rendered terrain beside the road at Northshire Abbey rather than below terrain or in an adjacent tile. PNG hashes: cold `c08c43bcb75e5b3277105afb0d4e5a76caae9db91a7db64488770ffa03e32589`, warm `1b75237a090ea163836372a8e39e778c909773f4508063adc3f70a3e12a85a62`. - Fidelity: source remains AzerothCore revision `68fcf0098b16388093989627f37be530fc91f07d`; server `(-8949.95,-132.493,83.5312)` maps to Godot `(17199.159666667,83.5312,26016.616666667)`, ADT `(32,48)`, MCNK `(3,12)`. This proves coordinate/renderer integration, not original-client visual parity or TrinityCore populated-row equivalence. - Runtime notes: D3D12 descriptor-heap initialization fell back to Vulkan; optional ignored character/ambient GLB imports were unavailable. Neither affected terrain/marker evidence. The known anonymous ObjectDB teardown warning remained; no Node, renderer resource or RID leak diagnostic occurred in the cache-complete run. - Repository hygiene: four accidentally committed local GUI logs are removed by `318e6ae`; root `*.stdout.log`/`*.stderr.log` files are now ignored. Generated PNG/JSON evidence and proprietary corpus remain outside Git. - Remaining risks: the diagnostic marker is not a production network entity; live server adapters belong to M06/M08. Exact original-client character spawn presentation and TrinityCore database equivalence remain unverified. - Documentation: `RENDER.md`, renderer-baseline procedure, coordinate-mapping and world-renderer module API/input-output/data-flow/capability/source-map sections updated. No lifecycle/state diagram changed because the verifier and mapper path are synchronous; capture reuses the documented renderer lifecycle. - Recommended merge order: `318e6ae` after master merge `747fae8`. Then the M01 milestone integrator may accept all M01 claims, update target Evidence/checks and evaluate `OPENWC_TARGET_DONE`.