A's committed site schema (SPRINT10 world.js loadSite/createWorld) is
dress-source, and my loadSite assumed resolved positions. Run head-on against
A's real data/sites/backyard_01.json the tool reported:
✗ FAIL — no quad in the band shades the bed at all. The site cannot be rigged.
That is a lie, and the dangerous kind: the site is fine; the TOOL couldn't read
it. It is the SPRINT6 unwinnable-site trap in reverse — a false negative that,
in a "every site runs the audit before it ships" workflow, condemns a good site.
Two things make the schema unreadable headless, both real:
· posts are pre-rake. JSON carries {id,x,z,h}; world.js:361 leans each post 8°
off centre. p4's spec (-3.2,-1.2) dresses to (-3.72,-1.40) — the exact 0.56 m
error this tool's own snapshot shipped in SPRINT9. Reading x/z raw re-makes it.
· house/tree anchors have no coordinates — only `node`, a GLB empty's name.
Their position exists only after dress() reads matrixWorld, and dress() needs
GLTFLoader + fetch, neither of which runs in node. Branch anchors are exactly
where the dangerous quads live (t2b at 10 kN), so dropping them silently is
the worst possible failure.
The correct source of dressed positions is createWorld(site).anchors, which is
browser-only. That path lands once A's data-driven createWorld is in main; until
then loadSite REFUSES dress-source JSON with the reason and the plan, and exits 2
(distinct from the winnability FAIL's exit 1). The built-in DRESSED snapshot and
a resolved { anchors:[{id,type,pos}] } export both still audit. Raised to A in
THREADS: audit in-browser off createWorld(site).anchors, or export resolved anchors.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
d222a1e0dd